Tiny Deathstars of Foulness

I covered managing devices based on policy in One of those policies is “modern authentication”, Azure Passthrough Authentication, or OAuth if you will. To enable it, log into Exchange Online via PowerShell and run the set-OrganizationConfig to set -OAuth2ClientProfileEnabled to True:

Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

If you’re using Skype, do an override:

Set-CsOAuthConfiguration -ClientAdalAuthOverride Allowed

Now check that OAuth was enabled properly:


And viola, you’ve caught up to where WordPress was at with OAuth 8 years ago! Next, check the global ADFS authentication rule:


And you can use Set-AdfsAdditionalAuthenticationRule. Now, you should be able to check the ADFS rules required for a given MFA requirement:

Get-AdfsRelyingPartyTrust –Name "Krypted"

And then if necessary, set them:

Set-AdfsRelyingPartyTrust –TargetRelyingParty Krypted –AdditionalAuthenticationRules ‘c: [Type == "", Value == "S-1-5-21-Insert your Group SID here"] && [Type == "", Value == "false"] => issue(Type = "", Value = "");’

You can then check groups:

GetADGroup -Identity "Krypted Users"

May 9th, 2017

Posted In: Microsoft Exchange Server, Network Infrastructure, Windows Server

Tags: , , , , ,

Profile Manager first appeared in OS X Lion Server as the Apple-provided tool for managing Apple devices, including Mobile Device Management (MDM) for iOS based devices as well as Profile management for OS X based computers, including MacBooks, MacBook Airs, Mac Minis, Mac Pros and iMacs running Mac OS X 10.7 and up. In OS X Mountain Lion, Apple added a number of new features to Profile Manager and revved the software to Profile Manager 2.0, most notably adding the ability to push certain types of apps to mobile devices. In Mavericks Server (Server 3), Apple provides new options and streamlined a bunch of things, most notably App Store and VPP integration. In subsequent releases (point releases) Apple also added DEP functionality and you can also now distribute content (in the form of books) to devices. In this article we’ll get Profile Manager setup and perform some basic tasks.

Preparing For Profile Manager

Before we get started, let’s prep the system for the service. This starts with configuring a static IP address and properly configuring a host name for the server. In this example, the hostname will be We’ll also be using a self-signed certificate, although it’s easy enough to generate a CSR and install it ahead of time. For the purposes of this example, we have installed Server from the App Store (and done nothing else with Server except open it the first time so it downloads all of its components from the web) and configured the static IP address using the Network System Preferences. Next, we’ll set the hostname using scutil.

sudo scutil --set HostName

Then the ComputerName:

sudo scutil --set ComputerName

And finally, the LocalHostName:

sudo scutil --set LocalHostName YosemiteSam

Now check changeip:

sudo changeip -checkhostname

The changeip command should output something similar to the following:

Primary address =
Current HostName =
DNS HostName =
The names match. There is nothing to change.
dirserv:success = "success"

f you don’t see the success and that the names match, you might have some DNS work to do next, according to whether you will be hosting DNS on this server as well. If you will be hosting your own DNS on the Profile Manager server, then the server’s DNS setting should be set to the IP address of the Server. To manage DNS, start the DNS service and configure as shown previously:


Provided your DNS is configured properly then changeip should work. If you’re hosting DNS on an Active Directory integrated DNS server or some other box then just make sure you have a forward and reverse record for the hostname/IP in question.

Profile Manager is built atop the web service, APNS and Open Directory. Next, click on the Web service and just hit start. While not required for Profile Manager to function, it can be helpful. We’re not going to configure anything else with this service in this article so as not to accidentally break Profile Manager. Do not click on anything while waiting for the service to start. While the indicator light can go away early, note that the Web service isn’t fully started until the path to the default websites is shown (the correct entry, as seen here, should be /Library/Server/Web/Data/Sites/Default) and a View Server Website link is shown at the bottom of the screen. If you touch anything too early then you’re gonna’ mess something up, so while I know it’s difficult to do so, be patient (honestly, it takes less than a minute, wait for it, wait for it, there!).


Once the Web service is started and good, click on the View Server Web Site link at the bottom and verify that the Welcome to OS X Server page loads.

Setting Up Profile Manager

Provided the Welcome to OS X Server page loads, click on the Profile Manager service. Here, click on the Configure button.


At the first screen of the Configure Device Management assistant, click on Next.


Assuming the computer is not yet an Open Directory master or Replica, and assuming you wish to setup a new Open Directory Master, click on Create a new Open Directory domain at the Configure Network Users and Groups screen.


Then click on Next. At the Directory Administrator screen, provide the username and password you’d like the Open Directory administrative account to have (note, this is going to be an Open Directory Master, so this example diradmin account will be used to authenticate to Workgroup Manager if we want to make changes to the Open Directory users, groups, computers or computer groups from there). Once you’re done entering the correct information, click Next.


At the Organization Information screen, enter your information (e.g. name of Organization and administrator’s email address). Keep in mind that this information will be in your certificate (and your CSR if you submit that for a non-self-signed certificate) that is used to protect both Profile Manager and Open Directory communications. Click Next.


At the Confirm Settings screen, make sure the information that will be used to configure Open Directory is setup correctly. Then click Set Up (as I’ve put a nifty red circle next to – although it probably doesn’t help you find it if it’s the only button, right?).


The Open Directory master is then created. At the Organization Information screen, enter the name of the contact information for an administrator and click on the Next button. Even if you’re tying this thing into something like Active Directory, this is going to be a necessary step (unless of course you’re already running Open Directory on the system). Once Open Directory is setup you will be prompted to provide the information for an SSL Certificate.

At the Organization Information screen, enter your information and click Next.


At the Configure an SSL Certificate screen, choose a certificate and click Next.


This can be the certificate provided when Open Directory is initially configured, which is self-signed, or you can select a certificate that you have installed using a CSR from a 3rd party provider. At this point, if you’re using a 3rd party Code Signing certificate you will want to have installed it as well. Choose a certificate from the Certificate: drop-down list and then click on Next.


If using a self-signed certificate you will be prompted that the certificate isn’t signed by a 3rd party. Click Next if this is satisfactory.

If you do not already have a push certificate installed for the system, you will then be prompted to enter the credentials for an Apple Push Notification Service (APNS) certificate. This can be any valid AppleID. It is best to use an institutional AppleID (e.g. rather than a private one (e.g. Once you have entered a valid AppleID username and password, click Next.

Provided everything is working, you’ll then be prompted that the system meets the Profile Manager requirements. Click on the Finish button to complete the assistant.

When the assistant closes, you will be back at the Profile Manager screen in the Server application. Here, check the box for Sign Configuration Profiles.


The Code Signing Certificate screen then appears. Here, choose the certificate from the Certificate field.


Unless you’re using a 3rd party certificate there should only be one certificate in the list. Choose it and then click on OK. If you are using a 3rd party certificate then you can import it here, using the Import… selection.


If you host all of your services on the one server (Mail, Calendars, VPN, etc) then leave the box checked for Include configuration for services; otherwise uncheck it.


One of the upgrades in Profile Manager 2.2 is the ability to distribute objects from the App Store Volume Purchase Program through Profile Manager. To use this option, first sign up on the VPP site. Once done, you will receive a token file. Using the token file, check the box for “Distribute apps and books from the Volume Purchase Program” and then use the Choose button to select the token file.

Now that everything you need is in place, click on the ON button to start the service and wait for it to finish starting (happens pretty quickly).


Once started, click on the Open Profile Manager link and the login page opens. Administrators can login to Profile Manager to setup profiles and manage devices.


The URL for this (for is Use the Everyone profile to automatically configure profiles for services installed on the server if you want them deployed to all users. Use custom created profiles for everything else. Also, under the Restrictions section for the everyone group, you can choose what to allow all users to do, or whether to restrict access to certain Profile Manager features to certain users. These include access to My Devices (where users enroll in the system), device lock (so users can lock their own devices if they loose them) and device wipe. You can also allow users to automatically enroll via DEP and Configurator using this screen.


Enrolling Into Profile Manager

To enroll devices for management, use the URL (replacing the hostname with your own). Click on the Profiles tab to bring up a list of profiles that can be installed manually.


From Profiles, click or tap the Enroll button. The profile is downloaded and when prompted to install the profile, click Continue.


Then click Install if installing using a certificate not already trusted.


Once enrolled, click on the Profile in the Profiles System Preference pane to see the settings being deployed.


You can then wipe or lock the device from the My Devices portal. Management profiles from the MDM server are then used. Devices can opt out from management at any time. If you’re looking for more information on moving Managed Preferences (MCX) from Open Directory to a profile-based policy management environment, review this article and note that there are new options in dscl for removing all managed preferences and working with profiles in Mavericks (10.9) and Yosemite (10.10).

If there are any problems when you’re first getting started, an option is always to run the script that resets the Profile Manager (aka, devicemgr) database. This can be done by running the following command:

sudo /Applications/

Automating Enrollment & Random Management Tips

The two profiles needed to setup a client on the server are accessible from the web interface of the Server app. Saving these two profiles to a Mac OS X computer then allows you to automatically enroll devices into Profile Manager using Apple Configurator, as shown in this previous article.
When setting up profiles, note that the username and other objects that are dynamically populated can be replaced through a form of variable expansion using payload variables in Profile Manager. For more on doing so, see this article.

Note: As the database hasn’t really changed, see this article for more information on backing up and reindexing the Profile Manager database.

Device Management

Once you’ve got devices enrolled, those devices can easily be managed from a central location. The first thing we’re going to do is force a passcode on a device. Click on Devices in the Profile Manager sidebar.


Click on a device in Profile Manager’s admin portal, located at https:///profilemanager (in this case Here, you can see:

  • General Information: the type of computer, capacity of the drive, version of OS X, build version, serial number of the system and the currently logged in user.
  • Details: UDID, Ethernet MAC, Wi-Fi MAC, Model, Last Checkin Time, Available disk space, whether Do Not Disturb is enabled and whether the Personal Hotspot is enabled.
  • Security information: If FileVault is enabled, whether a Personal Recovery is set and whether an Institutional Recovery Key has been installed.
  • Restrictions, whether any restrictions have been deployed to the device from Profile Manager.
  • Installed Apps: A list of all the apps installed (packages, App Store, Drivers, via MDM, etc).
  • In Device Groups: What groups are running on the system.
  • Certificates: A list of each certificate installed on the computer.


The device screen is where much of the management of each device is handled, such as machine-specific settings or using the cog-wheel icon, wiping, locking, etc. From the device (or user, group, user group or device group objects), click on the Settings tab and then click on the Edit button.


Here, you can configure a number of settings on devices. There are sections for iOS specific devices, OS X specific settings and those applicable to both platforms. Let’s configure a passcode requirement for an iPad.


Click on Passcode, then click on Configure.


At the Passcode settings, let’s check the box for Allow simple value and then set the Minimum Passcode Length to 4. I find that with iOS, 4 characters is usually enough as it’ll wipe far before someone can brute force that. Click OK to commit the changes.


Once configured, click Save. At the “Save Changes?” screen, click Save. The device then prompts you to set a passcode a few moments later. The next thing we’re going to do is push an app. To do so, first find an app in your library that you want to push out. Right-click (or control-click) on the app and click on Show in Finder. You can install an Enterprise App from your library or browse to it using the VPP program if the app is on the store. Before you start configuring apps, click on the Apps entry in the Profile Manager sidebar.


At the Apps screen, use the Enterprise App entry to select an app or use the Volume Purchase Program button to open the VPP and purchase an app. Then, from the https:///profilemanager portal, click on an object to manage (in this case it’s a group called Replicants) and at the bottom of the About screen, click Enable VPP Managed Distribution Services.


Click on the Apps tab.


From the Apps tab, click on the plus sign icon (“+”).


At the Add Apps screen, choose the app added earlier and then authenticate if needed, ultimately selecting the app. The app is then uploaded and displayed in the list. Click Add to add to the selected group. Then, click on Done. Then click on Save… and an App Installation dialog will appear on the iOS device you’re pushing the app to.

At the App Installation screen on the iPad, click on the Install button and the app will instantly be copied to the last screen of apps on the device. Tap on the app to open it and verify it works. Assuming it does open then it’s safe to assume that you’ve run the App Store app logged in as a user who happens to own the app. You can sign out of the App Store and the app will still open. However, you won’t be able to update the app as can be seen here.

Note: If you push an app to a device and the user taps on the app and the screen goes black then make sure the app is owned by the AppleID signed into the device. If it is, have the user open App Store and update any other app and see if the app then opens.

Finally, let’s wipe a device. From the Profile Manager web interface, click on a device and then from the cog wheel icon at the bottom of the screen, select wipe.

At the Wipe screen, click on the device and then click Wipe. When prompted, click on the Wipe button again, entering a passcode to be used to unlock the device if possible. The iPad then says Resetting iPad and just like that, the technical walkthrough is over.


Note: For fun, you can use the MyDevices portal to wipe your iPad from the iPad itself.


To quote Apple’s Profile Manager page:

Profile Manager simplifies deploying, configuring, and managing them all. It’s one place where you control everything: You can create profiles to set up user accounts for mail, calendar, contacts, and messages; configure system settings; enforce restrictions; set PIN and password policies; and more. Because it’s integrated with the Apple Push Notification service, Profile Manager can send out updated configurations over the air, automatically. And it includes web-based administration, so you can manage your server from any modern web browser. Profile Manager even gives users access to a self-service web portal where they can download and install new configuration profiles, as well as clear passcodes and remotely lock or wipe their Mac, iPhone, or iPad if it’s lost or stolen.

For the money, Profile Manager is an awesome tool. Apps such as Casper MDM, AirWatch, Zenprise, MaaS360, etc all have far more options, but aren’t as easy to install and nor do they come at such a low price point. Profile Manager is a great option if all of the tasks you need to perform are available within the tool. If not, then it’s worth a look, if only as a means to learn more about the third party tools you’ll ultimately end up using. One thing I can say for it is that Profile Manager is a little faster and seems much more stable (in fact, Apple has now published scalability numbers, which they have rarely done in the past). You can also implement newer features with it, including Books distribution, Gatekeeper, DEP and Messages.

October 16th, 2014

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , , , ,

One of the more common requests we get for iOS devices is to restrict what sites on the web that a device can access. This can be done in a number of ways. The best, in my experience, has been using a proxy.

In Apple Configurator 1.2 there’s an option for a Global HTTP Proxy for Supervised devices. This allows you to have a proxy for HTTP traffic that is persistent across apps.

Each Wi-Fi network that you push to devices also has the ability to have a proxy associated as well. This is supported by pretty much every MDM solution, with screens similar to the following, which is how you do it in Apple Configurator.

The above has I am all about layered defense, though. Or if a proxy is not an option then having an alternative. Another way to disable access to certain sites is to outright disable Safari and use another browser. This can be done with most MDM solutions as well as using a profile. To see what this would look like using Apple Configurator, see the below profile.

Now, once Safari has been disabled, you then need to provide a different browser. There are a number of third party browsers available on the App Store. Some provide enhanced features such as Flash integration while others remove features or restrict site access.

In this example we’re using the K9 Web Protection Browser. This browser is going to just block sites based on what the K9 folks deem appropriate. Other browsers of this type include X3watch, Mobicip (which can be centrally managed and has a ton of pretty awesome features), bSecure (which ties in with their online offerings for reporting, etc) and others.

While this type of thing isn’t likely to be implemented at a lot of companies, it is common in education environments and even on kiosk types of devices. There are a number of reasons I’m a strong proponent of a layered approach to policy management for iOS. By leveraging proxies, application restrictions, reporting and when possible Mobile Device Management, it becomes very possible to control the user experience to an iOS device in such a way that you can limit access to web sites matching a certain criteria.

October 19th, 2012

Posted In: iPhone

Tags: , , , , , , , , , , , , , , , , ,

One of my favorite tools for penetration testing is Nessus from Tenable Network Security. Nessus 5 is the latest release in the family of vulnerability scanners that is probably amongst the most prolific. Nessus 5 does discovery, configuration auditing, profiling, looks at patch management and performs vulnerability analysis on a variety of platforms. Nessus can also run on a Linux, Windows or Mac OS X and can be used to scan and keep track of vulnerabilities for practically any platform, including Mac OS X.

To install Nessus, go to the Nessus site and click on the Download button, around the middle of the page. Agree to the download agreement and then choose the version that is right for you (Mac OS X in this case).

Download Nessus for Mac OS X

Download Nessus for Mac OS X

The software will then download and need to be installed. Once downloaded, open the Nessus dmg and extract it. Inside will be the Nessus 5 package installer.

The Nessus Installer pkg

The Nessus Installer pkg

Open the installer and click through the defaults to perform a basic installation.

Installing Nessus

Installing Nessus

Once done, you’ll have the Nessus Server Manager and Nessus Client.url in a Nessus folder in the Applications directory.

The Nessus Applications

The Nessus Applications

Open the Nessus Server Manager and authenticate as an administrator when prompted. When you downloaded the software you would have been prompted for registration. Provide that information in the registration field. Then click on Update plugins to make sure all of the Nessus plugins are running the latest version. Finally, click on Manager Users… to create your users.

Nessus Server Configuration

Nessus Server Configuration

At the list of Nessus users, click on the plus sign and create a new user, likely making the user an admin (I see few vulnerability scanning stations that have non-administrative users, which would just be for viewing reports and the such). Click Save to create the user and then close at the List of users screen.

Create Nessus Users

Create Nessus Users

If the Nessus server isn’t started, click on Start Nessus Server. Then click on the Nessus Client.url file back where the Nessus Server manager was accessed. At the Nessus login screen, provide the username and password for the Nessus server that was previously created.

Authenticate to Nessus

Authenticate to Nessus

Once authenticated, you will be placed in the Scans screen. Before we configure any scans, we’re first going to create a Policy (which defines how a scan operates for the most part). To do so, click on Policies and then click on the Add button. There are four policy tabs (aligned on the left sidebar). In the General pane, you will configure the name for the Policy, “Mac Servers” in this example. Then we’re going to check the boxes in the Scan section for Designate Hosts by their DNS Name, Log Scan Details to Server, Stop Host Scan on Disconnect and Avoid Sequential Scans. Then check the boxes in the Port Scanners section for TCP, SYN, SNMP, Netstat SSH and Ping Host. Leave the Port Scan Range set to default and the Performance options at their default values as well. These are useful when you’re done tinkerating to get better performance out of the system, but we’re not really there just yet.

Nessus' General Policy Settings

Nessus' General Policy Settings

Click on the Next button to define any credentials you’ll use during scans. Initially, I’d leave this blank, although you can provide SMB information for up to 4 accounts to see what kind of access users have. You can also define Kerberos, SSH and various cleartext credentials as well. We’re going to skip that for now and click Next to define the Plugins.

Giving Nessus Credentials To Your Boxen

Giving Nessus Credentials To Your Boxen

At the Plugins screen, we’re initially going to leave all of the plugins on. The reason for this is that many of the Lion Server services are similar to those of the various Unix and Linux variants and we can scan SMB with the Windows plugins. These can’t hurt, they might just waste a little time though. Clicking on a Family and then a plugin will show you what each does. Clicking on the green light for each will disable it.

Choosing Nessus Plugins

Choosing Nessus Plugins

Click on Preferences and define any preferences that you need. Amongst the plugin preferences I usually enable network printer scanning, CGI scanning, Enable experimental scripts, set my Report verbosity to Verbose, provide any certificates needed and then hit Submit to create the new Policy.

Defining Nessus Options

Defining Nessus Options

Next, let’s click back on Scans in the navigation bar on the screen. As you can see here, I’ve created a few template scans, but we’re going to create a new one by clicking on the Add button.

Adding A Nessus Template

Adding A Nessus Template

Provide a name for the scan and then choose the Policy you just created. Set the Type to Run Now (since we’re just testing) and put the IP address of a target into the Scan Targets field. You can also import a large set of targets using the Brows button and a csv file or use Schedule or Template rather than Run Now in the Type field to schedule scans or create a template scan. Click Launch to kick off the first scan.

Running a Manual Test Scan

Running a Manual Test Scan

Once started, click on the Reports button in the top nav bar to see the status of the scan.

Completed Nessus Scan

Completed Nessus Scan

Once the scan is finished, click on the scan to see a list of vulnerabilities and open ports, sorted by the severity of issues. Here, double-click on the host.

Nessus Scan Results Overview

Nessus Scan Results Overview

The Report screen then shows each service and the vulnerabilities found for that service. Click on one of the vulnerabilities to see what Nessus thinks is problematic with it.

Nessus' Service List

Nessus' Service List

Now for the fun part. Each of the vulnerabilities listed will have CVEs attached.

Nessus Vulnerability Listing

Nessus Vulnerability Listing

By default, Nessus is just looking at the service banners to determine vulnerabilities. If you look up the CVE at CVE Details or PacketStorm you’ll see that it was patched a few months ago by most vendors. Now Nessus can get things wrong with Mac OS X. The issue is that Apple forks the code for many open source projects, not always updating version numbers on banners. Looking up or testing whether a vulnerability is still applicable can be tedious but would likely need to be done per service according to your internal security policies.

An easy way to test these vulnerabilities is to use Metasploit, a tool I’m long overdue to write an article on. Another way is to try and run the exploit against the host. Apple does a pretty good job of addressing CVEs in their security updates, so don’t waste a lot of time trying things if Apple has already patched them. I have found a really good tool for automatically attempting to exploit via msf + nessus to be Carlos Perez’ auto exploit tool, available on github.

Finally, Nessus is a great tool for scripting. One of the big differences that throws off many an experienced Nessus operator off with the version for the Mac is the location of the Nessus binaries. They are in /Library/Nessus/run/bin. In here you’ll find nasal, nessus, nessus-fetch, nessuscmd etc. The command line control here is pretty awesome. Let’s run nessuscmd to scan a net mask of hosts (

sudo /Library/Nessus/run/bin/nessuscmd

There are tons of other options for nessuscmd, such as adding ssh keys, smb logins, scanner options, using a remote nessus server, etc. Or use the nessus binary to kick off scans using a nessus config file. The nessus.conf file is also stored in the /Library/Nessus/run/etc/nessus directory, worth looking into.

February 23rd, 2012

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , , , , , , ,

The Login Window in OS X is the screen you see while you’re typing in a username and password. There are a number of customizations used in some environments to make the system easier for users to use, or to make it more specific to a given user environment. One such is customizing the Login Window’s background, which can be done by replacing this file with one that you would like to use:


You can also configure a message to be shown to users. This message, often referred to as an Acceptable Use Policy, can be used as a policy banner that users must accept in order to log into a computer. To set a policy banner, create a file called PolicyBanner.txt, PolicyBanner.rtf, or PolicyBanner.rtfd with the information you want displayed for end users. Save this file to /Library/Security. Then, the contents of the file will be used as a login banner users will be required to click on the Accept button in order to login.


You can also use Profile Manager and Managed Preferences to manage the items from the System Preferences pane and set a message at the LoginWindow as well. These are available under the Login Window section of Profile Manager.

Update: Those crazy kids at AFP548 have posted a video on YouTube with additional info on Profile Manager. That video can be found here.

Update2: For

August 6th, 2011

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , ,

You can set various policies for Microsoft Office.  When you install the Office Resource Kit (orktools.exe) you will be able to go into the Start->Programs->Microsoft Office Tools-> Microsoft Office Resource Kit -> System Policy Editor to do so. 

July 24th, 2008

Posted In: Windows XP

Tags: , , ,

Now if you’re looking to push policies out from a centralized directory service that is not Active Directory then you will have slightly more work to do.  You will be using the poledit.exe utility rather than gpedit.msc.  The poledit.exe tool is stored on a Windows 2000 Server CD.  If you install the Admin Tools using the driveletteri386adminpak.msi installer then you will be able to build a policy file in adm format that can then be distributed.  When you open the Poledit.exe application you will click on File-> New New Policy.  From here you will see Default User and Default computer (much as with it’s successor gpedit.msc). 

Options in poledit.exe for Computers include a variety of settings.  One of the more important here is the Local Computer->Network->System Policies Update->Remote Update which can be used to identify where the system will be getting policy updates and how they will be updated.  To set/create the policy file (Ntconfig.pol), first remove all #if version and #endif statements from the System.adm, Inetres.adm and conf.adm files on the local workstation in order to prevent the unintended loading of these files by the Poledit.exe tool.  This isn’t absolutely necessary. 

Next, save your policy settings as Ntconfig.pol. Save the file to the Netlogon share of the Windows NT 4.0 domain controller.  But, what if you do not have a Netlogon share or a replication service to replicate between shares.  Well, create the share by adding the following lines to your SMB config:


comment = Network Logon Service

path = /path/to/your/adm/files

guest ok = Yes

browseable = No

Obviously you will replace the /path/to/your/adm/files with the actual directory you will store the data on your server.  This directory needs to allow everyone read only access.  Copy the ntconfig.pol file into this directory and you will now be pushing the policy out to your users.

Options in poledit.exe for users include policies dealing with Control Panels (restrict access to display), Desktop (wallpaper and color scheme), Shell (Start Menu controls and Network Neighborhood controls), System (Run Dialog), Windows NT Network ($ hidden shares), Windows NT Printers (beeps and priorities), Windows NT Remote Access (dialup networking), etc.

Finer Grained controls in Policy Editor

If you are building your policies from a system that has been bound into Open Directory then you can use the Add Groups option and then browse to the group you would like to build policies for.  This allows you to have one overarching policy hosted in the netlogon share. 

Another way to access obtain more finely grained access to policies is to deploy settings using the login scripts.  You can build multiple policy files and deploy them or deploy actual registry edits using login scripts.  

July 19th, 2008

Posted In: Mac OS X Server

Tags: ,

Ever wonder what the process is that manages Bluetooth on your machine? Well, it’s blued.  Now, I’ve had the occasion where I wanted to outright disable blued, so I’ve actually renamed it or removed it from my system image. But what if you want to set any preferences for Bluetooth? Well, those are stored in the*.plist file. The * here is due to the fact that it’s based on your machine, thus a ByHost Preference. The location is /var/root/Library/Preferences/ByHost. So if you take that preference file and copy it to another machine it won’t actually work. The other machine will create another as it has a different machine address. So, to configure it you would essentially need to implement login hooks (older revisions you could replace the machine address with an *, which is why I used that here). For more information on login hooks, check out this site (no reason for me to reinvent the wheel here):

July 16th, 2008

Posted In: Mac OS X, Mac OS X Server

Tags: , , ,

The open and save dialogs can automatically have the expanded view opened by default rather than having you need to open it manually each time you go to open or save a file. To enable this setting, use the following command:
defaults write -g NSNavPanelExpandedStateForSaveMode -bool TRUE

May 16th, 2008

Posted In: Mac OS X

Tags: , , , ,