2

I've been troubleshooting this problem for two years and it keeps coming back. Our Mac users authenticate to our Active Directory server which is running Windows Server 2008 Standard. One of the Mac users in particular has had a recurring problem where she can't log on and causes her AD account to lock before the maximum log-in attempts has been reached. The problem started again this week and yesterday I reconfigured her networking and Active Directory settings. This morning I logged on to her computer using her ID and password and had no problems. When she tried it twenty minutes later, her account was locked.

All Macs have Snow Leopard 10.6.7 and they all have the same network and AD settings, but this particular Mac continues to have a problem.

Any suggestions will be greatly appreciated.

Kent

|improve this question
  • 1
    Can you check the logs on the active directory server? I am not a user of AD generally, but if it is logging multiple attempts at a logging into the service, or some other bad behavior, I think that might be very useful. I have had users have mysterious errors that are almost always PEBKAC. Just nice people wanting to avoid looking bad. – ConstantineK Apr 15 '11 at 21:12
  • This is not a AD issue, this is a OSX related issues 100%. – user20562 Mar 22 '12 at 13:41
  • Just to update this, it turned out to be a keyboard problem. For some reason the right shift key would not work in the log-in panel so when she put in her password which had a capital letter, it would not accept it and would eventually get locked out. One day she logged in using the left shift key and all was good. After logging in the right shift key worked normally. – Kent Mar 23 '12 at 13:47
2

Bear in mind that interactive user logons are not the only thing that count as failed logons when it comes to Active Directory account locks. Services that are set to run as a network user and network resources with saved logins can rack up the failed logon count and lock the account.

Hobs' comment to your question is the direction you should head. Check the Security log on the domain controller that the computer authenticates against and you should get the information that you need as far as the source of the failed logons. The fact that it works on other computers only reinforces this. Something is definitely failing, it's just a matter of finding what.

|improve this answer
  • Thinking out loud here. After I logged in successfully this morning something could have been trying to access a network resource which may have caused the account to lock for the user a few minutes later. Can the account lock after it's already authenticated at the workstation? I'll take a look at the server logs on Monday for any hints. I also cranked up the Directory Services debugging log on the Mac. Thanks for the help. Kent – Kent Apr 16 '11 at 3:22
  • @Kent: An account can lock out any time the number of unsuccessful logins within a particular amount of time (or consecutive) is reached. Have you looked in the Security log in the Event Viewer on the DC? That will tell you where the failing authentication is coming from. – Adam Robinson Apr 16 '11 at 3:47
  • Still no clue as to what is causing the lock-ups. Manually entering our DNS servers in Network settings, rather than getting them from DHCP, appears to have solved the issue, again. I don't have the log from last Friday so I can't check it, but recent logs appear normal. – Kent Apr 19 '11 at 17:11
  • @Kent: Looking at the logs after you've patched the problem won't help, unfortunately. You'll have to be able to get the lockout to occur again and check the log for it to be of any value. – Adam Robinson Apr 19 '11 at 17:40
  • @Kent: You also can probably get more help on this issue if you post on serverfault.com instead of here. It sounds more like an AD configuration issue than something specific to OSX (even if the workstation with the issue is running OSX) – Adam Robinson Apr 19 '11 at 17:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .