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!
@Jared – Any number of things could be the issue. You should put one of the affected Macs in DS debug mode with “sudo killall -USR1 DirectoryService”. Then try to login, then check the contents of /Library/Logs/DirectoryService/DirectoryService.debug.log.
One thing that affected us early on is that one of our domain controllers was listed in the wrong site so our Macs would periodically would try to contact that DC. But that is something you would see if the debug log.
try http://www.centrify.com Centrify DirectControl delivers secure access control and centralized identity management by seamlessly integrating your UNIX, Linux and Mac systems and applications with Microsoft Active Directory. DirectControl effectively turns a non-Microsoft system into an Active Directory client, enabling you to secure that system using the same authentication and Group Policy services currently deployed for your Windows systems. DirectControl is non-intrusive, easy to deploy and manage, and is the only solution that enables fine-grained access control through its unique Zone technology.