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)Note that the default filenames used are /tmp/krb5cc_<uid> (for kerberos5) and /tmp/tkt<uid> for Kerberos4.Kerberos 4 ticket cache: /tmp/tkt500 klist: You have no tickets cached
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.ORGNote 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.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
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)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...Kerberos 4 ticket cache: /tmp/tkt500 klist: You have no tickets cached
[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.ORGAh 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.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
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.ORGDifferent temporary filename, but it works the same.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.
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.ORGI'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!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
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!