Title: Few quick ones on password polices
This would put the domain into an entirely inconsistent
state.
I have helped companies get out of similar predicaments
that they got into accidently like this that was due to poor FRS replication.
Basically what happens is that the changes get applied locally, replicate out
through the domain partition, get stomped on by some other DC somewhere else
which replicates back out. If you different policies on several DCs you would be
entirely in flux and could never guarantee where you would be in terms of
settings as it would depend on which DC you last replicated in changes from and
whether or not the local policy had recently reapplied.
I have
seen this for password policies, lockout policies, and restricted groups (this
is a hoot if the group is admins or domain admins because you have to time your
logon at a point when you have rights). Basically anything that replicates in
the directory as well as through FRS.
This
is fairly easy to catch by looking at version numbers on the domain nc
attributes, when you see something that is the hundreds, you may have an issue.
Alternatively have a script that watches for changes and you will keep seeing
the domain NC popping up as changing.
joe
Actually, this isn't entirely true. A little testing on
Win2K3 shows the following:
If I have domain account policy defined, say, on the
Default Domain Policy, and I set block inheritance on the Domain Controllers OU,
then any changes to the domain account policy on that domain-linked GPO will be
ignored by DCs located in the DC OU. You can see this by looking at the
effective account policy on a given DC by firing up the local GPO editor
(gpedit.msc). If you look at account policy on the local GPO of a DC, it shows
the current effective policy as delivered by any domain linked GPOs. If you try
to change it from the local GPO, you'll noticed its grayed out--and can't be
changed. Interestingly, if you set Block Inheritance on the DC OU, not only are
changes to domain account policy from that domain-linked GPO ignored, but you
can now change the local account policy on a given DC from the local GPO editor.
Obviously that isn't too desirable since this would imply to me that you could
have a different account policy on each DC. Yuck. Its unclear to me whether AD
has any kind of mechanism to prevent this, but I am currently doubting it until
I test some more. So bottom line is don't put Block Inheritance on the DC OU or,
better yet, always set the GPO where you define domain account policy to
Enforced.
Darren
1. Correct
2. Yes and no. Account policies as applied onto domain
users can't be blocked. However you can block those policies from being applied
to the local policies of member machines.
I don't think you need to set "user can not change
password", if the person doesn't want their password changed, setting that only
prevents them from doing it.
joe
Hey all!
Can you do me a quick favour and just confirm that
I'm not going mad by agreeing (or not, if I'm wrong) with these:
1) you can only apply
password policies (account policies to be exact, but this is a bone of
contention here at the moment) at the domain level. i.e.: if the domain
is abc.com you have to apply it at that level, not below.
2) account policies
cannot be blocked by using the "block inheritance" option? Not too sure on this
one, so could do with it clearing up. As a fail safe I'm going to make sure I've
got "password never expires" and "user can not change password" options selected
for those people who I don't want their password changing just yet.
Any answers greatly received and advice always
welcome.
Cheers, folks.
For Troup Bywaters + Anders
Tim Sutton
T: +44 (0) 113 243 2241
F: +44 (0) 113 242 4024
E:
[EMAIL PROTECTED]
W:
www.TBandA.com
Eastgate House
10
Eastgate
Leeds
LS2 7JL
Office Location
Map
Groupshield 6.0 - Troup Bywaters & Anders
Privilege and Confidentiality
Notice
This email and any attachments to it are intended only for the party
to whom they are addressed. They may contain privileged and / or confidential
information. If you have received this transmission in error please notify the
sender immediately and delete any digital copies and destroy any paper copies.
Thank you.
