Backing out Complex passwords enabled in Domain Group policy.

[Guest]

Hi

I'm currently testing the use of enabling complex passwords. It all works fine, however I've been requested to test backing it out

Here's my problem

Although I have changed the Domain Group policy for complex passwords back to the original setting (not defined). Every time I try to add a new user or have an existing user change their password, the system insists on using complex passwords instead of basic passwords. RSoP indicates that complex passwords have been turned off

Is there anything else I need to do on the Domain Controller

Cheers

Tony Gec.

 

[Steven L Umbach]

Change complexity to disabled in the domain policy. Ten run secedit /refreshpolicy
machine_policy /enforce. Wait a couple of minutes and try again. --- Steve

Hi,

I'm currently testing the use of enabling complex passwords. It all works fine,

however I've been requested to test backing it out.

Here's my problem.

Although I have changed the Domain Group policy for complex passwords back to the

original setting (not defined). Every time I try to add a new user or have an
existing user change their password, the system insists on using complex passwords
instead of basic passwords. RSoP indicates that complex passwords have been turned
off.

 

[Herb Martin]

Change complexity to disabled in the domain policy. Ten run secedit /refreshpolicy
machine_policy /enforce. Wait a couple of minutes and try again. --- Steve

I agree with you Steven but I have another thought about what
MIGHT have been done, correct me if you disagree, this is only
a supposition....

IF he changed the Domain Controller Policy (and forgot that) or
added another policy besides default (this is obviously true but I
am trying to be complete) then he might be trying to "fix" it in only
one of several places it is set.

 

[Steven L Umbach]

Hi Herb.

You bring up some excellent points. I gave the quick usual answer of first
thing to try. Of course if there is more than one GPO for the domain, then
any settings at the GPO highest in the list will take precedence and if
there is more than one they should dusable complexity on the top domain GPO
also which may not be obvious if someone is just trying Domain Security
Policy in administative tools.

Supposedly [and I might be wrong] it should not matter if it is configured
in Domain Controller Security Policy and my experience shows that, though it
would not hurt to disable it there also. However if a change is made to the
domain level and "block inheritance" is configured on the domain controller
container then password policy changes will not be implemented.

I also found that often the "effective" settings shown in Local Security
Policy even after a reboot can be incorrect and one way to tell what the
real effective settings are to run Security Configuration and Analysis
ool. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;269236

 

[Herb Martin]

Supposedly [and I might be wrong] it should not matter if it is configured

in Domain Controller Security Policy and my experience shows that, though it
would not hurt to disable it there also.

This was the cautionary part of my addition -- I am slightly wary that
complexity is actually controlled by the DCs and therefer any setting
to them (no matter where in the chain of GPOs) might cause this.

I believe the same to be true for things like "Account Logon" (but not
plain "Logon" <grin>) auditing.

The only settings that are strictly domain specific (AFAIK) are the
"security Account" settings: Password (length/expire/etc but not
complexity), Lockout, and Kerberos.

Anyone should feel free to correct me from real experience or definitive
documentation and be assured that my belief is somewhat speculative.

However if a change is made to the
domain level and "block inheritance" is configured on the domain controller
container then password policy changes will not be implemented.

Does this include "security account" Password policies or do they get
processed before the "block" is calculated?

These are some gray areas of the standard documentation of GPO
inheritance and override.

 

[Steven L Umbach]

Hi Herb.

Most documentation I have seen states that all account policies can only be defined
at the domain level and that has been my experience. Try this sometime [I have on W2K
SP3]. Define settings for all account polices at the domain level, except leave a
couple undefined. Then define conflicting settings at the domain controller level and
a few security options just to see that the policy indeed has changed. Do a reboot
and check the Local Security policy on the domain controller for effective settings.
I found that all of the account policies [including kerberos, lockout, and
complexity] that were defined or even undefined at the domain level showed as the
effective settings in Local Security policy indicating that none of them were
overridden by the defined settings in the Domain Controller Security Policy. I then
actually tried out some of the settings such as lock an account out, change a
password, etc to see if they reflected what I saw in the effective Local Security
Policy on the domain controller [same as domain policy] and everything worked as
shown [though I did not test kerberos]. My test may not be a thorough analysis of all
scenarios but it does indicate to me that any settings for any account policies in
the Domain Controller Security policy are ignored and overridden by Domain Security
Policy.

If you are going to the Summit, maybe you can discuss this further with some of the
MS team there and let us know what they say. Unfortunately, I don't think I will be
able to make it. --- Steve

Supposedly [and I might be wrong] it should not matter if it is configured
in Domain Controller Security Policy and my experience shows that, though it
would not hurt to disable it there also.

This was the cautionary part of my addition -- I am slightly wary that
complexity is actually controlled by the DCs and therefer any setting
to them (no matter where in the chain of GPOs) might cause this.

I believe the same to be true for things like "Account Logon" (but not
plain "Logon" <grin>) auditing.

The only settings that are strictly domain specific (AFAIK) are the
"security Account" settings: Password (length/expire/etc but not
complexity), Lockout, and Kerberos.

Anyone should feel free to correct me from real experience or definitive
documentation and be assured that my belief is somewhat speculative.

However if a change is made to the
domain level and "block inheritance" is configured on the domain controller
container then password policy changes will not be implemented.

Does this include "security account" Password policies or do they get
processed before the "block" is calculated?

These are some gray areas of the standard documentation of GPO
inheritance and override.


--
Herb Martin

Hi Herb.



I also found that often the "effective" settings shown in Local Security
Policy even after a reboot can be incorrect and one way to tell what the
real effective settings are to run Security Configuration and Analysis
ool. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;269236

 

[Herb Martin]

Hi Herb.

Most documentation I have seen states that all account policies can only be defined
at the domain level and that has been my experience.

I agree. I somehow convinced myself that Complexity was in a different
area.

According to rule, this should only work when linked at the domain level.