Active Directory & Mac OS X
Volume Number: 20 (2004)
Issue Number: 11
Column Tag: Programming
Active Directory & Mac OS X
by Michael Bartosh
Fitting in, not standing out. We mean it this time.
Ancient History
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.
History Reloaded
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.
The Active Directory Plug-in: Features
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.
- Single Sign On: The Active Directory plug-in leverages the extensive client-side work Apple has
pursed in order to effectively make use of the Kerberos authentication protocol. Kerberos is Active
directory's native authentication platform, and effective Active Directory integration demands a
mature Kerberos environment. When a User logs into Mac OS X using an Active Directory account they
are granted a TGT (ticket granting ticket) which ultimately allows them to access Kerberized
services-- including Exchange's Outlook Web Access-- without having to authenticate again.
- Windows Home Directories: In its default configuration, the Active Directory Plug-in obtains the
location of the User's home directory (in the homeDirectory attribute of the User's Active Directory
account) and puts it into the User's Dock so that it is easily accessible. It can also be
configured, however (as covered later in this article) to use the SMB-mounted Windows home share as
a Mac OS X network home directory.
- Password Policy Enforcement: In Jaguar password policies set in Active Directory were not
effectively enforced. Although the situation isn't perfect in Panther, users are allowed to change
expired passwords on log-in, and password changing is effectively integrated into the user
experience, allowing users to change their Active Directory password with either the passwd command
line utility or the Accounts pane of the System Preferences application.
- Multiple domain authentication: Active Directory is capable of scaling to very large
deployments. These large deployments often form forests made up of multiple domains. Apple's Active
Directory plug-in optionally allows for users from any domain in a forrest (even domains in a
different namespace-- for instance a domain called pantherserver.org in a forest called apple.com) to
log into the Mac in question.
- Active Directory Group Support: Active Directory keeps track of groups in a way that is very
different from Mac OS X (and most other Unix-based Operating Systems). This made it very difficult
in Jaguar to leverage the extensive group management capabilities of Active Directory. Panther's
Active Directory Plug-in is designed specifically to interpret Active Directory group data,
manipulating it in a way that makes it useful to Mac OS X.
- Delegated Administration: Active Directory largely operates on the principal of delegated
administration-- granting certain administrative privileges in a granular fashion to users who are
not domain administrators (users, for instance, are often delegated the authority to add their
workstations to the domain). The Active Directory Plug-in is friendly to this concept, optionally
allowing one or more Active Directory groups to administer the Mac OS X workstation. Administrative
capabilities can additionally be granted to specific users (rather than groups) the same way they
would be on the Windows platform, by setting the Managed By attribute in the Windows Active
Directory Users and Computers application.
- Disconnect Behavior: Panther displays far better disconnect behavior when domain resources are
not available. In Jaguar the user experience as Open Directory (Apple's Directory Services
infrastructure) struggled to re-connect to missing directory domains was painful to say the least,
with difficult timeouts that left the client useful for extended periods of time. This has improved
in Panther to the extent that Active Directory user accounts can even be cached locally, so that the
user is able to log in even if the domain is not available. When the domain is available password
policies (such as expiry) are enforced.
- UniqueID Generation: One of the biggest challenges of integrating any Unix operating system with
Active Directory is the UniqueID. This integer (sometimes called uid) is used to uniquely identify
Unix accounts. Active Directory supports several unique identifiers (among them guids and sids) but
they are 128 bit hex identifiers. This results in quite a bit of difficulty during integration,
since a user account without a UniqueID isn't really a user account as far as Mac OS X is concerned.
The Active Directory Plug-in works around this issue, generating an integer UniqueID from the 128
bit hex guid. This conversion (done according to Microsoft's specification at blah) produces an
integer UniqueID that is both consistent throughout the domain and Unique among all user accounts.
The only real downside to this process is that the converted UniqueID's are very large, and not all
Applications deal with them correctly.
- Domain controller preference: When the Active Directory Plug-in joins a domain it attempts to
locate the nearest domain controller using site policy published to DNS. Unfortunately site policy
is not always configured correctly, so the Active Directory Plug-in allows you to specify a
preferred domain controller.
Configuring the AD Plug-in
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.
Troubleshooting
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
Comment
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.
The User Experience
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).
Advanced Configuration
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.
The Active Directory Plug-in: Architecture
Important to the deployment of any application is a good architectural knowledge of the files,
executables, data stores and logs that support its functionality.
- /Library/Preferences/DirectoryService/ActiveDirectory.plist: The configuration file for the
Active Directory Plug-in. Options (set both graphically and using dsconfigad) are stored here, in
addition to mappings between Active Directory and Open Directory record types and attributes.
- /Library/Preferences/DirectoryService/SearchNodeConfig.plist: The file that stores the Open
Directory search policy, specifying which directory domains should be searched for user accounts and
other directory data.
- /Library/Preferences/DirectoryService/ADGroupCache.plist: As of 10.3.4, exists only in Mac OS X
Server. Active Directory stores group data differently from Mac OS X and most other Unix operating
systems. The transformation of Active Directory groups into something that Mac OS X understands is
relatively heavy weight. Because of this and because Mac OS X frequently likes to look up group
membership Apple initially cached a local copy of every group in the Active Directory. This solution
did not scale, taking up to three days and sometimes producing a cache file that was a hundred
megabytes or more. In 10.3.4 Apple abandoned this strategy in Mac OS X, reasoning that dynamic
lookups of group membership data probably could be achieved efficiently enough to meet user
performance expectations, meaning that (in the client OS) the ADGroupCache is no longer used. The
legacy behavior is preserved in Mac OS X Server since it needs access to a full listing of group
membership no matter who is logged in. The frequency of the Plug-in's interrogation, though, is
configurable by editing the Group Search Interval Hours key in ActiveDirectory.plist (it has a
default value of 12 hours).
Data transformation
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:
- Authentication Authority: A user's AuthenticationAuthority is the attribute that Apple uses
determine how the user should be authenticated. Users without AuthenticationAuthorities can not
support login-time password policies (such as expiry and forced changes) or password changes in the
Accounts pane. The AD Plug-in generates an AuthenticationAuthority for every user based on the
domain's configuration, allowing for the seamless support of Active Directory password policies.
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
- HomeDirectory and NFSHomeDirectory: HomeDirectory and NFSHomeDirectory describe the
location of a user's network home directory. The former is an XML plist describing how to create the
latter, which is a file system path. Neither is a standard part of an Active Directory user record
(although the latter can be supplied by Active directory's msSFU30HomeDirectory if services for Unix
are installed). As seen earlier, both are automatically generated based on the account's home
directory as described in their Active Directory user record (using the UNC path described earlier
in this chapter).
- Mount Record: The mount record works in conjunction with the User's HomeDirectory and
NFSHomeDirectory attributes to help support network home directories. Like the user home directory
attributes it is generated on the fly based on the User's home directory UNC.
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.
- Kerberos Auto Configuration record: One of Mac OS X's more intriguing Kerberos integration
features is auto-configuration. Mac OS X, when it determines that it needs to be configured for
Kerberos, will execute the kerberosautoconfig command. Kerberosautoconfig, in turn, will search the
directory domains that the client is aware of, looking for a Kerberos configuration record. This
record is very specific to Apple's infrastructure, and not typically found in non-Mac directories.
The Active Directory Plug-in, however, is smart enough to auto-generate this configuration record,
allowing for easy Kerberos interoperability.
Caveats
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.
Conclusion
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.
