Thanks everyone, this has been really helpful. I've just managed to get Lion working perfectly with both AD and Kerberos single-sign-on logins. Frankly, I am amazed ... after the first few hours of trial and error (mostly error) I didn't think it would ever work reliably. I''ve so far replicated my config on 2 machines, and it seems to work.
So, here's the setup:
We have an Active Directory Domain (henceforth the "Domain"), set up in a trust relationship with the Kerberos Realm (henceforth the "Realm") of the wider organisation. There are some users who exist only in the Domain, and others who exist in the Realm. For the latter, we have usernames in the Domain that mirror the Realm users, and have them mapped. (Just to make sure that's clear: there are some users in the domain that don't exist in the Realm, and then there are some users in the domain that do exist in the realm, and obviously their login credentials are managed by the realm, so they have Name Mappings on the DC to their respective Kerberos Principal names, which are identical to their AD logon names) We run 2 file servers, one - a Windows server - for the users that only exist in the Domain, and one - a Linux server - for those from the Realm. Now we wanted everybody to authenticate and use network home folders on OS X. Previously we had to make do with AdmitMac, and it created all sorts of problems but worked more or less (sometimes less; some applications expect to set file attributes that AdmitMac's smb client didn't support, so for example SPSS and EndNote gave us no end of grief). Today I was shocked to discover that I simply couldn't get things to work with Lion and AdmitMac 6, so I tried the impossible, ...
This is how it works for me:
Make sure you don't have a /Library/Preferences/edu.mit.Kerberos - just delete it if it's there.
Make sure you are NOT a member of any AD domain at this point.
Make sure the computer clock is set correctly (yes, I know ... the obvious things)
Create /etc/krb5.conf (I can't guarantee all those settings are really necessary, but it works for me at the moment):
[domain_realm]
.our.domain.within.wider.org = OUR.DOMAIN.WITHIN.WIDER.ORG
our.domain.within.wider.org = OUR.DOMAIN.WITHIN.WIDER.ORG
.wider.org = WIDER.ORG
wider.org = WIDER.ORG
[libdefaults]
default_realm = WIDER.ORG
dns_fallback = yes
rdns = no
dns_lookup_kdc = true
forwardable = true
noaddresses = true
allow_weak_crypto = true
default_etypes = arcfour-hmac-md5 des3-cbc-sha1
default_etypes_des = des3-cbc-sha1
default_tgs_enctypes = des-cbc-md5 des-cbc-crc arcfour-hmac-md5
default_tkt_enctypes = des-cbc-md5 des-cbc-crc arcfour-hmac-md5
permitted_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1 arcfour-hmac-md5
[logging]
admin_server = FILE:/var/log/krb5kdc/kadmin.log
kdc = FILE:/var/log/krb5kdc/kdc.log
[realms]
OUR.DOMAIN.WITHIN.WIDER.ORG = {
admin_server = tcp/windows_domain_controller.our.domain.within.wider.org:749
kdc = tcp/windows_domain_controller.our.domain.within.wider.org:88
kpasswd_server = tcp/windows_domain_controller.our.domain.within.wider.org:464
}
WIDER.ORG = {
kdc = kdc.wider.org:88
admin_server = kdc-admin.wider.org:749
default_domain = wider.org
}
Note that I don't know why the upstream organisation has separate kdc and kdc-admin servers ... so in your case this may be the same one ...
So far so good; the krb5.conf isn't that hard to get right; it' s only a bit complicated because of our specific set up.
BUT, here are the magic bits:
In /etc/authorization DON'T mess with the entry called <key>com.apple.KerberosAgent</key> ... but make the following changes:
in <key>system.login.console</key> the <array> entry looks like this:
<array>
<string>loginwindow:login</string>
<string>builtin:reset-password,privileged</string>
<string>builtin:forward-login,privileged</string>
<string>builtin:auto-login,privileged</string>
<string>builtin:krb5authnoverify,privileged</string>
<string>PKINITMechanism:auth,privileged</string>
<string>loginwindow:success</string>
<string>HomeDirMechanism:login,privileged</string>
<string>HomeDirMechanism:status</string>
<string>MCXMechanism:login</string>
<string>loginwindow:done</string>
</array>
find <key>authenticate</key> and make sure it's followed by:
<dict>
<key>class</key>
<string>evaluate-mechanisms</string>
<key>mechanisms</key>
<array>
<string>builtin:authenticate</string>
<string>builtin:reset-password,privileged</string>
<string>builtin:authenticate,privileged</string>
<string>builtin:krb5authnoverify,privileged</string>
<string>PKINITMechanism:auth,privileged</string>
</array>
</dict>
Finally, change the file /etc/pam.d/authorization to be
auth optional pam_krb5.so use_first_pass use_kcminit default_principal
auth optional pam_ntlm.so use_first_pass
auth required pam_opendirectory.so use_first_pass nullok
account required pam_opendirectory.so
ONLY THEN join the Active Directory domain.
Reboot. Maybe twice ...
And it works. I can log in with single-sign-on usernames from the Realm, and usernames from the domain.
Have a nice day, I am going to bed ...
:: Florian
