I mistyped my password three times today, and my account became locked on my windows 8.1 pro workstation. I checked Resultant Set of Policies (rsop.msc) and all three relevant settings are "Not Defined"

  • Account lockout duration
  • Account lockout threshold
  • Reset account lockout counter after

"Account lockout threshold" defaults to "0" and "If you set the value to 0, the account will never be locked out."



I ran gpresult /h [filename] and no lockout policy is defined at all (confirming all my other comments)

  • 1
    Is the machine domain-joined? May 20 '15 at 18:56
  • Yes, the machine is domain-joined.
    – Novox
    May 20 '15 at 19:00
  • 1
    Just because the local policy has a default value and are "Not Defined", a GPO configured and linked in the domain may still override that policy setting May 20 '15 at 19:03
  • Is the account stored on the local computer (accessible through Computer Management on your workstation) or in Active Directory?
    – IceMage
    May 20 '15 at 19:09
  • active directory
    – Novox
    May 20 '15 at 19:19

RSOP support has been deprecated. According to http://deployhappiness.com/gpresult-or-rsop/

"Beginning with Windows Vista SP1, Microsoft made the GPResult command the primary tool for troubleshooting Group Policy on a client."

Basically, to ensure that you are getting the full result of policies on the machine, you need to use GPResult instead of RSOP.

However, your account is located on the Domain Controller, and therefore, the policy of the Domain applies to lockouts. No amount of tweaking, configuring, or policy editing will change that on your local workstation. Any time you enter your password, the Domain must authenticate it, and it will count towards your attempts. Other things can count against your attempts as well, such as cached credentials, or being logged in to other computers with stale credentials.

This part is no longer relevant.

Furthermore, the location of the account is incredibly important! If the account is actually an Active Directory Domain account, your local machine policies will NOT affect your account lockout, you will have to check the group policy settings of the domain controller (e.g. run GPResult on the DC). Accounts stored on the domain don't authenticate against your computer, and the lockout is triggered on the domain controller, not your local workstation. Accounts stored locally will follow the GPResult, but only after you've rebooted the computer since the WinLogon service will have to re-initialize with the new GPO settings. (Not all GPO settings can be applied without a reboot).

  • gpresult did indicate more GPO's that were impacting me, however, I manually edited each one (also reviewed a summary of each one in the "Settings" tab from Group Policy Management) and all of them are also not defined.
    – Novox
    May 20 '15 at 19:12

For Group Policy "Not Defined" is NOT the same thing as "NOT SET", FALSE or any other meaning.

Not Defined means the group policy at the level you are analyzing makes no change to the Windows default.

You may also need to looks at - is there a lower security scope (local on a non-domain member) that IS defined.

  • What is the Windows Default action when this is not defined. I suspect it is to lockout but i'm not finding a concrete link I can refer you to.

Or you may want to jump straight to the answer: - If for some reason you want to bypass this helpful security setting, set the Account lockout threshold to a higher number of errors and allow the protection to remain enabled .....

  • Good catch on "Not Defined" I completely missed that. It also means other policies (such as network policies) can still be applied.
    – IceMage
    May 20 '15 at 18:57
  • yes, but... if it's "not defined" then the default is what's used, right? I mean... there's no other way for the "default" to be used...
    – Novox
    May 20 '15 at 19:03
  • 1
    Also, I tried setting it to 4 invalid attempts, and it still locked me out at 3 (after gpupdate /force).
    – Novox
    May 20 '15 at 19:03
  • 1
    @Novox -- if indeed you set the policy to 4, or 10, or more attempts nd it still locked out at 3 attempts, then the policy you are changing is NOT is scope and is having no effect - be careful - this same bag of rights exists at multiple levels (machine, domain, forest at least). May 20 '15 at 20:26
  • 1
    @IceMage - its been some time since "...the most specific policy always winning." Ever since Microsoft added the "precedence" value to the GPO and PSC objects the admin can construct some bizarre precedence trees that defy assumptions. Use the proper tool for your O/S version to compute the RSOP, regardless of its name this week to see the forest wide settigns for login security, and you will most likely find a setting has been added somewhere you "never thought to look" Jun 12 '15 at 19:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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