CRC and ND AFS discussion

The following email was sent to the ND-ACT email list and is provided here for advanced user's benefit. The author's names have been removed to protect their privacy.


---


On Sunday 1/5/14 the CRC is making a change to their AFS cell. USER plans to "disable" the "weak-encryption" option on the CRC Kerberos/AFS services. This will remediate the well-known security issue with AFS (at least it will for the CRC cell). I have not heard any timetable for a similar update to the campus AFS cell.

If your users ssh to one of the CRC front-end machines, and ***NEVER*** obtain CRC tickets/tokens directly on their desktop, you may be able to ignore this email.

If, on the other hand, your users authenticate directly to CRC from their desktop systems you probably need to make some changes. (Authenticate directly in this context means that the user, while logged in on their desktop system, obtains CRC tickets/tokens from the CRC services using kinit/aklog...even if this happens "magically" during the login process.)

CSE users: Don't worry, if you run RHEL5/RHEL6 on your machines

          (desktops, or servers) they have already been updated.

If you have MacOS/Windows/Solaris users which authenticate directly to the CRC cell, you may have to make similar changes to those environments. I did not do any testing of these OS's, nor do I plan to. Comsult your local Apple/Microsoft/Oracle guru to see what they recommend for these environments.

There are two things which you need to do in order to enable your users to authenticate to both the CRC and the ND AFS cells once the CRC change is made. NOTE: You can do the update now...it works with pre/post CRC updates.

1) Update your krb5.conf. In particular, you need to list the stronger

  encryption types in your krb5.conf file.  You should list the types
  with "strongest first", and "weakest last".  My krb5.conf file is
  included below.  It works for RHEL5, RHEL6 for both the CRC and
  the ND cells.  USER has a krb5.conf file as well.  I believe that
  USER's file is specific to the crc.nd.edu AFS cell.
       Why do you need to do this?  Because the CRC will require strong
       encryption, but the campus cell cannot use strong encryption.
       The code is smart enough to try the encryption types in the order
       that they are listed.  So for CRC, the strong encryption will
       succeed before the weak types are tried.  For the ND cell, the
       strong encryption will fail, but as the code moves down the list,
       it will hit the weak encryption types, which will succeed.  You
       still need the "allow_weak_crypto = yes" directive such that you
       can authenticate to the ND cell.  The CRC cell will (essentially)
       ignore this directive.
  NOTE: I did not do any RHEL4 testing, but I have heard that RHEL4 does
  not work with strong encryption without a lot of recompilation. YMMV.
  How do you know if the new krb5.conf file is working?
       Login on your system as root.
       Update krb5.conf  Reboot is not required.
       Open another window and login on your system as yourself
       (do not close the root window until you know everything is working).
       Can you login on the system using an AFS account once the file
       has been updated?  If so, it is probably working.  You can also
       use kinit to tell you what type of tickets/tokens you have.  For
       example the ND cell should say something like:
       [USER@MACHINE ~]$ klist -e
       Ticket cache: FILE:/tmp/krb5cc_45725_S2lFIS
       Default principal: USER@ND.EDU
       Valid starting     Expires            Service principal
       01/02/14 11:06:20  02/01/14 11:06:20  krbtgt/ND.EDU@ND.EDU
               renew until 01/09/14 11:06:20, Etype (skey, tkt): des-cbc-crc,
       des-cbc-crc
       01/02/14 11:06:20  02/01/14 11:06:20  afs@ND.EDU
               renew until 01/09/14 11:06:20, Etype (skey, tkt): des-cbc-crc,
       des-cbc-crc
       NOTE: The krbtgt and afs token are both currently des on the ND cell.


       If you authenticate to the CRC cell you should see something like:
       [USER@MACHINE ~]$ kinit USER@CRC.ND.EDU
       Password for USER@CRC.ND.EDU: (I entered my password here)
       [USER@MACHINE ~]$ aklog CRC.ND.EDU
       [USER@MACHINE ~]$ klist -e
       Ticket cache: FILE:/tmp/krb5cc_45725_vvlF4J
       Default principal: USER@CRC.ND.EDU
       Valid starting     Expires            Service principal
       01/02/14 11:41:49  01/03/14 11:41:49  krbtgt/CRC.ND.EDU@CRC.ND.EDU
               Etype (skey, tkt): des3-cbc-sha1, des3-cbc-sha1
       01/02/14 11:41:59  01/03/14 11:41:49  afs/crc.nd.edu@CRC.ND.EDU
               Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
       NOTE: The krbtgt (ticket) is currently des3.  I believe this
       will change to aes256-cts-hmac-sha1-96 once USER makes the
       change on his servers.  The AFS token currently appears as
       aes256-cts-hmac-sha1-96...which tells you that it is  using
       strong encryption.

2) Update your openafs code to (at least) openafs-1.6.5. I believe

  that USER told me (many months ago while we were testing things) that
  he ran into difficulties with openafs-1.6.2 during his testing.  I had
  some problems with it as well.  All of my RHEL5/RHEL6 machines are
  running (at least) openafs-1.6.5, and I have not seen any issues with
  strong encryption with the binaries that I am running.  Again, YMMV.
  If you install from my install server, and use the dkms service to manage
  the openafs kernel module, there is a script which you can use to update
  your AFS binaries:
       For RHEL5:
       mkdir /mnt/nfs
       mount bootleg.cselab.nd.edu:/export/install/RHEL5 /mnt/nfs
       cd /mnt/nfs/extras/bin/
       ./dkms_install_openafs_165
       For RHEL6:
       mkdir /mnt/nfs
       mount bootleg.cselab.nd.edu:/export/install/RHEL6 /mnt/nfs
       cd /mnt/nfs/extras/bin/
       ./dkms_install_openafs_165
       The RHEL5/RHEL6 scripts will remove old versions of the AFS
       binaries, and will install openafs-1.6.5-1 on your machine.
     NOTE: The testing_dkms_install_openafs_1.6.5.1-1 script will install
       an even newer version of the openafs binaries.  I have not done a
       lot of testing with it, but it seems to work on recent kernels
       with no issues.

My krb5.conf file: (assumes that you want ND.EDU to be your default realm, but allows you to obtain credentials from the CRC realm using kinit/alklog).


[appdefaults]

       forward = true
       forwardable = true
       ticket_lifetime = 2592000
       renew_lifetime = 2592000

[libdefaults]

   forwardable = true
   default_tkt_enctypes = aes256-cts-hmac-sha1-96 des3-hmac-sha1 des-cbc-crc
   default_tgs_enctypes = aes256-cts-hmac-sha1-96 des3-hmac-sha1 des-cbc-crc
   default_realm = ND.EDU
   allow_weak_crypto = yes

[realms]

       CRC.ND.EDU = {
               kdc = kerberos.crc.nd.edu:88
               kdc = kerberos-1.crc.nd.edu:88
               kdc = kerberos-2.crc.nd.edu:88
               admin_server = kerberos.crc.nd.edu:749
               default_domain = crc.nd.edu
       }
       ND.EDU = {
               kdc = kerberos.nd.edu:88
               kdc = kerberos-1.nd.edu:88
               kdc = kerberos-2.nd.edu:88
               admin_server = kerberos.nd.edu:749
               default_domain = nd.edu
       }

[domain_realm]

       .crc.nd.edu = CRC.ND.EDU
       .hpcc.nd.edu = CRC.ND.EDU
       .nd.edu = ND.EDU

[logging]

       default = FILE:/var/log/krb5libs.log