WinXP workstations on Server 2008 domain:

  1. User locks screen and leaves computer for a break.
  2. User forgets his/her password while away.
  3. User makes a series of invalid login attempts and his/her account is locked out. XP displays a dialog box warning the user that the lockout has occurred.
  4. User ignores dialog box and makes additional login attempts, suddenly remembering his/her correct password.
  5. Windows XP allows the user to unlock the screen with the correct password, despite that the user's account is now locked out on the domain controller(s).
  6. User eventually calls the help desk to complain about an inability to print or access network drives.

We were a bit shocked to discover that Windows is allowing users with locked-out accounts to unlock their screens, despite that it is hitting the domain controller with each authentication attempt and thus generating the lockout event.

Under the current scenario, it would seem that one could guess an unlimited number of passwords on any Windows XP station whose screen is locked. This is not desirable.

Is there a way to make Windows XP respect the account lockout and deny access until the account is unlocked?


3 Answers 3


It's by design and looks rather logical. If users account are locked on domain controller, users cannot login with domain account anymore.

But on the locked workstation, all authorization (since no attempts to access any resources, e.g. fileshare, which require a new domain credentials check) is performed by the local security system because the local system trusts such users (already checked and authorized by AD).

So for this unlocked workstation security system, such users are still legal, but they are not able to access use any resource with domain authentication (printer/network drive) because account is locked already.

  • Don't know why this was downvoted - I think the core of what you're saying is correct. An account lock-out is notified to each domain controller but it doesn't actively propogate to workstations. Workstation lock/unlock actions run on cached credentials and don't check-in with the domain. Hence, you may be able to unlock your workstation even if the account is locked out. Sep 23, 2010 at 22:40
  • +1 The lockout has no effect on an account unlocking a workstation, as that operation merely checks the credentials are those of the user who's session is locked, not whether or not that account is still valid and active. I've been able to unlock workstations even with accounts that have since been deleted from AD. Whoever downvoted this needs to do some serious learning. Sep 24, 2010 at 3:32
  • 2
    @Chris and John: Thanks for the insight. I hadn't even considered cached logon credentials and the ability to log on to the workstation even if the user account is locked out, disabled, or deleted. After reading your comments and thinking about it again, it's clear that that's what is happening in the OP's case.
    – joeqwerty
    Sep 24, 2010 at 14:00
  • OK. Actually, it turns out that there is a group policy setting requiring workstations to check with the domain controller before unlocking the screen. That's what I was looking for all along. I have added another answer referencing this setting.
    – Skyhawk
    Oct 13, 2010 at 0:24
  • I didn't down vote, but if this is by design as you state, then it's a very poor design IMHO! I wonder how many support staff would enforce a password reset upon unlocking an account? Not many I suspect!
    – Bryan
    Feb 13, 2011 at 22:51

Restricting cached credentials in Windows:

To force the workstation to consult a domain controller when unlocking, set the Computer Configuration, Windows Setting, Local Policy, Security Options control of "Interactive Logon: Require Domain Controller authentication to unlock workstation" to Enabled.


Doesn't that just mean the local account lockout policy needs to be changed?

Local Security Policy App

(I can't post comments now. OK, thanks, I'll read them. Shall I delete this one, o ye noob stompers?)

Seriously, upon reflection, I think this post was voted down as being too simple, and Sergey's was voted down for not being clear.

  • 1
    That's what my thought would be, if I'm understanding the question.
    – joeqwerty
    Sep 17, 2010 at 23:56
  • I'm confused: isn't the local account lockout policy irrelevant in a domain environment?
    – Skyhawk
    Sep 23, 2010 at 3:44
  • I don't know! It seems at this point the system falls back to the local policy. Have you tried it? Let's hope an expert drops by and clears this up.
    – Mark C
    Sep 23, 2010 at 22:22
  • As with other settings, if it's not defined or not configured at the site, domain, or OU level via GPO then the local setting takes precedence. So it is possible that the local settings are causing this issue. LSDOU
    – joeqwerty
    Sep 23, 2010 at 22:33
  • @Mark C: I don't know what's going on with your answer. I noticed it had been downvoted so I went to upvote it as I believe it's a good answer, but my upvote doesn't appear to be working. At any rate, with a problem like this you would want to look at the policy settings at the OU, Domain, Site, and Local level to see which one is taking preference, and in my opinion your answer is on track.
    – joeqwerty
    Sep 23, 2010 at 23:12

You must log in to answer this question.

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