Skip to main content

Account lockout help keep user accounts secure by preventing unauthorised users etc., from guessing the username and password. When your account is locked, you will have to wait for a specified amount of time before being able to log into your account again. Here is the link to the original blogpost.

 

In the past, it was recommended to disable the local Administrator account due to several known vulnerabilities such as the built-in administrator account cannot be locked out no matter how many failed logins it accrues, making it a prime target for brute-force attacks that attempt to guess passwords. This is no longer true as beginning October 11, 2022, or later Windows cumulative updates, a local policy will be available to enable local administrator account lockouts. 

 

Brute force attacks are one of the prevalent ways Windows devices are attacked today. Previously, Windows devices did not allow local administrators to be locked out. This leads to scenarios where, without the proper network segmentation or the presence of an intrusion detection service, the local administrator account can be subjected to unlimited brute force attacks to attempt to determine the password. This can be done using RDP over the network. If the passwords are not long or complex, the time it would take to perform such an attack is becoming trivial with modern CPUs/GPUs.

In an effort to prevent further brute force attacks/attempts, Microsoft is implementing account lockouts for Administrator accounts beginning with the October 11, 2022, or later Windows cumulative updates, a local policy will be available to enable local administrator account lockouts. This policy can be found under.

Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policies. 

 

For existing machines, setting this value to Enabled on existing machines using a local or domain GPO will enable the ability to lock out Administrator accounts. Such environments should also consider setting the other three policies under Account Lockout Policies; our baseline recommendation is to set them to 10/10/10. This means an account would be locked out after 10 failed attempts within 10 minutes and the lockout would last for 10 minutes, after which the account would be unlocked automatically. Kindly refer to this interesting guide: What is Pass the Hash Attack and how to mitigate the attack.

 

For new devices running Windows 11, v22H2, or any new device that will include the October 11, 2022, Windows cumulative updates before the initial setup, these settings will be set by default at system setup. This occurs when the SAM database is first instantiated on a new machine. So, if a new machine was set up and then had the October updates installed later, it will not be secure by default and will require the policy settings above. If you do not want these policies to apply to your new computer, you can set the local policy above or create a group policy to apply the Disabled setting for “Allow Administrator account lockout.”

 

Now, password complexity is now enforced on new devices having the local administrator account enabled. The password must have at least three of the four basic character types (lower case, upper case, numbers, and symbols). This will help further protect these accounts from being compromised because of a brute force attack. However, if you want to use a less complex password, you can still set the appropriate password policies in 

Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy

 

Yeah, saw this in a newsletter for Windows Insiders. Nice little policy for sure.


Think best practice these days is to disable the local admin account on domain joined workstations. If you do have to use local admin passwords, using something like LAPS: Windows LAPS overview | Microsoft Learn


Best practices but good reminder, it’s in MSCT baseline.

Download Microsoft Security Compliance Toolkit 1.0 from Official Microsoft Download Center


Think best practice these days is to disable the local admin account on domain joined workstations. If you do have to use local admin passwords, using something like LAPS: Windows LAPS overview | Microsoft Learn

+1 (I agree with you). But do you know in the past some admins simply renamed the administrators account without knowing it has a unique sid. With the sid, brute-force attack was still possible. Microsoft has actually disabled the built-in default administrators account from Win10,Win11, and WS2016 and will create a new local account that is a member of the Administrator group. Take a look at this today -:) With the the implementation of local admin lock out, these concerns are dealt with!


More information: The new lockout behavior only affects network logons, such as RDP attempts. Console logons will still be allowed during the lockout period.


More information: The new lockout behavior only affects network logons, such as RDP attempts. Console logons will still be allowed during the lockout period.

Thanks for the update! So, as always, protect console access!!!


Using this with LAPS is ideal, but LAPS has situations where it can’t be implemented. 

 

For many of us using Veeam off domain this is very handy. Already have it enabled.  

 

With the power of GPU’s these days anything to prevent brute force is necessary. 

 

 


@Iams3le Thanks for sharing, in fact I remember how from best practice it was necessary to implement a gpo to avoid password caching (anti mimikatz). Always a good practice to implement. 


@Iams3le Thanks for sharing, in fact I remember how from best practice it was necessary to implement a gpo to avoid password caching (anti mimikatz). Always a good practice to implement. 

Yep, that is correct. It’s one more step towards hardening devices. 


More information: The new lockout behavior only affects network logons, such as RDP attempts. Console logons will still be allowed during the lockout period.

Thanks for the update! So, as always, protect console access!!!

This is where Windows Hello for Business comes in. By the way, there is a new WHFB Hybrid Cloud Kerberos Trust Model now available. This takes away the complexity of key trust and certificate trust deployment models .You know Microsoft committed to its vision of a world without passwords!


More information: The new lockout behavior only affects network logons, such as RDP attempts. Console logons will still be allowed during the lockout period.

Thanks for the update! So, as always, protect console access!!!

This is where Windows Hello for Business comes in. By the way, there is a new WHFB Hybrid Cloud Kerberos Trust Model is now available. This takes away the complexity of key trust and certificate trust deployment models .You know Microsoft committed to its vision of a world without passwords!

I just wish they would simplify the management of it. 


More information: The new lockout behavior only affects network logons, such as RDP attempts. Console logons will still be allowed during the lockout period.

Thanks for the update! So, as always, protect console access!!!

This is where Windows Hello for Business comes in. By the way, there is a new WHFB Hybrid Cloud Kerberos Trust Model now available. This takes away the complexity of key trust and certificate trust deployment models .You know Microsoft committed to its vision of a world without passwords!

I just wish they would simplify the management of it. 

 


More information: The new lockout behavior only affects network logons, such as RDP attempts. Console logons will still be allowed during the lockout period.

Thanks for the update! So, as always, protect console access!!!

This is where Windows Hello for Business comes in. By the way, there is a new WHFB Hybrid Cloud Kerberos Trust Model now available. This takes away the complexity of key trust and certificate trust deployment models .You know Microsoft committed to its vision of a world without passwords!

I just wish they would simplify the management of it. 

 

Certainly, there will be new developments/improvements in this area! 


Comment