Over the years, the terms Magic, Golden, Triangle, Augments, Directory, Domains and Active have given the administrators of Mac OS X environments fits. So when you think about using Active Directory to manage iOS devices through the Profile Manager service, built into Lion Server, you may think that it’s a complicated thing to piece together. You may remember those days when you had to manually craft service principals because xgrid wouldn’t play nice with Acive Directory, or you might think of twisting augmented records to support CalDAV. But you’re gonna’ have to forget all that, ’cause getting Profile Manager to talk to Active Directory is one of the easiest things you’ll do.
Before we get started, architecture. Every Profile Manager instance is an Open Directory Master. Apple has included a local group in Mac OS X Server called Profile Manager ACL. Users and groups from any directory domain that can be viewed in dscl can be added to this group. Adding objects to this group enables them to authenticate to the MyDevices portal but not administrate. Kerberos isn’t really used here, nor are nested groups. You’ll apply policies directly to Active Directory groups in Profile Manager. For many long-term Apple administrators, this paragraph is all you need to read. If not, please continue on.
To get started, first set Profile Manager up, as shown in a previous article I did. Once configured, verify that Open Directory or local clients can authenticate, bind to Active Directory.
Bind to Active Directory
From within System Preferences, click on the Users & Groups System Preference pane and click on Login Options. Then click on the Edit… button for the Network Account Server. From here, click on the plus sign (“+”) and enter the domain name into the Server field.
Once bound, you will see the server listed. At this point, if you try to authenticate to the MyDevices portal as an Active Directory user, you will be able to authenticate, but you will not have permission to enroll devices. To log in, access the web service at the address of the server followed by /MyDevices (e.g. https://mdm.pretendco.com/MyDevices).
Provide the user name and password to the service. The Active Directory users are unable to access the MyDevices service.
Nest Groups Using Workgroup Manager
Click on Logout and we’ll fix this. There is no further configuration required for the Active Directory groups to function properly in regards to how they work with the server. However, we will need to open Workgroup Manager and nest some groups. You might think that you’d be doing something all kinds of complicated, but notsomuch. You also might think that you would be nesting the Active Directory users and groups inside Open Directory groups, given that you have to enable Open Directory in order to use Profile Manager. Again, notsomuch. To nest the groups, browse to the local directory and then then click on the com.apple.access_devicemanagement group.
Click on the lock icon to unlock the directory domain, authenticating when prompted.
Click on the Members tab and then click on the plus sign (“+”) to add members to the group.
Then in the menu that slid out, click on the domain browser at the top of that menu and select the Active Directory entry.
Test Access
Drag the user or group from the menu into the list of members and then click on the Save button.
Now log in again using the MyDevices portal and you’ll be able to Enroll. From within Profile Manager (log in here as a local administrator), you’ll see all of the users and groups and be able to apply policies directly to them by clicking on the Edit button for each (the information isn’t saved in the directory service on the server, but is cached into the directory service client on the client when using Mac OS X 10.7, Lion based clients).
Moving Mac OS X Management From MCX
You keep hearing that you need to move some of your managed preferences to profiles (or Profile Manager in most cases), but you can’t really think about that until you get Profile Manager integrated with Active Directory, can you? And getting those pesky iOS devices working with Active Directory style policies has been on your radar, but really, who has time?
Profiles then have a few distinct benefits over Managed Preferences (MCX) for some, which we’ll look at through the lens of Profile Manager. The first is that they’re instant. You can make a change to a profile on a device enrolled in an MDM service and you instantly see the changes on the client (most profile settings that is, not all), rather than having to log the client out and then back in. You can also wipe and lock devices and the interface is easier (I mean, no nesting thankyouverymuch).
But there are a few drawbacks as well. You can’t cluster Profile Manager, so there are some benefits to using 3rd party services in a move to profile based management. You also manage settings using the Always option, rather than being able to use the Once or Often settings. You can use custom property lists, though and importantly, MCX is used to actually implement most of these profiles on client systems, so those skills you’ve been honing for managing Managed Client workflows will not be totally lost in the transition. Overall, I had initially thought that management by profile would be much less granular than management via managed preferences, but I’ve found ways around any issues and have found it’s actually much easier and works as reliably as dual directory or Active Directory based managed preferences worked.