Understanding Mac OS X and Active Directory

Microsoft's Active Directory provides a standards-based LDAP directory service and various kerberized services. (Kerberos is covered in Lessons 6 and 9.)

Open Directory, the Apple directory services architecture, also supports LDAP and Kerberos. It provides this support through a flexible and extensible plug-in architecture, as you have seen in previous lessons.

Active Directory Integration Configuration

Integrating Mac OS X with Active Directory requires the use of diverse tools, processes, and configuration files. All of these pieces work together to provide a flexible framework for integrating into an existing Active Directory deployment. Understanding these pieces and how they work together provides a proper picture for the modification, trouble- shooting, and migration of a configuration.

The Active Directory configuration process is the same for both Mac OS X and Mac OS X Server, depending on how the directory structure is configured on Mac OS X Server. If it is initially a standalone server, then the binding will be identical to that of Mac OS X. But if you are planning to turn the Mac OS X server into an Open Directory master, then the option of binding to an Active Directory domain must be made prior to this process, as a decision must be made on whether the Active Directory server or the Mac OS X server will be the Kerberos KDC.

More Info

Kerberos is covered in Lessons 6 and 9, and Open Directory masters are covered in Lesson 7, "Hosting Open LDAP."

Using the Apple Active Directory Plug-In Basic

Mac OS X includes an Open Directory plug-in to help administrators more effectively integrate Mac OS X with Active Directory's schema without making changes in the Windows world. The Active Directory plug-in is configured inside of the Directory Access application.

Before binding can begin, a better understanding of a few Active Directory terms is in order.

Key Active Directory Terms

• Active Directory forest: A forest is the first domain that is created in an organization. Because of this, no Active Directory deployment can be free of a forest. If your organization has only one domain, then the forest name is identical to the domain name. It is not necessary to fill out the name of the forest in the plug-in. When you fill out the domain name, it will correctly return the name of the forest.

• Active Directory domain: Similar to traditional Windows NT domains, Active Directory domains are used to store user and resource definitions and information. Active Directory domain names are in a domain name system (DNS) format and never include the host name of the server hosting the domain.

• Computer ID: The computer ID is used by the Active Directory domain to associate the Mac OS X computer to its computer account. Its name is limited to 16 characters and will truncate any characters over 16.

  

Initial Configuration

Basic binding to an Active Directory domain requires the name of the domain that you want to bind to (entered in the Network preferences pane of System Preferences) and a computer ID, which is how the Mac OS X computer will be recognized in the Active Directory domain. Even though the Active Directory plug-in sets the computer ID to the name of the computer, you can override the default if your organization has an established naming scheme. With both values, check with the Active Directory server administrator if you are unsure.

Binding

Once you are ready to implement the plug-in settings, click the Bind button and you will see another dialog, as shown in the figure below. After you've entered the user name and password of a user with the ability to add computer records to the Active Directory domain, the user's Mac OS X computer will join the specified domain.

Note

You cannot configure the plug-in without entering the name and password of an account with the ability to add user names in the container (or ou) specified in the Computer OU field.

Similar to the LDAP plug-in, during the binding you can select the options to add the Active Directory domain to the Authentication and Contacts search paths with their two respective checkboxes. When the checkboxes are selected, the search paths will show up in the Authentication and Contacts tabs in Directory Access.

Once bound, the Mac OS X computer is fully configured to integrate with Active Directory, without a single modification to the Active Directory schema.

Default User Experience With the Active Directory Plug-In

With the Active Directory plug-in fully configured, users can now log in to Mac OS X with a user name and password in the bound Active Directory domain. There are several variations of the user name that can be used for login: long name, short name, email address, or domain principal. This allows Mac OS X users the same user name options that Windows users have when authenticating.

After login, users can access certain network services without being continually prompted for a user name and password. Services like file and protected Web may no longer require reauthentication. This change occurs because a Kerberos ticket-granting ticket (TGT) is received from the Active Directory domain when the user logs in to Mac OS X with an Active Directory account.

Advanced Plug-in Configurations

Although the default configuration will suffice for many users, the Active Directory plug-in provides advanced options to configure the plug-in to meet your needs. The following figure shows the different user options.

Creating Mobile User Accounts

A mobile account caches the user's Active Directory identification data and authentication credentials on the bound Mac OS X computer, allowing the user to log in using the Active Directory name and password while the Mac OS X computer is disconnected from the Active Directory domain. A mobile account has a local home folder on the startup volume of the Mac OS X computer. You also have the choice of creating a notification when the user logs in for the first time.

Defining Home Folder Location

By default, the Active Directory plug-in creates a local home folder for each Active Directory user who logs in. Using a local home folder helps ensure that Mac OS X processes and applications have a place to store user-level preferences and resources, even during a network outage. Additionally, saving documents to a local drive is generally faster than saving to a remote volume.

By default, the plug-in is configured to create a local home folder named after the user's RecordName, as in SAMAccountName. When configured to create a local home folder, the plug-in also mounts the user's Windows network home folder (a native Active Directory HomeDirectory attribute, as specified in the User's Active Directory account) as a network volume, like a share point. To further assist the user's ability to access his or her data on the server, an alias to that user's network home folder is also placed in the Dock. The user can copy files between the Windows home folder network volume and the local home folder.

Note

If a home folder already exists with the same short name as that of a new Active Directory user, Mac OS X will not know to create the new home folder and the logged-in user will be unable to access the pre-existing folder, due to a permission mismatch.

If you change the name of a user account in the Active Directory domain, the server will create a new home folder (and subfolders) for the user account the next time it is used for logging in to a Mac OS X computer. The user can navigate to the old home folder and see its contents in the Finder. You can prevent the creation of a new home folder by renaming the old folder before the user next logs in.

When someone logs in to Mac OS X with an Active Directory user account, the Active Directory plug-in can automatically mount the Windows network home folder that's specified in the Active Directory user account as the user's Mac OS X home folder. You can specify whether to use the network home specified by Active Directory's standard home directory attribute or by the Mac OS X Home Directory attribute, if the Active Directory schema has been extended to include it. The protocols that can be used for this are are Apple Filing Protocol (AFP) and Server Message Block (SMB), but not network file system (NFS).

Had the administrator chosen to use the LDAPv3 plug-in to support Active Directory users in a similar way, the Active Directory schema would have needed modification to map mount records and the two home folder user attributes. The Active Directory plug-in, on the other hand, dynamically creates these missing pieces for Mac OS X at login, thus obviating the need for schema modifications.

User Shell

Finally, you can set the command-line shell that users with Active Directory accounts will use when interacting with Mac OS X in the Terminal application. The default shell is also used for remote interaction via SSH (Secure Shell Protocol) or Telnet. Each user can override the default shell by changing a Terminal preference.

Mapping Options

When the "Map UID to attribute" option is not selected, the plug-in dynamically generates a unique user ID and a primary group ID based on the user account's globally unique ID (GUID) in the Active Directory domain. The generated user ID and primary group ID are always the same for each user account, even if the account is used to log in to different Mac OS X computers. When the "Map UID to attribute" option is selected, the Active Directory plug-in maps the user ID and primary group ID to the Active Directory attributes that have been previously repurposed or added to the AD schema to hold those user values. The user ID value is unique per user, but the Primary Group ID will generally be the same for most users.

The Active Directory plug-in also generates a group ID based on the Active Directory group account's GUID. Like the user ID, you can configure the plug-in to map the group ID for group accounts to a specified Active Directory attribute.

Administrative Options

You have a few additional options when binding to an Active Directory domain. These are found on the Administrative tab.

When you select the "Prefer this domain server" option, you tell Active Directory to first attempt a connection with a particular server rather than dynamically discovering the closest domain server. If the designated server is not found, Mac OS X will attempt to locate an alternate domain server at startup. If this option is not selected, the Active Directory plug-in automatically determines the closest Active Directory domain in the forest. This option is useful in situations where an older, slower Windows computer is being used as an Active Directory domain server within a given network. You may want to direct your requests to a faster, more powerful Active Directory server somewhere other than the server that is physically closest to your Mac OS X computers.

By selecting "Allow administration by," you can specify which groups of users within Active Directory have administration rights in Mac OS X. When logged in to Mac OS X, users who are members of these groups are treated as if they were members of the local admin group on the Mac OS X computer, meaning they have access to install applications and write to the local library folder. Some Active Directory administrators prefer to create a new group within the Active Directory domain called MacAdmins and place all Macintosh administrators within that group. You can then choose to allow only that MacAdmins group with this option.

If you select the "Allow authentication from any domain in the forest" option, Mac OS X will authenticate users who are members of domains outside of its own domain. After changing this setting, you need to change the custom search policy in the Authentication pane and/or Contacts pane to include the Active Directory forest or selected domains as appropriate. This could reduce the number of users who can log in to that Mac OS X computer.

You can also add the Active Directory forest to the computer's custom search policies for authentication and contacts. When adding to a custom search policy, the forest appears in the list of available directory domains as /Active Directory/All Domains (the default setting). Alternatively, you can add Active Directory domains individually to the computer's custom search policies for authentication and contacts. When adding to a custom search policy, each Active Directory domain appears separately in the list of available directory domains and can be rearranged just like any other directory service to which the Mac OS X computer is bound.