Skip to main content

Update: Local Admin Account lockout is now available


Iams3le
Forum|alt.badge.img+11

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

 

13 comments

Chris.Childerhose
Forum|alt.badge.img+21
  • Veeam Legend, Veeam Vanguard
  • 8395 comments
  • October 17, 2022

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


dips
Forum|alt.badge.img+7
  • Veeam Legend
  • 808 comments
  • October 17, 2022

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


BertrandFR
Forum|alt.badge.img+8
  • Influencer
  • 527 comments
  • October 17, 2022

Iams3le
Forum|alt.badge.img+11
  • Author
  • Veeam Legend
  • 1374 comments
  • October 18, 2022
dips wrote:

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!


Iams3le
Forum|alt.badge.img+11
  • Author
  • Veeam Legend
  • 1374 comments
  • November 17, 2022

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


MicoolPaul
Forum|alt.badge.img+23
  • 2358 comments
  • November 17, 2022
Iams3le wrote:

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!!!


Scott
Forum|alt.badge.img+8
  • Veeam Legend
  • 993 comments
  • November 17, 2022

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. 

 

 


Link State
Forum|alt.badge.img+11
  • Veeam Legend
  • 602 comments
  • November 17, 2022

@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. 


dips
Forum|alt.badge.img+7
  • Veeam Legend
  • 808 comments
  • November 18, 2022
Link State wrote:

@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. 


Iams3le
Forum|alt.badge.img+11
  • Author
  • Veeam Legend
  • 1374 comments
  • November 18, 2022
MicoolPaul wrote:
Iams3le wrote:

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!


dips
Forum|alt.badge.img+7
  • Veeam Legend
  • 808 comments
  • November 18, 2022
Iams3le wrote:
MicoolPaul wrote:
Iams3le wrote:

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. 


Iams3le
Forum|alt.badge.img+11
  • Author
  • Veeam Legend
  • 1374 comments
  • November 18, 2022
dips wrote:
Iams3le wrote:
MicoolPaul wrote:
Iams3le wrote:

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. 

 


Iams3le
Forum|alt.badge.img+11
  • Author
  • Veeam Legend
  • 1374 comments
  • November 18, 2022
Iams3le wrote:
dips wrote:
Iams3le wrote:
MicoolPaul wrote:
Iams3le wrote:

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!