Troubleshooting Mac Binding and Authentication Problems: AD perspective

Ensuring a clean DNS and directory environment is key to resolving a host of problems, not all of them Mac specific.  Many binding, authentication and slow login issues can be traced back to incorrectly configured DNS, a missing subnet in Sites and Services or poor replication between domain controllers.

This post is designed to provide a check list of sorts for directory services administrators as they attempt to diagnose Mac and AD issues.  None of the steps listed here are designed for end-users or the Mac clients themselves- they are back-end checks for system administrators comfortable with DNS, DHCP and domain controller diagnostics using the command line.

Domain Controller Checks

The health of the local DC is a factor with Mac binding and post-binding authentication problems.  Many sites have ageing DCs with inadequate RAM and they may not be able to process authentication request properly.

Adding to the problem is the fact that pre-Lion Macs are only dimly site-aware.  This means that during the binding process they can attempt to connect to whatever DC they find that has a valid SRV record.  Thus, even if a local DC is brand new and functioning perfectly, Macs could still have binding problems because they are looking to a DC on a remote site that is not reachable or otherwise unavailable.

Steps can be taken on the client to force the use of the local DC: using a custom edu.mit.kerberos file and setting the local DC as the preferred domain controller during the binding process.  These procedures are detailed in other posts on this site.

From a Directory Services standpoint there are several checks that can be done to ensure that the DC is performing optimally.

• Check the RAM.  1GB is generally not enough
• Check the processor load to ensure the CPU is not consistently running over 50%
• Check that the primary DNS is set to the DC’s IP address
• Check that the secondary DNS is correct
• Remove WINS from the NIC configuration
• Run a dcdiag to check the general health of the DC
• Ensure that the DC is not multi homed.  If NIC teaming is enabled, ensure that it is configured correctly.
• Run “repadmin” to ensure that the DC is replicating properly and that there are no latency issues

DNS Checks

Mac binding is heavily dependent on a pristine DNS environment.  Duplicate A or PRT records cause major problems.  Additionally, Mac clients prior to 10.7 Lion do not reliably register PTR records.  Without these reverse records Macs can fail to bind and may experience authentication issues.

The first step in any troubleshooting process is to check for duplicate A and PTR records.  Our organization enables PTR record scavenging; this has caused the instance of duplicate PTR records to drop dramatically.  However, duplicates can and do creep in and enabling A record scavenging is not recommended .  A full clean-up involves  removing all workstation A and PTR records and starting fresh.

• Connect to DNS on the local DC (or open the DNS mmc snap-in)
• Expand the Reverse Lookup Zones
• Find the zone or zones for the site
• Highlight and delete all existing PTR records
• Do not delete PTR records for non-Windows servers or network devices
• Expand the Forward Lookup Zones
• Delete the A records which belong to desktops and notebooks only!

Because of changes in the DNS snap-in, it is no longer possible to easily search for PTR records by subnet.  Therefore in order to find and delete errant PTR entries you must use the DNS services on a 2003 DC or the XP DNS mmc snap-in.

The DHCP server must be set to update A and PTR records as well as grant ownership of the records to a service account.  These changes are detailed in the “DHCP Checks” section of this page.

SPN
Check Service Principle Names (SPN) using setspn -l [server short name]

In particular you are looking to see that the ldap, DNS and HOST entries are present and have both the short and FQDN of the local DC.

SRV
Check for missing or inaccurate SRV records.

• Open DNS snap-in
• Go to Forward Lookup Zones
• Expand the domain
• Expand “_sites"
• Locate the site you are working on
• Expand the location and click on “tcp”
• Ensure that the correct _kerberos and _ldap entries are present

Most locations should have only one _kerberos and _ldap entry and they should be directed to the local DC.  Some sites have many entries; it has been found that multiple entries can cause slow logins for both PCs and Macs and also prevent Macs from binding/authenticating correctly.  Unless there is a specific requirement, SRV records in this location should be kept to an absolute minimum.

Conversely, if the site is missing _kerberos or _ldap entries they need to be added.  Check the following locations to ensure that the local DC’s SRV records are present:

• Open DNS snap-in
• Go to Forward Lookup Zones
• Expand the domain
• Click on “_tcp”
• Check that the local DC has both _kerberos and _ldap entries. If not, add them
• From the domain level expand “_msdcs”
• Expand “dc”
• Open “_tcp” and check that the local DC has both _kerberos and _ldap entries. If not, add them

SRV records for the DC should be created each time Netlogon service starts however, sometimes this must be forced.

• On the DC open a terminal window
• Run the command “nltest /dsregdns” to force the DC to register it’s SRV records in DNS

nltest is also useful for checking and repairing secure channel communications issues.  A full list of nltest commands can be found HERE.


DFS
Check that DFS is active on the local DC.

• Go to Start/Run
• Type  \\your.domain.here\sysvol
• Right-click anywhere in the folder window
• Got to Properties/DFS
• The active DFS patch should be the local DC

If the local DC is not the active DFS path follow these instructions to correct the problem.

Sites and Services

Like Windows computes, Macs use Sites and Services to ensure that they are authenticating to the correct DC.  Get a list of subnets from the location and ensure that they are entered into Sites and Services correctly.  Make sure the list includes any Wi-Fi subnets that are on the IPG network as well as server subnets.

Double check that the correct DC is setup and that its replication partners are correct.  It is also a good idea to force replication (you may have already done this using “repadmin” in an earlier step).

DHCP Checks

DHCP must be configured in such a way that Mac clients are forced to register A and PTR records when they receive a DHCP lease.

The site must be running a Windows 2003 or later DHCP server in order to make these configuration changes.  The process will not work with Windows 2000 DHCP.

• Open DHCP manager either through the mmc snap-in or on the DHCP server
• Right click on the server and select Properties
• Click on the DNS tab
• Put a tick in the following boxes
• Enable DNS dynamic updates according to the settings below:
• Always dynamically update DNS A and PRT records
• Discard A and PTR records when lease is deleted
• Dynamically update DNS A and PTR records for DHCP clients that do not request updates
• Click on the Advanced tab
• Click the Credentials button

Here you should enter the name of a service account that will own the DNS records.  You can make the account name anything you like but its purpose should be apparent, "service.dns" or "service.dnsrecords" etc.  Create the account on AD and set the password to never expire.  This account will be used by DNS to add and delete records when machines get new leases or old leases expire.  Without this account records can remain in DNS; if a Mac client attempts to use an IP that is already associated with a DNS record the client can fail to bind.

• User name: your DNS service account
• Domain: netbios name for the domain
• Password: enter the service account password
• Click OK and OK again to save the changes 

Further DHCP checks

• Remove WINS from the DHCP scope
• Check that the DHCP scopes match what is in Sites and Services
• Check that the FQDN of the domain is correct
• Check that the primary and secondary DNS servers are correct
• Look at the DHCP leases and delete any that do not have a resource name associated with them
• Check that there are enough free IP addresses

User Account Checks
Once a Mac client has been bound to AD it can experience a host of authentication issues.  These normally manifest themselves as a “shaky login”: when a user attempts to log in the authentication window shakes and denies them access. 

Although most of the troubleshooting steps regarding shaky logins involve client-side procedures, there are a couple of things you can check in AD.

• Remove the UNC path to the user’s home folder in their AD profile
• Ensure that the SAMAccount name and UPN match and are in all lower-case

Conclusion
DNS issues cause the vast majority of Mac binding and authentication issues.  If a site is having across the board problems in these areas, performing DNS health checks should be Directory Services’ first troubleshooting steps.

Shaking login with console error: Could not get a user record for [username] from Directory Services

Symptom

After binding a Mac AD account log-ins fail (shaking login).  Console logs report the following:

SecurityAgent[735] Could not get user record for 'username' from Directory ServicesSecurityAgent[735] User infor context values set for usernameSecurityAgent[735] unknown-user (username) login attempt PASSED for auditingSecurityAgent[735] Could not get the user record for 'username' from Directory Services

kinit [username] will generate a Kerberos ticket

id [username] will produce a list of LDAP info for the AD account


login [username] fails


Solution

If you see the Console log errors as described above it generally means that the computer is not able to create a mobile account at log-in.  Try creating a mobile account from Terminal first:


sudo /System/Library/CoreServices/ManagedClient.app/Contents/Resources/
createmobileaccount -n username
sudo createhomedir -c -u username

Log out and back in with the user's AD credentials.

Can not log in to bound Mac using an AD account

Symptom 
A Mac that has been bound to the AD will not allow log-in from a particular AD user.  Other AD accounts are able to log-into the bound Mac and the user can log-into other computers.

This is generally a symptom of a corrupt account on the computer.  You have several options to remedy the situation.

Solutions

Scenario One:  You are migrating a local account to a domain account.  You have bound the computer and are attempting to log in for the first time using the user's AD account and you get a shaking log in or an error "you are unable to log into the user's account".  Follow these steps to create a new local account, migrate the user’s data to that account then create an AD account and migrate the data to the AD account.

• Log in as root
• Unbind the computer and delete the entire /Library/Preferences/Directory Service folder and the edu.mit.kerberos file
• Restart the computer
• Log in as root
• Go to System Preferences/Accounts
• Create a new local account for the user
• Do not use the same name as the user’s AD account
• Do not use the same name as the existing account
• Go to Users and locate the user’s old home folder
• Select all the folders in the old home folder and drag them into the new home folder for the account you just created.  When it prompts you select Replace All
• Go back to the Desktop hit Shift-Apple-U to open the Utilities folder
• Launch Terminal
• Type cd /Users
• Type chown –R [user name]:staff /Users/[user name]. For example:  chown –R tsmith:staff /Users/mlewis
• Remember, you are doing the above command on the newly created home folder- the one you copied all the data into
• Use the newly created account name for “user name”
• Re-bind the computer
• Log out and then back in with the user’s AD account
• This will create a new blank profile
• Log out and back in as root
• Go to Users and locate the local home folder you created in a previous step (the one you moved all the data into and did a “chown” on)
• Select all the folders in the folder and drag them into the newly create home folder (it will have the user’s AD name)  When it prompts you select Replace All
• Go back to the Desktop hit Shift-Apple-U to open the Utilities folder
• Launch Terminal
• Type cd /Users
• Type chown –R [user name]:staff /Users/[user name]. For example:  chown –R tom.smith:staff /Users/tom.smith
• Log out and back in using the user’s AD account credentials
• Their desktop icons should appear
• Go to Users/[user name]/Library/Keychains and rename the login.keychain to login.keychain.old 

 
Scenario Two:  Sometimes having a UNC path to a home folder in AD prevents a user from logging in.  In this case the user can not log into any Mac but loggin into a PC works.

Open the user's AD account and go to the Profile tab.  If there is a UNC path to a home folder, remove it.  Wait for replication and attempt to log in again.

Scenario Three:  You have bound the computer and are attempting to log in for the first time using the user's AD account and you get a shaking log in or an error "you are unable to log into the user's account".

Other users can log in using their AD accounts.  Checking System Preferences/Users DOES NOT show an account for the user that is unable to log in.

It is possible that the AD profile was partially created but that the process failed somewhere along the way.   You first need to check if the profile exists on the computer even though it is not in "Users".

• Open a Terminal window
• Type "dscl localhost"
• Type "cd /Local/Default/Users
• Type "ls"
• If the problem user's account is displayed you must remove it

To remove the account you must first download and install Apple Server Admin Tools onto the client computer.  10.6.4 admin tools can be found here:
http://support.apple.com/kb/DL1071

After you have installed Admin Tools follow these steps to remove the problem account:

• Go to Applications/Server
• Launch Workgroup Manager (WGM)
• At the connection screen enter an address of "localhost" and the UID and password of the local machine administrator
• In WGM click on the "Accounts" icon
• Make sure you are authenticated to /Local/Default
• Click on the single-user icon above the search menu

•  Find the problem account in the list and click on the "Delete" icon
•  Exit WGM and attempt to log into the machine again with the user's AD account

 

Mac Binding Fails- Advice from Apple

Apple's KB regarding binding problems and possible work-arounds involving clearing out Kerberos config files and DNS config check:

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

Snow Leopard: first impressions

I did these tests using an older 1.83 GHz iMac Core Duo with 1GB of RAM

Binding

Logged in as “administrator” binding from the “Join” button in Accounts failed with an error “unable to add server eServerSendError -14740.”

When binding through Directory Utility I received a notice that the computer account already existed.  I checked the entire directory and the account was not there.

In Terminal I typed “dsconfigad- show” and found that the computer name was different than the name I had specified for the computer.  I searched the AD and found the computer account listed by the “show” command and deleted it.

I also deleted all the PRT records for my subnet and reconfigured DHCP so that our DNS service account owned the DNS records.  This is our new standard DHCP/DNS setup for all subnets.

I attempted to bind again with the [binding service account] and the bind failed with “insufficient privileges.”   Using my domain admin account, I was able to bind the computer.

The edu.mit.kerberos file generated by the binding process was incorrect (lacking realm and server information) so I replaced with a file containing the correct information.

LDAP lookups were handled properly after the bind.

dsconfigad- show displayed the correct computer name.

Restarted the computer and logged in with my AD account.  I was given a warning that my password would expire in 29 days (I had just changed my password) and it prompted me to set up a mobile account.  On subsequent logins I was not given the password expiration warning. 

Restarting the computer was very quick- it only took about 40 seconds.  Directory Services was slow to start: 30-45 seconds after the login window appeared.

File handling and transfers

It has been reported that connecting to an SMB volume produces a beach ball lockup.  I was able to connect to SMB shares (using SSO) but it took about 2 minutes.  AFP connections were virtually instantiations.

3GB transfers to/from a SMB share on a Windows 2003 server across a 100mb network took 3 minutes.

3GB transfers to/from an AFP share on a Mac Mini running 10.5.8 server across a 100mb network took 6 minutes.

If I enabled Secure Empty Trash I was unable to delete the 3GB file.  It would hang about halfway through the process and I was forced to restart the Finder.  Turning off Secure Empty Trash allowed me to empty the trash without a problem.

Deleting an item from an AFP or SMB server volume closed the window.

There is now a “put back” function in Trash just like in XP.

Mac Mail

Auto setup asked twice to trust the certificate from IPG mail server.

There was no need to configure LDAP to do a GAL lookup.

Mail cannot access Public Folders.

There is now an archive mail function.

Meeting invites from Outlook and Entourage functioned perfectly regardless of whether or not they had attachments.

Meeting invites to Outlook and Entourage functioned perfectly.

It took a long time for mail to download and display in the Inbox window.  Both my Blackberry and Entourage received mail much faster.

Notes are now synced properly with Blackberries.

Removing signatures locks up Mail.

There is no way to remove attachments!  You must delete the entire mail.

Calendar

Delegates are limited to Calendar viewing only: you cannot configure shared mailboxes from the Mail client.

Free/Busy status in Calendar worked very well and it is nice that you can search for the next available time your invitees are available.

When viewing another person’s calendar their events are merged into your calendar and displayed as a different colour.  People will either love this or hate it.

Once you’ve started to create a meeting request there is no “Cancel” button.  You have to finish the request and then delete it.

Tasks entered into Mail say they will be put into a Tasks calendar but they are not.

There doesn’t seem to be a way to change the colour of calendar events.

Invites sent from a different time zone display the correct local time in the message header.  The body text shows time for the sender, accepting the invite puts it into Calendar at the correct time.  Entourage still has the problem where meeting invites sent from different time zones display the incorrect time when you double click on the event in your calendar.

There is a handy button that changes the time zone for all events in your calendar.  Changing them back works too!

Address Book seems to be pretty much unchanged.