I got stupid again this week and decided to investigate management of Mac computers. Since we are both cheap and overworked, I wanted a solution that would be both free, and would not require any new infrastructure. The only options that came to mind were either to extend our OpenLDAP server to support apple schema, or to extend Active Directory. Since I am the “Windows Guy”, and since use of AD also brings benefits such as Kerberized login to file servers, support for NTLM auth, and support for File Sync, I went with the AD option.
Not fun, very messy, but it works. Here are the gotchas:
- Use the Lion Active Directory integration guide or later. Earlier guides might lead you to create a schema extension file that will, in turn, create invalid classes in your AD schema. The new guide works well.
- If your computer was bound to AD before the schema update, you likely will need to unbind/rebind before you will be able to take advantage of MCX settings in AD. The reason is that your apple hardware uuid and macAddress are not populated as part of your AD computer object until after the schema extension is done. Apple says you only need to restart the OpenDirectory daemon (“killall opendirectoryd” as root) to get the attributes populated, but I do not think this is accurate.
- If your domain/forest is at the 2008 or 2008 R2 level, you will need to run “dsconfigad -alldomains disable” after domain bind, or you will not be able to find apple computer-list objects in the domain. After running this command, you have to specify the AD domains to search using Directory Utility, or by running the following commands as root:
dscl lolcalhost -delete /Search CSPSearchPath “/Active Directory/CAMPUS/All Domains”
dscl localhost -append /Search CSPSearchPath “/Active Directory/CAMPUS/campus.ad.uvm.edu”
- The Lion+ AD plugin will look in computer objects in only one place in your domain… “CN=Mac OS X”. If you want to manage macs using computer lists you must create a “container” object (not an Org Unit) with this name in the root of your domain, and create your apple-computer-list objects there. You will need to use ADSI Edit to create the container and apple-computer-list objects, as ADUC does not allow for creation of these object types.
There is a lot more to learn here. One thing I am curious about is how we might be able to safely delegate Mac computer management, given that someone with control over a user group or computer group can add any user or computer to that group, and thus can impose settings on users and computers arbitrarily. One option might be to disable or constrain access to the apple extensions to the user and group objects, so that only select and highly trusted individuals can control user MCX settings. For computer-list objects, we might not be able to delegate management of the members attribute of the computer list object, but instead only delegate management of the MCX settings. Messy.
I also am curious to know how MCX settings are applied when multiple MCX settings are used on users, groups, computers, and computer-lists. Which policy takes priority? How is merging accomplished?
Ultimately, it is nice to know that Apple has provided a functional solution for Mac management in an AD domain. It may not be perfect, but it is a start. Perhaps when combined with “Munki”, or another Apple Software Update clone, we will really have something solid for Enterprise Management of the Mac.