- This topic has 2 replies, 1 voice, and was last updated 17 years, 7 months ago by
.
-
Posts
-
Hi,
I’m working in a project to integrate non-windows computers in to Active Directory and now i have run in to some trouble with our mac clients. I’ve been told that these forums are the most likely place to find an answer. I have searched the forums but have come up empty.
My problem is with getting single sign on to work when connecting to the mac, outgoing connections work as expected. The problem is that i can not get my mac to bind to AD with correct Service Principal Name.
Our AD layout look like this(all names are anonymized):
Domain: example.com
Computer name: mac
FQDN of computer: mac.clients.example.comTo make SSO work DNS name and Kerberos SPN have to match. The computer object in AD should have the following records:
servicePrincipalName: host/mac.clients.example.com
dNSHostName: mac.clients.example.comWhen i bind to AD i get these records instead:
servicePrincipalName: host/mac.example.com
dNSHostName: mac.example.comSo far i have figured out a few things that could go wrong when joining.
1) My client doesn’t know its name
2) AD plugin of Directory Utility doesn’t honor fully qualified hostname.I have verified that my hostname is correct and is matching dns by doing
mac% hostname
mac.client.example.commac% host mac.client.example.com
mac.client.example.com has address (myip)
mac.client.example.com mail is handled by (our mailserver)I have also set the “computer name” field in the “Sharing” view of “System Preferences”
This leads me to believe that option 2 is the most likely cause of the problem. I have tried the following to correct the problem.
1) Precreate my computer account in AD with servicePrincipalName and dNSHostName set to correct values. This did not work, Directory Utility correctly detected my precreated computer account but overwrote the fields with wrong values.
2) Edit servicePrincipalName and dNSHostName to correct values after i bound the client to AD and use the net command from samba to create a new keytab. (net ads keytab create). This did not work either, the net command silently fails and does nothing. The only net ads keytab command that work is flush which empties your keytab, not that helpful…
3) I have searched for a osx tool to update my keytab but i haven’t found one. The tool need to be able to update the keytab by using supplied “Domain Admin” credentials since i think authentication using the computer account will fail due to the faulty SPN. (i’m not 100% sure about that)
Has anyone else noticed this behavior and/or have a workaround for this issue? My testsystem is running macos version 10.5.6 on the previous generation of mac mini. If you need me to supply more information feel free to ask.
Best Regards,
Andreas> From what system are you attempting to access the Mac from?
Im trying to connect from a Debian machine running lenny with ssh. This host has a fully functional kerberos setup (AD integrated using samb/winbind).
If i bypass DNS on the linux client by adding the machost to the hosts file. I get a ticket for host/mac.example.com@EXAMPLE.COM, the mac rejects this ticket even though the ticket exists in /etc/krb5.keytab. This is a bit weird, i would have expected that to work. I’m going to try to set the machine up as mac.example.com in dns just to verify that SSO works in that case.
> If it’s a Mac you can look into creating Kerberos DNS mappings which /should/ allow the Mac to understand the disjointed namespace.
How do you mean? I have Resource records in my DNS for kerberos so i have no trouble finding the kerberosserver. I dont think i have any resourcerecords in clients.example.com only in example.com, i’ll check that with our AD gurus.
> From a PC you should be able to edit the SPN.
> It sounds like you done the second… so maybe you’re attempting to SSO in from a Mac.Yeah, i can edit SPN in AD but i cant get the new keytab to the mac, i could theoretically use ktutil.exe on one of the domaincontrollers but i hope it can be done in another way.
EDIT: i have verified that if i change dns name of the host to mac.example.org and rejoin AD SSO is working as intended. That however is not really an option in my production environment.
Sorry for the late answer, i’ve been on home with the cold.
The mac think it’s name is mac.clients.example.org as i should. Its just that the AD plugin seems to register it in AD as hostname (mac) + AD domain (example.com).
Since we don’t run MS DNS (or any other dynamic dns) the AD plugin cant change the macs name in DNS which leads to a mismatch between DNS and the AD record. In my opinion the AD plugin should not make the assumption that the dns name of the client is shortname + domainname since that will prove to be false in a number of organizations.
- You must be logged in to reply to this topic.