The Kerberos Experience

From the Observers book of 'You don't have to be a Rocket Scientist but it helps'. ISBN-0322-07716-88

Don't do this. My latest must have began back in November 2011. I decided to take the plunge and get involved with a software project called Samba 4. Although plunge was the right word, philosophy could well be used in its place. This is almost on a par with trying to imagine what an infinite universe is.

Cerberus, Guard Dog of Hades
I received a recording of Claudio Monteverdi's Il ritorno d'Ulisse in patria (1641) as an Xmas gift in 1972, just 331 years after it was first performed. (Vox Turnabout Records, 3 LP set, £2.98) It is an Opera. It is a love story, a home coming, a close encounter, a struggle. Everything any decent drama always is. Ulisse returns home but no one recognises him, not even his wife. In the end she does and it's all a happy ending. It took me longer to find another of his three operas, L'Orfeo on record. By the time I did, it was out on CD.

Orfeo descends into Hades, the Underworld, to try to bring his dead bride Euridice back to the living world. We hear Gods of the Sky and the Underworld pass judgement upon Orfeo. Cerberus is the three headed dog which guards the entrance to and from the Underworld. There's a river in it somewhere too. Now I really do want one of those turntables which can record old records  to a memory stick.

To give you an idea of the drama, here are Neptune and Jupiter in Ulisse passing judgement on humanity.
I'm currently writing out the brass introduction which is heard before we get to this part of the Hass edition of 1922
Italian opera, German translation, Spanish subtitles

And if you want to hear that low C at bar 9

An unprecedented move by Microsoft had them disclose details of part of their software called Active Directory (AD). The AD schema contains details of how user and computer information is stored on Microsoft networks. AD first shipped with Microsoft 2000 server and enjoyed two revisions in the same decade. It is the at centrre of all Microsoft servers and contains not only technical information about all the computers on the nework, but also data about all the users too.

During the early 1980's security and computer systems began to clash. Massechusets Institute of Technology (MIT) decided enough was enough and decided to do something about computer security on their campus in Boston. By the mid 80's, hackers were beginning to extract passwords by intercepting them as they traveled between computers connected by wires into a network. By now, instead of being sent as plain text, passwords were scrambled before being sent across the network to another computer. The computer at the other end knew how to unscramble the code back to the original password and in so doing, allow the user access to data therein. Of course, hackers got better and better at unravelling the scrambled passwords. They intercepted data on its way over from the server to the client posing as the computer that was to receive the data in the first place. This man in the middle attack would prove very difficult to detect. Sensitive information contained on the server would already have been compromised by the time it was realised that an attack had happened. Originally codenamed Athena, the intense 8 year resarch project at MIT became the Kerberos we know today.

The US Government classified Kerberos and prohibited its export for use outside the US. That is why it is used worldwide today.

As Cerberus guarded the entrance to Hades, so Kerberos guards entrance to your server. Both client and server have to authenticate themselves to each other before any information can be exchanged. I have been unable to find any readable explanation of Kerberos. Without implementing it yourself, I don't think you could ever understand it. It's invisible to the user.

Kerberos has its roots firmly set in Unix networks which would have prevailed at MIT at the time of its development. And at last we get to mention Samba 4 which has a superbly engineerd Kerberos server implementation.  I'll start with Daniel Sonck's Wikipedia diagram:

The same Wikipedia article begins its explanation like this:
Kerberos uses as its basis the symmetric Needham-Schroeder protocol. It makes use of a trusted third party, termed a key distribution center (KDC), which consists of two logically separate parts: an Authentication Server (AS) and a Ticket Granting Server (TGS).

Yeah, well. Don't run away yet. Let's see.
Cerberus' three heads represent the three pillars of Kerberos:
-The Server in this example, a fileserver
-The Client
-The trusted third party. This is the Key Distribution Centre (KDC) The KDC consists of
- An authentication server (AS)
- A Ticket granting server (TGS)
-A database containing user, computer and service principals.

e.g. User steve is working on a computer called steve-pc and needs to edit a file stored on an nfs server called fileserver.  The principals involved here are steve as a user, steve-pc as a machine, fileserver as a machine and nfs as a service. For a realm called MYDOMAIN.COM in the domain mydomain.com, those principals look like this:


User principals are created when a user is created. Machine principals are created when a computer is joined to the domain. On our setup with Samba 4 as the KDC, the host principals are created on the machine and stored in a keytab. Similarly, the nfs principal is stored in a keytab on the fileserver. The structure of a keytab is the same as the principal database on the KDC. You can make principals on any computer in the realm by using the samba-tool or net cli.

OK, I'm going to have a think about how to explain this. Here is my first attempt.

In this example, the user needs to edit a file on the fileserver. The client sends its password. The client sends a plain text message to the AS requesting authentication. The AS asks for his password. Back on the client, the password is hashed and sent to back to the AS. The AS then issues a time stamped TGT back to the user. The user can use his TGT to ask the TGS to give him a ticket for the fileserver. This ticket is then sent to the fileserver. The fileserver checks the ticket and requests a ticket too. If the keys for the on the two tickets match and they were created by the TGS within an agreed time skew, the user is then sent the file. Not quite good enough!

Don't laugh. Here is my diagram.
I gave up on this

Next I suppose I have to go through A to H in the first diagram. My diagram didn't get to the A to H stage. Not even close, so let's do it with an example.
Here's what appears on the KDC during a session after authentication.
user steve5 in Kerberos realm HH3.SITE
fileserver and nfs server fqdn hh3.hh3.site
Client, KDC and fileserver all on the same old laptop running from a USB memory stick. Sic.

The fileserver share is mounted on the client:
We'll use /mnt as the client.

mount -t nfs4:/home /mnt -o sec=krb5
produces a lot of activity including:
Kerberos: TGS-REQ HH3$@HH3.SITE from ipv4: for
nfs/hh3.hh3.site@HH3.SITE [canonicalize, renewable]
Kerberos: TGS-REQ authtime: 2012-01-28T21:16:16 starttime:
2012-01-28T21:16:16 endtime: 2012-01-29T07:16:16 renew till:

user steve5 logs in:

Kerberos: AS-REQ steve5@HH3.SITE from ipv4: for
Kerberos: Client sent patypes: 149
Kerberos: Looking for PKINIT pa-data -- steve5@HH3.SITE
Kerberos: Looking for ENC-TS pa-data -- steve5@HH3.SITE
Kerberos: No preauth found, returning PREAUTH-REQUIRED -- steve5@HH3.SITE
Kerberos: AS-REQ steve5@HH3.SITE from ipv4: for
Kerberos: Client sent patypes: encrypted-timestamp, 149
Kerberos: Looking for PKINIT pa-data -- steve5@HH3.SITE
Kerberos: Looking for ENC-TS pa-data -- steve5@HH3.SITE
Kerberos: ENC-TS Pre-authentication succeeded -- steve5@HH3.SITE using

steve5 goes to the mount to get a file:

Kerberos: TGS-REQ steve5@HH3.SITE from ipv4: for
nfs/hh3.hh3.site@HH3.SITE [canonicalize, renewable, forwardable]
Kerberos: TGS-REQ authtime: 2012-01-28T21:21:50 starttime:
2012-01-28T21:23:29 endtime: 2012-01-29T07:21:50 renew till:

I'll get back 2 u!