RE: Group Policy: multiple password policies in the same domain?

From: Brady McClenon (BMcClenon_at_uamail.albany.edu)
Date: 09/01/05

  • Next message: Derick Anderson: "RE: Group Policy: multiple password policies in the same domain?" 
    Date: Thu, 1 Sep 2005 10:52:52 -0400
To: "Derick Anderson" <danderson@vikus.com>, <focus-ms@securityfocus.com>

    Why would you ever want different password policies for different
    accounts? I don't see the point of only having a portion of your
    accounts with strong passwords. If you are going to be serious about
    password security, be serious about it. What account is it not
    necessary to have a strong password if the others are? I'm just
    curious...

    -----Original Message-----
    From: Derick Anderson [mailto:danderson@vikus.com]
    Sent: Wednesday, August 31, 2005 3:44 PM
    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

    ------------------------------------------------------------------------ 

    ---
------------------------------------------------------------------------
---
---------------------------------------------------------------------------
---------------------------------------------------------------------------
  • Next message: Derick Anderson: "RE: Group Policy: multiple password policies in the same domain?"

    Relevant Pages