we had an issue in the past where a lab of machines wouldn't be able to log in on every third machine that started up.
Turned out there were some old records still in the DNS pointing to a Domain Controller that had long since been de-commissioned.
The below commands will return the DNS records for each service that AD uses:
LDAP
KERBEROS
KPASSWD
and
GC
host -t SRV _ldap._tcp.YOUR.DOMAIN
host -t SRV _kerberos._tcp.YOUR.DOMAIN
host -t SRV _kpasswd._tcp.YOUR.DOMAIN
host -t SRV _gc._tcp.YOUR.DOMAIN
Hope that helps
Hi,
This is quite a big question as there are lots of things that could be causing it. If you have some working and some not, the first question is what is the difference between them? Specifically, what DNS server(s) are they looking at? are their times in sync? Can they successfully perform the lookups mentioned above? Can they reach the servers that are found in the above DNS lookups?
I'm fairly sure information from one of these questions will give you the answer.
We have had problems logging onto the domain if the time on the Mac is wrong or if the permissions on their home directory on a Windows server were not correct.
I would double-check AD and see if there is a home folder path setup. If the path is incorrect, or if the user doesn't have the correct permissions to the home folder, you won't be able to login on the mac.
I recently ran into a similar sounding issue with the computers bound to AD. It turned out to be an issue with login information being cached on the computers. A restart apparently does not reset the cache and rebinding a computer does not reset the cache either. I was able to resolve the issue by running the following command against a computer that had the issue.
odutil reset cache
Once the command was run, all users were able to login to the computer again. Hopefully, this helps you out.