Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

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.

share|improve this answer
    
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. –  Chris Thorpe Sep 23 '10 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. –  John Gardeniers Sep 24 '10 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 '10 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 '10 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 '11 at 22:51
up vote 5 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
1  
That's what my thought would be, if I'm understanding the question. –  joeqwerty Sep 17 '10 at 23:56
    
So Miles, is this an acceptable answer? –  Mark C Sep 22 '10 at 18:25
    
I'm confused: isn't the local account lockout policy irrelevant in a domain environment? –  Skyhawk Sep 23 '10 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 '10 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 '10 at 22:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.