Chapter 3. Active Directory

Active Directory is a Directory Services solution developed by Microsoft. It is built using certain proprietary technologies, which only (currently) runs on the Microsoft Windows Server platform. Samba may soon turn out to be worthy of running in production as a Windows Active Directory replacement. While many of the back end components of Active Directory are designed for the windows client platform, Microsoft based much of the structure of Active Directory on open standards, such as the LDAP format known as RFC 2307 and the Kerberos v5 protocol defined in RFC 1510. Active Directory can be used to seamlessly integrate Windows systems en masse, but the real advantage of blending these technologies and open standards is that foreign operating systems can then be integrated with Active Directory as well.

Integrating Mac OS X and Mac OS X Server with Active Directory is very similar to integrating with the native directory services that a Mac OS X Server's Open Directory service can provide. The reason for this is Active Directory supports gaining access to information within its Jet Database by using the Light Weight Directory Access Protocol (LDAP). When thinking about directory services, it is sometimes best thought of as a large delimited document, such as something you would create in a spreadsheet program like Microsoft Excel. When a client attempts to use a directory for authentication and authorization it looks up an object such as a user account via the LDAP protocol much like searching for a field in a spreadsheet. This lookup entails finding the field in the directory that matches the requested information. For example, when a user types his or her username this information is stored as a key value pair in Active Directory.

If user zsmith logs in, then an LDAP query is started that attempts to find a user in the directory with that value. Once the user is found, the resultant set of keys that make up their user account can be accessed. For example, zsmith may have a home directory that is stored on a network server. This path name will be stored as a key (homeDirectory) in the Active Directory database. Apple has two default plug-ins for communicating with LDAP servers, the LDAPv3 plug-in and the Active Directory plug-in. These two plug-ins are very similar in terms of the back end communication they use. However, Apple developed the Active Directory plug-in to supplement missing LDAP attributes that are not normally available in a standard Active Directory Schema. The best example of this is the uidNumber attribute. This attribute is normally used to contain the numerical value associated with an account. On a native Open Directory Server, this value is mapped from the server's uidNumber attribute to the local clients UniqueID attribute. Without a UniqueID, users are not able to login, this is because of Mac OS X's UNUI underpinnings which require a UniqueID to track ownership on the file system.

If you use the LDAPv3 plug-in to authenticate to Active Directory (which is possible to do, though rarely implemented), the default RFC 2307 mappings would map a server attribute called uidNumber to a local plug-in mapping called UniqueID. When a user attempted to login they would then query the server attribute uidNumber, and because it was unavailable but required for login, they would be unable to authenticate to the login window. Apple saw this scenario and mitigated it in the design of the Active Directory plug-in. When a user logs into a workstation that is bound to Active Directory, the plug-in itself generates a numerical value based on other information in the native directory and maps it to the UniqueID attribute. You can think of this as a mask in front of the Active Directory server to make it seem more like a native Open Directory server.

Additionally, the Apple Active Directory plug-in will not only mask missing attributes but will also convert attributes that are in the wrong format for Mac OS X to being in the correct format. Go back to our example of a home directory that was hosted on a network volume. In Active Directory this network path is stored using Universal Naming Convention (UNC) or \servershare. Despite its "universal" name, this format is not supported for connecting to URIs in Mac OS X. If you wanted to connect to \servershare using the built in file-sharing clients, you would format the URI as smb://server/share. This simple format difference would mean the difference of being able to login or not using the LDAPv3 plug-in. In this instance, Apple again configures the Active Directory plug-in to read in the server homeDirectory attribute and then reformats and maps it to the local HomeDirectory attribute.

With all the supplements that are provided by Apple through the native Active Directory plug-in, it serves as an adequate tool for integration in many different environments. In the beginning of this chapter, we will cover the Apple-provided and supported tools that can be used to bind to Active Directory environments. However, depending on the needs of your environment you may need to take advantage of some Active Directory features which cannot be facilitated using just the Active Directory plug-in. The most common needs in an enterprise environment move beyond mere authentication and into the realm of ongoing client management. For this, Apple has a very robust set of management options known as "Managed Preferences" or MCX (covered extensively in Chapter 7). Though not natively supported by Active Directory, MCX can still be implemented alongside Active Directory via a few different methods. After reading this chapter, you will be familiar with the various options available, as well as the pros and cons of each.

On a native Open Directory server these management options are stored as keys within a given object. For instance, user zsmith (or more commonly a "workgroup" that he is a member of) may have a managed preference that configures his Dock to appear on the left-hand side. These management attributes cannot be natively stored in Active Directory without modifying the Active Directory schema, a modification that is global for all objects in an organization's directory. As such, from a political aspect, extending the schema can be difficult to push through in environments with a proportionally small number of Mac OS X workstations. For this reason, other options such as maintaining a separate supplemental Open Directory server or using a third-party active directory plug-in may best suit your needs. These options are covered in the following sections. Because the needs and business requirements of each environment are different, after explaining how to use the built-in Active Directory plug-in, the remainder of the chapter is dedicated to customizing the Active Directory plug-in and the common third party add-ons.