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.ORGI 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.ORGSo 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.ORGand 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.