Anomaly in applying password policies to DCs

You have done excellent work ruling out nearly all typical failure points (SYSVOL, FGPP, PSOs, and SceCli).

Consider running the following on one of the affected DCs (and reboot it afterwards) -

secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /verbose

gpupdate /force

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Hello Dmitry,

What you are seeing is indeed an inconsistency between domain-level password policy enforcement and the local SAM/NetAPI state on the two cloud-based DCs. The fact that MaxPasswordAgeRaw is showing -1 (TIMEQ_FOREVER) on YA-DC01/02 while the Default Domain Policy is correctly set to 180 days strongly suggests that those DCs are not correctly interpreting or applying the domain password policy, even though replication and policy application logs look fine.

The critical point here is that domain password policies are not applied through local security policy objects on DCs. Instead, they are enforced by the domain controllers themselves via the Default Domain Policy. When you see “Maximum password age: Unlimited” in net accounts on a DC, that reflects the local SAM policy, not the effective domain password policy. Normally, on DCs, the local SAM values are irrelevant because domain accounts are governed by domain policy. The anomaly is that your cloud DCs are exposing the SAM values as if they were authoritative, which leads to the discrepancy in msDS-UserPasswordExpiryTimeComputed.

This behavior has been observed in certain builds of Windows Server 2022 where the local SAM policy on DCs can incorrectly override or misreport domain password policy values. Microsoft has not yet published a KB specific to this, but the recommended approach is to ensure that the Default Domain Policy is the only policy defining password settings, and to avoid configuring password policies in Local Security Policy on DCs. In practice, you should confirm that no local GPOs or baseline hardening templates were applied on YA-DC01/02 that might have set Maximum password age = 0. Even if you see “successful application” in SceCli, the local policy object may still be persisting a conflicting setting.

The immediate remediation is to reset the local security policy on those DCs so that they inherit only domain-level settings. Run secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /verbose on YA-DC01 and YA-DC02 to restore the default local security policy baseline. After that, force a GPUpdate and reboot. Then recheck net accounts and msDS-UserPasswordExpiryTimeComputed. The values should align with the domain policy (180 days).

If the anomaly persists even after resetting local policy, you are likely hitting a product bug in Server 2022’s handling of SAM policy on DCs. In that case, the only reliable path forward is to open a support case with Microsoft CSS, as they can provide hotfixes or confirm whether this is a known issue in your build.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

HP.

Thanks, guys. I'll definitely report back once I've done it!

But while we're in the process of changing the password lifetime to 90 days, I wouldn't skip it right now to avoid another policy enforcement conflict and impact on end users.