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"

Using Snow Leopard server for Lion software updates

Here is a step-by-step guide for setting up a Snow Leopard SUS server so that it will distribute Lion updates.

I do not know who originally wrote this article.  If anyone can find the author please let me know and I will credit him/her.


First things first. Fire up Server Admin and stop the Software Update service. Next fire up a Terminal window and head to /etc/swupd.

cd /etc/swupd

Now let's make backups of the .plist and .conf files for swupd.

cp swupd.plist swupd.plist.bak; cp swupd.conf swupd.conf.bak

Great. Now we are going to add a catalog to the catalog array in the swupd.plist. When we are done it will look like this:

otherCatalogs
   
    
       index-leopard.merged-1.sucatalog
       
       index-leopard-snowleopard.merged-1.sucatalog
       
       index-lion-snowleopard-leopard.merged-1.sucatalog
   
    

You can do this with a text editor, but PlistBuddy makes it easier.


sudo /usr/libexec/PlistBuddy -c 'add :otherCatalogs:2 string index-lion-snowleopard-leopard.merged-1.sucatalog' /etc/swupd/swupd.plist

Will do it in one shot. Adding this catalog is what will tell our SUS Server to go and get the Lion updates.

The next bit we need to do is to tell the server that it can provide this catalog to Lion clients. Open up swupd.conf with the editor of your choice.

vi swupd.conf

Go to the bottom of the file, or just search for Rewrite. Look for the Darwin/11 agent string and change the rewrite rule to look like this.

RewriteCond %{HTTP_USER_AGENT} Darwin/11
RewriteRule ^/index.sucatalog$ /index-lion-snowleopard-leopard.merged-1.sucatalog

Basically we are adding the word "lion" into the sucatalog name.

Now close out of the terminal and start up the Software Update Service with Server Admin again. If you watch the logs, or the updates tab, you will see the Lion updates and on-demand software appear and begin downloading. After a while they will be local and you can start updating those Lion clients!

How to enable Directory Services debugging and packet capture at log on

When diagnosing login problems it can be very helpful to generate a packet capture during log-in.  Unfortunately tools like Wireshark or PacketPeeper do not run at start-up. 

Following are the commands to enable DS debugging and a packet capture during log-in.  You will need another computer connected via SSH to the one on which you want the packets captured.

1. Run the following command to set the debug level to seven (all one line):
       
 sudo defaults write /Library/Preferences/DirectoryService/DirectoryServiceDebug "Debug Logging Priority Level" -integer 7

NOTE: Only run this command if you are running 10.5 or later

2. Enable Directory Service Debugging by running the following command:
        
        sudo /usr/bin/killall -USR1 DirectoryService
       
3. SSH to the client and start a packet capture:
       
        sudo /usr/sbin/tcpdump -vvv -n -s 0 -w /Library/Logs/`date +%Y%m%d-%H%M%S`.pcap
               
4. Reproduce the issue by attempting to login.

5. Stop the packet capture using Control+C.

6. Disable Directory Service Debugging by running the following command again:
        
        sudo /usr/bin/killall -USR1 DirectoryService

The capture will be in the /Library/Logs with a ".pcap" extension.