Good point Laura, I'd suspected that you might be able to use a different GPO
at the same level but having never tested it I didn't want to committ it to
writing! At least I know now :)
Derick if you've filtered the security of the GPO's to just the service
accounts then under what user account are you running RSoP? it will run under
the context you are logged in as unless you are running it in planning mode to
apply it to the account in question. Even then I am not sure that it will work
properly if you've denied the user account you running it under access to the
GPO.
Taking Laura's point into account, whilst the password policy is applied at the
computer level, it still requires that the user accounts it affects be able to
read it and have "apply group policy" permissions. Presumably then, if you were
to set up an additional GPO at the top of the AD tree and deny all user
accounts but the service accounts "apply group policy" permissions then the
policy would only be applied to the service accounts. Similarly you would need
to ensure that the rest of the user accounts in the domain have "apply group
policy" permissions denied on the GPO for the service accounts, or that it is
lower in the list.
As to why the password policy is computer based or user based - I think it
makes no difference in the context of your question - you can only apply a
password policy at the top of the AD tree and not in a GPO or object beneath
it, so if it was user based it would make no difference to what you are trying
to achieve.
My thoughts as to why its computer based - well perhaps its related to the fact
that it is "the computer" that authenticates the login? The account policies on
a local machine are found in the local security policy msc. on a computer -
which has no user related settings. A Group Policy combines these settings with
various other related policies, it would make little sense then for password
policy to be found under the user node of a GPO since user objects have nothing
to do with authenticating logins.
Richard
-----Original Message-----
From: Derick Anderson [mailto:danderson@vikus.com]
Sent: 31 August 2005 20:44
To: focus-ms@securityfocus.com
Subject: RE: Group Policy: multiple password policies in the same
domain?
-----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
---------------------------------------------------------------------------
---------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------
Disclaimer: This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed.
If you have received this email in error please notify the
originator of the message. This footer also confirms that this
email message has been scanned for the presence of computer
viruses and Henshaws Society for Blind People will not accept
any responsibility for any loss of data or financial loss caused
directly or indirectly by opening or processing this email and any
accompanying attachments.
Any views expressed in this message are those of the individual
sender, except where the sender specifies and with authority,
states them to be the views of Henshaws Society for Blind People.
Please Note: Recipients of this message should be aware that
Henshaws Society for Blind People reserves the right to monitor
all email sent to and from the hsbp.co.uk domain or any other
domain that may be administered by the said organisation.
Head office telephone number: 0161 872 1234
Head office fax number: 0161 848 9889
website: http://www.hsbp.co.uk
---------------------------------------------------------------------------
---------------------------------------------------------------------------
