I had an interesting issue with a customer recently.
After a recent promotion of a couple of Domain Controllers , it came to light some time later that users were able to set their passwords to 0 e.g. minimum password length = 0.
On investigation what was discovered was the following.
When the Domain controller was promoted a secedit script was run. This had been part of a server build process for sometime. It was normally run on completion of the normal member server build was run.
What was included in the secedit.db script was the following critical entries to our discussion;
MinimumPasswordAge = 0
MaximumPasswordAge = 42
MinimumPasswordLength = 0
PasswordComplexity = 0
PasswordHistorySize = 0
LockoutBadCount = 0
RequireLogonToChangePassword = 0
ForceLogoffWhenHourExpire = 0
Secedit configuration that was run
copy x:\abc\xxx\secedit.db c:\secedit.sdb /y
secedit /configure /db c:\secedit.sdb /cfg x:\abc\xxx\xxxabc.inf /overwrite /log x:\abc\xxx\error.log /quiet
attrib +h c:\secedit.sdb
This script was run using Domain Admins credentials
The result of running this command After the Domain Controller was promoted was the following Behaviour;
The Default Domain Account Security settings were overwritten by the “new” Secedit.sdb settings above. This overwrote the settings that are getting applied via the Account Security section in the Default Domain Policy.
Note this is expected behaviour because of the way Domain Controller reads its Security settings.
Information below taken from a Gary Olsen blog of 2005.
“Domain controllers provide security settings to domain users at logon time. This is a critical (and confusing) concept. The user’s machine doesn’t pull the security settings from the GPO at startup as it does for other machine settings. The client gets the security settings when the user is validated. The security settings that domain controllers apply to clients upon a successful user logon are those that are stored in the DC’s local secedit.sdb security database. The DC gets the Account Security settings from the domain policy and applies them to its local .sdb. Note that this applies only to the account security settings, not to any other policy setting. DCs then replicate their local .sdb with each other.”
Note: If you modify block the Default Domain Policy applying to the Domain Controllers it is likely to exhibit this behaviour. Especially if the blocking or modification of the secedit.sdb is leaving the Domain Controller with insecure settings.
Therefore DO NOT run any modification to the secedit.sdb on a Domain Controller. Also do not block the application of the Default Domain Policy to the Domain Controllers OU. Please see previous blog links for further information.
It can potentially have serious implications.
Other useful links