Panther and Active Directory
Pages: 1, 2
Active Directory Plug-In: Architecture
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:
- AD GlobalCatalog Attribute List
- Mappings between Open Directory data types and specific LDAP attributes
- base64 encoded AD Computer Password
Active Directory Plug-In: Single Sign-on and Mac OS X Server
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:
- that the NT name for the AD in question is specified in the workgroup setting
- "use spnego" is changed from "no" to "yes"
- a "security = ads" flag is added
- a "realm" flag is specified. This is the kerberos realm associated with your Active Directory. More often than not, it will be the DNS name of your AD in all caps. For our sample domain, ads.ecample.com, the flag looks like this: "realm = ADS.EXAMPLE.COM"
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