Some time ago I wrote a big blog entry entitled Simplifying Zone Management with Kerberos. Since that time (3 years ago!?!) several improvements and simplifications have come along to make life far more pleasant. If your new to Kerberos, please refer to my previous entry before proceeding with this one.

Kerberos is still something I struggle to really wrap my head around. Thats probably due to the fact that I have never used it in a full production deployment… the problem with using something only in the lab is that you never are “done” and you never hit real world problems that push you beyond that which you dream up.

There are classicly two reasons people get interested in Kerberos: Single Sign On (SSO) and secure NFS. Once upon a time general purpose encryption support for tools like telnet, rlogin, and FTP were a great draw, but today between SSH and SSL/TLS support in almost everything there just isn’t a reason to jump down the Kerberos path. SSO is a reason, but given that the defacto UNIX remote management protocol is SSH and SSH supports passwordless (authorized keys) login, its easy to mimic the benefits of SSO…. particularly if you use OpenSSH LPK, which allows you to store public keys in LDAP. As for NFS, well, there you probly still wanna stick with Kerberos unless you are willing to go the NFSv4/IPsec route.

The point here being, prior to SSH’s rise to glory Kerberos was a vitally important enterprise solution, whereas today its a hard sell. When it comes down to it, there is really only one real standout reason to seriously consider Kerberos: passwords are never on the wire, period. That is indeed a kool thing, but I doubt it will convince most people enough to really get them to go at it. In the end, Kerberos is only really exciting when its implemented in a way such as ActiveDirectory, where you don’t even know its there, you just turn it on and reap the benefits. So you can almost conclude that Kerberos is as important as ever, its just no longer worth the expenditure of effort.

To this end, I advise anyone interested in LDAP/Kerberos get familiar with ApacheDS, the work their doing is truly amazing. …but more about that some other time.

As I was saying, Kerberos is now easier than ever to get up and running on Solaris, thanks to the kdcmgr and kclient tools.

Thanks to the kdcmgr command we no longer need to hand edit files and use the kinit command to initialize a Kerberos KDC. Here is an example of kdcmgr in action:

$ kdcmgr -a benr/admin -r CUDDLETECH.COM create master

Starting server setup
---------------------------------------------------

Setting up /etc/krb5/kdc.conf.

Setting up /etc/krb5/krb5.conf.

Initializing database '/var/krb5/principal' for realm 'CUDDLETECH.COM',
master key name 'K/M@CUDDLETECH.COM'                                            
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: 
Re-enter KDC database master key to verify: 
 
Authenticating as principal root/admin@CUDDLETECH.COM with password.
WARNING: no policy specified for benr/admin@CUDDLETECH.COM; defaulting to no policy
Enter password for principal "benr/admin@CUDDLETECH.COM":
Re-enter password for principal "benr/admin@CUDDLETECH.COM":
Principal "benr/admin@CUDDLETECH.COM" created.

Setting up /etc/krb5/kadm5.acl.

---------------------------------------------------
Setup COMPLETE.

Done! If you look around you’ll see this has created the necessary config and keytabs, as well as started the appropriate SMF services:

$ svcs -a | grep security
disabled       May_30   svc:/network/security/krb5_prop:default
online         May_30   svc:/network/security/ktkt_warn:default
online          3:11:34 svc:/network/security/krb5kdc:default
online          3:11:36 svc:/network/security/kadmin:default
$ ls -alh /etc/krb5/
total 40
drwxr-xr-x   2 root     sys          512 Jul 27 03:11 .
drwxr-xr-x  96 root     sys         4.5K Jul 25 14:58 ..
-rw-r--r--   1 root     sys           52 Jul 27 03:11 kadm5.acl
-rw-r--r--   1 root     root         998 Jul 27 03:11 kadm5.acl.sav
-rw-------   1 root     root        1.5K Jul 27 03:11 kadm5.keytab
-rw-r--r--   1 root     sys          430 Jul 27 03:11 kdc.conf
-rw-r--r--   1 root     root        1.3K Jul 27 03:11 kdc.conf.sav
-rw-r--r--   1 root     sys          968 Mar 22 10:43 kpropd.acl
-rw-r--r--   1 root     sys          367 Jul 27 03:11 krb5.conf
-rw-r--r--   1 root     root        2.0K Jul 27 03:11 krb5.conf.sav
-rw-------   1 root     root         383 Jul 27 03:11 krb5.keytab
-rw-r--r--   1 root     sys         1.1K Mar 22 10:43 warn.conf

As you can see, its all there and in order. You can immediately use kinit to get a ticket and use kadmin to create additional principles, no kadmin.local required. Very refreshing indeed.

As for the clients, manual configuration is so simple as to require very little improvement, never the less we can use the kclient command to standardize it:

# kclient -a benr/admin -k kdc1.cuddletech.com -R CUDDLETECH.COM

Starting client setup

---------------------------------------------------
Do you want to use DNS for kerberos lookups ? [y/n]: n
        No action performed.
kdc1.cuddletech.com

Note, this system and the KDC's time must be within 5 minutes of each other for Kerberos to function.  Both systems should run some form of time synchronization system like Network Time Protocol (NTP).

Setting up /etc/krb5/krb5.conf.
Obtaining TGT for benr/admin ...
Password for benr/admin@CUDDLETECH.COM:
localhost: RPC: Rpcbind failure - RPC: Success
kinit:  no ktkt_warnd warning possible

host/zone1.cuddletech.com entry ADDED to KDC database.
host/zone1.cuddletech.com entry ADDED to keytab.

---------------------------------------------------
Setup COMPLETE.

Easy as that. Please note that the RPC failure did suceed and didn’t effect the configuration.

I want to note explicitly that in the above examples the hosts involved, namely the KDC, were present in DNS. Trying to do the same configuration above without DNS is not so easy and if you need to do so I recommend avoiding kdcmgr and using the manual procedure in my previous Kerberos post.

With regard to SSH, in Solaris 10 there is no need to make any changes to accomidate SSH. You do not need to edit /etc/pam.conf or even change the /etc/ssh/sshd_config file. Setup a KDC as above, setup a client as above (a zone for instance), get a ticket (“kinit”) and SSH… your rockin’ and rollin’.

If you need help with your installation or want to get connected with other Solaris Kerberos fans, visit the OpenSolaris Kerberos Project.