-----Original Message-----
From: Laura A. Robinson [mailto:laurarobinson@earthlink.net]
Sent: Wednesday, August 31, 2005 3:20 PM
To: Derick Anderson; focus-ms@securityfocus.com
Subject: RE: Group Policy: multiple password policies in the
same domain?
Inline replies to a couple of different people.
You can only set password policies affecting domain
accounts using the
"default domain policy" GPO - ie. the GPO at the top of
the AD tree
for a particular domain.
Actually, that's not the case. You can only affect domain
accounts at the domain level, but you do NOT have to use the
"Default Domain Policy" GPO.
You can create your own and it works. If you have multiple
domain-level policies that specify password settings, the
last applied policy at the domain level will "win". My other
post answering the original question got bounced, but I
clarified some of this in it.
On my DC, running GPMC, if I do a GPO model with conflicting policies,
the report shows that the policies aren't set at all. Are they actually
set? Doing a RSoP gives me the red X over all conflicting policies. I
wasn't able to hunt down the actual meaning of the red X in the couple
minutes I could spare to investigate, but I figure it's not good. I am
just wondering if the policy is actually set but the reporting/RSoP
features see it as a bad thing and that explains their output.
Does anyone know why the password policy is a computer and not a
user-based setting?
Why would it be a computer setting? That would make no sense
for all of the users in the domain who are people rather than
computers. Again, you can only have a single password policy
that affects accounts stored in AD for a given domain.
Because both users and computers are stored in AD, the
password policy applies to *any* account stored in AD.
Laura
The password settings are in the computer section, not the user section.
I couldn't fathom that idea, so I set up security filtering on the
"Service Accounts" GPO to apply only to "Service Accounts" (a user
group). Group Policy modeling reported back that the GPO was denied
access due to security filtering.
Here's my theory: It's easier to have the password policy computer-based
instead of user-based. When a user authenticates/resets their
password/is created, Windows checks the local computer password policies
against the supplied password. Because it's a computer setting, there is
only one thing to check: the local computer's policy (which is set by
the domain policy on a domain). Since a domain user is like a local user
on a domain controller (sort of), the domain controller policy is the
only one that matters for that user in respect to passwords.
Now let's imagine this was a user setting: I can now apply password
policies to an individual user, group, whatever. I log on to a domain
computer and the domain controller now has to figure out what group I'm
in, what group policy applies to me, and therefore what my password
requirements are. It must do this every time I attempt to authenticate
(ignoring caching, etc.). And what if I'm a member of more than one
group with differing password policies? Which group wins?
I bet Microsoft thought about all that and said "nevermind."
Derick Anderson
---------------------------------------------------------------------------
---------------------------------------------------------------------------
