How to Remove the PASSWD_NOTREQD Flag in Active Directory (Nessus 150489)

The PASSWD_NOTREQD finding (Nessus “AD Starter Scan – Blank passwords”, PingCastle S-PwdNotRequired) means Active Directory accounts carry userAccountControl flag 32, which lets them hold an empty password even when the domain password policy requires one. Fix it by giving each account a strong password, running Set-ADAccountControl -PasswordNotRequired $false, and disabling accounts nobody owns.

Below: what the flag is and where it comes from, how to list affected accounts, a remediation script that also reveals which accounts really have blank passwords, and how to prove the fix on rescan.

What the scanner is actually detecting

None of these tools can see whether a password is actually empty, because Active Directory offers no way to query that. They read the userAccountControl attribute and report every account where the PASSWD_NOTREQD bit (0x0020, decimal 32) is set. Microsoft’s UserAccountControl reference defines the bit as “no password is required”. Flags are additive, so you usually see it inside a larger number: userAccountControl 544 is a normal enabled account (512) plus 32, and 546 is the same account disabled.

Nessus runs this check from the Active Directory Starter Scan template, which needs Domain Admin credentials, LDAPS and a domain controller as the scan target. Tenable positions the plugin for preliminary analysis of smaller deployments (up to 5,000 users, groups or machines), so in a large domain treat the PowerShell inventory below as the authoritative list.

Why accounts end up with the flag

Microsoft field engineers trace most cases to provisioning. Identity management systems and scripts create the user through ADSI or LDAP without a password, which leaves userAccountControl at 0x222 (disabled, password not required, normal account), set the password in a second call, and never clear the flag. Active Directory Users and Computers completes all the steps and does not leave it behind. Two sources are by design: interdomain trust accounts carry PASSWD_NOTREQD by default (userAccountControl 2080), and pre-created computer objects carry 4128 until a machine joins and the value drops to 4096.

Real-world risk

The flag alone does not mean the account has an empty password. It means Active Directory will accept one. Anyone who holds the reset password right on that object (a helpdesk delegate, a provisioning service, or an attacker who has taken over either) can set an empty password and the minimum length rule will not stop it. An account created without a password simply stays that way.

If an enabled account really does have a blank password, anyone who knows or guesses the username can authenticate as it. Tenable maps the condition to MITRE ATT&CK T1078 (Valid Accounts) for initial access and privilege escalation, and on a privileged account that is a direct route to the domain.

Keep it in proportion. A Microsoft engineer who ran AD security assessments wrote that the flag is common but actual blank passwords on enabled accounts were rare in his experience. Prioritize enabled accounts, members of privileged groups (adminCount = 1) and service accounts. Do not ignore disabled ones: Active Directory only refuses an enabled, blank-password account when the flag is clear, so a disabled account that still has the flag can be re-enabled with its empty password intact. Account settings like this belong in the same review as the rest of your Windows Server hardening checklist.

How to confirm it

Run this from a machine with the ActiveDirectory PowerShell module (RSAT). It lists normal user accounts with the bit set and saves a before snapshot you will need for rollback:

Import-Module ActiveDirectory
$filter = '(&(sAMAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=32))'
Get-ADUser -LDAPFilter $filter -Properties userAccountControl, adminCount, LastLogonDate, PasswordLastSet, whenCreated |
    Select-Object SamAccountName, Enabled, userAccountControl, adminCount, LastLogonDate, PasswordLastSet, whenCreated, DistinguishedName |
    Export-Csv .passwd_notreqd_before.csv -NoTypeInformation
Import-Csv .passwd_notreqd_before.csv | Format-Table SamAccountName, Enabled, userAccountControl, adminCount, LastLogonDate

sAMAccountType=805306368 (SAM_NORMAL_USER_ACCOUNT) leaves out computer and trust accounts, and 1.2.840.113556.1.4.803 is the LDAP bitwise AND matching rule. For a quick count, Get-ADUser -Filter ‘PasswordNotRequired -eq $true’ reads the same flag. Check computer objects and trust accounts separately:

Get-ADComputer -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=32)' -Properties userAccountControl, LastLogonDate, whenCreated |
    Select-Object Name, Enabled, userAccountControl, LastLogonDate, whenCreated

Get-ADObject -LDAPFilter '(sAMAccountType=805306370)' -Properties sAMAccountName, userAccountControl |
    Select-Object sAMAccountName, userAccountControl

Trust accounts (sAMAccountType 805306370) should show 2080. That is Microsoft’s default, not something to change.

How to fix it

1. Triage the list

• Enabled users, privileged accounts and service accounts: fix now.
• Accounts nobody owns: disable them, clear the flag, and remove them later under your normal account lifecycle process.
• Pre-created computer objects (4128): if the machine is still being deployed, the domain join resolves it. If the object is stale, delete it. Do not reset computer account passwords at random.
• Trust accounts (2080): leave them alone.

2. Clear the flag and find the blank passwords

When you clear PASSWD_NOTREQD on an enabled account, the domain controller compares the current password hash with the hash of an empty password and refuses the change if they match, reporting that the password does not meet the domain’s requirements. That turns the fix into a blank-password detector. This loop is adapted from Microsoft’s field engineering guidance and uses Set-ADAccountControl:

$filter = '(&(sAMAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=32))'
foreach ($acct in Get-ADUser -LDAPFilter $filter) {
    try {
        Set-ADAccountControl -Identity $acct -PasswordNotRequired $false -ErrorAction Stop
        Write-Output "Cleared: $($acct.SamAccountName) (enabled: $($acct.Enabled))"
    }
    catch [Microsoft.ActiveDirectory.Management.ADPasswordComplexityException] {
        Write-Output "BLANK PASSWORD: $($acct.SamAccountName)"
    }
    catch {
        Write-Output "Failed: $($acct.SamAccountName): $($_.Exception.Message)"
    }
}

Try one account with -WhatIf first. Run large batches outside business hours, since every change replicates to all domain controllers.

Two caveats. The blank check only runs on enabled accounts: a disabled account with an empty password clears without error, and enabling it later fails until a compliant password is set. And clearing the flag does not test existing passwords against current policy, because Active Directory only knows whether a password is blank. Reset privileged accounts whose password predates your current policy.

3. Accounts that really have a blank password

Set a strong password first, then clear the flag:

Set-ADAccountPassword -Identity svc-legacy -Reset -NewPassword (Read-Host -AsSecureString "New password")
Set-ADAccountControl -Identity svc-legacy -PasswordNotRequired $false

Then update every system that signs in with that account. If nobody can name an owner, disable it instead:

Disable-ADAccount -Identity old-account
Set-ADAccountControl -Identity old-account -PasswordNotRequired $false

4. GUI alternative

In Active Directory Users and Computers, turn on View > Advanced Features, open the account, and on the Attribute Editor tab subtract 32 from userAccountControl (544 becomes 512). ADSI Edit works the same way, and the same blank password rule applies.

5. Fix the source

If new accounts keep arriving with the flag, the provisioning process is setting it. Microsoft’s guidance for identity management code is to send the password (unicodePwd) and userAccountControl 512 in the same create operation, or at minimum clear the flag once the password is set. To catch recurrences, enable Audit User Account Management on domain controllers: event 4738 shows ‘Password Not Required’ – Enabled in its User Account Control field when someone turns the flag on.

How to verify the fix and rescan

Re-run the inventory query against the domain controller your scanner targets (add -Server dc01.example.com) so replication lag does not mislead you. The user query should return nothing, and trust accounts should still show 2080.

Then rerun the Active Directory Starter Scan against the same domain controller with the same credentials and confirm plugin 150489 no longer lists the accounts. Check that the scan actually connected over LDAPS with domain credentials, because a scan that could not read the directory has nothing to report either. For PingCastle, run a new healthcheck and confirm S-PwdNotRequired is gone. Check again a few weeks later: new hits mean some process is still creating flagged accounts.

What can break and how to roll back

• Accounts with a real password: sign-ins are unaffected. Clearing the flag only prevents a future blank password.
• Accounts you moved off a blank password: services, scheduled tasks, application connection strings or devices configured with an empty password fail to authenticate until they get the new one.
• Disabled accounts with an empty password cannot be enabled until a compliant password is set. That is intended.
• Provisioning tools may put the flag back on the next create or sync.

To roll back one account, use the before snapshot and run Set-ADAccountControl -Identity <account> -PasswordNotRequired $true. That restores the flag, not an empty password. Do not set a blank password back; give the dependent system the new password, and record any restored flag as a time-limited exception.

Common false positive reasons

• Interdomain trust accounts. The flag is Microsoft’s default there, and PingCastle’s own solution limits the fix to accounts not used in trusts. Mark them as expected.
• Pre-created computer accounts that have not joined yet.
• “The password is not blank.” Not a false positive. The finding is about the flag, and clearing it will succeed.
• Stale results: the report predates the change, a different domain controller was scanned before replication, or a provisioning tool flagged the account again.

FAQ

Does PASSWD_NOTREQD mean the account has a blank password?

No. It means the account is allowed one. An enabled account whose flag cannot be cleared because of a password error is the confirmed case.

Is there a Group Policy setting that removes the flag?

No. The flag is stored on each account’s userAccountControl attribute, and bypassing the domain password policy is exactly what it does. Fix it per account and fix whatever creates the accounts.

Will clearing the flag lock anyone out?

Not accounts that already have a password. On an enabled account with an empty password the change is refused, so the only sign-in impact comes when you set a password on it.

Does clearing the flag force weak passwords to change?

No. Active Directory cannot check an existing password against policy, only whether it is blank. Reset accounts you do not trust.

Tracking this finding across domains and scans

PASSWD_NOTREQD lives in the directory rather than on individual hosts, and it tends to return whenever a provisioning process reintroduces it. SITEY, a self-hosted vulnerability management platform, imports Nessus results when you upload a .nessus export (it does not pull them automatically), so plugin 150489 can be tracked alongside your other findings. Per-finding retest works for Nessus findings, so it can confirm the finding has closed once the accounts are fixed.

Sources

• Tenable: AD Starter Scan – Blank passwords (plugin 150489)
• Microsoft Learn: UserAccountControl property flags
• Microsoft Learn archive: User provisioning and Password_Not_Required set, why?
• Microsoft Learn archive: Understanding and Remediating PASSWD_NOTREQD
• PingCastle: rule descriptions (S-PwdNotRequired)