Editor's note -- This is an update (April 2004) to the original article that Michael Bartosh published on Dec. 9, 2003.
Mac OS X 10.3 Panther- in both its client and server personalities- brings signifigant progress to Apple's place in Windows-centric organizations. Unlike the LDAPv3-based Jaguar strategies we examined in my earlier articles, Panther's capabilities have been specifically engineered by Apple to work in much the same way that a Windows client would when joining and participating in an Active Directory. This allows us to spend much less time on the basics of directory integration, and a lot more time on more advanced scenarios and deeper integration techniques.
However- it should be noted that Panther is in general a very different animal from Jaguar. Support infrastructures are expensive to build and maintain- updating those infrastructures for a new major OS revision shouldn't be undertaken hastily. This is especially the case for Panther's Active Directory Plug-in, which has never before seen widespread deployment. A better understanding of this phenominon can be seen by examining Apple's LDAPv3 Plug-In- Jaguar's primary method for interaction with Active Directory. Throughout the 10.2 development cycle it made tremendous gains not only in stability and robustness, but also in its feature set. As more and more Apple customers test and deploy the Active Directory Plug-In, it will likely follow a similar path.
In order to understand Mac OS X's place in an enterprise directory, we first need to understand its capabilities, processes and configuration. Apple's Directory Services Architecture is known as Open Directory. You can think of Open Directory as Mac OS X's Rosetta Stone- Open Directory knows how to talk to directories so that specific Mac OS X applications (like Apache or loginwindow) do not have to. In a very general sense, the process looks something like this:
Fig 1.1 Open Directory
One of the primary features of Open Directory is its extensibility. Its modular, plug-in based architecture allows Open Directory client applications to access new directories without being updated. The applications continue to dispatch their lookups to Open Directory. Open Directory itself manages interaction with the new plug-in, and hence the new directory itself.
For more information on the Open Directory architecture, see part 1 of my previous Active Directory Article.
Chief among the Active Directory Plug-In's features is its architectural direction. It is designed to work much (if not exactly) like a Windows client. This minimizes tremendously the negative impact that Mac OS X could have on existing infrastructures- we no longer have to talk about access methods, schema extension or SSL. Instead, the AD Plug-In makes a kerberized ldap connection to the nearest domain controller- just like a Windows client. Users are also authenticated via kerberos- just like a Windows client. Macs have a computer account in the AD- just like Windows clients. The trend should be obvious. Because the AD Plug-In does most things in a manner very similar to a Windows client, it allows IT staff to focus on building added value into their infrastructures, rather than changing their entire infrastructure to achieve some basic level of functionality with their Mac hosts. This is nothing short of a ground breaking development in Mac OS X's adoption into big IT.
The log-in process is actually quite simple. The user presents their username (which can be in several forms)
...and password, which is verified using kerberos. If log in is successful, the user is given a local home directory in the /Users directory and a fairly complete user experience.
More specifically, the Plug-In's features (some of which are promoted by Apple and some of which aren't) include:
There are only a few caveats. Specifically, unlike Windows clients, which can fall back to WINS name resolution, Apple's AD Plug-In requires a reverse DNS entry for domain controllers for the domain in question. This detail is ofent overlooked in Active Directory deployments. While this can be an annoyance, though, it is in keeping with Microsoft's recommendations. Additionally, the Plug-in keeps a group membership cache- ADGroupCache.plist- in the /Library/Preferences/DirectoryService directory. In complex Active Directory deployments, this file can take up to 36 hours to build.
The primary configuration interface for Panther's AD Plug-in is its configuration dialog in the Directory Access application.
It can be accessed (provided the user has authenticated as a member of the client's admin group) by selecting "Active Directory" from Directory Access's Services pane and clicking the "Configure..." button:
The Plug-in's initial configuration is actually pretty simple- the forrest and domain DNS names are entered into their respective fields, along with a name for the machine account that is going to be created for the Mac. When the "Bind" button is pressed, you're prompted for domain credentials, along with an organizational unit (ou) or container where the account should be created:
This process does not require domain administrative credentials- instead, its available to any user who has been delegated the "Create/Delete Computer Objects" right for the organizational unit or container in question. This is actually a very common delegation, and isn't something most domain administrators will be concerned about. At the very least, it is feasible to create a Mac-specific ou, and delegate creation (and, feasibly, little ealse) to Mac-specific personnell.
At a more detailed level, however, the "Show Advanced Options" disclosure grants access to some of the Plug-in's other features, most of which were covered previously.
Another particularly interesting Panther feature is the dsconfigad command-line utility- which can access all of the same configuration data as the Plug-in configuration dialog. Its basic usage looks like this:
dsconfigad -a clientname -u username -p password -ou "distinguished name of ou or container" -forrest fqdnofforrest -domain fqdnofdomain
So a sample run from a simple domain might look like:
dsconfigad -a ibook00 -u macadmin -p nA90i2m -ou "ou=macs, dc=example,dc=com" -forrest example.com -domain example.com
The downside is the necessity of embedding the password in the command's flags- but it is feasible in the case of large labs or installations to temporarily create an account capable of adding computer accounts to some portion of the domain and then to run dsconfigad in a scripted, automated fashion. The temporary account should then either be deleted of have its password changed. This is an important option for organizations that manage a medium to large number of machines.
Regardless of the configuration method, the data is written to the plug-in's configuration file, which exists at /Library/Preferences/DirectoryService/ActiveDirectory.plist (in the same directory as ADGroupCache.plist mentioned earlier). In addition to the settings specified in the Plug-in's graphical interface (user caching, Domain Admin groups, etc) there are several important and useful aspects of this file:
Supposing Windows Services are otherwise configured properly, a configured Active Directory Plug-in will allow AD users to log in via most services that Mac OS X offers. The Active Directory Plug-in for all intents and purposes proxies the credentials presented at file service log-in, authenticating the user via NTLMv1 (or, if NTLMv1 is disabled, via NTLMv2) via winbind's ntlm_auth tool. While this effectively allows access to Mac OS X resources based on AD credentials, it does not provide a single sign-on experience- something that has long been expected in Windows-based infrastructures. In order to preserve this user experience, Mac OS X can be configured to honor kerberos authentication principals from the Active Directory KDC.
Mac OS X Server can accept kerberos authentication for a variety of services- FTP, ssh, AFP and SMB. For the purposes of this article we'll be focusing on SMB and AFP- although AFPdoesn't seem to work as of 10.3.1. More than anyhting this is an effort to keep the article to a managable, digestible length. Similarly, since this deals heavily with Kerberos, it would make sense to start with a basic discussion of that protocol. Unfortunatly this, even at a basic level, would be a lengthy discussion, so we'll forgo it. For a good basic description of kerberos see this site. For more in-depth coverage, O'Reilly's <blah> is a good choice.
We'll start with Windows File Services- which, in Mac OS X, are implemented by the open source Samba package. Samba has been modified in Mac OS X to work with Password Server- Apple's service for legacy (rather than kerberos) authentication methods. In the case of Active Directory integration, though, we don't want to use Password Server. Instead we'll make use of one of Samba 3.0's new features- the ability to be a member server in an Active Directory domain. Previous to 10.3.3, this process was somewhat more onerous. This article has been updated to reflect 10.3.3's newer, easier method.
1) Join Active Directory using the AD Plug-in.
2) Edit the /etc/smb.conf file, ensuring:
The resulting entries should look something like this:
security = ads use spnego = yes realm = ADS.EXAMPLE.COM workgroup = ADS
Editing smb.conf in Jaguar was tricky- the sambadmind daemon would re-write it whenever Windows Services were re-started, sometimes (but not always) disgarding most manual changes. The bad news is that smb.conf is still re-written on a regular basis, making it very difficult to keep your edits organized. The good news is that manual changes are now preserved without any of the headache involved seen in Jaguar (they're just moved around in the file, makintg them quite a headache to locate sometimes).
Finally, enable Windows Services using the Server Admin application or its command-line equivelent, serveradmin. Clients- both Mac OS X and Windows- who are logged in to the Active Directory should now be able access your server via SMB without re-authenticating. In our example, the user Sam Adams has logged into a Mac OS X client with his Active Directory account. Notice (either using the klist command or the Kerberos application in /System/Library/CoreServices) that he now has a TGT:
Browsing for file services is still a bit raw in Panther, so we'll connect to our smb server by specifying its address:
The user is not prompted to authenticate- instead a share is simply chosen:
...We now see a new service ticket in the Kerberos application or klist's output:
...and a new volume mounted on the user's desktop:
The Windows user experience is very similar, and in fact is identical the the experience of logging into any other member server in the domain.
This is a tremendously powerful capability, because it means that a Mac OS X Server- a commercial product from a traditional OS vendor- can seamlessly replace a windows file server, without sacrificing user experience (single sign-in) or password security (kerberos). Added to this is the inherent security advantage of running a non-Windows server (the next Blaster won't phase Mac OS X) and that's a valuable proposition in the IT space.
Apple File Services:
It should follow that native Mac file services- AFP, Apple's long-time standard filing protocol- should support similar user experience features. Unlike Samba package, though, the two weren't specifically designed to work with one another, and right now getting kerberized AFP to work is a little tricky. Given the resources, I will document it. My hope, though, is that Apple will make this an automatic part of the Join process for Mac OS X Server.
Panther ushers in a new, more dynamic era of directory integration in Mac OS X. From the client side, this means that Mac OS X becomes even more viable in the Media, Scientific and Administrative desktop enviorments where its currently meeting with great reviews. From a server side perspective, it means that te XServe and XServe RAID can really begin to make inroads into the cross platform workgroup enviornments where Windows has been so dominant in the past 10 years.In either case this signals a remakable opportunity for Apple, and something implementors have been working towards for a long time.
Return to the Mac DevCenter
Copyright © 2009 O'Reilly Media, Inc.