Jan 122013
 

In this post, I will describe how to setup incremental database propagation as described in the MIT documentation. Unfortunately, the instructions at the preceding link are incomplete (as of this writing). The aim of this post is to completely describe how to setup incremental propagation.

For the purposes of this tutorial, I will assume you have 2 KDCs (referred to here as kdc1.example.com and kdc2.example.com). Installing the KDCs is out of the scope of this post. In this post, I will use the default filesystem paths as they exist on Debian for illustration purposes.

First, you need to add kiprop principals for kdc1 and kdc2.

kdc1 # kadmin.local 
Authenticating as principal solj/admin@EXAMPLE.COM with password.
kadmin.local:  addprinc -policy service -randkey kiprop/kdc1.example.com
Principal "kiprop/kdc1.example.com@EXAMPLE.COM" created.
kadmin.local:  addprinc -policy service -randkey kiprop/kdc2.example.com
Principal "kiprop/kdc2.example.com@EXAMPLE.COM" created.

Once you have done this, you will need to dump the database on kdc1 and load it on kdc2.

kdc1 # kdb5_util dump principal

Use a secure method (e.g. scp) to transfer the principal database to kdc2 and load the database there.

kdc2 # kdb5_util load principal

Add the following options in the appropriate [realms] section of /etc/krb5kdc/kdc.conf on both KDCs.

iprop_enable = true
iprop_port = 2121

The actual port you use is up to you. Note that there are other iprop_ options you can use and they are already documented on the MIT page.

Next, you need to allow the kiprop principals the access they need to propagate the database. On kdc1, add the following to /etc/krb5kdc/kadm5.acl.

kiprop/krb1.example.com p
kiprop/krb2.example.com p

Extract kdc1’s kiprop keytab to /etc/krb5kdc/kadm5.keytab.

kdc1 # kadmin.local 
Authenticating as principal solj/admin@EXAMPLE.COM with password.
kadmin.local: ktadd -k /etc/krb5kdc/kadm5.keytab kiprop/kdc1.example.com
Entry for principal kiprop/kdc1.example.com with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5kdc/kadm5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5kdc/kadm5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 2, encryption type des3-cbc-sha1 added to keytab WRFILE:/etc/krb5kdc/kadm5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 2, encryption type arcfour-hmac added to keytab WRFILE:/etc/krb5kdc/kadm5.keytab.

You also need to extract kdc2’s kiprop keytab, however, it should go to the default keytab file (DEFKTNAME).

kdc2 # kadmin -p solj/admin
Authenticating as principal solj/admin with password.
Password for solj/admin@EXAMPLE.COM: 
kadmin: addprinc -policy service -randkey kiprop/kdc2.example.com
Principal "kiprop/kdc2.example.com@SIRIAD.COM" created.
kadmin:  ktadd kiprop/kdc2.example.com
Entry for principal kiprop/kdc2.example.com with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 2, encryption type des3-cbc-sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 2, encryption type arcfour-hmac added to keytab WRFILE:/etc/krb5.keytab.

You should now be able to restart kadmind on kdc1 and run kpropd on kdc2 to successfully propagate the database. Note that you can debug this process by watching the kadmind logs as well as running kpropd in the foreground (kpropd -S -d).

 Posted by at 16:25
Aug 312011
 

I was unable to find any guides which accurately described setting up a NFSv4 client with Kerberos on Gentoo. There are guides for setting things up on other distros, but I have run into numerous issues which were directly related to using Gentoo. Therefore, I am going to use this guide to document some of those problems. Please note that the NFS server is running Ubuntu 10.04, so there are some parts of this guide which won’t apply to Gentoo.

Setting up the Kerberos server is fairly straightforward, however, there is a difference in the way things are compiled on Gentoo. The OpenAFS guide on the wiki is mostly correct. I’ll reiterate the correct steps here.

Installation

First, you need to install the Kerberos server.

emerge -av mit-krb5

Copy the /etc/krb5.conf.example file that is included over to /etc/krb5.conf and edit it according to your needs.

cp /etc/krb5.conf.example /etc/krb5.conf

The edited file will look similar to this

[libdefaults]
        default_realm = EXAMPLE.COM
        forwardable = true
        renew_lifetime = 7days

[realms]
        EXAMPLE.COM = {
                kdc = krb.example.com
                admin_server = krb.example.com
        }

[domain_realm]
        .example.com = EXAMPLE.COM
        example.com = EXAMPLE.COM

You will need to replace “EXAMPLE.COM”, “example.com”, and “krb.example.com” with appropriate values for your environment. Note that realm names are always uppercase. The name of your KDC (krb.example.com in the example) is arbitrary.

Setting up the primary KDC

This is where the OpenAFS guide is confusing. The kdc.conf file should reside at /var/lib/krb5kdc/kdc.conf, not /etc/kdc.conf. So, go ahead and copy /var/lib/krb5kdc/kdc.conf.example and create a new file. Here are what the contents should look like.

[kdcdefaults]
        kdc_ports = 750,88

[realms]
        EXAMPLE.COM = {
                database_name = /var/lib/krb5kdc/principal
                admin_keytab = FILE:/var/lib/krb5kdc/kadm5.keytab
                acl_file = /var/lib/krb5kdc/kadm5.acl
                key_stash_file = /var/lib/krb5kdc/.k5.EXAMPLE.COM
                kdc_ports = 750,88
                max_life = 10h 0m 0s
                max_renewable_life = 7d 0h 0m 0s
                default_principal_flags = +preauth
        }

[logging]
        kdc = FILE:/var/log/kerberos/kdc.log
        admin_server = FILE:/var/log/kerberos/kadmin.log

Replace “EXAMPLE.COM” with your own realm name. Also note that some of the options above are changed from their default values. I have added a logging section at the end and changed the directory where things reside.

An important difference is that the default_principal_flags has been set to +preauth. The reason for this is that without it, Kerberos is vulnerable to offline dictionary attacks. If you are going to have your KDC publicly accessible, then you definitely want to consider enabling preauthentication. In my opinion, you probably want this even if the KDC is not publicly accessible, but that’s because I trust no one.

After modifying /var/lib/krb5kdc/kadm5.acl to your liking, you can go ahead and create the database.

cd /var/lib/krb5kdc
kdb5_util create -r EXAMPLE.COM -s

As usual, make sure you use your realm name.

Principal Creation

I’ll leave this as an exercise for the reader. I generally create varying policies for services and users and those won’t be entirely useful for most. For a really good guide on creating/using policies, see http://techpubs.spinlocksolutions.com/dklar/kerberos.html#id2500817.

Start Kerberos Server

To start the kdc and kadmind servers, run the following.

/etc/init.d/mit-krb5kadmind start
/etc/init.d/mit-krb5kdc start

Add them to the default runlevel so that they start up after a reboot

rc-update add mit-krb5kadmind default
rc-update add mit-krb5kdc default

Installing NFSv4 client

First install the nfs client utilities

emerge -av nfs-utils

You will want to make sure you have both the kerberos and the nfsv4 USE flags enabled.

Configuring the kernel

You will need to configure the kernel with the appropriate relevant options. I won’t bother going through that entire process. Rather, I’ll point out some things that went wrong for me, but weren’t immediately obvious.

The kernel needs to have the rpcsec_gss_krb5 option configured as a module. I spent quite a while debugging this problem. I had the option compiled directly into the kernel. Looking in the nfs client’s syslog, I also found this obscure error message.

gss_create: Pseudoflavor 390003 not found!
RPC: Couldn't create auth handle (flavor 390003)

Whatever the hell that means. Surprisingly, there are very few references to this error. One of them I found suggested recompiling the kernel with the rpcsec_gss_krb5 module and simple loading it after boot. Surprisingly, this actually worked.

Adding nfs principals

Both the nfs server and the nfs client need nfs principals added to their krb5.keytab. Since my nfs server was running an older kernel (Ubuntu 10.04), I needed to do a couple things to get this to work.

First, you need to add an nfs principal for both the client and the server. In my case, the server needed an encryption type which isn’t generated by default on a Gentoo Kerberos server. Therefore, I generated the principal like this.

addprinc -policy service -randkey -e "des-cbc-crc:normal" nfs/nfsserver

Since I had a service policy defined, this created the nfs/www.siriad.com principal with the “des-cbc-crc” encryption type. This is necessary for the older version of nfs that is available for Ubuntu 10.04. You then need to login to the nfs server, run kadmin, and do the following.

kadmin:  ktadd -e des-cbc-crc:normal nfs/nfsserver

This will add the entry to your nfs server’s host keytab. Using this encryption type is extremely important. If you don’t, you will probably end up with very cryptic errors like the ones I had.

rpc.svcgssd: ERROR: prepare_krb5_rfc_cfx_buffer: not implemented
rpc.svcgssd: ERROR: failed serializing krb5 context for kernel
rpc.svcgssd: WARNING: handle_nullreq: serialize_context_for_kernel failed

This indicates that the NFS server has not implemented the encryption types being used in your keytab.

Now you just need to add an nfs principal for your client. In this case, Gentoo had support for the more recent encryption types, so I didn’t need to do anything special. I just created the principal.

addprinc -policy service -randkey nfs/nfsclient

then added it to the client’s host keytab using kadmin on the client

kadmin:  ktadd nfs/nfsclient

Lastly, you need to make sure you allow for weak encryption types in the /etc/krb5.conf file. Add the following to the [libdefaults] section.

allow_weak_crypto = true

Setting up the NFS server

First, you need to allow for weak encryption types on the NFS server. You can do this by modifying the /etc/krb5.conf file. You will need to add the following two lines in the [libdefaults] section.

allow_weak_crypto = true
permitted_enctypes = "des-cbc-crc arcfour-hmac des3-cbc-sha1 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96"

Note that the values listed as permitted are those generated by default on my Kerberos server. Please DO NOT set the default encryption type to the weak encryption. I see far too many howtos that tell you to do this and it is NOT a good idea. If you can use the stronger encryption for things other than NFS, there is no reason not to.

On the NFS server, you also need to make sure that rpc.svcgssd is set to start alongside NFS. On Ubuntu, you can do this by editing your /etc/default/nfs-kernel-server file and editing/modifying the following line.

NEED_SVCGSSD=yes

You will also need to edit the following line in the /etc/default/nfs-common file.

NEED_IDMAPD=yes

Edit the /etc/idmapd.conf file and set the Domain line to the appropriate value for your environment. Make sure you restart rpc.idmapd if necessary.

Lastly, you need to modify /etc/exports with the appropriate values. My export looks something like this.

/export/dir        gss/krb5(rw,fsid=0,insecure,no_subtree_check)

You can then restart the nfs-kernel-server service and your NFS server should be ready to go.

Setting up the NFS client

You need to first make sure that rpc.idmapd and rpc.gssd are set to start with nfs. Edit your /etc/conf.d/nfs file and modify the following line.

NFS_NEEDED_SERVICES=”rpc.idmapd rpc.gssd”

You will need to edit /etc/idmapd.conf with the same information from the NFS server. Then you can /etc/init.d/nfs restart and test your NFS mount.

Testing your NFS mount

You can now test your nfs mount with the following command

 mount -vvv -t nfs4 -o sec=krb5 nfsserver:/ test/

This should work successfully and you should be able to see the appropriate requests coming through in your KDC logs.

 Posted by at 16:38
Aug 172011
 

This is just a quick post to show how I go about debugging problems with GSSAPIAuthentication. You want to debug both the server side and the client side, so the first thing to do is start a new instance of the openssh server in the foreground on a different port.

# `which sshd` -o "GSSAPIAuthentication yes" -d -D -p 2222
debug1: sshd version OpenSSH_5.3p1 Debian-3ubuntu7
debug1: read PEM private key done: type RSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: rexec_argv[2]='-D'
debug1: rexec_argv[3]='-p'
debug1: rexec_argv[4]='2222'
debug1: Bind to port 2222 on 0.0.0.0.
Server listening on 0.0.0.0 port 2222.
debug1: Bind to port 2222 on ::.
Server listening on :: port 2222.

This will start up the ssh server listening on port 2222 with debugging turned on. Then you need to try connecting to this instance from the client that is unable to connect.

$ ssh -o "GSSAPIAuthentication yes" -vvv -p 2222 server.example.com

This will output a ton of information on both the server and the client which should help you figure out why you are unable to login using GSSAPIAuthentication. Some common pittfalls to keep in mind

  • Make sure you have GSSAPIAuthentication turned on either globally or for the user trying to login (this is done for you in the examples above, so if things work then this may be your problem).
  • Make sure you have created a host principal for the ssh server and have added it to that machine’s /etc/krb5.keytab
    • You can test this by logging into the ssh server and running klist -k.
      # klist -k
      	Keytab name: WRFILE:/etc/krb5.keytab
      	KVNO Principal
      	---- --------------------------------------------------------------------------
      	   2 host/server.example.com@EXAMPLE.COM
      	   2 host/server.example.com@EXAMPLE.COM
      	   2 host/server.example.com@EXAMPLE.COM
      	   2 host/server.example.com@EXAMPLE.COM
  • If none of these steps turn up anything useful, check the kdc logs for errors.

Please note that the environment referred to above is using MIT Kerberos. I would expect the methods for debugging other software to be similar, but I cannot guarantee that the kerberos-related commands will be the same.

 Posted by at 19:06