Kerberos Part 3

Kerberos Part 3 - Kerberos On Member Servers

Monday, July 24 2006 @ 10:40 am CDT Contributed by: MacTroll Views: 1,095 You should be familiar with Kerberos in general and specifically the kdc now. Plus you should have a good working knowledge of how a client participates in the Kerberos party. Everything that we have covered so far, with some luck, should already have been done for you by Apple. It is now that we venture into virgin keytabs. We'll start off with replicant servers and work our way through generic member servers, OS X client systems, and finish off with how to integrate your OS X Server into a larger non-Open Directory Kerberos realm. 1. Replicants When a replica is created the entire kdc database is copied over. The replica pulls down the kdc config file that's been stashed in the OD domain and fires up the kdc. Then the Kerberos client config record in the OD domain is updated to include the replica's IP address in the list of Kerberos servers. Client systems will pull down this new config file during their next network change. In a typical multi-kdc environment only one kdc will have the kadmind process running. Since kadmind is the process where all changes to the database are made, this results in a single-master kdc domain. At a specified interval the kpropd process is run which takes the kdc database on the primary kdc and replicates it out to the other kdcs. OS X Server does this a bit differently. Each replica thinks it's the authoritative kdc and so each one runs the kadmind process. This allows for a fully multi-master Kerberos environment where any kdc can accept password changes. The kdc will push the change to the local instance of the Password Server which will then replicate this out to all the other Password Servers which in turn will push the change into their local kdcs. kpropd is not need in this setup. If your replica was created without a kdc it's most likely because you didn't have Kerberos fully operational when you created the replica. While it's possible to hand crank the kdc on the replica it is easier by far to just demote the replica and re-promote it once Kerberos is functional on the Open Directory Master. 2. Member server There are two ways to join a member OS X Server to an Open Directory Kerberos domain. The first is entirely GUI-based, and is the official Apple method for doing this. On 10.3 it was more than a little backward, rather involved and sometimes problematic. However, starting with 10.4 the entire process has been condensed into a single button. Once your server has been joined into Open Directory all you need to do is use the "Join Kerberos" button in the Open Directory module of Server Admin. You'll be prompted for an admin user name and password, and you're kerberized. This can also be done from the CLI if you'd like by using the sso_util command. You feed this the Kerberos realm, the OD admin user name and password and it does all of the heavy lifting. sso_util configure -r KERBEROS-REALM -a od_admin -p password all The "all" at the end is important here, as it will create a keytab for every service on OS X Server that supports Kerberos. Alternatively you can specify individual principle names. 3. Non-Open Directory Kerberos realm If you are in a larger MIT Kerberos environment you should have a Kerberos admin, if not a full-blown Kerberos team. With a polite inquiry and perhaps a quick form you should be able to get a keytab exported to you. If you haven't already configured the /Library/Preferences/edu.mit.Kerberos file, now would be a good time. Just ask for the krb5.conf file for your realm. OS X uses the same configuration file as the other Unixes, we just call it by a different name. To expedite the procedure you'll need to know what service principles to ask for. These will depend on the server application that you want to protect. Looking in the documentation is a good first choice here. However imap, ftp, smtp, host, and afpserver are the most common ones that you'll fun into. So let your Kerberos admin know which ones you need. It would also be helpful to include the DNS name of the server, or servers, that will be hosting the services. Before exporting the keytab these service principles will need to be created on in the kdc database. You most likely will not have the permission to do this, hence your entreaty to the Kerberos admin. The end result will be a small file that contains the service keys that you have requested. Hopefully, since this is a rather sensitive file, you will be able to acquire these using sftp or some other secure protocol. If you do not currently have a keytab on your machine, you can safely just copy the new keytab file to /etc/krb5.keytab and lock down the permissions. sudo chown root:wheel /etc/krb5.keytab sudo chmod 600 /etc/krb5.keytab Do note that if you are kerberizing mail services you'll need to allow the "mail" group to read the keytab. So set the group to root:mail and the permissions to 660. And then check to make sure it's been installed correctly by listing the contents of the keytab sudo klist -kt Things get a little stickier if you already have entries in your keytab. In this case you'll need to read the new keys into ktutil and then write them out to a new file and overwrite the old /etc/krb5.keytab with the new. sudo ktutil > rkt /etc/kerb5.keytab > rkt /private/var/root/new.keytab > wkt /private/var/root/combined.keytab > quit sudo mv /private/var/root/combined.keytab /etc/krb5.keytab sudo chmod 600 /etc/krb5.keytab You can test the whole setup again by using sudo klist -kt Once your keytab is set most services will automatically find the correct service key that they need to use. However, some services need to be told. To kerberize the AFP server you need to add the principle name as shown in the keytab, for example "afpserver/esheep.afp548.com@AFP548.COM" to the Appleshare Server's pref file at /Library/Preferences/com.apple.AppleFileServer.plist. You can also do this with the serveradmin command. sudo serveradmin settings afp:kerberosPrincipal = "afpserver/phillipkdick.afp548.com@AFP548.COM" For your mail services do the same to the /etc/othermail.plist file. Now for the moment of truth. Either by logging into a configured client machine or by using kinit from the command line acquire a valid TGT. Then attempt to use a kerberized service. If it works you're done. If not you'll need to take a look at your keytab again. 4. OS X Client Typically for a client system you only need one entry in your keytab for the "host" principle. This will allow incoming ssh connection to use Kerberos for authentication. if you have the luxury of knowing the admin username and password for the Kerberos realm, regardless of whether it is a OS X Server-hosted system or not, you can just use the kadmin command for this process. On the client system sudo kadmin -p admin@REALM.COM Once in the kadmin shell ank -randkey host/client.afp548.com The DNS name here is important as it must be the actual DNS name of the client system or this Kerberos won't work. No configuration for ssh should be necessary for the ssh service to pick up this key. Finally write the key out to the local keytab file. This assumes that you don't currently have a keytab file, or are desirous of overwriting it. Otherwise you're going to have to use the ktutil command as before to merge the two. ktadd -k /etc/kerb5.keytab host/client.afp548.com@AFP548.COM quit If you don't have access to the admin password, then you can follow the same procedure as you would have if you were setting up an OS X Server in a standard MIT Kerberos environment. Again, you probably really only need the "host" key on a client system.