Leopard Active Directory Integration Headaches
Ever since Leopard came out, we have been having a heck of a time trying to get Leopard to bind and/or authenticate to Active Directory reliably. We use Active Directory sites and our Leopard macs were trying to authenticate to Domain Controllers in the wrong site. I’m reminded of something Joel Rennich said in a Troubleshooting Directory Services (I can’t find the link at the moment) webcast, (I’m paraphrasing here) “adding Macs to AD can reveal problems with your AD you didn’t known about”.
The reason is because your PCs will work around and hide problems differently than a Mac will. While your PCs might try to authenticate to a decommissioned or pingable domain controller, it will give up sooner whereas a Mac will sit there for 240 seconds per domain controller before giving up. Tiger would use ping to determine if a domain controller was reachable or not, if it was, DirectoryServices would assume it should be able to authenticate to it until it eventually timed out. A solution to this was to prevent your domain controllers from responding to pings from outside of the networks it provides authentication to or to use DNS zones.
Leopard however, changed this. It appears that Leopard does not use ping to determine if a domain controller is reachable. It now checks to see if port 389 (LDAP) is open. If it is, it assumes 88 (kerberos), 464 (kpassword) and 3268 (Global Catalog) will be available. For some reason, our organization had 389 open to our domain controller’s in our DMZ but nothing else from the rest of our network. This was probably for added redundancy or replication since almost every service we have uses LDAP on the back end.
This command (in Leopard) will tell you which DC’s your machine is trying to talk to.
dscl . -read /Config/Kerberos:YOUR.REALM.EDU
I am not sure what makes Leopard even attempt to use a domain controller outside of its defined AD site, but if it does, make sure ports 88, 389, 464 and 3268 are not reachable between sites unless there’s a reason to do so.
Ever since we blocked port 389 to the domain controllers’s in our DMZ, we have been having much better success with Leopard AD authentication.
Related posts:
If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.
I work at Yale university in the IT Dept. We mostly don’t even bother pushing the macs into AD. Any reason why you went this way……typically mac users march to their own drummer.
@Jonathan – AD is where the user accounts are.
@Patrick – I have several macs bound to the domain, but after working for some time (successfully authenticating to the domain) – they stop authenticating when connected to the network. AD account and password status are perfectly ok and verified, but when trying to authenticate with AD credentials and connected to the network, authentication fails. If the user simply disconnects the network connection, they are able to authenticate successfully. They are using a mobile account, and their password should be cached anyway, but something weird seems to be happening when the mac is contacting the domain controller. Any ideas? I was just wondering if you have come across this before. This is happening on a couple of computers running 10.5.8 and 10.6.2. Thanks for any suggestions!