Home / server / Questions / 48144
Accepted
Adam Brand
Asked: 2009-07-31 08:15:25 +0800 CST

Lock Workstation Glitch? (AD/Windows XP)

  • 772

I was playing with a lab setup recently (Windows 2003 R2 x32 SP2, Windows XP SP3, Active Directory) and noticed that if I locked the workstation, the following strange behaviour appeared:

  1. I have a lockout policy that says that an account is locked after three invalid attempts. When trying this when unlocking the workstation, the workstation correctly says the account is locked after three invalid attempts, but it lets me continue trying passwords. If I eventually type in the correct password, it unlocks the workstation.

  2. If I change the user's password while the workstation is locked, both the old and new password will unlock the workstation.

  3. If I disable the user's account while the workstation is locked, they can still log in and continue to access resources.

Is this behaviour correct or just a bug in my setup? Any pointers on how to mitigate this problem?

The attack vector to exploit #1 would be if the hacker has a set list of maybe 200 or so possible passwords based on combinations of the user's birthday, kids names, whatever. They then try each of these passwords, in turn, to see if they are right (maybe using a USB keyboard wedge to automate it).

Because they are not locked out after three attempts, they can keep trying until they get the password. Once they have the password, they just wait for the user to get their account unlocked by the admin, then they can login as the user.

The issue with #2 and #3 would be if, say, someone just got fired and you wanted to prevent them from taking files with them, and disabled their account/changed their password, they could still access the files if their workstation was locked (or I assume if they were already logged into their computer).

windows-server-2003 security password-management accounts

3 Answers

  1. Best Answer

    I don't believe this is a bug.

    The difference is that the account lock out policy applies to new sessions with new auth and login under default circumstances.

    In the case of a locked workstation, there's already an active, logged-in session on the box.

    This can apparently be changed by the "ForceUnlockLogon" registry setting. Toggling this requires a workstation unlocking to get re-auth from the DC and thereby avoids the use of old, cached credentials.

    In the case of a locked LOCAL account in the workstation, you can add the following registry value into HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\policies:

    DisablePasswordCaching DWORD 00000001

    Quick googling turned up this paper by MS over at sysoptools: http://www.sysoptools.com/support/files/Account%20Passwords%20and%20Policies%20In-Depth.doc

    It has details relating to logons, account lockout policy, and discussions of settings that can come into play.

    Additional Note re: #3 (also covered in the linked paper): a locked-out user may still gain access if their still-valid kerberos ticket has not expired.

    • 3

  2. 2 things I figure: "unlock workstation" isn't actually a logon, and cached credentials are playing their part here. But I agree, it's strange and it's something I'm thinking I need to check out too.

    • 0

  3. The lockout may have a time limit? This is a group policy setting also and may be set, so what you think is that your password eventually works, but in fact the account just automatically unlocks and then you enter the correct password?

    Regarding number 3, I believe there is a way to list current active domain logins, though I'd have to research that. Then when you terminate someone, you can boot them off the system, disable their account, and you'd be safe.

    • 0