Automating Kerberos Authentication

Sometimes you need unattended authentication. Sometimes you are just lazy. Whatever the reason, if a user (human or otherwise) wants to fetch a Ticket Granting Ticket (TGT) from a Kerberos Key Distribution Center (KDC) automatically, the Global Security Services API (GSSAPI) library shipped with most recent distributions support it.

Kerberos is based on symmetric cryptography. If a user needs to store a symmetric key in a filesystem, she uses a file format known as a Key table, or keytab for short. Fetching a keytab is not a standard action, but FreeIPA has shipped with a utility to make it easier: ipa-getkeytab

Before I attempt to get a keytab, I want to authenticate to my KDC and get a TGT manually:

$ kinit ayoung@YOUNGLOGIC.NET
Password for ayoung@YOUNGLOGIC.NET: 
[ayoung@ayoung530 tempest (master)]$ klist
Ticket cache: KEYRING:persistent:14370:krb_ccache_H4Ss9cA
Default principal: ayoung@YOUNGLOGIC.NET

Valid starting       Expires              Service principal
05/01/2015 09:07:06  05/02/2015 09:06:55  krbtgt/YOUNGLOGIC.NET@YOUNGLOGIC.NET

To fetch a keytab and store it in the users home directory, you can run the following command. I’ve coded it to talk to my KDC, so modify it for yours.

ipa-getkeytab -p $USER@YOUNGLOGIC.NET -k $HOME/client.keytab -s

You can get your own principal from the klist output:

export KRB_PRINCIPAL=$(klist | awk '/Default principal:/ {print $3}')

If you are running on an ipa-client enrolled machine, much of the info you need is in /etc/ipa/default.conf.

$ cat   /etc/ipa/default.conf 
#File modified by ipa-client-install

basedn = dc=younglogic,dc=net
domain =
server =
host =
xmlrpc_uri =
enable_ra = True

You can convert these values into environment variables with:

 $(awk '/=/ {print "export IPA_" toupper($1)"="$3}' < /etc/ipa/default.conf)

Now a user could manually kinit using that keytab and the following commands:

$(awk '/=/ {print "export IPA_" toupper($1)"="$3}' < /etc/ipa/default.conf)
kinit -k -t $HOME/client.keytab $USER@$IPA_REALM

We can skip the kinit step by putting the keytab in a specific location. If you look inthe man page for krb5.conf you can find the following section:

This relation specifies the name of the default keytab for obtaining client credentials. The default is FILE:/var/kerberos/krb5/user/%{euid}/client.keytab. This relation is subject to parameter expansion

What is %{euid}? It is the numeric userid for a user. For yourself, the value is set in $EUID. What if you need it for a different user? Use the getent command to configure the name service switch configured database for this value:

$ getent passwd ayoung
ayoung:*:622800001:622800001:Adam Young:/home/ayoung:/bin/sh

It is that third value. Again, if you want to automate:

export AYOUNG_EUID=getent passwd ayoung | cut -d: -f3

You need to create that directory before you can put something in it. You only want the user to be able to read or write in that directory.

sudo mkdir  /var/kerberos/krb5/user/$EUID
sudo chown $USER:$USER  /var/kerberos/krb5/user/$EUID 
chmod 700  /var/kerberos/krb5/user/$EUID

Now use that to store the keytab:

 ipa-getkeytab -p $KRB_PRINCIPAL -k   /var/kerberos/krb5/user/$EUID/client.keytab -s $IPA_SERVER

To test out the new keytab, kdestroy to remove the existing TGTS then try performing an action that would require a service ticket.

Here I show an initially cleared credential cache that gets automatically populated when I connect to a remote system via ssh.

[ayoung@ayoung530 tempest (master)]$ kdestroy -A
[ayoung@ayoung530 tempest (master)]$ klist -A
[ayoung@ayoung530 tempest (master)]$ ssh -K
Last login: Fri May  1 16:42:28 2015 from
-sh-4.2$ exit
Connection to closed.
[ayoung@ayoung530 tempest (master)]$ klist -A
Ticket cache: KEYRING:persistent:14370:krb_ccache_WotXvlm
Default principal: ayoung@YOUNGLOGIC.NET

Valid starting       Expires              Service principal
05/01/2015 12:42:46  05/02/2015 12:42:45  host/
05/01/2015 12:42:46  05/02/2015 12:42:45  host/
05/01/2015 12:42:45  05/02/2015 12:42:45  krbtgt/YOUNGLOGIC.NET@YOUNGLOGIC.NET

I would not recommend doing this for normal users. But for service users that need automated access to remote services, this is the correct approach.

4 thoughts on “Automating Kerberos Authentication

  1. Really nice article and Blog, thanks !
    I had the same objective – allow some services to access kerberized storage servers – and solved it using k5start, a daemon version of kinit for Kerberos v5. (from EPEL repository) It seems it gets to the same point with much less efforts. It’s also able to renew tickets at a predetermined intervall.
    Also be aware that requesting a keytab for a principal will reset it, i.e. a user principal password will no longer be valid for example.

  2. THAAAAAAAAAAANKSSSSSS! You helped me soooo muuuuch!
    I write here down my steps if anyone will face with this issue like me!

    I added credential to file:
    #ktutil: addent -password -p administrator@SKUNKWORKS.LOCAL -k 1 -e RC4-HMAC
    Password for administrator@SKUNKWORKS.LOCAL:
    #ktutil: wkt username.keytab
    #ktutil: q
    And try it out
    kinit administrator@SKUNKWORKS.LOCAL -k -t username.keytab

    but this is working only with AD users!
    Your way helped me to do it with local ipa users. Yes, I read the doc but I did not understood it well.

    So, thanks again!

  3. FYI .. If you don’t have ipa, you can do this on a windows box to get a usable keytab for an AD user:

    ktpass /princ username@MYDOMAIN.COM /pass password /ptype KRB5_NT_PRINCIPAL /out username.keytab

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.