I'm having a huge problem with Active Directory too. Our AD server is set to lock an account after three failed login attempts.
It appears that for some reason when logging in to the network from the login page, you get two tries before being locked out instead of three. Also, when logged in, then logging out and then trying to log back in again, you get one try.
There also appears to be a random, system-wide, issue when authenticating using Active Directory credentials, particularly with modal boxes asking for authentication. Sometimes it will work, other times it will lock the account on the first try EVEN WITH THE CORRECT INFORMAITON.
I've been calling IT all day having them reset my password. They'll never let Mountain Lion in the building if this continues.
Mine is not having a problem where it is locking me out, however, every error points to "failed authentication"
I have filed a case with Apple and have it already escalated to Engineering, so as soon as I know more, I will update this thread.
(also, this appears to be ML specific, as I have a colleague experiencing very similar issues after his upgrade to ML)
It's terrible. I logged a bug report with them too but just uder feedback.
It seems to now be randomly locking my account even when I haven't done anything. I've been on the phone with my IT buddy and he'll watch it be unlocked, I'll logout of my account, and it will lock.
Active Directory has been a nightmare since they launched Lion. With every "fix" came another problem. It seems this lack of caring or testing or whatever it is, has persisted into Mountain Lion.
Might have just had a little breakthrough -
I would like to see if someone else can confirm this resolves their issue -
try and going into NETWORK PREFERENCES > (your connection, wifi or ethernet) > ADVANCED > HARDWARE >
Set your Configuration to "MANUALLY"
Speed - "AUTOSELECT"
MTU = "CUSTOM" - set to 1350 (for example)
Basically, there is an issue on the local network that prevents packet sizes over a certain size (at least for me) which was causing all these random issues.
(also, you dont want to know what all i had to go through to figure this out)
Thanks for the efforts Justin but no dice here either.
Here's what it's come down to for me. I've been working from the local admin account all morning. I logged out of Administrator and went to login to my Active Directory account. I absolutely made sure I typed everything perfectly, hit enter and it instantly locked my AD account.
Seriously, does Apple test this stuff AT ALL?
Well, I figured out what is causing my problem. It's Mobile accounts. I started fresh with a new install and a standard Active Directory account (not Mobile). I authenticated 20+ times. Rebooted at least 10 times. Everything worked great. Then I decided to create the Mobile account. That's when everything broke again. My Active Directory account was getting locked after one accurate attempt to authenticate. When IT unlocked it I could go one step further but then would lock me out the next time I tried to authenticate.
So for me, it's clearly a Mobile account problem. Which is bad because half of the Macs under my care are notebooks.
Please let me know what you find out on your end.
We are also seeing an issue in ML where some AD users cannot log in. The common factor is that they all have a PrimaryGroupID value of '-2'. Here are the relevant logs:
2012-07-30 10:17:39.630098 EDT - 4202.17304.17306.17310.17312, Node: /Active Directory/BUTLER/Global Catalog, Module: ldap - found result - 'CN=tjohnsto,CN=Users,DC=butler,DC=edu'
2012-07-30 10:17:39.630216 EDT - 4202.17304.17306.17310.17312, Node: /Active Directory/BUTLER/Global Catalog, Module: ldap - translation routine callback failed to translate 'dsAttrTypeStandard:PrimaryGroupID', falling through to other methods
2012-07-30 10:17:39.649537 EDT - 4202.17304, Module: SystemCache - Ignoring entry (tjohnsto@/Active Directory/BUTLER/butler.edu) missing critical identifier dsAttrTypeStandard:PrimaryGroupID
As you can see, the PrimaryGroupID cannot be handled by opendirectory, and the user is denied access.
What we cannot determine is why some users are interpreted as having a GID of -2, despite the fact that their primary group in AD is the same (Domain Users).
We are having exactly the same issue. All accounts work fine using machines bound to AD using 10.6 or 10.7. Some accounts using 10.8 will work, others not. Fresh install or upgrade, same result.
Filed Bug Track last week.
Problem ID: 11956556
Quick test = at the terminal window type "id account" on bound 10.8 machine, if AD groups come back, that account will work. If "no such user" is returned, it won't work.