IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
Hello, my name is Jason Krause and this is my first time writing a blog post for AskPFEPlat. I am a Platforms PFE here at Microsoft and work primarily in Active Directory and Group Policy. Recently a customer approached me with a question I thought I knew the answer to, “Can the administrator account be locked out”? In their environment, a security scanning tool was attempting to log into the RID 500 Administrator account with invalid credentials. This activity was generating lock out events that were being collected by their security information and event management (SIEM).
In Active Directory, an account lockout occurs when the amount of failed logon attempts exceeds the allowed limit set in Group Policy. Each time a bad password is presented to the domain controller, the “badPwdCount” attribute is incremented on that account. Account lockout policy is defined once per domain, traditionally in the Default Domain Policy.
Note: The current recommended security baseline for Account Lockout Threshold should be set to a minimum of 10 invalid login attempts. These settings may not be right for your organization. Please refer to Aaron Margosis’ post on configuring account lockout. NIST currently recommends limiting invalid login attempts to 100.
Account lockout threshold: How many bad password attempts are allowed before the account is locked out on the domain controller? This setting is also referred to as the “LockoutThreshold”
Account lockout duration: How long should the account remain locked out after exceeding the threshold?
Reset account lockout counter after: After the first bad password is attempted, how long should the domain controller record subsequent attempts? This setting is also referred to as the “ObservationWindow”
When a normal domain user attempts to log in with an account that has been locked out, Kerberos returns a KDC_ERR_CLIENT_REVOKED. This is true even if the correct password is typed.
KRB_AS_ERROR, KDC_ERR_CLIENT_REVOKED: Clients credentials have been revoked, Cname: testuser, Realm: contoso, Sname: krbtgt/contoso
When the Administrator (RID 500) account is locked and another bad password is attempted, Kerberos returns a KDC_ERR_PREAUTH_FAILED.
KRB_AS_ERROR, KDC_ERR_PREAUTH_FAILED: Pre-authentication information was invalid, Cname: administrator, Realm: contoso, Sname: krbtgt/contoso
The two differences for the Administrator account are
- The authentication package ignores the Lockout attribute and returns a failed login
- The Lockout attribute is reset upon successful login.
This behavior can be changed by modifying the domain PasswordProperties attribute, but I would caution against this change.
|The password cannot be changed without logging on. Otherwise, if your password has expired, you can change your password and then log on.|
|Forces the client to use a protocol that does not allow the domain controller to get the plaintext password.|
|Allows the built-in administrator account to be locked out from network logons.|
|The directory service is storing a plaintext password for all users instead of a hash function of the password.|
|Removes the requirement that the machine account password be automatically changed every week.
This value should not be used as it can weaken security.
To answer the original question, you can lock out the administrator account, but by default it does not stay locked out.
As long as we still have your attention, take the time to review our recommended practices on securing built-in administrator accounts in Active Directory. Implementing these changes goes a long way towards securing your environment.
Thanks for reading, and I hope you find this helpful!