Freigeben über


Understanding and Remediating "PASSWD_NOTREQD"

In my previous post on querying the userAccountControl attribute, I noted one of the flags I want to ensure you understood was the PASSWD_NOTREQD or "Password Not Required" flag. As the name suggests, this flag allows you to have a fully functioning account with a blank password (even with a valid domain password policy in place).

In my time performing AD security assessments, I would estimate I've seen nearly 300,000 accounts with this flag set. Out of those accounts, I have only ever seen 5 unprivileged active accounts that had blank passwords set. So yes I want you to remediate the affected accounts, but even if a quick audit shows a large number of them present in your domains, it's probably not as bad as you think.

How does it happen?

This issue most commonly arises due to identity management systems that create accounts with the flag set, set a password but fail the last step of removing the flag. Our in-built tools such AD Users and Computers perform all the appropriate steps to remove the flag.

To actually have an enabled account with a blank password, the following things need to occur:

  1. You need to have PASSWD_NOTREQD enabled on your userAccountControl attribute and
  2. Have a password not set at creation time OR have privileged user exercise the "Reset-Password" security right and simply press enter on the password change prompt to grant the account a blank password.

So I have "X" amount of accounts in my report, can you tell me how many have blank passwords?

Not directly, there is no interface to query if an account has a blank password BUT if we try to remove the flag on an enabled account and the password is blank, we will get an error because the DC definitely knows it won't meet the password length/complexity requirements of your domain (its blank duh!)

The following flow chart shows you the behavior that will occur when we try to remove the PNR flag from an account. The outcome depends on the current status of the account and if the current password is blank or not.

Remove PNR Flow

Cleanup Aisle 3

The following script can be used to help identify (again) and then attempt to remove the PASSWD_NOTREQD flag on all affected accounts. It will visually report the findings using Out-Grid then confirm if you want to proceed. Along with visual feedback, it will also export the affected accounts and reset status to a .CSV for further investigation.

 # Report on Affected Accounts
$StatusLog = @()
Get-ADUser -Filter 'useraccountcontrol -band 32' -Properties "passwordnotrequired","useraccountcontrol","msDS-LastSuccessfulInteractiveLogonTime","lastLogonTimestamp" | Select-Object -Property DistinguishedName,Enabled,PasswordNotRequired,"msDS-LastSuccessfulInteractiveLogonTime","lastLogonTimestamp" | Out-GridView -Wait
# Attempt to remediate and log output
$Response = Read-Host "`nDo you want to attempt to remove PASSWD_NOTREQD from the listed accounts?"
If($Response.ToLower() -eq "y"){
 ForEach ($Account in (Get-ADUser -Filter 'useraccountcontrol -band 32')){
 $Status = "" | Select Status,Account 
 $Status.Account = $Account 
 Get-ADUser $Account | Set-ADUser -PasswordNotRequired $False -ErrorAction SilentlyContinue
 If($?){
 Write-Host "Succesfully removed PASSWD_NOTREQD from $Account" -ForeGroundColor Green
 $Status.Status = "Success"
 }
 Else{
 Write-Host "Failed to remove PASSWD_NOTREQD from $Account" -ForeGroundColor Red
 $Status.Status = "Failure"
 }
 $StatusLog += $Status
 }
}
Write-Host $StatusLog.Count "accounts processed. Refer to FIX_PASSWD_NOTREQD.csv for full details"
$StatusLog | Export-CSV -NoTypeInformation FIX_PASSWD_NOTREQD.csv

Remediate-PNR Output

Final Words

So hopefully every identified account successfully has the PASSWD_NOTREQD flag removed and you feel a little easier knowing all of your user accounts have a password of some kind. If an account has failed (and you have permissions to modify it), there is a good chance it is both enabled and has a blank password. Press CTRL+ALT+DEL on domain member and try to login with a blank password.

Wait a few weeks after your initial clean-up and then check again. If any more accounts pop-up, you obviously have another system or operational process to remediate as well as some accounts to clean up.

Note:  If any of the disabled accounts had a blank password, and your try to enable them in the future, you will receive an error saying the don't meet the password policy requirements. Simply set a password that meets requirements and then you will be able to enable it as expected.

If you find any blank passwords in your domains, let me know in the comments below.

Russ

Comments

  • Anonymous
    May 26, 2016
    nice
  • Anonymous
    May 28, 2016
    good explanation
  • Anonymous
    November 07, 2016
    Mucha thankie.
  • Anonymous
    December 07, 2016
    Thanks. I found this useful article when searching why few users in Active Directory have PASSWD_NOTREQD flag.I assume, that some communication problem with IDM system is the reason. All users in AD are created by IDM (inhouse IDM using openICF connector) and all users with flag were created in same time.LDAP filter for flag is: (userAccountControl:1.2.840.113556.1.4.803:=32)Btw. every computer account created in AD before the computer joins to the domain has also this flag. It is because you don't set any password when creating computer objects.
  • Anonymous
    January 31, 2017
    I'm wondering if this could get set on accounts automatically if you make a change to your domain password policy. Like, if you increase the minimum length, does PASSWD_NOTREQD get set to True on the accounts that didn't meet the minimum length?
    • Anonymous
      January 31, 2017
      Well, I'm comfortable with that being a dumb question. It looks like it was indeed our user creation script not unsetting the PASSWD_NOTREQD flag after setting the password.
  • Anonymous
    June 28, 2017
    What do you do about computer object that are pre-created in AD and these get stamped "PASSWD_NOTREQD", does this mean once an asset is joined to the domain and binds to the pre-crate computer object it does not establish a password and will not establish one (default every 30 days)? It sure seems to be the case...
    • Anonymous
      July 02, 2017
      I will have another post soon on the topic of computer accounts, but they always have a password there, never blank. Yes, when joined the machine resets the password and then maintains it.
  • Anonymous
    August 30, 2017
    What if some accounts have passwords which are not blank, but also do not meet the password policy (e.g. service accounts which were created prior to password policy implementation). Will these successfully get the flag removed?
    • Anonymous
      October 25, 2017
      Yes. AD has no knowledge of what the current clear text password is and if it meets the previous or new password policy requirements. Only if it is blank or not.