Mac OS X Directory and Microsoft Active Directory

It's easy to integrate Mac OS X into an Active Directory environment. This chapter shows you how.

Active Directory is Microsoft’s directory services solution that provides LDAP and Kerberos services for identification and authentication. Many organizations with Windows computers use Active Directory because it provides these features:

Security and policy management for Windows computers
Tight integration with popular application servers such as Microsoft Exchange and Microsoft SQL Server
High availability, with the ability to place multiple replica servers across geographic locations in a multimaster configuration

It is easy to integrate Mac OS X into an Active Directory environment. Although Mac OS X computers can access directory information provided by Active Directory via the LDAPv3 plug-in, you should use the Active Directory plug-in, which provides the following capabilities:

Creating a computer account for secure communication with Active Directory services
Configuring mappings of Open Directory objects and attributes to Active Directory objects and attributes
Setting up the Kerberos environment for seamless integration with Active Directory
Enabling SMB packet signing and packet encryption
Support of Active Directory password policies
Support of Active Directory Sites, which directs Windows and Mac OS X client computers to the most appropriate services based on their IP network
Caching information from Active Directory services so that Mac OS X computers can use the information even if they are not connected to the network

In this chapter you will learn how to use both Directory Utility and the command line to bind to Active Directory, and to modify the default settings for the Active Directory plug-in to enable login and access to a network home folder. You will learn how to overcome problems with your initial bind to Active Directory, and you will learn troubleshooting techniques for login problems with an Active Directory user account.

Configuring Mac OS X to Log In Using Active Directory

You can either use Directory Utility or dsconfigad to bind a Mac OS X client computer to an Active Directory domain. dsconfigad allows you to configure some features that Directory Utility does not expose, but if you use dsconfigad you need to take some additional steps (such as enabling the Active Directory plug-in and adding the Active Directory node to your search paths). Before you can bind with either method, however, you need to know a few things about your Active Directory service.

Understanding Active Directory Terms

When you bind to Active Directory, you need to know the domain name and you must have the credentials of a user who has authorization to join computers to Active Directory.

A domain is the building block of Active Directory; it is a collection of directory objects such as users, groups, and computers. An Active Directory domain requires a domain controller, which can be a computer running any version of Windows Server 2000 through Windows Server 2008. A domain is identified by its DNS namespace; in this book the example server windows-server.pretendco.com hosts the domain pretendco.com. Active Directory relies on DNS records generated by a DNS service that is tightly integrated with Active Directory, so you should configure Mac OS X to use the DNS service associated with the Active Directory domain before attempting to bind.

A tree is one or more domains in a contiguous name space. A forest is a set of domain trees that have a common schema and global catalog, which is used to describe a best-effort collection of all the resources in a domain. The global catalog is commonly used for email address lookups.

Like standard Windows clients, Mac OS X binds to only one Active Directory domain at a time.

Understanding the Active Directory Computer Object

When you bind a Mac OS X client computer to Active Directory, you use or create a computer object for Mac OS X. Just like user objects, computer objects are used for identification, authentication, and authorization. The computer object has rights to do certain things, such as to bind and update its own DNS record.

When you bind a Mac OS X computer to Active Directory, Mac OS X uses the user credentials you supply to set up a computer account and password. This password is a shared secret between your Mac OS X computer and the Active Directory service. Your Mac OS X computer uses this password to authenticate to Active Directory and set up a secure channel to enable your Mac OS X computer to communicate with Active Directory. The password is randomly generated, and is unrelated to the user account you use to perform the bind. For more information, see “Confirming Your Active Directory Plug-in and the Samba Service Are Using the Same Active Directory Computer Password” in Chapter 8.

If you delete the computer object or reset the computer object password in Active Directory, you need to rebind Mac OS X to Active Directory in order for Mac OS X to access Active Directory.

When you use Directory Utility to bind to Active Directory, Directory Utility suggests a computer ID to use for the name of the Active Directory computer object. This computer ID is based on the computer name or Bonjour name that you set in the Sharing pane of System Preferences. If your computer name is longer than 15 characters, you may experience errors when binding to Active Directory. Also note that Directory Utility may replace any instance of a dash (-) with an underscore (_) and change capital letters to lowercase in the suggested computer ID. You should use the same Mac OS X computer name and Active Directory computer name to help keep track of computer names, unless you have a good reason not to do so.

Specifying a User to Create the Computer Object

When binding to Active Directory, you need to supply the credentials of an Active Directory administrator or user who is authorized to create computer objects. By default, you can use a regular active directory user to bind to Active Directory ten times, but after that you will encounter an error. “Troubleshooting Binding Issues,” later in this chapter, offers some solutions for this problem.

Binding to Active Directory with Directory Utility

The simplest way to bind Mac OS X to Active Directory is to use Directory Utility with all the default settings in place. The steps are as follows:

Quit Directory Utility if it is open.
Use the Sharing preference in System Preferences to set your computer name to be the name of the computer object you want to create for binding to Active Directory.
Open Directory Utility.
If necessary, click the lock in the lower-left corner and provide credentials for a local administrator.
Click the Add (+) button in the lower-left corner.
Click the “Add a new directory of type” pop-up menu and choose Active Directory.

7. In the Active Directory Domain field, type the name of the Active Directory domain—in other words, “pretendco.com” not “windows-server.pretendco.com.”

This can be any domain in the forest, but remember that the domain name is the DNS namespace of the domain, not the DNS name of the domain controller.

In the Computer ID field, type the name of the Active Directory computer object to use for this Mac OS X computer.
In the AD Administrator Username field, type the name of an Active Directory administrator or the name of an Active Directory user who can join a computer to the domain.
In the AD Administrator Password field, type the password for the user you specified in step 9.
Click OK.

Mac OS X attempts to bind to Active Directory with the default settings.

Logging In as an Active Directory User on Mac OS X

Once you bind your Mac OS X computer to Active Directory, you can log in with your Active Directory user account at your Mac OS X login window.

The following figure shows the default desktop for an Active Directory that logs in to a Mac OS X computer. Note that the home folder is located on the startup disk (Option-clicking the name of a folder in the title bar of a Finder window reveals the path to the folder). The user launched the Kerberos application (in /System/Library/CoreServices), which shows that Mac OS X obtained a Kerberos ticket-granting ticket (TGT) for the user as part of the login process.

Specifying a User Name at the Login Screen

By default the Mac OS X login window displays the names of local user accounts and Other to allow you to specify a user name from a different directory node, as shown in this figure.

When you choose Other, the login window reveals a field for Name and Password.

At the Mac OS X login window, you can use many combinations of the user identifiers “Full name,” “User login name,” or “User login name (Pre-Windows 2000)” from Active Directory, along with other elements of the domain name. Consider the figure at left, which shows a user created with Active Directory tools.

You can log in with any of the following names in the Name field in Mac OS X’s login window:

schoun-regan
sregan
Schoun Regan
schoun-regan@pretendco.com
sregan@pretendco.com
Schoun Regan@pretendco.com
PRETENDCO\schoun-regan
PRETENDCO\sregan
PRETENDCO\Schoun Regan

Understanding the Home Folder Default Behavior

When you log in with a user account for Active Directory, by default Mac OS X creates a home folder for the user on the startup disk in /Users/usershortname.

If a directory already exists with that name, Mac OS X will not create a new home folder. You may experience unexpected results because the Active Directory user does not have write permissions to the home folder.

See “Transitioning from a Local User to an Active Directory User,” later in this chapter, if that is appropriate for your situation.

Understanding Home Folder Synchronization

The default settings do not configure Mac OS X to synchronize the local home folder with a network home folder. If you log in as the same Active Directory user on multiple Mac OS X computers that are configured with the default settings for the Active Directory plug-in, you will have a different home folder on each computer, and the contents will not be synchronized. To prevent this situation you can do the following:

Configure mobile accounts and home folder synchronization. See “Understanding Mobile Accounts” for more on this.
Deselect the option to force the creation of a local home folder, and use Active Directory tools to assign a network home folder for the Active Directory user account. See “Specifying a Network Home Folder” for details.

Changing the Active Directory Plug-in Default Settings

The Active Directory plug-in’s default settings might not meet your needs. For instance, you may want to not force local home folders on the startup disk, or you may want to use custom mappings or to specify Active Directory groups to members that have local administrative access on your Mac OS X computer. In this section you will learn how to use Directory Utility and the command line to configure some of the advanced options of the Active Directory plug-in.

Follow these steps to use Directory Utility to access Active Directory Advanced Options:

Open Directory Utility. If necessary, click the lock in the lower-left corner and provide credentials for a local administrator. If necessary, click the Show Advanced Settings button in the lower-right corner of the Directory Utility window.
Click Services in the toolbar.
Make sure the Active Directory service checkbox is selected.
Select the Active Directory service.
Click the Edit button in the lower-left corner of the Directory Utility window.
Click the disclosure triangle next to Show Advanced Options.

Exploring the “User Experience” Advanced Options Pane

The default pane for Directory Utility’s Advanced Options is the User Experience pane, shown in the figure to the left.

The first option, “Create mobile account at login,” is disabled by default. A mobile account caches user credentials locally so they can be used when the computer is not connected to the directory node. See “Understanding Mobile Accounts” for more details about mobile accounts and synchronized home folders.

The “Force local home directory on startup disk” option is enabled by default. If you deselect this option, and an Active Directory user who does not have a network home folder defined logs in, Mac OS X creates a local home folder in /Users/username for the user when the user logs in (unless a local home folder already exists).

Specifying a Network Home Folder

There are two possible ways to specify a network home folder:

If your Active Directory schema has been extended to support Apple objects and attributes, map dsAttrTypeStandard:HomeDirectory to an extended attribute in your user record, and use Workgroup Manager to specify the home folder.
Enable the option “Use UNC path from Active Directory to derive network home location” and use Active Directory tools to populate the Home Folder field for an Active Directory user. The Active Directory plug-in maps dsAttrTypeStandard:SMBHomeDirectory to Active Directory’s dsAttrTypeNative:homeDirectory. You can also specify this option with the -uncpath option of dsconfigad.

You must specify which file-sharing protocol to use: SMB or AFP (Apple Filing Protocol). SMB is the default setting, so it is easy to use Windows file services to host home folders for Active Directory users who log in to a Mac OS X computer.

New in Mac OS X v10.5 is full support for SMB packet signing, a security feature designed to prevent man-in-the-middle attacks, which is required by default on Windows Server 2003 SP1 and later. Many Windows Server administrators require client computers to use this option, which makes it impossible for computers using earlier versions of Mac OS X to access their SMB share points without installing third-party SMB client software.

AFP offers some advantages over SMB as a file service protocol for Mac OS X client computers: It is faster, native to Mac OS X, supports Time Machine and network Spotlight searching, has better auto-reconnect, and handles a wider range of file names in a mixed environment. Unfortunately, Windows servers do not offer AFP by default.

Although Windows Server 2000 and Windows Server 2003 can offer AFP via Services for Macintosh (SFM), the SFM version of AFP is not current. For example, SFM supports only 31 characters in a file name, which causes a problem when Mac OS X uses a long file name, such as ~/Library/Preferences/ByHost/com.apple.iCal.helper.0017f3e00523.plist. SFM is not recommended for Mac OS X network home folders. If you must use your Windows server for network home directories, consider running a third-party AFP file service, such as GroupLogic’s ExtremeZ-IP, on your Windows server.

You can use a Mac OS X Server to host network home folders for Active Directory users, whether they log in to Mac OS X computers or Windows computers. You can use Mac OS X Server’s AFP service for users who log in to Mac OS X computers, and Mac OS X Server’s SMB service for users who log in to Windows computers. Discourage users from simultaneously logging in as the same user simultaneously on Mac OS X and Windows computers, because if they edit the same file over two different protocols simultaneously, this could corrupt the file.

For more information about offering file services from a Mac OS X Server, see Chapter 10 of Mac OS X Advanced System Administration v10.5.

Logging In with a Windows Home Folder

If you use Active Directory tools to define a network home folder (dsAttrTypeNative:SMBHome) for the user, as shown in the figure to the left, Mac OS X mounts the network volume that contains that Active Directory home folder. Unless you specify otherwise, by default the Active Directory plug-in creates a local home folder on the startup disk, so Mac OS X mounts the Windows home folder but does not use it as the user’s home folder.

The network folder appears in the Dock, but the volume does not appear on the user’s desktop by default. The default preference for the Finder in Mac OS X v10.5 is to not display mounted network volumes on the desktop. To change this in the Finder, select Finder > Preferences and select the checkbox for “Connected servers.”

The next figure illustrates what the standard desktop looks like for an Active Directory user who has an Active Directory home folder defined. The user opened Finder preferences and enabled “Connected servers” so that the Windows share point appears on the desktop. Note also that the user’s home folder is located on the startup disk, which is the default setting for the Active Directory plug-in.

The figure below shows the desktop of an Active Directory user who has a Windows home folder set (dsAttrTypeStandard:SMBHome) and logs in to a Mac OS X computer that does not have the “force local home directory on startup disk” option enabled in the User Experience pane of the Active Directory plug-in.

Some things to note:

The home folder is not on the startup disk.
This user did not enable the option to show connected volumes on the desktop, so the volume containing the network home folder does not appear on the desktop.
The user launched the Kerberos application to confirm that Mac OS X obtained a TGT, then the user closed the main window of the Kerberos application. The icon for the Kerberos application displays how much time is remaining (in hours and minutes) in the validity of the TGT. The usual TGT lifetime is 10 hours; after that time, the user can reauthenticate to renew the TGT.
The question mark in the user’s Dock represents the user’s Documents folder, which has not yet been created. If the network home folder was hosted on a Mac OS X Server file service, Mac OS X Server would create the set of standard folders.

Changing User and Group Mappings

By default, the Active Directory plug-in generates a dsAttrTypeStandard:UniqueID for an Active Directory user record based on that user’s GUID attribute. The calculated UniqueID is unique across the domain, yet consistent across every Mac OS X computer in the domain. Likewise, the Active Directory plug-in generates a unique integer for each Active Directory group record as well. If you have extended your Active Directory schema, you can use the Mappings pane to access the appropriate attributes from the Active Directory user and group records.

Be forewarned that if you change the mappings, users may lose access to files that they previously owned or could access.

The Mappings pane, shown below, allows you to change the mappings for the following:

UID—dsAttrTypeStandard:UniqueID
User GID—dsAttrTypeStandard:PrimaryGroupID
Group GID—dsAttrTypeStandard:PrimaryGroupID

If the Active Directory schema were extended with Microsoft’s Services for UNIX, the following would hold:

Map UID to msSFU-30-Uid-Number
Map both user GID and group GID to msSFU-30-Gid-Number

If the Active Directory schema were extended with RFC2307 or Apple object classes and attributes:

Map UID to uidNumber
Map both user GID and group GID to gidNumber

Exploring the “Administrative” Advanced Options Pane

The “Prefer this domain server” option shown in the figure below specifies a domain controller to use for the initial bind.

Use the “Allow administration by” option to enable any user of the Active Directory groups that you specify to be in the group of local administrators for this Mac OS X computer. This is useful if you create an Active Directory group and populate it with users who should have the authority to administer the Mac OS X computers in your organization.

When you add Active Directory to your search path, Directory Utility adds the node Active Directory/All Domains to your search path by default. If you want to restrict the authentication search path to use specific domains only in your forest, follow these steps:

Deselect the option “Allow authentication from any domain in the forest,” then click OK to dismiss the Active Directory services pane.
Click Search Policy in the toolbar of Directory Utility, and then click the Authentication tab.
Select Active Directory/All Domains, click the Remove (-) button in the lower-left corner of the Directory Utility window, and then click OK at the confirmation dialog.
Click the Add (+) button in the lower-left corner of the Directory Utility window. Directory Utility displays a list of the domains in your forest. Select the domains that you want to enable in your authentication search path and click Add, as shown in this figure:

Click Apply to activate the change.

Creating the Computer Account in a Custom Location

Unless you specify otherwise, the Active Directory plug-in creates computer objects in CN=Computers with the domain that you specified to join. Depending on the configuration of your Domain Controller, this may not be correct. For example, some administrators have a special container (CN) for all Mac OS X computers, while others use organizational units (OU).

Follow the steps listed below to tell the Active Directory plug-in to add the computer to the container CN=MacComputers,DC=pretendco,DC=com. Rather than binding from the default pane in Directory Utility, you will bind from within the Active Directory services pane, which offers different binding options.

Open Directory Utility. If necessary, click the lock in the lower-left corner and provide credentials for a local administrator. If necessary, click the Show Advanced Settings button in the lower-right corner of the Directory Utility window.
If your Mac OS X computer is already bound to Active Directory, you must first unbind. See “Unbinding from Active Directory” for instructions.
Click Services in the toolbar.
Make sure the Active Directory service checkbox is selected.
Select the Active Directory service.

6. Click the Edit button in the lower-left corner of the Directory Utility window.

If you are not already bound to Active Directory, Directory Utility displays the dialog shown in the figure below. If you are already bound, you must first unbind in order to change the location of your computer account.

In the Active Directory Domain field, type the Active Directory domain.
In the Computer ID field, type the name of the Active Directory computer object to use for this Mac OS X computer.

9. Click Bind.

Directory Utility displays the authentication and Computer OU dialog shown in this figure:

sudoIn the Username field, type the name of an Active Directory administrator or the name of an Active Directory user who has authority to join a computer to the domain.
In the Password field, type the password for the user you specified in step 10.
In the Computer OU field, type the custom container in which to create the computer object for this Mac OS X computer to use.

Click OK to start the bind process, and then click OK to dismiss the Active Directory services pane. Quit Directory Utility.

Binding to Active Directory with dsconfigad

The dsconfigad command is particularly useful for scripting the process of binding to Active Directory, and it offers a way to bind with custom settings in one step. This command has drawbacks, however: It does not enable the plug-in, nor does it add the Active Directory node to the search paths. You must also use the defaults and dscl commands to accomplish those tasks.

To bind a computer to Active Directory with dsconfigad, collect the following information for the following dsconfigad options:

-a—Name of Active Directory computer object to use
-domain—Fully Qualified Domain Name (FQDN) of Active Directory domain to join
-u—Name of an Active Directory user who is authorized to add this computer to the domain
-p—The password for the Active Directory user
-lu—Name of a local administrator
-lp—The password for the local administrator

The commands listed below enable the Active Directory plug-in, bind to Active Directory, and add the Active Directory node to the authentication and contacts search paths:

Use the defaults command to modify the settings of the file /Library/Preferences/DirectoryService/DirectoryService.plist:

2.           client17:~ cadmin$ sudo defaults write \

3.

4.           /Library/Preferences/DirectoryService/DirectoryService \

5.

"Active Directory" Active

Use dsconfigad to bind to Active Directory.

7.           client17:~ cadmin$ dsconfigad -a client17 \

8.

9.           -domain pretendco.com \

10.

11.       -u Administrator -p ADadminpw \

12.

13.       -lu cadmin -lp cadmin

14.

Computer was successfully Added to Active Directory.

For the authentication search path, use dscl to add "Active Directory/All Domains" to the custom search path (CSPSearchPath), and set the authentication search path to use CSPSearchPath:

16.       client17:~ cadmin$ sudo dscl /Search -create / SearchPolicy CSPSearchPath

17.

18.       client17:~ cadmin$ sudo dscl /Search -append / CSPSearchPath "Active Directory/All

Domains"

For the contacts search path, use dscl to add "Active Directory/All Domains" to the custom search path (CSPSearchPath), and set the contacts search path to use CSPSearchPath:

20.       client17:~ cadmin$ sudo sudo dscl /Search/Contacts -create / SearchPolicy

21.       CSPSearchPath

22.

23.       client17:~ cadmin$ sudo sudo dscl /Search/Contacts -append / CSPSearchPath "Active

Directory/All Domains"

Stop DirectoryService, which automatically starts up again with these new settings:

client17:~ cadmin$ sudo killall DirectoryService

Use dscl to confirm that the Active Directory node is in the search paths:

26.       client17:~ cadmin$ dscl /Search -read / CSPSearchPath SearchPolicy

27.

28.       CSPSearchPath:

29.

30.        /Local/Default

31.

32.        /BSD/local

33.

34.        Active Directory/All Domains

35.

36.       SearchPolicy: dsAttrTypeStandard:CSPSearchPath

37.

38.       client17:~ cadmin$ dscl /Search/Contacts -read / CSPSearchPath SearchPolicy

39.

40.       CSPSearchPath:

41.

42.        /Local/Default

43.

44.        /BSD/local

45.

46.        Active Directory/All Domains

47.

SearchPolicy: dsAttrTypeStandard:CSPSearchPath

Use id to confirm that Open Directory knows about an Active Directory user.

In this example, the user aduser1 is an Active Directory user object. The -p option makes the output human readable:

client17:~ cadmin$ id -p aduser1

uid aduser1
groups AD\domain users

If you issue the id
command after binding and the result is no
such user, wait a few seconds and then try again.

More Info

For more options, see the man
page for dsconfigad.

Using Configuration Options Available Only with dsconfigad

dsconfigad offers much of the
same functionality that Directory Utility offers: You can bind, unbind, set
configuration options, and show the status of a bind. In addition, dsconfigad offers some functionality that
Directory Utility does not offer, such as the following:

·
-packetsign
<disable | allow | require>—This supports packet signing
options for both SMB and LDAP. SMB signing is required by default on Windows
Server 2003 SP1 and later. This caused much frustration with earlier versions
of Mac OS X. The default is to allow
packet signing, a new feature in Mac OS X v10.5.

·
-packetencrypt
<disable | allow | require>—This supports packet
encryption options for both SMB and LDAP. The default is to allow packet encryption, which is a new
feature in Mac OS X v10.5.

·
-namespace
<forest | domain>—The forest
option enables a user to log in even if there is another user account with an
identical user name in the forest. Be forewarned that if you specify forest, the Active Directory plug-in
calculates each Active Directory user’s local home folder as /Users/DOMAIN\username instead of /Users/username. Toggling the namespace setting after Active Directory
users have already logged in can cause confusion as Active Directory users
perceive the contents of their home folder to be missing. The default is domain.

·
-passinterval
<days>—This specifies how often Mac OS X changes the
Active Directory computer object password, measured in days. It is common for
Active Directory administrators to use Active Directory tools to look for
computers that have not recently changed their passwords. The default is for
Mac OS X to change its computer object password every 14 days.

Providing Managed Preferences to Active Directory Users

Using Active Directory Group Policy Objects is the traditional method for
managing users, groups, and computers, but Mac OS X is not compatible with
Group Policy Objects. If you want to apply Managed Preferences to Mac OS X
users, you could do any of the following:

Augment Active Directory
with an Open Directory server, and then make Active Directory users
members of Open Directory groups to which you apply Managed Preferences.
See “Using Workgroup Manager to Provide Managed Preferences in the Magic
Triangle Configuration,” in Chapter 8, for instructions.
Use third-party software
such as Thursby ADmitMac, Centrify DirectControl, or other similar user
management utilities.
Extend your Active
Directory schema to handle Apple-specific object classes and attributes,
and then use Workgroup Manager to manage preferences for objects in the
Active Directory domain. See Appendix B.

Troubleshooting Binding Issues

For the most part, binding to Active Directory should just work. Some
conditions, however, will prevent binding. This section introduces potential
problem areas and provides instructions on how to resolve them.

Using Command-Line Tools to Confirm Binding

You can confirm that you are bound to Active Directory with the dsconfigad -show command and option, which
also shows the status of many Active Directory plug-in options. You can also
use the dscl or id commands to confirm that Mac OS X is
bound to Active Directory. For example:

client17:~ cadmin$ dsconfigad -show
cadmin's Password: [password typed but hidden]
You are bound to Active Directory:
Active Directory Forest = pretendco.com
Active Directory Domain = pretendco.com
Computer Account = client17
Advanced Options - User Experience
Create mobile account at login = Disabled
Require confirmation = Enabled
Force home to startup disk = Enabled
Use Windows UNC path for home = Disabled
Network protocol to be used = smb:
Default user Shell = /bin/bash
Advanced Options - Mappings
Mapping UID to attribute = not set
Mapping user GID to attribute = not set
Mapping group GID to attribute = not set
Advanced Options - Administrative
Preferred Domain controller = not set
Allowed admin groups = not set
Authentication from any domain = Enabled
Packet signing = allow
Packet encryption = allow
Advanced Options - Static maps
None
client17:~ cadmin$ dscl /Active\ Directory/All\ Domains \
-list /Users
[a successful bind will display a list of users; not shown here]
client17:~ cadmin$ id -p aduser1
uid aduser1
groups AD\domain users

Binding After Imaging

If you use a standard image for Mac OS X, do not bind the image model to
Active Directory before making the master image that you will use to image
multiple computers. All computers imaged from that master image will use the
same computer object in Active Directory, which may cause problems. If you
later remove the computer object, all of the Mac OS X computers will be unable
to log in with Active Directory user accounts, and you will need to force an
unbind, then rebind each computer to Active Directory.

Using System Logs

If the bind fails, check /var/log/system.log, which contains the progress
for each step of the binding process listed here:

Step 1 of 6: Searching for Forest/Domain information
Step 2 of 6: Finding nearest Domain controllers
Step 3 of 6: Verifying credentials
Step 4 of 6: Searching for existing computer
Step 5 of 6: Joining new Domain
Step 6 of 6: Writing config

The binding process writes files to /var/db/dslocal/nodes/Default/config/,
which only the root user can view.

Confirming DNS Service

The binding process is sensitive to DNS records, so make sure that you
specify the Active Directory DNS service in the Network preference of System
Preferences, and that port 53 (UDP and TCP, used for DNS requests and replies)
to the DNS service is not blocked. If your Active Directory DNS is incorrectly
configured, you may experience problems binding Mac OS X to Active Directory.

The Active Directory plug-in requires several DNS service records (SRV) in
order to determine which hosts provide certain services on certain protocols.
SRV records use the form _Service._Protocol.domain,
and the requests are usually in lowercase text. Examples of the searches and
replies for a few of the SRV records necessary to bind to Active Directory are
shown below:

client17:~ cadmin$ host -t SRV _ldap._tcp.pretendco.com
_ldap._tcp.pretendco.com has SRV record 0 100 389 windows-server1.pretendco.com.
client17:~ cadmin$ host -t SRV _kerberos._tcp.pretendco.com
_kerberos._tcp.pretendco.com has SRV record 0 100 88 windows-server1.pretendco.com.
client17:~ cadmin$ host -t SRV _kpasswd._tcp.pretendco.com
_kpasswd._tcp.pretendco.com has SRV record 0 100 464 windows-server1.pretendco.com.
client17:~ cadmin$ host -t SRV _gc._tcp.pretendco.com
_gc._tcp.pretendco.com has SRV record 0 100 3268 windows-server1.pretendco.com.

The host option -t SRV specifies a search of type SRV, and the queries are for various
services that are available via the protocol tcp
(as opposed to udp) in the
domain pretendco.com. The key
thing to notice is the port number and host offering the service. This example
forest is very simple, and the same host offers all the services
(windows-server1.pretendco.com). However, the port number is different for each
service, as shown here:

389 LDAP
88 Kerberos (used for
obtaining Kerberos tickets)
464 Kpasswd (used for
making Kerberos password changes)
3268 gc (used for Active Directory
Global Catalog lookups)

Although it is possible to use a DNS service that isn’t integrated with
Active Directory, many SRV records are required, so it may be difficult to set
up all the necessary records and keep them up-to-date.

Confirming Access to Service Ports

After performing SRV requests to find the hosts and ports that offer the
required services, you can use telnet
to open a connection to a specific port, to verify that you can make a basic
connection to each service port. When you see a “Connected to” message from the
service, type quit and
press Return to end the connection. If you do not see the “Connected to”
message, make sure there is no firewall blocking access, check underlying
network connectivity, and make sure the service is running on the server.

NOTE

There may be network monitoring processes that perceive as hostile the
network traffic you generate to test access to the services, so coordinate with
your network and Active Directory administrators before using these techniques.

Below are two examples of using telnet
to connect to a port, and the replies from the service. The first connects to
port 389 for LDAP service, followed by port 88 for Kerberos service. A failed
attempt would stop at “Trying 10.1.0.5...,” but each of these telnet sessions successfully connect to
the service:

client17:~ cadmin$ telnet windows-server1.pretendco.com 389
Trying 10.1.0.5...
Connected to windows-server1.pretendco.com.
Escape character is '^]'.
quit
Connection closed by foreign host.
client17:~ cadmin$ telnet windows-server1.pretendco.com 88
Trying 10.1.0.5...
Connected to windows-server1.pretendco.com.
Escape character is '^]'.
quit
Connection closed by foreign host.

Understanding the Binding Process

Mac OS X fully supports Active Directory Sites, which allows directory
administrators to associate specific domain controllers with specific networks.
When you bind a Mac OS X client computer to an Active Directory domain, this
kicks off a complicated series of events, shown in the next figure. Understanding
the process can help you isolate any problem that might crop up.

Here are the steps, in detail:

Mac OS X performs a
request for LDAP, Kerberos, and Kpasswd DNS service records in the domain.
If Mac OS X is not using the DNS server that is integrated with Active
Directory, the process will likely fail at this point.
Mac OS X binds
anonymously with LDAP and gathers basic Active Directory domain
information.
DirectoryService’s Active Directory
plug-in creates a preliminary Kerberos configuration.
Mac OS X uses the Kerberos
configuration, authenticates, and then requests the nearest Domain
Controller.
The Domain Controller
returns a list of the nearest Domain Controllers, based on the IP subnet
of the Mac OS X computer.
Mac OS X confirms that it
can connect to the LDAP and Kerberos services of the Domain Controller
list from step 5, and DirectoryService
and kerberosautoconfig
create a final Kerberos configuration in
/Library/Preferences/edu.mit.Kerberos and
/var/db/dslocal/nodes/Default/config/Kerberos:REALM.plist.
Mac OS X connects to what
it was told was the nearest Domain Controller.
Mac OS X searches the
domain for an existing computer record, and it creates a new computer
record to use if it cannot find one.

Specifying a User with Authorization to Bind

When binding, you must provide an Active Directory user name and password.
You’ll need to confirm that this user has write privileges for the container in
which the computer object will be created or used. If the computer object
already exists, the user whom you specify must have write access to the
computer object. By default a regular Active Directory user can join and create
a computer object only ten times. After that, you will get an error. Here are
some workarounds for this limitation:

Create the computer object
in Active Directory and assign a user or group the ability to join the
computer to a domain.
Modify the number of
times that a particular user can join computers to a domain.
Give all authenticated
users the unlimited ability to join computers to the domain.
Use an administrator
account to perform the bind.

Unbinding from Active Directory

You can unbind from Active Directory with either the Directory Utility
application or the dsconfigad
command with the -r option. If
you cannot communicate with the Active Directory service, you can force the
unbind. If you force the unbind and the computer object that Mac OS X was using
still exists in Active Directory, you can use Active Directory tools to remove
the computer object.

In rare circumstances, you may be unable to do a clean unbind from Active
Directory. To get a fresh start with the Active Directory plug-in, remove the
files that are associated with the Active Directory plug-in, kill DirectoryService, and then try your bind
again.

In /Library/Preferences/DirectoryService the files are as follows:

ActiveDirectory.plist
ActiveDirectoryDomainCache.plist
ActiveDirectoryDomainPolicies.plist
ActiveDirectoryDynamicData.plist

/Library/Preferences/edu.mit.Kerberos will no longer include information
about the Active Directory KDC, but do not remove this file if you are bound to
any other Kerberos realm.

In /var/db/dslocal/nodes/Default/config/ you can remove these files:

Kerberos:REALM.plist,
where REALM is your Active Directory Kerberos realm
AD DS Plugin.plist

You may also want to remove the following:

The computer object in
Active Directory that Mac OS X used
The record for the Mac OS
X computer that the Active Directory plug-in created and updated in the
DNS service

If you unbind, change the computer name, and then rebind, you may notice
Kerberos errors in /var/log/system.log that reference the old computer name.
These occur because the name that you last used to bind to Active Directory may
still be found in /Library/Preferences/SystemConfiguration/ in the preferences.plist
file, which modifies com.apple.smb.server.plist. Do not modify these files, as
the errors are harmless and appear only right after you bind.

If the computer object that Mac OS X uses has been deleted or reset, you
will not be able to log in using an Active Directory user account. However, if
you are troubleshooting, you should be aware that you will be able to obtain a
Kerberos TGT for an Active Directory user. However, you will not be able to use
su to switch to an Active
Directory user, and dirt will
return a dDSAuthFailed error
even if you supply the correct password. In this case, you must unbind and
rebind to Active Directory.

Binding to Active Directory and Open Directory

In any circumstance in which a user account is missing some attributes—for
example, because you cannot extend the schema, or you do not have authority to
edit the attributes you are interested in—you can always try using the Magic
Triangle, in which you use an Open Directory node to supplement data available
from the primary node. You learned about this configuration in Chapter 3, in
“Augmenting LDAP Data with Information from an Open Directory Server,” and it
is illustrated in the figure below.

The Magic Triangle configuration lets you apply Managed Preferences to Open
Directory computers and workgroups, and then add Active Directory groups and
users to Open Directory workgroups to manage them. See the instructions in
Chapter 8, in “Preparing Mac OS X Server for the Magic Triangle Configuration.”

Because the Active Directory plug-in dynamically generates mount records for
network home folders, you do not need to provide an additional directory node
or mount object to automount an AFP home folder.

Troubleshooting Login Issues

The process for logging in with an Active Directory network user is similar
to the process of logging in with a network user from other directory services.
You can use the troubleshooting techniques in Chapters 2 and 3, which include
scenarios in which Open Directory accesses user records from Active Directory
and uses mount, computer, and group records (including attributes for Managed
Preferences) from Open Directory.

This section discusses some common problems, but also covers issues that are
specific to logging in with an Active Directory user record.

Before you begin, verify that you are not experiencing binding issues; for
instructions, see the section “Troubleshooting Binding Issues” later in this
chapter.

Try to determine if the login problem is related to identification,
authentication, or authorization. Start with identification of the user record.
To confirm that you can use the id
or dscl commands to identify the
user, use the following:

client17:~ cadmin$ dscl localhost read /Search/Users/aduser1

It is possible that DirectoryService
is having problems communicating over LDAP to Active Directory. Use a graphical
LDAP browser or an ldapsearch
query to ensure that you can make LDAP requests authenticating as an Active
Directory user:

client17:~ cadmin$ ldapsearch -x -D "cn=dcolville,CN=Users,DC=pretendco,DC=com" -W
-H ldap://windows-server.pretendco.com -b "CN=Users,DC=pretendco,DC=com" cn=dcolville
homeDirectory
[authentication information deleted]
dn: CN=dcolville,CN=Users,DC=pretendco,DC=com
homeDirectory: \\windows-server\smbhomes\dcolville

Verify that your Active Directory node is listed in your authentication
search path.

Check to see if you can authenticate as the Active Directory user. Log in as
a local user or local administrator, and then use su to switch identity to the Active Directory user.

Verify that your Kerberos configuration is set up for the Active Directory
domain; the file /Library/Preferences/edu.mit.Kerberos should reference your
Active Directory Kerberos domain.

Confirm that you can use kinit
or the Kerberos application (in System/Library/CoreServices) to obtain a TGT
from the Active Directory KDC.

Resolving Time Issues

If the clocks on the Active Directory domain controller and Mac OS X are
more than 5 minutes apart, you cannot obtain a Kerberos ticket and you cannot
log in. Make sure your Mac OS X computer is in the correct time zone, has the
correct daylight saving time settings, and uses the same Network Time Protocol
server as your Active Directory servers.

Using the Logs

Use the log file /var/log/system.log and the log files in /Library/Logs/DirectoryService/DirectoryService
to gather information if you are experiencing problems logging in. Refer to
Chapter 1 for information about enabling

DirectoryService logging by
sending the USR1 or the USR2 signal to DirectoryService.

Transitioning from a Local User to an Active Directory User

If you want to transition from using an established local user account to a
network account, yet continue to use the existing home folder, you must perform
these steps:

On your Mac OS X
computer, log in as a local administrator. Open System Preferences and
choose the Accounts preference.
Click the lock in the
lower-left corner to authenticate as a local administrator.
Choose the local account
that conflicts with the Active Directory account.
Click the Remove (-)
button in the lower-left corner.
When prompted, leave the
default selected, “Do not change the home folder,” then click OK.

If the short name of the
local user differs from the short name of the Active Directory user,
change the name of the home folder. The following command changes the name
of the home folder from the local user short name “david” to the Active
Directory user name “dcolville”:

client17:~ cadmin$ sudo mv "/Users/david (Deleted)" /Users/dcolville

7. Change
the ownership of the files in the preserved home folder so that the Active
Directory user is the new owner. Open Terminal and issue the chown (change ownership) command, which
takes the form of

chown [options] owner[:group] file

The option -R
changes ownership recursively, so the command changes ownership for the entire
home folder. The chown command
below changes the owner and group associated with all the files in the home
folder:

client17:~ cadmin$ sudo chown -R dcolville:"PRETENDCO\domain users" /Users/dcolville

Log out as the local
administrator account, and then log in as the Active Directory account.

Understanding Mobile Accounts

A mobile account is a local copy of a network user account, with attributes
and credentials synchronized at login if the network node is available. A
mobile account allows you to log in even when the network directory node is not
available. The mobile account concept is not specific to Active Directory, but
the Active Directory plug-in provides a checkbox to enable Mac OS X to a create
a mobile account when users log in. This enhances the user experience because
it caches other information, such as group membership, about Active Directory. Mobile accounts work well
when you synchronize the contents of the local home folder with a network home
folder, but this is not automatic.

See “Exploring the ‘User Experience’ Advanced Options Pane,” earlier in this
chapter, for instructions on configuring the Active Directory plug-in to
configure Mac OS X to create mobile accounts. For more information about home
folder synchronization, see the section “Managing Mobile User Accounts,”
starting on page 502 of Mac OS X Server Essentials, Second Edition, or
read Chapter 8, “Managing Portable Computers,” of Mac OS X Server User
Management for Version 10.5 Leopard.

Updating Active Directory Indexing

As do other directories, Active Directory indexes the values of commonly
requested attributes in order to increase the speed of operations. If your
Active Directory implementation contains a large amount of Mac OS X clients,
your Mac OS X computers may request attributes that Active Directory does not
index. Microsoft provides a downloadable Server Performance Advisor tool that
lets you investigate whether there are any attribute queries that could be sped
up by better indexing. Use this tool to determine if there are many requests
for attributes that are not indexed, and then use Active Directory tools to add
the unindexed attributes to the list of attributes to index.

Forcing Replication

If the computer object is created in one site but hasn’t been replicated to
another, you may not be able to log in until the replication takes place. You
can force replication to take place with standard Active Directory tools.

Summery

Mac OS X’s Open Directory
has a specific Active Directory plug-in that uses Active Directory’s LDAP
and Kerberos services and enables extra functionality with the Active
Directory domain, such as Dynamic DNS updates. The Active Directory
plug-in comes with a default set of mappings for objects and attributes,
which you can modify.
You can use Directory
Utility or dsconfigad to
bind a Mac OS X computer to Active Directory. You must specify the Active
Directory domain, the name of a computer object in Active Directory to use
or create, and the user name and password of an Active Directory user who
has the ability to create or that computer object.
By default, Mac OS X
assigns a home folder in /Users for Active Directory users. If the user
also has an Active Directory network home folder assigned, the folder will
appear in the Dock and the Network volume will be mounted, but by default
Mac OS X does not display network volumes on the desktop.
The Active Directory
plug-in uses DNS extensively, including SRV records. You should configure
Mac OS X to use the Active Directory DNS service or continually replicate
the complicated set of records on another DNS service.
Binding to an Active
Directory domain takes several steps, and the progress is logged to
/var/log/system.log.
Mac OS X v10.5 supports
packet signing, packet encryption, and dynamic DNS updates by default.
The login process after
binding to Active Directory is similar to the login process after binding
to any other LDAP directory node.

References

Administration Guides

·
Command-Line Administration

http://images.apple.com/server/macosx/docs/Command_Line_Admin_v10.5.pdf

·
Open Directory Administration

http://images.apple.com/server/macosx/docs/Open_Directory_Admin_v10.5.pdf

Apple Knowledge Base Documents

·
Mac OS X: Using the Active Directory plug-in in
a multidomain controller environment

http://docs.info.apple.com/article.html?artnum=301010

·
Using network homes with the Active Directory
plug-in for Mac OS X 10.3.3 or later

http://docs.info.apple.com/article.html?artnum=107943

·
Mac OS X 10.5: Active Directory—Name and
password considerations when binding with Directory Utility or dsconfigad

http://support.apple.com/kb/TS1532

http://www.likewisesoftware.com

·
SMB/CIFS Comparison

http://www.grouplogic.com/products/extremeZ-IP/?fa=smb-cifs-comparison

·
Introduction to Microsoft Windows Services for
UNIX 3.5

http://technet.microsoft.com/en-us/library/bb463212.aspx

·
Microsoft^® Windows Server™ 2003
Performance Advisor

http://www.microsoft.com/downloads/details.aspx?familyid=09115420-8c9d-46b9-a9a5-9bffcd237da2&displaylang=enAdd your content here

Welcome to Ihsan Yahya’s Home Page

Knowledge Is Power