Lock AD account without disabling the account

Anyone know how to change the “LockedOut” attribute to True without disabling the account? I know I can loop through multiple bad passwords, hit the attempt threshold and lock it, but is there a way to replace the LockedOut attribute with ‘True’ using POSH?.

I do not believe there is a way to replace that value. The Set-ADUser does not have parameter or attribute to flip that value.

pwshliquori

AFAIK, its a big NO.

As a workaround you can enter a wrong password until the account is locked (this can be done programmatically).

Just wondering what could be a use case for this…

I agree - I checked the functionality of that cmdlet as well as Set-ADObject. At the moment, I do not see a way to set that single attribute value using that approach.

As a workaround you can enter a wrong password until the account is locked (this can be done programmatically).

  • Good point, yes I found a nice little function to rapidly try many bad passwords to force the lock. I don't mind doing that on my own test account, however if the account is for someone (a real person/account) in a test enviroment, I don't want to kick that off in a large ENT environment as the SOC will discover that activity quickly and alert even though the action would be for a legitimate test.
Just wondering what could be a use case for this...
  • Say you have many connected systems where AD is only part of the connected systems and your IAM system talks to AD and a user had there account locked out due to too many unsucessful attempts....well the IAM system would be authoritative in this case with regard to actioning the unlock for that account. If this were the case, you would want to lock a test account and then attempt to unlock that account with your IAM system.

What is the use case behind the question?

E.g. why not just change the password to something no one knows instead of hammering the lockout functionality?
Or disable interactive logon for the account etc. etc.

Fredrik’s advise seems the best here, entering the wrong password until the account locks might trigger your Security Team to “assume” there’s a hacker attack (or other fantasies Sec Teams have).