Publishers of technology books, eBooks, and videos for creative people

Home > Articles > Apple > Operating Systems

  • Print
  • + Share This
This chapter is from the book

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        =
  Active Directory Domain        =
  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
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 has SRV record 0 100 389
client17:~ cadmin$ host -t SRV has SRV record 0 100 88
client17:~ cadmin$ host -t SRV has SRV record 0 100 464
client17:~ cadmin$ host -t SRV has SRV record 0 100 3268

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

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,” but each of these telnet sessions successfully connect to the service:

client17:~ cadmin$ telnet 389
Connected to
Escape character is '^]'.
Connection closed by foreign host.
client17:~ cadmin$ telnet 88
Connected to
Escape character is '^]'.
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:

  1. 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.
  2. Mac OS X binds anonymously with LDAP and gathers basic Active Directory domain information.
  3. DirectoryService’s Active Directory plug-in creates a preliminary Kerberos configuration.
  4. Mac OS X uses the Kerberos configuration, authenticates, and then requests the nearest Domain Controller.
  5. The Domain Controller returns a list of the nearest Domain Controllers, based on the IP subnet of the Mac OS X computer.
  6. 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/ and /var/db/dslocal/nodes/Default/config/Kerberos:REALM.plist.
  7. Mac OS X connects to what it was told was the nearest Domain Controller.
  8. 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/ 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 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.

  • + Share This
  • 🔖 Save To Your Account