- Configuring Mac OS X to Log In Using Active Directory
- Troubleshooting Binding Issues
- Troubleshooting Login Issues
- What You've Learned
- References
- Review Quiz
This chapter is from the book
This chapter is from the book
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 = 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.
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.