10.7 and 10.8 Clients do not generate Kerberos tickets at login: FIX

(For information about forcing 10.6.x clients to get a Kerberos ticket at login see this Apple KB)

We have encountered a problem where Lion and Mountain Lion clients are not generating Kerberos tickets at login.  This causes problems with single-sign-on (SSO) to network shares as well as with Kerberos enabled applications like SAP.

Apparently Apple's latest version of Kerberos will not automatically request a ticket when a Kerberos enabled application launches.  Instead you must either go to Terminal and type "kinit" and enter your password or force a ticket to be generated at login using the following instructions.

Note: in order to correctly authenticate using Kerberos enabled applications like SAP your user name in AD and in the application itself must match.  This means that both your SAMAccount name and UPN in must be identical- including the case.  Many non-Microsoft instances of Kerberos are case-sensitive.

To generate a Kerberos ticket at login (10.7 and 10.8 clients):

•  Open Terminal
• Type "sudo -s" and authenticate as super user
• Navigate to /etc/pam.d
• Type "cp authorization authorization.bak" to make a backup of the authorization file
• Type "pico authorization" to edit the file (you could also use vi or your favourite editor)

Find the line:

auth       optional       pam_krb5.so use_first_pass use_kcminit

Add the key "default_principal" to the end of the line. For example:

auth       optional       pam_krb5.so use_first_pass use_kcminit default_principal

• Save the file
• Restart and log back into the computer
• Check that a Kerberos ticket has been generated by opening Terminal and typing "klist"

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"

Lion clients unable to connect to Snow Leopard server

If you are attempting to connect from a bound Lion client to a bound Snow Leopard server you must use the FQDN for the server. 

For example:  myserver.test.network.com

If you do not you may receive an error that says "The version of the server you are trying to connect to is not supproted.  Please contact your system administrator to resolve the problem."

Also check what authentication method you are using.

• Open Server Manager
• Highlight "AFP"
• Click on the "Access" tab
• Change "Authentication" to "Any Method"

Attempt to connect from at Lion client using the FQDN of the server.

Note: changing the authentication to Any Method can possibly break single-sign-on for Snow Leopard client.  If this happens change the authentication to "Kerberos".  Lion clients should still be able to access the server.

How OS X uses login names to generate Kerberos tickets

AD users have two valid names that can be used for authentication: the login name and the "pre-Windows 2000", or "short" name. 

OSX recognizes both of these as valid, however in order to have a Kerberos ticket granted the user must login with the short (pre-Windows 2000) name.  Login attempts using the long name or domain\username will not be granted a Kerberos ticket.

Shaking Login: corrupt Kerberos file

Apple has informed us that sometimes anti-virus software can corrupt the kerberos files found in:

/var/db/dslocal/nodes/Default/config/

They suggest that a trouble shooting step for a shaking login should be to remove all the Kerberos files in the above directory.

sudo /var/db/dslocal/nodes/Default/config/
rm Kerberos*

then restart.

How to force a 10.6 client to generate a Kerberos ticket at login

Refer to this Apple KB article:

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

You need to add the string:

builtin:krb5store,privileged

Under the key:

system.login.console

In the /etc/authorization file

Generating a kerberos ticket from the command line in OS X

kinit [user name]

You will be prompted for the user's password

Bound Leopard Server not allowing SMB or AFP connections

Problem:  A 10.5.8 server was not allowing SMB or AFP connections.  The server was bound to AD but "id" commands were failing- sometimes.

Looking at the logs I saw that they were filled with launchd errors:

 com.apple.launchd[1] (org.openldap.slapd): Throttling respawn: Will start in 10

These were causing very, very poor performance and pretty much preventing Directory Service from operating; that in turn prevented any logins.

The first thing I attempted was to unbind the server but as it couldn't connect to the domain I did a Force Unbind, deleted the edu.mit.kerberos file and the Directory Services folder and restarted.  I then re-bound the server and immediately unbound: this ensured that the server's AD account would be removed.

From the unbound server I took these actions:

• Changed the Windows role to Standalone server
• Stopped the SMB services
• Opened Terminal and ran "sudo –s /usr/libexec/slapd –Tt"

This returned:

could not stat config file "/etc/openldap/slapd.conf": No such file or directory (2)
slaptest: bad configuration file!

I then viewed the contents of the directory:  cd /etc/openldap/ls

There was no slapd.conf file present but there was a slapd.conf.default file so I renamed  it: "cp slapd.conf.default slapd.conf"

I then re-ran the slapd command:  "/usr/libexec/slapd –Tt" and it returned:

bdb_db_open: Warning - No DB_CONFIG file found in directory /private/var/db/openldap/openldap-data: (2)
Expect poor performance for suffix dc=my-domain,dc=com.
config file testing succeeded

Since LDAPv3 is turned off in Directory Services this shouldn't be a problem

• Reboot 
• Launch Server Manager
• Change the Windows role to Domain Member
• Start the SMB service

AFP and SMB log-ins now worked.

These steps and more info can be found here:  http://discussions.apple.com/message.jspa?messageID=10613310

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: Kerberos ticket not renewing coming out of Screen Saver

We had another case opened with Apple about Kerberos ticket not renewing after typing in password coming out of screen saver in Snow Leopard. They send me this instruction on modifying a file in /etc and it looks like it is resolving the problem. If you guys have Snow Leopard machine bound to AD. Please try it out too so we can confirm it does work.

Please edit the "“system.login.screensaver” entry in the /etc/authorization file to read like this:

system.login.screensaver

class
rule
comment
(Use SecurityAgent.) The owner or any administrator can unlock the screensaver.
rule
authenticate-session-owner-or-admin


Note that the string:

The owner or any administrator can unlock the screensaver

is changed to:

(Use SecurityAgent.) The owner or any administrator can unlock the screensaver

Mac: Kerberos time-outs and locked screen saver

This is an interesting little glitch.

On AD bound Macs if a user has their screen-saver set to require a password to deactivate and the user leaves their computer on for more than 10 hours, they will not be able to unlock the screen-saver. Apple has confirmed that this is a problem and advises that the user should enter their user name and password and then wait for one minute before they press “OK.”

This affects all versions of OS X through 10.5.7. The latest 10.5.8 patch is supposed to fix the issue.

The default time-out for a Kerberos ticket is 10 hours but with the screen-saver password lock enabled the Mac doesn’t auto renew the ticket properly. Normally every time you unlock your screen-saver it refreshes the Kerberos ticket back to 10 hours but this simply doesn’t happen if they machine has been sitting on and idle for over 10 hours.