Lesson 5. Integrating Mac OS X With Active Directory

Time

This lesson takes approximately 2 hours to complete.

Goals

Understand basic Active Directory terms Configure Mac OS X to use the Active Directory plug-in Learn when the various advanced options available with the Active Directory plug-in in Mac OS X should be considered Use the Active Directory plug-in and Mac OS X Server to supplement an Active Directory server Use a Mac OS X Server to supplement directory services provided by an Active Directory server Use an Active Directory server for authentication and a Mac OS X server for managed client information Use a Mac OS X server to supplement an Active Directory server for providing MCX information to Mac OS X computers

From Lesson 4, “Integrating Mac OS X With Third-Party Directory Services,” you already know how to use the Lightweight Directory Access Protocol (LDAP) plug-in to bind a computer to an Active Directory server. Mac OS X also includes an Active Directory plug-in, which, when properly configured, allows your computer to access the same directory records as the Windows computers on the network.

With the Active Directory plug-in for Open Directory, configuring a Mac OS X computer to access an Active Directory server is fairly straightforward. If you prefer, though, you can override its default settings and specify how to map key user account attributes, where to store the home folder, and what accounts have admin access.

In this lesson, we will cover the many dynamics of integrating Mac OS X with Active Directory. Prior to Mac OS X version 10.3, the best way to integrate Mac OS X computers with Active Directory was through the LDAP plug-in, which is still a functional option. Today, the Active Directory plug-in facilitates easier configuration, a richer feature set, and a better user experience than that of the LDAP plug-in, which can still used for Active Directory integration. The focus of this lesson will be on the Active Directory plug-in with both Mac OS X and Mac OS X Server.

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.

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.

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.

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.

More Integration With Active Directory

Integration with Active Directory does not stop with simple login support; other, more subtle features are supported through the plug-in:

• Users who have successfully logged in to Mac OS X can change their password through System Preferences. If the Active Directory administrator has password policies in place, they are fully enforced.

• Depending on the plug-in configuration, members of Active Directory admin groups will be treated as administrators.

• Address Book and other applications that use Address Book for contact searches can now search Active Directory for contact information.

• The command-line tool dsconfigad can be used to set all Active Directory bind settings shown in the plug-in. Because it’s a command-line tool, it can be used in shell scripts. And since AppleScripts can call shell scripts, dsconfigad can be used with AppleScript as well. A login hook shell script that binds a computer to an Active Directory domain the first time the computer is booted without user or administrator interaction can be very useful when doing mass deployment of Mac OS X systems within an Active Directory environment.

Exploring the Active Directory Plug-in

In this exercise, you will explore the various options of the Active Directory plug-in and its counterpart, dsconfigad.

1 Open Directory Access, located in /Applications/Utilities.

2 Select the Services tab, and double-click the Active Directory plug-in to open it.

3 Click the disclosure triangle on the left to show the advanced options.

4 Click each option to observe the various choices you have when binding to an Active Directory domain.

5 Close the plug-in, quit Directory Access, and open a Terminal window.

6 Type man dsconfigad and press the Return key to view the man page for dsconfigad.

7 Press the Space bar to view more of the man page.

The dsconfigad tool is well documented.

8 Quit the Terminal.

Behind the Scenes: Active Directory Bind

Now that you have seen the user experience with the Active Directory plug-in, let’s go behind the scenes to understand how the plug-in makes integration so easy. Before users can log in, the plug-in must be configured. When an administrator clicks the Bind button and authenticates, the plug-in begins a sequence of events to appropriately configure Mac OS X.

1. The plug in uses _domain.tcp.domain.com to find the DNS server, which should return a list of hosts providing LDAP and Kerberos services.

2. It then uses LDAP to find out what domain it’s currently in. The plug-in will attempt to authenticate to that domain to look for the closest domain controller.

3. Assuming a successful authentication, the domain controller will use another extension of DNS, which supports site records, and respond by supplying the host information for the nearest domain controller to the Mac OS X computer.

4. With a list of domain controllers now returned, the plug-in chooses one and builds an edu.mit.Kerberos configuration file based on it.

5. The plug-in will attempt to authenticate to the new domain controller and begin searching the domain and forest for a computer record with a computer ID that corresponds to the one specified for the plug-in.

6. If a match is found, the plug-in will use that computer record.

7. If a match is not found, the plug-in will create a new computer record with the plugin’s specified computer ID.

8. A password is then attached to the newly created computer ID or changed if the computer account already exists.

At this point, Mac OS X is fully configured to integrate with Active Directory.

Encountering Errors

To cleanly unbind Mac OS X from an Active Directory domain, first connect the computer to the domain to ensure that the plug-in can remove the associated record. When you clicked the Bind button, it automatically changed to an Unbind button, so all you have to do now is click Unbind.

Administrators can forcefully remove the binding configuration information by deleting the ActiveDirectory.plist file. If you choose to do this, you will need to remove the computer record from the Active Directory domain manually, then remove the listing from the authentication path.

However, several errors can occur when attempting to bind to Active Directory. Below are explanations of the more common errors:

• Invalid domain: This message refers to the plug-in’s inability to find a domain controller or Global Catalog server with the existing Mac OS X network configuration. This is due to incorrect names being typed during plug-in configuration or because the Mac OS X computer is using a DNS server lacking the appropriate service records that would normally be populated through Dynamic DNS. For best results, Mac OS X computers should be using a Microsoft Dynamic DNS server or another DNS server that has been configured to allow Dynamic DNS updates from Active Directory servers.

• Active Directory time error: This error occurs because the plug-in depends on a functional Kerberos environment. Kerberos requires that all Kerberos host and client clocks be relatively in sync. In any Kerberos deployment, the use of a network time server is essential to reliable operation. In general, a 5-minute time difference is all that is permitted.

• Insufficient privileges: This error will occur when the user name and password supplied do not have permission to join a computer to the listed domain.

Troubleshooting

To troubleshoot Active Directory DNS issues, you can run nslookup in interactive mode:

nslookup -sil

The prompt turns to >. To look at various service records associated with binding, type any of the following, depending on your query:

host -t SRV _ldap._tcp.domain.com

host -t SRV _kerberos._tcp.domain.com

host -t SRV _kpasswd._tcp.domain.com

Each one of these will return information based on your lookup. If you do not see any results for the entries, then the entries are not valid domains.

You can also use nslookup to test reverse DNS lookups. To look up standard records, type set type=A and enter the server address, such as

mainserver.pretendco.com

The results should look like the following:

mainserver.pretendco.com = 10.1.0.1

Typing 10.1.0.1 should yield a result similar to this:

10.1.0.1.in-addr.arpa PTR mainserver.pretendco.com

Also, when binding with the Active Directory plug-in, you can send DirectoryService a -USR1 message to request that it log to /Library/Logs/DirectoryService/DirectoryService.debug.log.

sudo killall -USR1 DirectoryService

This is a toggle switch command; running it again will turn off the debug log.

Plug-in Configuration Files

The Active Directory plug-in uses a collection of files to make Active Directory integration a reality:

• edu.mit.Kerberos: This is the primary Kerberos configuration file. It is chiefly responsible for identifying the Kerberos server used to facilitate password policies and single sign-on within the domain. This file is located in /Library/Preferences/.

• ActiveDirectory.plist: Contains all values for the plug-in’s advanced options. Also contains the schema mappings being employed by default. Advanced users can make manual modifications to this file to further configure the plug-in. This file is located in /Library/Preferences/DirectoryService/.

• SearchNodeConfig.plist: Used by Directory Access to record which directories to search and in what order to search them. Administrators troubleshooting directory configurations may want to delete this file, thus resetting Mac OS X to a state in which no remote directories are searched. This file is located in /Library/ Preferences/DirectoryService/.

• ContactsNodeConfig.plist: Used by Directory Access to track which directories to use for contact lookups. Applications like Mail and Address Book use these directories to automatically locate contact information. This file is located in /Library/ Preferences/DirectoryService/.

Supplementing Active Directory With Mac OS X Server

Like other third-party directory servers, an Active Directory does not include Mac OS X–specific attributes without modifying the schema. Through discussions with the server administrator, you need to determine the appropriate approach, either by modifying the Active Directory schema or by configuring a supplemental server.

MCX Records Can Be Stored in Active Directory

Being able to log in to Active Directory from Mac OS X is adequate integration for many organizations. However, others may also wish to use the Apple Managed Client for X (MCX) technology to further enhance their Active Directory user experience.

One way of supporting MCX on Mac OS X for Active Directory accounts is to modify the existing Active Directory schema so that it incorporates Apple’s MCX schema attributes. Then the administrator will need to create and populate all the MCX user, group, and computer records with functional data.

Administrators using the Active Directory plug-in can deploy MCX in their Active Directory schema whenever they choose without thought to client configuration. If the Active Directory schema has been extended to include Mac OS X record types (object classes) and attributes, the Active Directory plug-in detects and accesses them automatically. This schema modification enables the Active Directory plug-in to support managed client settings (MCX) made using Workgroup Manager.

Integrating MCX, Active Directory, and Open Directory

Instead of merging the Apple schema with that of Active Directory, you can host MCX directory content on a separate Open Directory server. Configuring a Mac OS X computer to use this setup is relatively simple. In Directory Access, administrators just need to add an LDAP configuration for the Open Directory server in addition to their Active Directory configuration, which will work for both the Active Directory plug-in and the LDAPv3 plug-in. It also lets you use Workgroup Manager to create MCX workgroup and computer lists.

The biggest drawback is that administrators forfeit their ability to manage individual users; users will need to be managed by group or computer. Still, it’s usually more than acceptable, since the more users you have, the more time consuming it is to manage them individually.

Startup

Understanding the big picture is an important part of being able to effectively troubleshoot a problem. In the following figure, you can see what happens at startup with a Mac OS X computer that has been configured to use the Active Directory plug-in for user records and the LDAPv3 plug-in for MCX settings.

1. All the appropriate plist files discussed earlier have been configured with Directory Access prior to restart.

2. At startup, the configured Mac OS X computer searches all configured directories for MCX computer records and applies the appropriate settings to itself.

3. After the MCX settings are applied to the Mac OS X computer, the login screen appears.

User Authentication

The following figure shows the process of user authentication:

1. The user now types a user name and password into the login screen and presses Return.

2. The loginwindow process checks the local NetInfo database for the user record and if no match is found, loginwindow will then query the first configured directory from the Directory Access authentication path list.

3. Assuming the directory server responds with the contents of the user’s record, loginwindow will attempt to validate the user using the password.

4. The existing Kerberos server specified in the edu.mit.Kerberos file.

5. The user is issued a Kerberos TGT and is then logged in to the Mac OS X computer.

MCX and Home Directory

Now that the user has been verified, the following figure shows what happens next:

1. The user is verified.

2. Mac OS X searches all configured directories shown in the Directory Access authentication path list for MCX groups that are applicable to the current user.

3. The login screen presents the user with a choice of available groups.

4. The user chooses a group.

5. Mac OS X continues the login process with the MCX settings applied to the session.

6. If the user’s record in Active Directory is configured with settings for an SMB home folder, Mac OS X attempts to mount the SMB home folder using Kerberos authentication. If the user’s record in Active Directory is configured with settings for an AFP home folder, Mac OS X attempts to mount the AFP home folder.

Other Binding Considerations

Administrators will want to consider some final details prior to deploying Mac OS X with the Active Directory plug-in:

• Currently, packet signing and packet encryption are not supported.

• Mac OS X attempts to mount SMB home folders using Kerberos for authentication. Domain controllers can be set up to allow various forms of authentication. If the server hosting the SMB home folder has been configured not to allow Kerberos, Mac OS X will attempt to connect with NTLMv2.

• The Active Directory plug-in is designed with the assumption that more than 40 user record attributes are readable by the computer record that the Mac OS X computer is configured to use. If these attributes are not readable, then Mac OS X may behave unexpectedly.

• The plug-in works best with Active Directory deployments that are set up with the pre–Windows 2000 permission style. If you are not sure which permission style was used when your organization’s Active Directory deployment was set up, you should coordinate with the Active Directory administrator and inspect the permissions of the attributes the plug-in uses.

• The Active Directory plug-in makes Mac OS X computer integration with Active Directory a practical reality. The Active Directory plug-in greatly simplifies the work that administrators must perform to provide a full Active Directory experience for Mac OS X users. Some of the key Active Directory plug-in features are:

• LDAP and Kerberos support

• True SMB home folders

• MCX support

• No Active Directory schema modifications

What You’ve Learned

• The computer ID is limited to 16 characters and will truncate any characters over 16.

• The different methods a user can use to log in to a Mac OS X computer when bound to an Active Directory domain are: long name, short name, email address, and domain principal.

• When setting Active Directory administrative options, using “Allow administration by” specifies which groups of users within Active Directory have administration rights in Mac OS X.

• The majority of files connected with an Active Directory bind are located in /Library/Preferences/DirectoryService except the edu.mit.kerberos file, which is located in /Library/Preferences.

• Packet signing and packet encryption are not supported with the current Active Directory plug-in in Mac OS X v10.4.

References

Administration Guides

“Mac OS X Server Open Directory Administration”: http://images.apple.com/server/pdfs/Open_Directory_v10.4.pdf

“Mac OS X Command-Line Administration”: http://images.apple.com/server/pdfs/Command_Line_v10.4.pdf

Apple Knowledge Base Documents

The following Knowledge Base documents (located at www.apple.com/support) provide further information about Active Directory.

Document 107830, “Mac OS X Server 10.3 or later Active Directory: Using computer account attribute ACLs”

Document 301010, “Using the Active Directory plug-in in a multi-domain controller environment”

Books

Allen, Robbie, and Lowe-Norris, Alistair G. Active Directory, 2nd Edition (O’Reilly and Associates, 2003).

URLs

Open Directory and Active Directory: www.macdevcenter.com/pub/a/mac/2003/08/05/active_directory.html

Shukwit.com: www.shukwit.com

Windows Server 2003 Active Directory: www.microsoft.com/windowsserver2003/technologies/directory/activedirectory/default.mspx

Apple Professional Services: www.apple.com/services/consulting

Lesson Review

1. What protocol does the Active Directory plug-in use to retrieve directory data from an Active Directory server?

2. If an attribute is not specified, what Active Directory attribute does the Active Directory plug-in use to create the user ID?

3. If you do not configure the Active Directory plug-in other than binding to an Active Directory server, where is the user’s home folder stored?

4. When binding to an Active Directory server, what information does the Active Directory plug-in require?

5. What are the server configuration options for implementing Managed Client for X (MCX) support for Active Directory users?

6. What is the possible danger of making changes to the schema of an Active Directory server?

7. What is an advantage to using an Open Directory server to supplement an Active Directory server?

8. If an Open Directory server is used to supplement an Active Directory server instead of modifying the Active Directory schema, can Workgroup Manager manage user account preferences?

Answers

1. LDAP

2. The Active Directory plug-in bases the user ID on the user account’s globally unique ID (GUID).

3. A home folder for the user is created locally in /Users.

4. The Active Directory plug-in needs the Active Directory domain and a computer ID. It also requires the name and password of a domain administrator account on the server.

5. Modify the Active Directory schema or use an ancillary Open Directory server to store the MCX data for Active Directory users.

6. Erroneous schema changes on an Active Directory server are very difficult to correct. Great care should be taken when you make schema changes.

7. An Open Directory server can supplement an Active Directory server, providing Mac OS X computers with Mac OS X–specific records, such as MCX records.

8. No. In order to allow user preferences to be managed, the Active Directory schema must be modified to allow user records to store managed user preferences.