Windows2000 Domain Security Policy problem, changes revert back after 1 hour!?!
From: Wouter (email@example.com)
From: firstname.lastname@example.org (Wouter) Date: 3 Mar 2003 05:25:55 -0800
I have quite a frustrating problem with the Default Domain Security
Policy in my Active Directory domain.
First of all, let's explain the situation.
As I said, I have a Windows 2000 domain divided into 4 AD Sites. Each
site has 1 DC, except for my 'main'site, this site contains 2 DC's. 1
Of these DC's holds all FSMO roles for my domain.
Somehow, my default domain security policy got changed a few weeks ago
and since then, this policy contains some password settings and
account lockout settings and I'd like to get rid of them. For example,
this policy currently requires a minimum password length of 8
character, password complexity is enabled and account lockout
restrictions are set. To get rid of there policies, I configured in
the Domain security policy MMC that my minimum password length is 0
chars and password complexity + account lockout settings are disabled.
Seems to work fine but within 1 hour, all of the settings I made here
are being reverted to the original settings, 8 chars minimum,
complexity enabled and so on! Whatever I try, I'm not able to change
this policy so my settings get applied. Whatever I change in this
policy, it doesn't seem to work
I have 4 GPO's in my domain: users, notebookusers, default
domaincontroller security policy and the default domain security
policy. All of them are fine, can change settings without any problems
except for the default domain security policy! When I try to change a
password in AD, I get a popup that my password doesn't meet the
password policy or complexity requirements.
After that, I tried the GPOTool.exe from the resource kit to check my
domain policies. It found all my DC's and policies, no errors where
I also tried to manually edit the gpttmpl.inf file and incremented the
gpt.ini version number but I get the same results. After approximately
one hour, all my changes are somehow being reverted to the previous
settings! After this, I tried something else. I edited the GptTmpl.inf
file, changed password
settings manually and after that, I raised the GPO versionnumber in
the GPT.ini file to 65905 (100 higher, the previous value was 65805).
After that, I manually copied the GptTmpl.inf to all my other DC's and
also copied GPT.ini manually to the right location of all DC's. So, on
all DC's, the versionnumber in GPT.ini was 65905 and the right
GptTmpl.ini existed on all DC's. Waited for a while and checked again.
I was almost stunned to see that my settings were reverted to the
previous settings! Still no solution... and the most strange part was
that the versionnumber in
GPT.ini wasn't the number I added plus 1 but the previous number plus
1! As I said, I had entered 65905 as number but the new number after
the policy was reverted was 65806!
Replication (and my FRS...) seem to work fine, all content from the
SYSVOL share gets replicated without any problem or delay. I even
disconnected my main DC (with all FSMO roles) from the rest of the
network but still no improvements. Don't have any replication warnings
or errors in my eventlog.
When I run the command 'net accounts', I get the following settings,
which show that these password settings are still active, which I
constantly try to disable:
C:\Documents and Settings\administrator>net accounts
Force user logoff how long after time expires?: 0
Minimum password age (days): 2
Maximum password age (days): 42
Minimum password length: 8
Length of password history maintained: 24
Lockout threshold: 5
Lockout duration (minutes): 30
Lockout observation window (minutes): 30
Computer role: PRIMARY
The command completed successfully.
No other policy except my default domain security policy containts
settings like minimum password length, passwordcomplexity and lockout
settings. Somehow, my DC still grabs these settings from another
location than GptTmpl.inf and GPT.ini! How the hell is this possible?
Who knows a solution?
Thanks in advance! Struggling with this problem for ages right now...
Wouter, The Netherlands