Slow Login on Snow Leopard Clients Bound to AD

We have received several reports that Snow Leopard clients that are bound to AD are experiencing very slow logins- up to five minutes before the desktop would appear.

One fix is to remove Active Directory/All Domains from the Authentication tab in Directory Services.  Once this is done the login is very fast.

The drawback is that no other user will be able to log into the computer using their AD credentials.

AD password changes done via the login screen or System Preferences/Users/Change Password continue to work.

Full details can be found on Tech Smog.

Single-Sign-On (SSO) not working for Snow Leopard clients connecting to a Windows server running ExtremeZIP

We received a report from an office that three of their Windows 2003 servers running ExtremeZIP were not allowing SSO connections from AD bound Snow Leopard Macs.

After a good deep-dive into the problem, including packet traces and help from Group Logic, we resolved the problem.  Here are the steps we took:

Make sure the Mac clients are using the FQDN to connect to the ExtremeZIP AFP volume on the server.  Short names should not be used (in Lion you must use the FQDN or you get an error).

Check that the time on the server, clients and DC match.  One of the servers' clock was out by six minutes (max Kerberos time skew is five minutes).  When the time was set correctly Lion clients were able to log in.

Check that the Server Principle Name (SPN) of the servers is correct; if they are not then authentication can fail.  Read more about SPNs here.

To check the SPN on a Windows 2003 server you must first download and install Windows Server Support Tools.  You can get them here.

After you have installed the tools go to Programs/Windows Server Support Tools and launch the app- it will open a command line.

Both the long and the short SPN for the AFP protocol need to exists for your servers:
afpserver/servername.company.com
afpserver/servername

To display the SPNs from the Support Tools command line type "setspn servername"

You should see both the FQDN and the short name.  If one is missing do the following:

- To add the long name: setspn -a afpserver/servername.company.com servername
- To add the short name: setspn -a afpserver/servername servername

We also found that although the Snow Leopard clients were authenticating users correctly, they were not generating a Kerberos ticket at login (you can verify this by going to the Ticket Viewer.app located in System/Library/Core Services).  After manually generating a Kerberos ticket, SSO worked.

To force a Snow Leopard client to generate a Kerberos ticket at login follow the instructions in this Apple KB article.

After carrying out each of these steps, the Snow Leopard clients were able to get SSO to the ExtremeZIP enabled servers.

Although it wasn't necessary in this case, make sure you update ExtremeZIP to the latest version

How to check if an Apple server is Kerberized against AD: verify Service Principals

If Mac clients are having trouble accessing a bound OS X server, check that the server is Kerberized against AD.  First, run the following command:

sudo klist -kt

You should see a number of service principals with the Kerberos realm of your.domain.com

Second, you need to ensure that the correct service principal is in use by the AFP service.  You can use the following command to do this:

sudo serveradmin settings afp:kerberosPrincipal

This should show something like "afpserver/@YOUR.DOMAIN.COM".   If it shows a value in the LKDC realm it is incorrect and will need to be fixed before you can connect using Kerberos.

Here's a command you can use to fix it:

sudo serveradmin settings afp:kerberosPrincipal = "afpserver/@YOUR.DOMAIN.COM"

Shaking login: duplicate accounts

We had a user who couldn't log into any bound Mac but was able to log into Windows machines.  After much swearing and consternation we found that there was already a user with the same login and pre-Windows 2000 name as our user in a different domain of our forest.

Macs search forest-wide for authentication information and the PCs only look in the current domain.  Thus all user accounts must be unique everywhere within a forest or the duplicate user will be unable to log in.  By changing the login and pre-Windows 2000 names of the user in our domain he was able log in.

Mac savvy readers might point out that there is a tick box in Directory Services that says "Allow authentication from any domain in the forest".  One might think that un-ticking that would force the Macs to only look to the domain it is a member in for authentication information but this is incorrect.  In practice we have found that this tick-box does nothing at all and Apple admits that it is of little use.

Keep in mind that when you bind a Mac and then look in the Search Policy it displays "Active Directory/All Domains".  Therefore it will look in all available AD domains in the forest for authentication information.

Cannot exit Snow Leopard Screen Saver with AD credentials

On bound Macs there is a problem where a computer that has been left on, with the screen saver active, for more than 10 hours has its Kerberos ticket expire.  If this happens a user is unable to unlock the screen saver using their AD credentials.

Here is the KB article from Apple on how to fix this problem:

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

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