Beginning kerberos

Disclaimer: I know nothing about Kerberos. I’m learning it all from scratch.

I wanted to do some playing around with Kerberos (once I know Kerberos then I can look better at how to integrate with AD), so at home I set up a couple of CentOS 5.6 server VMs on my home network, built one out as a KDC (“yum install krb5-server”) and one as a Kerberos client talking to the KDC (krb5-workstation installed by default). This is a pretty good “getting started” guide.

On a machine that isn’t kerberized, I have no tickets

non-kerb-client% klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_500)

Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached

Note that the default filenames used are /tmp/krb5cc_ (for kerberos5) and /tmp/tkt for Kerberos4.

On the Kerberos client machine I configured sshd to perform kerberos authentication. So now I login to it:

non-kerb-client% ssh mylogin@kclient
mylogin@kclient's password:
Last login: Wed Jun 29 09:47:29 2011 from mercury.spuddy.org
[mylogin@kclient ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_500_KhWkrB4506
Default principal: mylogin@SPUDDY.ORG

Valid starting Expires Service principal
06/29/11 09:48:53 06/30/11 09:48:53 krbtgt/SPUDDY.ORG@SPUDDY.ORG

Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached

Note the krb5 ticket file has a different name; this is a per-session kerberos ticket file that was created by ssh when I logged in.

I have a “krbtgt” which is a kerberos ticket granting ticket, which means I can now use this session to access other resources…

Let’s access another machine by ssh. In this case the kerberos key distribution center (kdc)

[mylogin@kclient ~]$ ssh kdc
Last login: Wed Jun 29 09:48:11 2011 from kclient.spuddy.org
[mylogin@kdc ~]$ klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_500)

Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached

Well, it let me in without needing a password… but my ticket didn’t carry over! That’s because I didn’t ask for the ticket to be forwarded…

[mylogin@kdc ~]$ logout
Connection to kdc closed.
[mylogin@kclient ~]$ ssh -o 'GSSAPIDelegateCredentials=yes' kdc
Last login: Wed Jun 29 09:49:11 2011 from kclient.spuddy.org
[mylogin@kdc ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_500_GSTIKd5634
Default principal: mylogin@SPUDDY.ORG

Valid starting Expires Service principal
06/29/11 09:49:21 06/30/11 09:48:53 krbtgt/SPUDDY.ORG@SPUDDY.ORG

Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached

Ah ha! Here we go. By telling ssh to delegate credentials, we get a new TGT on the remote server, which can be used for further access.

ktelnet can also do this…

[mylogin@kdc ~]$ logout
Connection to kdc closed.
[mylogin@kclient ~]$ telnet -a -f kdc
Trying 10.0.0.23...
Connected to kdc.spuddy.org (10.0.0.23).
Escape character is '^]'.
[ Kerberos V5 accepts you as ``mylogin@SPUDDY.ORG'' ]
[ Kerberos V5 accepted forwarded credentials ]
Last login: Wed Jun 29 09:49:21 from kclient.spuddy.org
[mylogin@kdc ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_p5780
Default principal: mylogin@SPUDDY.ORG

Valid starting Expires Service principal
06/29/11 09:51:41 06/30/11 09:48:53 krbtgt/SPUDDY.ORG@SPUDDY.ORG

Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached
[mylogin@kdc ~]$ logout
Connection closed by foreign host.

Different temporary filename, but it works the same.

Kerberos can also be used for ‘su’

[mylogin@kclient ~]$ ksu
Authenticated mylogin@SPUDDY.ORG
Account root: authorization for mylogin@SPUDDY.ORG
Changing uid to root (0)
[root@kclient mylogin]# klist
Ticket cache: FILE:/tmp/krb5cc_0.1
Default principal: mylogin@SPUDDY.ORG

Valid starting Expires Service principal
06/29/11 09:48:53 06/30/11 09:48:53 krbtgt/SPUDDY.ORG@SPUDDY.ORG
06/29/11 09:51:06 06/30/11 09:48:53 host/kclient.spuddy.org@SPUDDY.ORG

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

[root@kclient mylogin]# cat /root/.k5login
mylogin@SPUDDY.ORG

I’m pretty sure this is not a good idea; at work we want stronger controls over who can access route, so it means we’ll have to check for .k5login files if we ever switch to kerberos for authentication!

Note that ‘root’ now also has the host key in the kerberos cache.

Note that Kerberos is just an authentication system; it doesn’t handle naming services nor authorizations; it’s just a “secure password repository”.

This is exactly the sort of testing I wanted my XenServer for!