Technology from the trenches

Previous: Setting up Sieve and Vacation Messages on Mac OS X Server
Next: The MySQL ruby gem on Leopard (client)

Tiger to Leopard Server Migration, Part Four

Kerberos and Single Sign-on in Leopard Server

espressosjeemz.jpg It has been awhile since my last post of this series — sorry to keep you waiting. Kerberos on Mac OS X Server is a finicky thing, and it took me this long to get it working! Well, I did take a 3 week vacation, and was busy with other projects for at least 2 weeks … but it was a major pain in the ass to set up, and I’m not yet entirely satisfied.

To get straight to the point, the following procedure got kerberos with single sign-on up and running for me. Hopefully it will work for you too.

1. Make sure that DNS is properly configured

You need to make absolutely certain that your DNS is properly configured. There is a lot of info out there on the web about this. Run ‘hostname’ at the command line — it should spit out your fully qualified domain name (FQDN), which is the name of your host plus the domain name. i.e., leopardserver.netmojo.ca. Your domain name by itself is not a FQDN.

Run ‘host your-servername‘ on the command line. It should tell you your IP address. Then do the reverse: run ‘host your-ipaddress. This should give you your-ipaddress-backwards.in-addr.arpa domain name pointer your-full-hostname.

This wasn’t a problem for me, but apparently some people can’t get this to work, and this solves the problem: add “your-ip-address your-FQDN” to the bottom of the /etc/hosts file, so that /etc/hosts looks like:

127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost
123.456.789.111 leopardserver.netmojo.ca

Once you are certain that your DNS configuration is correct, you can get started on Kerberos.

2. Start from scratch

I decided to start from scratch by removing the Kerberos-related files and de-configuring the KDC, since it wasn’t working properly for me anyways, and I seemed to be going in circles trying to fix it. Some things were working, like client logins, but other things, like iChat and AFS still required users to enter their passwords. In retrospect, the problem was likely due to my import of user accounts via LDIF files without the proper authAuthority entries for the new server’s Kerberos.

Another annoyance was that, at some point, OSX automatically created a kerberos realm called “LKDC:SHA1.C9DB48C6101D5CF8A3B11CE41EF999B771B490F8″, which I learned is what 10.5 clients now do, since each Leopard client runs its own KDC. Anyways, I only need one realm on my server, and it’s name won’t be a random string.

To remove the existing Kerberos configuration, I followed this guy’s advice, and used sso_util to remove both of my realms:

sso_util remove -k -a diradmin -p mypasswd -r MY.REALM
sso_util remove -k -a diradmin -p mypasswd -r LKDC:SHA1.C9DB48C6101D5CF8A3B11CE41EF999B771B490F8

Then I moved these files/directories to a backup dir (which I never used again):

mkdir ~/backup
cp -R /var/db/krb5kdc ~/backup
rm -rf /var/db/krb5kdc
mkdir -m 0700 /var/db/krb5kdc
mv /etc/krb5.keytab ~/backup
mv /Library/Preferences/edu.mit.Kerberos ~/backup
mv /Library/Preferences/DirectoryService/ ~/backup

If you get an error when you try to move /Library/Preferences/edu.mit.Kerberos, the user immutable flag is probably set. Remove it with the command:

chflags nouchg /Library/Preferences/edu.mit.Kerberos

3. Create a new edu.mit.Kerberos file

Run:
/sbin/kerberosautoconfig -f /LDAPv3/127.0.0.1 -r MYREALM.CA -v -m leopardserver.netmojo.ca -u -v 5

4. Setup the KDC

First in LDAP:
/usr/sbin/kdcsetup -f /LDAPv3/127.0.0.1 -w -a diradmin -p mypasswd -v 5 MYREALM.CA
...

Then on the filesystem (a “stock MIT configuration”):
kdcsetup -a diradmin -p mypasswd MYREALM.CA

You should now have a bunch of files in /var/db/krb5kdc that relate to your realm, such as “principal.MYREALM.CA”.

5. Create service principles in LDAP

Run:
slapconfig -kerberize -f diradmin MYREALM.CA

6. Kerberize all of the services

Run:
sso_util configure -r MYREALM.CA -a diradmin -p mypasswd all

This will add principals for the FQDN; if there are other names that your clients will use to access services, you can kerberize them like so:

krbservicesetup -r MYREALM.CA -a diradmin -p mypass xmpp xmpp/ichat.netmojo.ca@MYREALM.CA

I have a CNAME in DNS for ichat.netmojo.ca that points to my server. The above will add kerberos records to allow authentication to the ichat service, with that name.

Check the logs to make sure that everything is working: /var/log/system.log, /var/log/krb5kdc/kadmin.log, /var/log/krb5kdc/kdc.log. You should be able to connect seemlessly with kerberized services now. Each service may have its own little quirks though. SSHing to localhost, for example, gives me:

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found
debug1: Unspecified GSS failure. Minor code may provide more information

IMAP seems to authenticate OK at first, but then changes its mind and asks for a password. iChat authenticates smoothly, as does AFP. I haven’t done other testing, but I get the sense that everything is going smoothly, and there are some service-specific gotchas to work out.

The next article will cover connecting client machines to the server. It seems to work effortlessly with Leopard clients, but I’m having some issues with a Tiger client…

Some useful resources

Tags: , , , , , , , ,

This entry was posted on Wednesday, January 30th, 2008 at 3:33 am MST and is filed under Articles, System Administration. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

15 Responses to “Tiger to Leopard Server Migration, Part Four”

  1. Urs Says:
    February 1st, 2008 at 2:38 pm

    The next article will cover connecting client machines to the server. It seems to work effortlessly with leopard clients, but I’m having some issues with a Tiger client…

    Which issues did you have?

  2. Brent Says:
    February 1st, 2008 at 2:52 pm

    I will discuss it in detail in my next post, but I was unable to bind to the directory from the Tiger client. I’m not using SSL, but otherwise all of the security options for binding are enabled, and there was a log entry indicating that at least one of them isn’t supported on Tiger.

  3. Urs Says:
    February 1st, 2008 at 3:22 pm

    I had posted my problem here:
    http://www.afp548.com/forum/viewtopic.php?showtopic=19422

  4. Brent Says:
    February 7th, 2008 at 4:26 pm

    As it turned out, the problem was a client side issue. The Tiger client had an old /Library/Preferences/edu.mit.Kerberos file with a non-existent REALM in it. This was somehow interfering with the bind process; when I changed the REALM in that file to the correct one, it bound to the server without a problem.

    However, I now have the same issue that you mention in your AFP forum post — no Kerberos authentication for the AFP service, even though users get a kerberos ticket when they login, and network home directories work…

  5. Brent Says:
    February 7th, 2008 at 4:59 pm

    I solved my AFP problem. Check the Kerberos principal in your AFP settings using the ’serveradmin’ command:


    sudo serveradmin settings afp:kerberosPrincipal

    It should match the afpserver principal that is listed in your keytab file:


    klist -kt | grep afpserver

    If not, you can set it using serveradmin:


    serveradmin settings afp:kerberosPrincipal = afpserver/leopardserver.netmojo.ca@MYREALM.CA

    It should echo the value after the ‘=’ back to you. After I changed this setting, I was able to login to a Tiger client, and I was automatically granted a kerberos ticket for afpserver/leopardserver.netmojo.ca@MYREALM.CA, and I could access the network filesystems without further authentication.

  6. Benjamin Says:
    February 29th, 2008 at 7:35 am

    It seems that this command:


    slapconfig -kerberize -f diradmin MYREALM.CA

    Actually performs the commands in step 2, 3 and the first command in step 6. It does a lot more also, including setting authAuthority records.

    I had a similar problem, that actually revolved around my /Local/Default directory and my LDAP directory containing stale Kerberos records. The records can be removed with the dscl utility:


    cd /Local/Default
    rm Kerberos*
    cd /LDAPv3/127.0.0.1/Config
    rm Kerberos*

    After doing this the slapconfig command worked just fine. Before removing the records the kdcsetup command failed with a segmentation fault…

  7. Mano Says:
    May 22nd, 2008 at 3:55 pm

    Brent,
    I am a power user who just switched to Leopard Server. I set it up at home and have had various issues with it. I was fairly certain I had Kerberos set up right but I couldn’t connect to AFP at all. (Though at one point it was working ?!?) Your tip made it work right for me. Thanks for taking the time to write that down.

    Mano

  8. Sean Says:
    May 30th, 2008 at 10:23 am

    I keep getting segmentation faults as well when running kdcsetup. Using the dscl utility I see that there are no Kerberos records to remove. Wondering if there is something else I’m missing?

  9. damien Says:
    June 3rd, 2008 at 6:18 am

    Hello,
    i’m sorry to disturb you again but our server as an other problem taht i don’t find docs or help on forums: cyrus seems to have a problem…all logs files in the mailing are good except the mail access that gives me :
    extrait du journal des logs mail access:
    Jun 3 13:35:03 artsway ctl_cyrusdb[3461]: DBERROR: couldn’t checkpoint: Operation not permitted
    Jun 3 13:35:03 artsway ctl_cyrusdb[3461]: DBERROR: sync /var/imap/db: cyrusdb error
    Jun 3 13:35:03 artsway ctl_cyrusdb[3461]: archiving log file: /var/imap/db/log.0000000001
    Jun 3 13:35:03 artsway ctl_cyrusdb[3461]: done checkpointing cyrus databases
    Jun 3 13:35:03 artsway master[161]: process 3461 exited, status 0
    Jun 3 14:05:03 artsway master[3524]: about to exec /usr/bin/cyrus/bin/ctl_cyrusdb
    Jun 3 14:05:03 artsway ctl_cyrusdb[3524]: checkpointing cyrus databases
    Jun 3 14:05:03 artsway ctl_cyrusdb[3524]: archiving database file: /var/imap/annotations.db
    Jun 3 14:05:03 artsway ctl_cyrusdb[3524]: DBERROR db4: /var/imap/deliver.db: unable to flush page: 0
    Jun 3 14:05:03 artsway ctl_cyrusdb[3524]: DBERROR db4: txn_checkpoint: failed to flush the buffer cache Operation not permitted
    Jun 3 14:05:03 artsway ctl_cyrusdb[3524]: DBERROR: couldn’t checkpoint: Operation not permitted
    Jun 3 14:05:03 artsway ctl_cyrusdb[3524]: DBERROR: sync /var/imap/db: cyrusdb error
    Jun 3 14:05:03 artsway ctl_cyrusdb[3524]: archiving log file: /var/imap/db/log.0000000001
    Jun 3 14:05:03 artsway ctl_cyrusdb[3524]: archiving database file: /var/imap/mailboxes.db
    Jun 3 14:05:03 artsway ctl_cyrusdb[3524]: DBERROR db4: /var/imap/deliver.db: unable to flush page: 0
    Jun 3 14:05:03 artsway ctl_cyrusdb[3524]: DBERROR db4: txn_checkpoint: failed to flush the buffer cache Operation not permitted
    ”

    D’apres ce que je comprends des erreurs qui sont repertoriées, c’est un probleme au niveau de cyrusdb… mais je ne comprends pas ou se situe le probleme: ce fichier etait utilise sur l’ancien serveur et fonctionne dessus, mais ne fonctionne pas sur le nouveau… quelqu’un peut m’aider? (je debute en mac )

  10. Ryan Says:
    August 11th, 2008 at 8:37 am

    I’m still getting Segmentation fault when trying to run step 4 ‘/usr/sbin/kdcsetup -f /LDAPv3/127.0.0.1 -w -a diradmin -p ***** -v 5 MYREALM.CA’

    Even after removing Kerberos* like Benjamin suggested.

    Also ’slapconfig -kerberize -f diradmin MYREALM.CA’ gives me an error:

    kdcsetup command failed with exit code 10: stdout=(null), error-message=Contacting the Directory Server

    Any advice?

  11. Ryan Says:
    August 11th, 2008 at 8:38 am

    Sorry, forgot to mention that the open directory master is a clean install of v10.5.4

  12. Steven Says:
    August 16th, 2008 at 5:38 am

    I’m having exactly the same problem as Ryan - clean install of 10.5.4 and getting Segmentation faults as well as the exit code 10.

    V, v frustrating.

  13. Steven Says:
    August 16th, 2008 at 5:39 am

    Sorry, any help would be appreciated. It’s the only thing on my server than needs fixing.

  14. Brent Says:
    August 16th, 2008 at 7:36 am

    Ryan & Steven: can you connect to your directory service using ‘ldapsearch’ or other tools? Have you tried the kerberosautoconfig command from step 3? What do you see in the logs (/var/log/system.log, /var/log/slapd.log, /var/log/krb5kdc/kdc.log) when you’re getting segfaults and exit code 10?

    Does the command:

    serveradmin fullstatus dirserv

    tell you anything useful about the state of Kerberos (kdc)?

  15. Brent Says:
    August 16th, 2008 at 7:39 am

    Oh, and did you do:

    chflags nouchg /Library/Preferences/edu.mit.Kerberos

    as per step 2?

Leave a Reply