Update Kerberos on our Servers

The kerberos servers were installed long ago when DES was the primary encryption. We need to change to using newer more secure algorithms.

See http://web.mit.edu/kerberos/krb5-devel/doc/admin/advanced/retiring-des.html for details.

On linat03 issued:

enctypes=aes256-cts-hmac-sha1-96:normal,aes128-cts-hmac-sha1-96:normal,des3-hmac-sha1:normal,arcfour-hmac-md5:normal,des-cbc-crc:normal

kadmin.local -r ATLAS.UMICH.EDU -q "cpw -e ${enctypes} -randkey -keepold krbtgt/ATLAS.UMICH.EDU"

Then make sure the updated keys are propagated to the slaves:

[linat03:etc]# bash /etc/cron.hourly/kprop

Database propagation to linat04.grid.umich.edu: SUCCEEDED

Database propagation to linat02.grid.umich.edu: SUCCEEDED

Now let's get the updated kdc.conf in place on the slaves:

[linat03:etc]# scp /var/kerberos/krb5kdc/kdc.conf linat02:/var/kerberos/krb5kdc/kdc.conf
Scientific Linux SL release 5.4 (Boron)
kdc.conf 100% 725 0.7KB/s 00:00

[linat03:etc]# scp /var/kerberos/krb5kdc/kdc.conf linat04:/var/kerberos/krb5kdc/kdc.conf
Scientific Linux SL release 5.4 (Boron)
kdc.conf 100% 725 0.7KB/s 00:00

[linat03:etc]# ssh linat02 "service krb5kdc restart"
Scientific Linux SL release 5.4 (Boron)
Stopping Kerberos 5 KDC: [ OK ]
Starting Kerberos 5 KDC: [ OK ]

[linat03:etc]# ssh linat04 "service krb5kdc restart"
Scientific Linux SL release 5.4 (Boron)
Stopping Kerberos 5 KDC: [ OK ]
Starting Kerberos 5 KDC: [ OK ]

Currently have the kdc.conf using:

[kdcdefaults]
        kdc_ports = 88,750
        v4_mode = nopreauth

[realms]
        ATLAS.UMICH.EDU = {
                database_name = /var/kerberos/krb5kdc/principal
                admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
                acl_file = /var/kerberos/krb5kdc/kadm5.acl
                dict_file = /var/kerberos/krb5kdc/kadm5.dict
                key_stash_file = /var/kerberos/krb5kdc/.k5.ATLAS.UMICH.EDU
                kadmind_port = 749
                max_life = 720h 0m 0s
                max_renewable_life = 62d 12h 0m 0s
                master_key_type = des-cbc-crc
                supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal des3-hmac-sha1:normal arcfour-hmac-md5:normal
                kdc_supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal des3-hmac-sha1:normal arcfour-hmac-md5:normal
        }

New requests should use secure (no single DES) encryption types.

Next I updated the kadmin/admin and kadmin/changepw similarly to the above:

enctypes=aes256-cts-hmac-sha1-96:normal,aes128-cts-hmac-sha1-96:normal,des3-hmac-sha1:normal,arcfour-hmac-md5:normal
kadmin.local -r ATLAS.UMICH.EDU -q "cpw -e ${enctypes} -randkey kadmin/admin"
kadmin.local -r ATLAS.UMICH.EDU -q "cpw -e ${enctypes} -randkey kadmin/changepw"

It is not necessary to retain a single-DES key for these services, since password changes are not part of normal daily workflow, and disruption from a client failure is likely to be minimal. Furthermore, if a kerberos client experiences failure changing a user password or keytab key, this indicates that that client will become inoperative once services are rekeyed to non-DES enctypes. Such problems can be detected early at this stage, giving more time for corrective action.

Re-Keying OpenAFS

Once Kerberos is strengthened we can worry about updating OpenAFS. There are instructions on implementing rxkad-k5 at http://openafs.org/pages/security/install-rxkad-k5-1.6.txt and specific details on the re-keying at http://openafs.org/pages/security/how-to-rekey.txt

Basically we need to create a new keytab for OpenAFS 1.6.5+ to allow it to use better encryption.

We can use the kadmin.local or kadmin -p admin@ATLAS.UMICH.EDU programs to generate the new keytab file for our OpenAFS servers.

ktadd -k /tmp/rxkad.keytab afs/atlas.umich.edu

This command should list the new AES encryption types we add in Kerberos

Next scp it to all the AFS servers: linat02, linat03, linat04, linat06, linat07, linat08 and atback1 like:

scp /tmp/rxkad.keytab linat02:/usr/afs/etc/

Similarly for all the other AFS servers. Once it is there do a restart of AFS

service openafs-server restart

-- or --

service afs-server restart

Verify you can 'kinit admin' and do 'bos status linat0x' on to each AFS server.

--Main.ShawnMcKee - 28 Jul 2013