none
Where is the GPO for "service account" lockout policy? RRS feed

  • Question

  • Hi,

    I have a strange issue where the GPO for account lockout policy says "lockout after 10 failed logons".

    However if I provide wrong credentials in a net use sequence then the account is locked immediately for 30 minutes.

    so something like 

    net use \\server17\share20 /user:heredomain\johndoe1

    then it prompts me for the password

    when I have a typo the account is locked immediately for 30 minutes with an auto-unlock 

    Where can I find this policy?

    Hint: it is not the "user account lockout policy" which is set to lock out the account after 10 unsuccessful logon attempts.

    Edit: it's not bound to the AD level, I had this on 2008R2 level, 2012 r2 level and 2016 level, and regardless of the OS of the client where I issued the net use with the wrong password


    IT architect - Terminal servers, virtualizations, SQL servers, file servers, WAN networks and closely related to software devleopment (8 years + experience in VB, C++ and script langugaes), MCP for SQL server and CCAA for Xenapp 6.5


    • Edited by Al Hasoob Wednesday, October 2, 2019 10:20 AM
    Wednesday, October 2, 2019 10:19 AM

Answers

  • after long research and many questions I found out two facts:

    1.) long time ago there was a bug in Windows, where a failed service account login did NOT follow the rules in the lockout policy and locked the account immediately although the lockout count was set to 10 and not to 1

    2.) it was a multi sessoion environment, the counter for unsuccessful logins was 10 in the scenario but distrubuted over 20 Terminal servers, and each of them showed only one or 0 login failures in the security part of the event log

    3.) the root cause was an attempt to use an interactive session and impersonate another AD account however the account credentials was attempted to be use  via NTLM, where the GPO was set to "refuse NTLM". Unfortunately there were two different components in the application, the one component was NTLMv2 aware, the other (used infrequently) wasn't.

    IMO this is a bug, because failed negotiations shell not be interpreted as unsuccessful login attempts becuase technically seen the security protocol negotiation failed and not the login. Probably I will file a bug with MS  :-)


    IT architect - Terminal servers, virtualizations, SQL servers, file servers, WAN networks and closely related to software devleopment (8 years + experience in VB, C++ and script langugaes), MCP for SQL server and CCAA for Xenapp 6.5



    Wednesday, October 9, 2019 10:21 AM

All replies

  • Hello,

    The Account Lockout Policy GPO can be found over here:

    Computer Configuration > Windows Settings > Security Settings > Account Policies > Account Lockout Policy

    For more information, see:
    https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/account-lockout-threshold

    Best regards,
    Leon


    Blog: https://thesystemcenterblog.com LinkedIn:

    Wednesday, October 2, 2019 10:22 AM
  • Hello Leon,

    I mentioned that the regular lockout policy is effectively ignored in my case and a different GPO setting seems to override this in case the failed login originates from a script or a service.

    The lockout policy you mention is only for interactive logons.


    IT architect - Terminal servers, virtualizations, SQL servers, file servers, WAN networks and closely related to software devleopment (8 years + experience in VB, C++ and script langugaes), MCP for SQL server and CCAA for Xenapp 6.5

    Wednesday, October 2, 2019 1:40 PM
  • Start by looking what policies are applied to the servers with GPResult /H ”C:\Temp\GPOReport.html”


    Blog: https://thesystemcenterblog.com LinkedIn:

    Wednesday, October 2, 2019 1:48 PM
  • Hi,

    Thanks for posting here!

    I would recommend you view the result of  gpresult /h c:\gpreport.html, and check which GPO  is winning for the account policy.

    Also , if there are any other gpo applied to the account ?

    If possible , please share a screenshot or link of the result .(Tip: If private information is involved in the screenshot, it is recommended to blur sensitive information.)

    Best Regards,

    Fan


    Please remember to mark the replies as an answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Thursday, October 3, 2019 6:07 AM
  • Hi,

     

    Just want to confirm the current situations.

     

    Please feel free to let us know if you need further assistance.

     

    Best Regards,

    Fan


    Please remember to mark the replies as an answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, October 7, 2019 1:46 AM
  • after long research and many questions I found out two facts:

    1.) long time ago there was a bug in Windows, where a failed service account login did NOT follow the rules in the lockout policy and locked the account immediately although the lockout count was set to 10 and not to 1

    2.) it was a multi sessoion environment, the counter for unsuccessful logins was 10 in the scenario but distrubuted over 20 Terminal servers, and each of them showed only one or 0 login failures in the security part of the event log

    3.) the root cause was an attempt to use an interactive session and impersonate another AD account however the account credentials was attempted to be use  via NTLM, where the GPO was set to "refuse NTLM". Unfortunately there were two different components in the application, the one component was NTLMv2 aware, the other (used infrequently) wasn't.

    IMO this is a bug, because failed negotiations shell not be interpreted as unsuccessful login attempts becuase technically seen the security protocol negotiation failed and not the login. Probably I will file a bug with MS  :-)


    IT architect - Terminal servers, virtualizations, SQL servers, file servers, WAN networks and closely related to software devleopment (8 years + experience in VB, C++ and script langugaes), MCP for SQL server and CCAA for Xenapp 6.5



    Wednesday, October 9, 2019 10:21 AM
  • Hi, AL

    Thanks for your posting here and sharing the current situation!

    If there is anything else we can do for you, please feel free to post in the forum.

    Best Regards,

    Fan


    Please remember to mark the replies as an answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Thursday, October 10, 2019 1:34 AM
  • no thanks... just learned to ask some more questions in case I have such a problem again.


    IT architect - Terminal servers, virtualizations, SQL servers, file servers, WAN networks and closely related to software devleopment (8 years + experience in VB, C++ and script langugaes), MCP for SQL server and CCAA for Xenapp 6.5

    Friday, October 18, 2019 9:45 AM