- Configuring Mac OS X to Log In Using Active Directory
- Troubleshooting Binding Issues
- What Youve Learned
- References
- Chapter Review
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 connector 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$ dscl /Active\ Directory/All\ Domains -list /Users
[A successful bind will display a list of users; not shown here.]
client17:~ cadmin$ id -p aduser01
uid=1551314511(aduser01) gid=36262516(PRETENDCO\domain users)
groups=36262516(PRETENDCO\domain users),62(netaccounts),12(everyone),402(com.apple.
sharepoint.group.1)
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, and then rebind each computer to Active Directory.
Using DS Debug Error Logs
If the bind fails, enable directory service debug error logging (see “Troubleshooting Directory Services” in Chapter 1), try the bind again, and look for the phrase “Bind Step” in the DirectoryService.debug.log. You could use the Console application, or at the command line, use the following command:
tail –f /Library/Logs/DirectoryService/DirectoryService.debug.log | grep "Bind Step"
The following figure shows the this command and the output associated with a successful bind to Active Directory:
)
For even more information on the bind process, search for “Active Directory:” in the debug log. Be sure to include the colon, otherwise you will see each of the numerous entries that mentions “Active Directory”; the messages relating specifically to binding include the colon character. The following figure illustrates only a portion of the large amount of information in the debug log that starts with “Active Directory:” during a successful bind:
)
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 connector 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 here:
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, it may be impractical, because many SRV records are required, and 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 your access to the service is not blocked by a firewall and that you can make a basic connection to each service port. When you see a Connected to message from the service, enter 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.
Following 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 389Trying 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 88Trying 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 connector creates a preliminary Kerberos configuration, which may be replaced during this process.
- 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.
- Mac OS X updates its Samba machine password and domain SID.
- Mac OS X updates its DNS record in Active Directory.
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 (not recommended due to security concerns).
- Use an administrator account to perform the bind.
Many administrators choose to create an Active Directory user that has few rights other than the ability to join computers to a domain and use this user for scripts.
Unbinding from Active Directory
You can unbind from Active Directory with the Accounts pane of System Preferences, 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 should probably 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 connector, remove the files that are associated with the Active Directory connector, 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
Update your search paths with the command:
client17:~ cadmin$sudo dscl /Search -delete \/ CSPSearchPath \/Active\ Directory/All\ Domainsclient17:~ cadmin$sudo dscl /Search/Contacts -delete \/ CSPSearchPath /Active\ Directory/All\ Domains
[There is no output from these commands.]
/Library/Preferences/edu.mit.Kerberos is automatically generated based on nodes in your authentication search path, so you shouldn’t need to modify that file (unless you removed the autogeneration lines from that file).
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(s) for the Mac OS X computer that the Active Directory connector created and updated in the DNS service
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. You will not be able to use su to switch to an Active Directory user, and dscl with -authonly for an Active Directory user will return an eDSAuthFailed error even if you supply the correct password. However, if you are troubleshooting, you should be aware that you will be able to obtain a Kerberos TGT for an Active Directory user. In this case, you must unbind and rebind to Active Directory.
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” earlier 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 a local administrator, and then use su to switch identity to the Active Directory user, or use dscl /Search -authonly username to verify authentication.
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. For more information about the Local KDC, see Appendix C, “Understanding the Local KDC,” available online.
Confirm that you can use kinit or the Ticket Viewer application (in System/Library/CoreServices/) to obtain a TGT from the Active Directory KDC with Active Directory user credentials.
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 savings 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 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.
- In the lower-left corner, click the lock to authenticate as a local administrator.
- Select the local account that conflicts with the Active Directory account.
- In the lower-left corner, click the Remove (–) button.
- When prompted, select “Don’t 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 “david (Deleted)” to the Active Directory user name
“dcolville”:
client17:~ cadmin$
sudo mv "/Users/david (Deleted)" /Users/dcolville - 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 following chown command 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.
)
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.