Interesting Issue with Major Implications

Hi ,

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;

[Unicode]
Unicode=yes
[System Access]
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.

https://blogs.technet.com/janelewis/archive/2007/04/24/just-don-t-do-it.aspx 

Other useful links

https://technet.microsoft.com/ja-jp/library/cc730910(WS.10).aspx

https://support.microsoft.com/kb/313222

https://support.microsoft.com/kb/278316