Active Directory Password Security: Misconfigurations That Matter

What Is Active Directory Password Security?

Active Directory password security covers the policies, account flags, and legacy authentication settings that determine how credentials are created, stored, and reused across the domain. When those controls are weak, attackers do not need an exploit chain to get started. A weak password, a never-expiring admin account, or a password copied into an attribute can be enough.

These issues are often quiet in day-to-day operations. Accounts with PasswordNeverExpires or PasswordNotRequired can remain in production for months, passwords copied into description fields are easy to miss, and legacy settings such as WDigest or NTLMv1 make recovered credentials much easier to reuse.

This article focuses on six high-impact password-related misconfigurations in Active Directory and how to validate that the fixes actually removed the exposure.

How It Works

Active Directory enforces password controls through two main mechanisms:

• Default Domain Password Policy applied domain-wide through Group Policy
• Fine-Grained Password Policies (FGPP) applied to specific users or groups through Password Settings Objects

Fine-Grained Password Policies are implemented as Password Settings Objects (PSOs), and their precedence is set through the msDS-PasswordSettingsPrecedence attribute: a lower value means a higher-priority PSO. A PSO linked directly to a user always wins; when multiple PSOs apply through group membership, the one with the lowest precedence value becomes the resultant policy, and the Default Domain Password Policy only applies if no PSO matches at all. In practice, tier-0 and service accounts should sit under a PSO with a low precedence value and a materially stronger baseline than the domain default.

If neither is reviewed regularly, the result is predictable: weak or long-lived passwords, accounts exempted from normal controls, and legacy authentication settings that make credential abuse easier once an attacker gets a foothold.

The Attack Chain

Step 1 - Enumerate Weak Accounts

Any authenticated domain user can query AD for accounts with weak password settings:

# Accounts with passwords that never expire
Get-ADUser -Filter {PasswordNeverExpires -eq $true} -Properties PasswordNeverExpires, PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet | Sort-Object PasswordLastSet

# Accounts where no password is required
Get-ADUser -Filter {PasswordNotRequired -eq $true} -Properties PasswordNotRequired |
    Select-Object SamAccountName

# Accounts with password in the description field
Get-ADUser -Filter * -Properties Description |
    Where-Object {$_.Description -match "pass|pwd|mdp|mot de passe|contrasena"} |
    Select-Object SamAccountName, Description

Step 2 - Check Legacy Protocol Exposure

# Check if WDigest is enabled
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest -Name UseLogonCredential

# Check NTLM compatibility level
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LmCompatibilityLevel
# Values 0-2 allow NTLMv1; value 5 enforces NTLMv2 only

Step 3 - Harvest and Crack

With WDigest enabled, a local compromise that reaches LSASS can expose cleartext credentials directly:

# Mimikatz example when WDigest is enabled
sekurlsa::wdigest

For weak or long-lived passwords, attackers can also crack NTLM material offline after a hash dump:

hashcat -m 1000 ntlm_hashes.txt /usr/share/wordlists/rockyou.txt

Step 4 - Persist Through Weak Password Hygiene

Accounts with PasswordNeverExpires are durable persistence targets. If the account is sensitive and the password is never rotated, the attacker keeps a valid authentication path until an administrator explicitly resets it.

Detection

Windows Event IDs

Behavioral Signals

• Accounts with passwords older than your approved rotation window
• Enabled accounts with PasswordNeverExpires or PasswordNotRequired
• Description fields containing credential-like strings
• WDigest enabled on endpoints or servers where it is not explicitly required
• NTLMv1 still negotiated in environments that should be NTLMv2-only

SIEM Detection Query (Elastic KQL)

event.code: "4624" AND
winlog.event_data.LmPackageName: "NTLM V1"

Remediation

1. Enforce a Strong Domain Password Policy

Set-ADDefaultDomainPasswordPolicy -Identity corp.local `
    -MinPasswordLength 14 `
    -ComplexityEnabled $true `
    -MaxPasswordAge (New-TimeSpan -Days 90) `
    -MinPasswordAge (New-TimeSpan -Days 1) `
    -PasswordHistoryCount 24

2. Fix Non-Expiring Passwords

Get-ADUser -Filter {PasswordNeverExpires -eq $true -and Enabled -eq $true} |
    Set-ADUser -PasswordNeverExpires $false

3. Fix Accounts Without a Required Password

Get-ADUser -Filter {PasswordNotRequired -eq $true} | ForEach-Object {
    Set-ADAccountControl -Identity $_ -PasswordNotRequired $false
}

4. Remove Passwords From Description Fields

Get-ADUser -Filter * -Properties Description |
    Where-Object {$_.Description -match "pass|pwd|mdp"} | ForEach-Object {
        Set-ADUser -Identity $_ -Description ""
        Write-Host "Cleared description for: $($_.SamAccountName)"
    }

5. Disable WDigest

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" `
    -Name UseLogonCredential -Value 0

Deploy through GPO where possible: Computer Configuration > Administrative Templates > MS Security Guide > WDigest Authentication = Disabled

6. Enforce NTLMv2 Only

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
    -Name LmCompatibilityLevel -Value 5

Or through policy: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network security: LAN Manager authentication level = Send NTLMv2 response only. Refuse LM & NTLM

7. Deploy Microsoft Entra Password Protection (Hybrid Environments)

For domains synced to Microsoft Entra ID, on-premises Microsoft Entra Password Protection blocks weak passwords at the domain controller during password changes and resets — closing a gap the built-in complexity policy does not cover: dictionary words, keyboard patterns, and organization-specific terms that technically satisfy complexity rules but are trivially guessable.

The deployment has two components: a Password Protection Proxy service that pulls the global and custom banned-password lists from Microsoft Entra ID, and a DC Agent installed on every domain controller that enforces the cached policy locally against password change and reset events. The DC Agent keeps enforcing from its cached copy even if connectivity to the proxy is temporarily lost.

# Confirm the DC Agent is installed and logging enforcement events
Get-EventLog -LogName "Microsoft-AADPasswordProtection-DCAgent/Admin" -Newest 20

Start in audit mode to baseline how many existing passwords would be rejected before switching to enforced mode, and add organization-specific terms — brand names, product names, internal project codenames — to the custom banned list; the global list alone will not catch those.

How EtcSec Detects This

EtcSec audits password-related identity controls on every AD scan.

PASSWORD_NEVER_EXPIRES flags enabled accounts with non-expiring passwords and helps surface the highest-risk identities first.

PASSWORD_POLICY_WEAK evaluates the Default Domain Password Policy against the chosen baseline for length, complexity, history, and age.

PASSWORD_NOT_REQUIRED identifies accounts where the PASSWD_NOTREQD flag is still set.

PASSWORD_IN_DESCRIPTION scans directory descriptions for credential-like strings.

WDIGEST_ENABLED checks for WDigest cleartext credential caching.

NTLMV1_ALLOWED highlights environments that still allow NTLMv1 negotiation.

Accounts That Need Special Handling

Do not apply the same remediation blindly to every account class.

• Service accounts often break when you reset a password without updating the service, scheduled task, or application pool that depends on it.
• Tier-0 or break-glass accounts should not keep weak or shared credentials just because they are rarely used; they require stronger handling, stronger storage, and explicit monitoring.
• Shared admin identities should be removed rather than merely rotated. Rotation does not fix the accountability problem.
• Legacy applications that still depend on NTLMv1 or weak password handling need a time-boxed exception and a migration plan, not a permanent waiver.

What Good Evidence Looks Like

A password-hardening review is much easier to defend when the team keeps the exact evidence that proved the cleanup happened. Useful artifacts include the before-and-after export of accounts with PasswordNeverExpires, the list of accounts that previously had PasswordNotRequired, confirmation that WDigest is disabled on representative systems, and the owner or migration note for any service account that still needs a temporary exception. That evidence matters because password hygiene tends to drift back through urgent exceptions and application shortcuts.

Validation After Remediation

Close the finding only after rerunning the same discovery steps an attacker would use:

• rerun the PasswordNeverExpires and PasswordNotRequired reports and confirm the remaining exceptions are intentional
• verify that service-account exceptions are documented, owned, and tied to a migration plan such as gMSA adoption
• spot-check representative systems to confirm UseLogonCredential is 0 where WDigest should be disabled
• validate that LmCompatibilityLevel matches your NTLMv2-only rollout plan and that legacy systems were handled explicitly
• rerun the description-field search and confirm credentials were removed rather than simply hidden in another attribute

Related Controls

Password hygiene becomes much more dangerous when it combines with Kerberoasting: How Attackers Crack Service Account Passwords, Stale Privileged Accounts: Hidden Risk in Active Directory, Active Directory Monitoring: Security Event IDs That Matter, or NTLM Relay Attacks: Hijacking Authentication in AD. Review those controls in the same remediation window so you remove the attack path rather than one symptom.