Kerberos and Active Directory

So I built a quick AD domain based on W2k3 R2. I created TESTDOM.AD.SPUDDY.ORG as my AD domain, and made my primary DNS delegate that part of DNS to the AD server.

I was able to join an XP client to the domain.

So far, so good!

So then I built a CentOS 5.6 machine and configured it for Kerberos. set up krb5.conf:

[libdefaults]
 default_realm = TESTDOM.AD.SPUDDY.ORG
 dns_lookup_realm = true
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 forwardable = yes

[realms]
 # TESTDOM.AD.SPUDDY.ORG ={
  # kdc = admaster.testdom.ad.spuddy.org:88
  # admin_server = admaster.testdom.ad.spuddy.org:749
  # default_domain = testdom.ad.spuddy.org
 # }

[domain_realm]
 .testdom.ad.spuddy.org = TESTDOM.AD.SPUDDY.ORG
 testdom.ad.spuddy.org = TESTDOM.AD.SPUDDY.ORG

I configured sshd for kerberos, same as for my real kerberos machine.

So far, so good:

sweh@dhcp219's password: 
Last login: Sun Jul  3 18:26:12 2011 from mercury.spuddy.org
$ klist
Ticket cache: FILE:/tmp/krb5cc_500_JYPNYK7309
Default principal: sweh@TESTDOM.AD.SPUDDY.ORG

Valid starting     Expires            Service principal
07/03/11 18:42:31  07/04/11 04:42:32  krbtgt/TESTDOM.AD.SPUDDY.ORG@TESTDOM.AD.SPUDDY.ORG
        renew until 07/04/11 18:42:31


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

Of course I’m using local users, but with Kerberos password authentication, and happily getting tickets.

Next step is to join the machine to the domain so I can use tickets. Here things get a little interesting. Samba’s “net ads join” command can seem to do it, but I didn’t want to modify the standard Samba config. Fortunately you can specify “-s” to a different config file:

# cat smb.conf.AD 
[global]
workgroup = TESTDOM
realm = TESTDOM.AD.SPUDDY.ORG
security = ads
password server = admaster.testdom.ad.spuddy.org
use kerberos keytab = true

# net ads join -s smb.conf.AD  -U administrator
administrator's password: 
Using short domain name -- TESTDOM
DNS update failed!
Joined 'DHCP219' to realm 'TESTDOM.AD.SPUDDY.ORG'

The DNS failure doesn’t seem important; it’s probably an artifact of my having a different DNS domain for my machines than the AD server. But looking at AD from the W2K3 GUI, I see the host is created. So not we can create they keytab:

# net ads keytab create -s smb.conf.AD -U administrator
administrator's password: 
# klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   5 host/dhcp219.spuddy.org@TESTDOM.AD.SPUDDY.ORG
   5 host/dhcp219.spuddy.org@TESTDOM.AD.SPUDDY.ORG
   5 host/dhcp219.spuddy.org@TESTDOM.AD.SPUDDY.ORG
   5 host/dhcp219@TESTDOM.AD.SPUDDY.ORG
   5 host/dhcp219@TESTDOM.AD.SPUDDY.ORG
   5 host/dhcp219@TESTDOM.AD.SPUDDY.ORG
   5 DHCP219$@TESTDOM.AD.SPUDDY.ORG
   5 DHCP219$@TESTDOM.AD.SPUDDY.ORG
   5 DHCP219$@TESTDOM.AD.SPUDDY.ORG

So far so good… I can login using tickets!

$ klist
Ticket cache: FILE:/tmp/krb5cc_500_JYPNYK7309
Default principal: sweh@TESTDOM.AD.SPUDDY.ORG

Valid starting     Expires            Service principal
07/03/11 18:42:31  07/04/11 04:42:32  krbtgt/TESTDOM.AD.SPUDDY.ORG@TESTDOM.AD.SPUDDY.ORG
        renew until 07/04/11 18:42:31


Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached
$ ssh -o 'GSSAPIDelegateCredentials=yes' dhcp219
Last login: Sun Jul  3 18:42:31 2011 from mercury.spuddy.org
$

At first attempt ksu didn’t work either.

But adding this domain_realm mapping:

  .spuddy.org = TESTDOM.AD.SPUDDY.ORG

and now ksu works:

$ klist
Ticket cache: FILE:/tmp/krb5cc_500_Zvavdv8343
Default principal: sweh@TESTDOM.AD.SPUDDY.ORG

Valid starting     Expires            Service principal
07/03/11 23:55:16  07/04/11 09:55:17  krbtgt/TESTDOM.AD.SPUDDY.ORG@TESTDOM.AD.SPUDDY.ORG
        renew until 07/04/11 23:55:16


Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached
$ ksu
Authenticated sweh@TESTDOM.AD.SPUDDY.ORG
Account root: authorization for sweh@TESTDOM.AD.SPUDDY.ORG successful
Changing uid to root (0)
[root@dhcp219 sweh]#

I guess I don’t understand the domain_realm mappings; I’d been cargo-culting. I guess they’re host DNS domain maps to kerberos realm. Which, really, doesn’t strike me as necessarily sane. Why wouldn’t the default_realm value from the [libdefaults] section take precedence, anyway?

It’s not all sunshine and roses, though. /var/cache/samba/gencache.tdb is modified; I don’t know if this would impact existing samba usage.