Panther and Active Directory

by Michael Bartosh
12/09/2003

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.

Open Directory Review

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.

Active Directory Plug-In: Features

Related Reading Active Directory By Robbie Allen, Alistair G. Lowe-Norris Table of Contents Index Sample Chapter Read Online--Safari Search this book on Safari:   Only This Book All of Safari Code Fragments only

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)

jdoe@example.com
jdoe
John Doe
EXAMPLE\jdoe

...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:

• Best Of Class Single Sign-On support: Because of its automatic kerberos configuration (on joining the domain, a Kerberos configuration file is generated for the domain in question) users that have signed into a domain do not have to re-authenticate in order to mount shares from other member servers in the domain. Pessimists will point out that Windows has had this capability for several years. What these pessimists fail to realize, though, is that Apple's client-side single sign on architecture is flexible and open enough to interoperate with 3rd party directory and authentication systems with no special configuration or infrastructure changes.
• Domain Controller (DC) Fail Over: Rather than being tied to a specific domain controller (like the LDAPv3 Plug-In) the AD Plug-In is able to dynamically discover and use the nearest available DC using the same dns-based service discovery that windows clients use...
• Vastly improved disconnected behavior: In Jaguar, Macs configured to access Active Directory suffered particulrly debilitating timeouts in the event that the domain could not be reached. Although this is due more to advances in Open Directory architecture than to the AD Plug-in, Panther does not suffer from these timeouts. Machines accessing Active Directory resources may be moved among networks (or disconnected entirely) without concern for a debiliting user experience.
• Access to Windows HomeDirectory: The UNC specified in the user's AD HomeDirectory attribute will automatically be mounted with the credential the user presents at log-in. It will not be used as the user's Mac OS X Home directory- but it is feasible to use a log-in script to link portions of the AD user's local home directory into the shared volume.
• Password Police Enforcement: In Jaguar, Expired Active Directory passwords meant that a user couldn't log into a Mac workstation until they'd visited a windows machine in order to change their password. Panther's updated kerberos infrastructure along with the Active Directory Plug-in now work together to deliver an equivilent cross-platform user experience. Expired AD passwords can be updated from the Mac OS X loginwindow in a fairly smooth manner. The only real downside is that the user is also prompted for a password hint- something that is not part of the Active Directory user record. If the user attempts to enter such a hint, loginwindow gets- well- confused- its elements (fields, buttons and graphics) mix together in some rather intersting ways.
• Local Caching of Active Directory users: Optionally, the most recent AD User can be cached locally, so that the user can authenticate when disconnected from the network (typically using a laptop). When the domain is accessible, password expiration and changes are enforced, even though the user is still viewed as local. Keep in mind that local accounts do not expire and that home directory contents are not automatically synchronized- the user is responsible for manually moving files from their local home directory to their desktop-mounted windows home directory at some point when it is available.
• Multiple Domain Authentication: LDAPv3-based solutions were somewhat limited by their need to specify an LDAP search base on a single domain controller. This typically limited the scope of user and group lookups to a single domain (although searching the global catalog with a broad search base could result in better results). It is fairly typical in larger environments to have multiple domains linked together in forrests or trees. Panther's AD Plug-in is much more suitable to these enviornments than the LDAPv3 Plug-in.
• UniqueID Attribute Mapping: One of the biggest issues when integrating Jaguar with Active Directory is providing a valid UniqueID- a 32 bit integer unique to each user or group. Active Directory uses a hex-encoded guid for unique account identification, This is incompatible with most unix varients, including Mac OS X. The AD Plug-In derives an integer from the user or group's guid in a way that is both consistent- so that the account always has the same UniqueID- and unique- so that no two users or groups have UniqueID value collisions. Optionally, though, UniqueID may be mapped to a specific AD attribute. This is useful if an organization is already using Microsoft's Services for Unix, or some other schema that provides a 32 bit unique decimal identifier.
• Administration by AD groups: Specific AD groups can be granted local administration rights on Active Directory-bound Mac OS X clients. This allows for a much more integrated administration experience- enterprise authorization data is leveraged in a heterogenious enviornment, rather than having to be maintained seperately for each platform.
• Improved Group Support: Active Directory groups were particularly hard to make use of in Jaguar. This is due to the fact that group membership in Windows is stored according to user distinguished names (the complete LDAP path to the user record), while unix operating systems expect short names. This makes it virtually impossible to utilize AD groups without some kind of schema modification and periodic synchronization process. Panther's AD Plug-in, however, is able to derive group membership from native Active Directory data- a much less intrusive, IT friendly process.

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.

Active Directory Plug-In: Configuration

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.

Pages: 1, 2

Next Page