Volume Number: 20 (2004)
Issue Number: 11
Column Tag: Programming
by Michael Bartosh
Many in the Mac IT community will recall the Windows NT revolution and its impact on Apple's place in the market. Microsoft began heavily promoting NT, selling its centralized management capabilities (which appealed to the rapidly professionalizing field of desktop IT management) as well as Apple's seemingly delayed reaction. You could make a case that Apple's strategy in this area was unsuccessful and may have had some degree of negative impact on its overall market share. In 1993 when Windows NT 3 was introduced Apple enjoyed a nearly 10% market share. By 1997, 1 year after NT4's introduction, Apple's market share had declined to around 4.4 %, and Microsoft had made great inroads, particularly in the server space, into some of Apple's core markets. Rather than embracing and fitting into the infrastructures that its customers had chosen, Apple continued to employee strategies that have not been proven successful in the enterprise marketplace.
In 2003, Active Directory (Microsoft's Directory Services product) was in much the same position that Windows NT was in the late 1990's. In its second revision (as a part of the Windows 2003 server product; the first was included with Windows 2000) Active Directory had achieved a deep level of penetration into several of Apple's core markets. Once again, Apple had a decision to make-- embrace the idea of heterogeneous multi-vendor networks driven by ad-hoc market standards, or retreat to its less successful roots. Luckily in 10.3 Apple seems to have at least tentatively chosen the former path, engineering into the Mac OS X specific capabilities for integration with Active Directory. This is a new and bold step forward for Apple, and something that goes a long way towards bring legitimacy to Apple in enterprise and institutional markets.
Active Directory Integration is nothing new to Mac OS X-- previous to Panther a certain level of interoperability was feasible. Feasible, however implies neither secure nor straightforward, to say nothing of the simplicity Mac users are accustomed to. The problem with pre-10.3 configurations is that they were tedious, complex, and relatively insecure. There was no standardized or consistent integration procedure, and the result was typically a mess of hacks, work-arounds and duct tape. Additionally, really complete solutions tended towards intrusiveness, often requiring extensive changes to the Active Directory.
Panther's Active Directory Plug-in provides a simpler and more full-featured platform for directory services configuration. It supports a number of line-item features (which I'll cover) but its single most important feature is not a line item at all, but a basic architectural principal. It seeks to emulate a Windows client as much as possible. Its communication with the Windows domain is nearly indistinguishable from its Microsoft-bred counterparts. Its goal is to integrate as seamlessly as feasible into the infrastructure that many of Apple's customers have chosen, requiring no infrastructure changes and little massaging or special treatment. Beyond that strategic goal, its specific features are many.
The Active Directory Plug-in, like most other end-user configurable Open Directory Plug-in's, is configured using the Directory Access application, which is located in an out of box Mac OS X install in /Applications/Utilities. Configuring Active Directory integration is as simple as starting Directory Access, choosing its Active Directory Plug-in, and clicking on the configure button, as seen in Figure 1.
Figure 1. The Directory
Access application.
Configuring the Active Directory Plug-in results in the dialog seen in Figure 2. It is, in its basic form, extremely straightforward, prompting for a domain and forest to join, along with an ID for the computer. In the case of Mac OS X clients this computer ID should reflect local naming conventions and policies (machines are often named sequentially, or based on their user or physical location). Servers joining Active Directory should use the unqualified portion of their hostname. Homes.pantherserver.org, for instance, would have a computer ID of homes (this allows for easier single-sign on interoperability between the server an the Active Directory Kerberos environment).
Figure 2. The Active
Directory Plug-in's basic configuration dialog.
Optionally, clicking on the Show Advanced Options triangle reveals the interface pictured in Figure 3. This is where most (but not all) of the features listed earlier in this article are implemented.
Figure 3. The Active
Directory Plug-in's advanced configuration dialog.
Options from this interface (along with other interesting bits of data) are stored in the Active Directory Plug-in's configuration file (/Library/Preferences/DirectoryService/ActiveDirectory.plist) which is discussed in more depth later in this article.
When the desired options have been specified, you may select the Bind button. This results in an authentication dialog, pictured in Figure 4. This dialog accepts a container or organizational unit in Active Directory along with credentials required to add a computer account to it. This is an important concept-- the graphical interface erroneously implies that Domain Administrator credentials are required to add the Mac to the Active Directory Domain. In reality, all you need to supply are the credentials of a user able to add computer accounts to the specified container or ou. As mentioned earlier this is a commonly delegated task, often left to users or low-level IT staff.
Figure 4. Joining Active
Directory requires that the specified credentials be able to add computer accounts to the indicated
organizational unit or container.
Other than a thorough understanding of Active Directory, Open Directory, and directory services in general the two most important tools for troubleshooting Active Directory integration issues are network sniffers (like tcpdump and ethereal) and the Directory Service daemon's debug mode.
tcpdump is installed on Mac OS X (and most other Unix operating systems) so I most commonly use it to initially gather data, later examining that data using a graphical tool like ethereal. Kerberos data in particular looks largely like a bunch of hex over the wire, and ethereal can be a great help translating this data into something that's human readable.
big15:~ mab$ sudo tcpdump -w join.dump -i en1 port domain or port 3268 or port kerberos or port kpasswd or port ldap
The work of the Active Directory plug-in is actually executed by the DirectoryService daemon, which produces very good logging data, particularly in the case of Active Directory interoperability. To turn debug logging in, you need to send the USR1 signal to the DirectoryService process. This begins logging to /Library/Logs/DirectoryService.debug.log. Active directory messages are prepended with the string ADPlugin:, so the log itself (which is very verbose) is easy to filter.
xsg5:~ tadmin$ sudo killall -USR1 DirectoryService
xsg5:~ tadmin$ tail -f /Library/Logs/DirectoryService/
DirectoryService.debug.log | grep ADPlugin
2004-10-14 01:38:17 PDT - ADPlugin: Calling CustomCall
2004-10-14 01:38:17 PDT - ADPlugin: Doing CheckServerRecords......
2004-10-14 01:38:17 PDT - ADPlugin: Good credentials for joiner@ADS.4AM-MEDIA.COM
2004-10-14 01:38:17 PDT - ADPlugin: No connection in connection mgr for joiner@
ADS.4AM-MEDIA.COM@ads.4am-media.com:389
2004-10-14 01:38:18 PDT - ADPlugin: Secure BIND Session with server
w2k.ads.4am-media.com:389
2004-10-14 01:38:18 PDT - ADPlugin: Processing Site Search with found IP
2004-10-14 01:38:19 PDT - ADPlugin: Added connection to connection mgr
joiner@ADS.4AM-MEDIA.COM@ads.4am-media.com:389
2004-10-14 01:38:19 PDT - ADPlugin: Found Default Domain ads.4am-media.com
Turning on debug logging in the DirectoryService daemon. The debug log is easy to filter with grep.
DirectoryService debug logging remains enabled until the daemon is re-started or until it receives another USR1 signal. Sending a USR2 signal enables API logging, which logs every Open Directory API call to the system log (/var/log/system.log). USR2 logging is heavy-weight, and will automatically turn off after 5 minutes.
In its default configuration, users from Active Directory are allowed to log in to Mac OS X using several forms of their user name (in order to be as compatible as feasible with the Windows user experience.) John Doe for, for instance might be able to log in as jdoe, John Doe, jdoe@ads.pantherserver.org or ADS\jdoe. The user is given a local home location in the /Users directory and a Kerberos TGT (ticket granting ticket) is obtained on log-in. This means that users can access most domain resources-- from kerberized file servers to Outlook Web Access (using Safari) without re-authenticating. In the client flavor of Mac OS X (Mac OS X Server's behavior differs) the user's SMB home directory (if it is listed in their user record) is placed in their dock and automatically mounted using NTLMv1 authentication (the TGT is not obtained early enough to mount it using Kerberos, which is far more secure).
Some of the Active Directory Plug-in's most significant features are not available in its graphical interface. Most of these are available through the dsconfigad command, the AD Plug-in's command-line configuration interface. The Active Directory homeDirectory UNC, for instance, can be used as the Mac OS X home directory (rather than being mounted on the desktop) using the dsconfigad command's -localhome flag.
djou:~ djou$ dsconfigad -localhome disable djou's Password: Settings changed successfully djou:~ djou$ dsconfigad -show You are bound to Active Directory: Active Directory Forest = ads.4am-media.com Active Directory Domain = ads.4am-media.com Computer Account = m-h02 Advanced Options Mount Style = smb:
Using dsconfigad, first to turn off the the default local home behavior, then to examine the Plug-In's configuration. When -localhome is disabled, user home directories are mounted late enough to support Kerberos authentication.
This disabled localhome behavior has two variants, controlled by the mountstyle flag. A mountstyle of SMB (the default configuration) interprets the UNC as an SMB URL plist, allowing Mac OS X to use it as an SMB home directory.
djou:~ djou$ dscl /Active\ Directory/ads.4am-media.com -read
/Users/winnie homeDirectory HomeDirectory
homeDirectory: \\w2k\homes\winnie
HomeDirectory: <home_dir><url>smb://w2k.ads.4am-media.com/
homes</url><path>winnie/</path></home_dir>
Coupled with the AD Plug-in's -localhome disable option, the SMB mount style interprites the Active Directory homeDirectory UNC as a Mac OS X HomeDirectory (a URL plist). Notice the case sensitivity here-- the Active Directory attribute is called homeDirectory. It is used to produce the Mac OS X HomeDirectory.
Conversely a mountstyle of AFP interprets the UNC as an AFP URL. In general, AFP offers a better home directory experience than SMB, so this option has potential to improve the overall effectiveness of your infrastructure. In the vast majority of cases this is less than useful, though, since Microsoft's AFP Server is specifically not up to the task of supporting Mac OS X home directories. This setting becomes advantageous in two cases: when the home directory server is running the newest version of ExtremeZ IP (which features an AFP implementation that is far more capable than Microsoft's) or when the home directories are housed on Mac OS X Server. The latter case is a new and powerful option, implying that Windows clients will mount the same (Mac OS X-hosted) home directory using SMB that Mac OS X clients mount using AFP. The homeDirectory UNC in the AD User record in this case actually specifies a share on Mac OS X Server. This allows you to leverage Apple's compelling and relatively affordable server solutions, even in a Windows-centric infrastructure. That this is feasible is a testament to the deep level of integration that Mac OS X Server is capable of. The only real down side is that in Panther this does limit administrators Unix user-group-other permissions, rather than the deep set of access controls provided by the Windows platform.
djou:~ djou$ dsconfigad -mountstyle afp
djou's Password:
Settings changed successfully
djou:~ djou$ dscl /Active\ Directory/ads.4am-media.com -read /Users/winnie HomeDirectory
HomeDirectory: <home_dir><url>afp:// w2k.ads.4am-media.com/homes<
/url><path>winnie/</path></home_dir>
Changing the -mountstyle to afp indicates that the Active Directory homeDirectory attribute should be interpreted as an AFP (rather than SMB) url.
Most other, graphically available, options can also be set with dsconfigad; these options are well documented on dsconfigad's man page.
Important to the deployment of any application is a good architectural knowledge of the files, executables, data stores and logs that support its functionality.
The Active Directory Plug-in is interesting in that it doesn't just query Active Directory for data. That wouldn't be very useful, since Active Directory doe not contain all the data that Mac OS X needs for valid user or group records. In addition to querying Active Directory, the Plug-in performs a number of data transformations, sometimes even appending data to the user records it finds. The best example of this is probably Managed Client data (MCXSettings). When the Plug-in's localhome flag is set to enable, a great deal of Managed client data is added to each user record, specifically place the user's Active Directory Home Directory into their dock (and to have it mounted at log-in) Other examples include:
djou:~ djou$ dscl /Active\ Directory/ads.4am-media.com -read /Users/winnie AuthenticationAuthorityAuthenticationAuthority: 1.0;Kerberosv5;83981D08-027D-3843-BE3B-AB80FA3DA07F;winnie@ADS.4AM-MEDIA.COM; ADS.4AM-MEDIA; comment
djou:~ djou$ dscl /Active\ Directory/ads.4am-media.com -read /Mounts/w2k:\\/homes
ADDomain: ads.4am-media.com
AppleMetaNodeLocation: /Active Directory/ ads.4am-media.com Comment:
Dynamically generated - DO NOT ATTEMPT TO MODIFY
RecordName: w2k:/homes
VFSLinkDir: /Network/Servers/w2k/homes
VFSOpts: net url==smb://w2k.ads.4am-media.com/homes
VFSType: url
The AD Plug-in generates an automount record designed to help mount network home directories. Guest access doe not have to be enabled on this share point. For now, Mac OS X is incapable of using virtual home shares (\\server\username) as user network home directories, and must be able to locate home directories at a path below a share point.
Panther's Active Directory Plug-in is by no means perfect, and although Apple has done a relatively good job I'd be remiss if I did not mention some of the pitfalls I've encountered. The most common issues tend to be unrelated to the Plug-in itself, and are more related to other capabilities in the OS. -localhome enabled's use of NTLMv1 authentication (which is disabled in security-sensitive environments), for instance, is due to the fact that the OS does not obtain a TGT early enough during log-in. There's not much that the AD Plug-in can do about that. Similarly, Mac OS X may not access user home directories on either DFS or a clustered CIFS file system. Incidentally, Thursby's ADmitMac product, which is a commercial Open Directory plug-in for both NT domains and Active Directory, is not subject to these particular limitations, since it uses Thursb'y Dave CIFS / SMB client. AdmitMac also overcomes a less common issue, where Computer accounts are not allowed to read certain user attributes. This measure is sometimes implemented to protect user privacy, but since Panther's AD Plug-in connects to the domain as the computer (rather than as the user) this could have the effect of keeping users from being recognized. AdmitMac pulls some tricks to actually connect to the domain as the user (rather than the computer) ensuring full access to at least some user data. Finally, note that AdmitMac supports Packet Signing, a cryptographic security feature turned on by default in Windows 2003 server. The AD Plug-in does not. Neither AdmitMac northe AD Plug-in support nested groups, a common management strategy in Active Directory.
Another common issue that is encountered at the basic integration level is the use of DNS. Mac OS X, like Windows clients, uses DNS to locate domain resources during the join process. This means that Mac OS X clients must have the Active Directory DNS server listed in the Network pane of the System Preferences application. Another DNS-related issue revolves around the common use of the .local TLD. This conflicts with Apple's Rendezvous multicast DNS implementation and must be worked around. Apple documents one procedure for this in kbase 107800. There are several other, less intrusive solutions but they are beyond the scope of this article.
Someone other than me said that "A willow tree bends in the wind and so the branches, being supple do not break." It takes little imagination to understand that Microsoft is a force of nature right now and that competing all out against them is ill advised. What matters to Apple's survival is sales, and Panther's Active Directory Plug-in, in making Mac OS X more willow-like, makes sales a lot easier. Good solutions support-- rather than fight-- existing IT infrastructures.
Michael Bartosh is a consultant specializing in large scale server deployments, directory services integration and scalable systems management.
