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.

Restoring Windows shares after migrating data from one server to another

Situation:  An office used robocopy to copy files from a Windows 2003 file server to a Windows 2008 R2 server.  Permissions were copied but shares were not.

Follow the steps below to restore the file shares.  Note: the drive letters and paths must be the same on the two systems or this procedure will not work.

This procedure applies only to NetBIOS shares and not to Macintosh volumes.

1.  On the SOURCE server that contains the shares that you want to transfer launch regedit
2.  Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
3.  Export the registry key by going to the File menu and clicking on Export
4. Save the file to a location that is accessible from the new server
5. On the TARGET server launch regedit
6. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
7. Import the saved registry key by going to the File menu and clicking on Import
8. Enter the path to the saved registry key that you exported in step 3
9. Restart the server

 Full details of this procedure can be found in this MS KB article.

OS 10.7 Lion and Citrix: 100% CPU use after upgrade

After upgrading from 10.6.8 to 10.7.4 I noticed that my battery life plummeted.  Prior to the upgrade I would be getting a solid 5 hours; after installing Lion my battery life dropped to 1:15.  Applications were also performing very poorly and the entire system seemed sluggish.

After some investigation and speaking with Apple I discovered that the problem was with the Citrix Access Gateway plug-in.  I removed it and my system instantly returned to normal.  In fact I started getting six hours of battery life so it could have been causing problems when I was on 10.6.8 too.

Citrix has acknowledged that several of their Receiver components are having problems with Lion.  HERE is a link to the Citrix page that explains the problems and offers work-arounds.