Contents

Kerberos Services in Ubuntu

Kerberos Services in Ubuntu

This article explains a little bit about the Kerberos protocol and how it can be used in Ubuntu. It's not a thorough manual, use more authoritative sources to get more accurate information and update if you see obvious mistakes.

Regular authentication, directory and Kerberos

In regular, or disjoint services, a user can get access to the service by providing his user+password to the service, which verifies it against its own store. Whenever you change the password there, it is only changed for that particular service.

As this causes some issues, i.e. the user needs to maintain many different passwords on all the services, a central directory protocol (LDAP) was standardized, so that the service can connect to a directory to verify the user credentials for the service. Although the user still needs to authenticate separately to each service, his password is kept consistent, as it is enough to just update the directory.

There is one other problem left with this scheme: if any of the services gets compromised, the user password can be used to acquire access to any other service. Kerberos was designed to solve this particular issue.

Kerberos tickets

Kerberos is about tickets: you have a Kerberos ticket for everything: for the master Kerberos server, for any service you authenticate against, for getting service tickets and for the services themselves.

From the client perspecive, it looks like this: you authenticate against the master Kerberos server and acquire a TGT (ticket granting ticket). When you want to authenticate to a service (say https://webserver.example.com), you use your TGT to acquire a ticket for the service you connect to. The service needs to have a previously-acquired Principal ticket and it verifies the ticket from the request with its principal ticket.

This provides a neat single sign-on mechanism - you do not need to enter your password for every service, as there is no password required, just the ticket which is acquired based on the initial log in.

Kerberos in Microsoft Directory Services

Microsoft Directory Services, also known as the Active Directory, provide both LDAP and Kerberos protocol implementations and they are on by default. The Domain Controllers hold the Kerberos Key Distribution Centre (KDC) role and can generate both the SPN (Service Principal Name) tickets, the TGT tickets and the service client tickets.

All the Windows machines have a machine account in Active Directory. In technical terms this machine account is very similar to a user account - it has its name and password, it can have its TGT ticket and a service ticket. You can also assign a SPN ticket to an account (machine or account). A subtle difference is that in LDAP the machine name has a dollar sign added to it in its samaccountname attribute, whereas a regular user account does not. Also the LDAP attributes may be different between a machine account and a user account.

Kerberos from a Ubuntu client perspective

For the correct configuration of a Ubuntu client to work in a Kerberos environment, please follow either sssd guide or LDAP+Kerberos guide. Either of those authentication methods should provide you with a valid TGT upon login. You can verify this by issuing the 'klist' command. The excerpt below was done after logging in:

$ klist
Ticket cache: FILE:/tmp/krb5cc_10101_vcZKNX
Default principal: ballock@EXAMPLE.COM

Valid starting     Expires            Service principal
02/07/13 14:16:58  03/07/13 00:16:58  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 03/07/13 14:16:58

When you connect using Kerberos to any Kerberized service, klist should also list the ticket for that particular service. The excerpt below shows a klist output upon authenticationg to a Kerberized webserver:

$ klist
Ticket cache: FILE:/tmp/krb5cc_10101_vcZKNX
Default principal: ballock@EXAMPLE.COM

Valid starting     Expires            Service principal
02/07/13 14:16:58  03/07/13 00:16:58  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 03/07/13 14:16:58
02/07/13 14:58:31  03/07/13 00:16:58  HTTP/webserver.example.com@
        renew until 03/07/13 14:16:58
02/07/13 14:58:31  03/07/13 00:16:58  HTTP/webserver.example.com@EXAMPLE.COM
        renew until 03/07/13 14:16:58

What you can do with a machine client ticket

If a Ubuntu machine has a respective AD machine account, it can use it for a couple of interesting cases.

First of all, the machine$ account behaves similarly to a user account. It is possible to login and act in the name of the machine account. So, it is possible to log into the AD's LDAP with the account to get the list of users. It is possible to grant access to Windows shares to machine accounts and access it from a script which uses the machine account.

Machine account has a machine password which can expire, so it is a good habit to periodically verify that the machine account is valid and to change the machine account password. This also triggers an update to the account's tickets.

In some (most?) AD-based DNS implementations it is also possible to use nsupdate to update DNS entries (A and PTR) and correct them if they are no longer valid, using the Kerberos machine account client ticket.

How to acquire the machine ticket

To acquire the aforementioned machine client ticket, you need to acquire the TGT ticket of the user that can join the machine to the domain (an admin account in most cases, but you can grant joining rights for the particular machine to a particular user) and use msktutil (http://code.google.com/p/msktutil/) to get the SPN ticket for the machine:

# kinit administrator
Password for administrator@EXAMPLE.COM: 
# msktutil -c

This is how you can verify that your machine has a valid Kerberos client ticket. Note 'sudo su -', not 'sudo -s', as we need the root's environment, including its Kerberos ticket cache.

$ sudo su -
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: machine$@EXAMPLE.COM

Valid starting     Expires            Service principal
03/07/13 07:28:17  03/07/13 17:28:17  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 04/07/13 07:28:17

Kerberized SSH

Once msktutil is run, the machine gets an SPN ticket for the host service. This service is used by the SSH service. Installing ssh-krb5 configures SSH daemon with GSSAPI enabled. This allows you to ssh to your Ubuntu machine without providing your password (of course, to your account on that machine). You don't even need SSH keys for that.

To verify your Kerberos-based SSH server works

Check your Kerberos SPN cache:

# klist -k -t
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
  13 02/07/13 09:02:18 machine$@EXAMPLE.COM
  13 02/07/13 09:02:18 machine$@EXAMPLE.COM
  13 02/07/13 09:02:18 machine$@EXAMPLE.COM
  13 02/07/13 09:02:19 host/machine@EXAMPLE.COM
  13 02/07/13 09:02:19 host/machine@EXAMPLE.COM
  13 02/07/13 09:02:19 host/machine@EXAMPLE.COM
  13 02/07/13 09:02:19 host/machine.example.com@EXAMPLE.COM
  13 02/07/13 09:02:19 host/machine.example.com@EXAMPLE.COM
  13 02/07/13 09:02:19 host/machine.example.com@EXAMPLE.COM

Note that you can see the 'host/' principal here. CASE MATTERS! The ssh service requires a lowercase 'host' service. If it's uppercase, it requires correction.

Check your /etc/ssh/sshd_config. It should contain the line:

GSSAPIAuthentication yes

Check that you can connect to the machine without entering your password. You may need to specify the whole fqdn for connection. Below excerpt is from verbose mode:

tokarbol@machine:~$ ssh -v machine.example.com
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /home/ballock/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to machine.example.com [192.168.12.12] port 22.
debug1: Connection established.
debug1: identity file /home/ballock/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/ballock/.ssh/id_rsa-cert type -1
debug1: identity file /home/ballock/.ssh/id_dsa type -1
debug1: identity file /home/ballock/.ssh/id_dsa-cert type -1
debug1: identity file /home/ballock/.ssh/id_ecdsa type -1
debug1: identity file /home/ballock/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA c3:f2:18:3e:24:45:46:37:68:a9:30:d1:19:38:41:a7
debug1: Host 'machine.example.com' is known and matches the ECDSA host key.
debug1: Found key in /home/ballock/.ssh/known_hosts:206
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Authentication succeeded (gssapi-with-mic).
Authenticated to machine.example.com ([192.168.12.12]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_IE.UTF-8
Welcome to Ubuntu 12.04.2 LTS (GNU/Linux 3.2.0-49-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

7 packages can be updated.
0 updates are security updates.

Last login: Wed Jul  3 07:41:13 2013 from machine.example.com

After a kerberos connection you should get a service ticket on the client machine:

$ klist
Ticket cache: FILE:/tmp/krb5cc_10101_vcZKNX
Default principal: ballock@EXAMPLE.COM

Valid starting     Expires            Service principal
03/07/13 07:31:40  03/07/13 17:31:41  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 04/07/13 07:31:40
03/07/13 07:41:06  03/07/13 17:31:41  host/machine.example.com@
        renew until 04/07/13 07:31:40
03/07/13 07:41:06  03/07/13 17:31:41  host/machine.example.com@EXAMPLE.COM
        renew until 04/07/13 07:31:40

Kerberized HTTP

If you wanted to provide single-sign-on to your webserver running on a Ubuntu machine, here's a rough how-to:

Verify you have a valid machine client ticket:

$ sudo su -
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: machine$@EXAMPLE.COM

Valid starting     Expires            Service principal
03/07/13 07:28:17  03/07/13 17:28:17  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 04/07/13 07:28:17

Acquire the HTTP service ticket from AD. Note CASE MATTERS. It's uppercase HTTP, not lowercase, unlike the 'host' service. Use HTTP even if you plan to use 'https://' (secure http).

# msktutil -u -s HTTP
Waiting for password replication (0 seconds past)
Waiting for password replication (5 seconds past)
Waiting for password replication (10 seconds past)
Waiting for password replication (15 seconds past)
Waiting for password replication (20 seconds past)
Waiting for password replication (25 seconds past)
Re-attempting password reset for machine$
Waiting for password replication (0 seconds past)
Waiting for password replication (5 seconds past)
Waiting for password replication (10 seconds past)

Verify your service ticket is in place. Look only at the highest KVNO (key version number), as the previous ones are kept in the keytab to maintain previous sessions.

# klist -k -t -e
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
  13 02/07/13 09:02:18 machine$@EXAMPLE.COM (arcfour-hmac) 
  13 02/07/13 09:02:18 machine$@EXAMPLE.COM (aes128-cts-hmac-sha1-96) 
  13 02/07/13 09:02:18 machine$@EXAMPLE.COM (aes256-cts-hmac-sha1-96) 
  13 02/07/13 09:02:19 host/machine@EXAMPLE.COM (arcfour-hmac) 
  13 02/07/13 09:02:19 host/machine@EXAMPLE.COM (aes128-cts-hmac-sha1-96) 
  13 02/07/13 09:02:19 host/machine@EXAMPLE.COM (aes256-cts-hmac-sha1-96) 
  13 02/07/13 09:02:19 host/machine.example.com@EXAMPLE.COM (arcfour-hmac) 
  13 02/07/13 09:02:19 host/machine.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96) 
  13 02/07/13 09:02:19 host/machine.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96) 
  14 03/07/13 07:32:12 machine$@EXAMPLE.COM (arcfour-hmac) 
  14 03/07/13 07:32:13 machine$@EXAMPLE.COM (aes128-cts-hmac-sha1-96) 
  14 03/07/13 07:32:13 machine$@EXAMPLE.COM (aes256-cts-hmac-sha1-96) 
  14 03/07/13 07:32:13 host/machine@EXAMPLE.COM (arcfour-hmac) 
  14 03/07/13 07:32:13 host/machine@EXAMPLE.COM (aes128-cts-hmac-sha1-96) 
  14 03/07/13 07:32:13 host/machine@EXAMPLE.COM (aes256-cts-hmac-sha1-96) 
  14 03/07/13 07:32:13 host/machine.example.com@EXAMPLE.COM (arcfour-hmac) 
  14 03/07/13 07:32:13 host/machine.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96) 
  14 03/07/13 07:32:13 host/machine.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96) 
  14 03/07/13 07:32:13 HTTP/machine.example.com@EXAMPLE.COM (arcfour-hmac) 
  14 03/07/13 07:32:13 HTTP/machine.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96) 
  14 03/07/13 07:32:13 HTTP/machine.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)

Install apache2 and libapache2-mod-auth-kerb packages. Configure the location you want to authenticate users:

  <Location /login>
    AuthType Kerberos
    AuthName "Ubuntu webserver - enter domain username and password"

    Krb5Keytab /etc/krb5.keytab
    KrbAuthRealm EXAMPLE.COM
    KrbMethodNegotiate on
    KrbSaveCredentials on
    KrbMethodK5Passwd on
    KrbLocalUserMapping on

    Require valid-user
  </Location>

Note that by default, Firefox browser in Ubuntu only trust 'https://' sites for Kerberos authentication, so you need to get a valid SSL certificate and configure https. For debugging you can change the client's about:config setting 'network.negotiate-auth.trusted-uris'.

Testing Kerberized HTTP

Try logging in to the webpage you configured for Kerberos. You should be automatically logged in, and the tickets cache should show your client service ticket:

$ klist
Ticket cache: FILE:/tmp/krb5cc_10101_vcZKNX
Default principal: tokarbol@EXAMPLE.COM

Valid starting     Expires            Service principal
03/07/13 07:31:40  03/07/13 17:31:41  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 04/07/13 07:31:40
03/07/13 08:09:22  03/07/13 17:31:41  HTTP/machine.example.com@
        renew until 04/07/13 07:31:40
03/07/13 08:09:22  03/07/13 17:31:41  HTTP/machine.example.com@EXAMPLE.COM
        renew until 04/07/13 07:31:40

If the authentication does not work for some reason, check if the Kerberos ticket version is valid and contains the valid crypttypes. You can

$ kvno HTTP/machine.example.com
HTTP/machine.example.com@EXAMPLE.COM: kvno = 14

I have also noticed that some valid services return kvno higher by 256 than the version in the keytab and this kvno seems to be valid too.

Alternative server name

Now, what if you wanted to have a service accessible not only with machine.example.com, but, also, say, webserver.example.com? It's possible, but not obvious.

Theoretically getting a DNS CNAME record should be enough. When a client tries to connect to webserver.example.com it will find it's a CNAME for machine.example.com and acquire a ticket for machine.example.com. Unfortunately, that does not always work. From my testing, it works from Windows clients and from Ubuntu, if you override the MIT gssapi with Heimdal's gssapi library. The behaviour, however, is not consistent when you use a proxy. It may or may not work.

So, what you need is to have a Kerberos SPN for that webserver.example.com domain name. Unfortunately, msktutil is only allowed to provide you with the fqdn of your machine. You need an AD admin to grant you a service for a different fqdn. Once you acquired a DNS (preferably CNAME) for your service, you need to have your AD domain admin run something like the commands below.

This one adds a kerberos HTTP service ticket for webserver.example.com and www.webserver.example.com to 'machine' machine account.

setspn.exe -a HTTP/webserver.example.com machine
setspn.exe -a HTTP/www.webserver.example.com machine

Once this is done, you need to update your keytable with 'msktutil -u'. Voila.

Web portal served by multiple servers

Active Directory generates an integrated Kerberos keytab for all services belonging to an account. So if you want to provide a service called balanced.example.com and you assign the SPN to machine 'machine1' (with setspn.exe as above), it can ONLY be used with that machine. You CANNOT add the same SPN to a 'machine2' machine account. Setspn.exe will allow that but both machines will be roasted, I mean, Kerberos authentication will no longer work.

In order to provide a Kerberos ticket for the same SPN for both machines, you need to acquire an AD user, most likely a regular user, not a machine account and assign the SPN with setspn.exe to that user and to NO ONE ELSE. You can verify duplicate SPNs on Windows 7+ with setspn.exe -X. Note that most likely you will need to set the user account with a password that does not expire.

The functionality in msktutil is only present in the 0.5 release of msktutil.

Use kinit on one of the machines using the user principals and run msktutil to get the user keytab (sorry, I did not test this command):

# kinit balanced_kerberos_user
# msktutil --create --use-service-account --service HTTP/balanced.example.com --keytab /etc/krb5.keytab --accountname balanced_kerberos_user --no-pac

Enterprise/Authentication/KerberosServices (last edited 2013-11-07 06:35:36 by 91)