RE: security policy 'not specified' option

From: Laura A. Robinson (larobins_at_bellatlantic.net)
Date: 10/27/05

  • Next message: Derick Anderson: "RE: security policy 'not specified' option" 
    Date: Thu, 27 Oct 2005 00:41:28 -0400
To: "'Derick Anderson'" <danderson@vikus.com>, "'matthew patton'" <pattonme@yahoo.com>, <focus-ms@securityfocus.com>

    Resultant Set of Policy does not in any way change the processing of Group
    Policy.

    Here is how group policy processing works:

    1. Machine starts up.

    2. A series of .dlls fire up (either 5 or 7 of them, IIRC) to begin
    processing different parts of group policy.

    3. Machine determines its own computer object's location in Active Directory
    and also determines its site membership.

    4. Machine parses local policy and applies any settings contained in the
    computer configuration portion of the policy.

    5. Machine parses each policy linked to the site of which it is a member and
    parses computer configuration settings in those policies. Policy parse order
    in the case of multiple policies linked to the site is determined by the
    order determined by the administrator who linked the policies to the site.
    (IOW, the policies are processed from bottom to top in the "link list".) Any
    policies marked "computer configuration settings disabled" or marked
    disabled altogether are ignored.

    6. Machine parses each policy linked to the domain of which it is a member
    and parses computer configuration settings in those policies. Policy parse
    order when multiple policies are linked to the same domain is based on the
    order determined by the administrator who linked the policies to the site.
    Any policies marked "computer configuration settings disabled" or marked
    disabled altogether are ignored.

    7. Machine follows the OU "path" to the OU in which the computer account is
    located, parsing any policies linked to any OUs in the path. At each OU
    level, if multiple policies are linked to the same OU, policies are parsed
    in the administratively-defined order, but OUs are processed in parent-child
    order down to the computer's OU.

    As these policies are being processed, any settings that are defined
    (whether as "enabled" or as "disabled" versus "not configured") are "carried
    down" unless a later-processed policy in the chain contains a setting that
    conflicts with the previous setting. For example, if a policy at the domain
    level implements a setting that configures the machine's DNS suffix to be
    "foo.bar" and then a policy linked to one of the OUs in the path leading to
    the computer object sets the machine's DNS suffix to "fu.bar", the
    later-processed setting would override the earlier-processed setting.

    8. After the machine has processed all of the policies leading to its
    computer object location in Active Directory, it then "re-crawls" the tree,
    this time looking for settings that are marked "no override" and for OUs
    marked with "block inheritance" for policies. As a "no override" setting is
    encountered, it is "re-implemented", meaning that it is processed again and
    therefore becomes the last-applied policy so that its settings "win" over
    those that had been applied farther down the tree.

    If, at any point, a "block inheritance" OU is processed, then all of the
    settings that were applied from higher in the tree, with the exception of
    those marked "no override", are removed.

    The machine then presents the logon dialog box to the user (and I won't get
    into synchronous versus asynchronous processing of policy because it will
    further complicate what I'm trying to illustrate, but let's just take it as
    fact [because it's actually the default behavior in XP] that it is possible
    that group policy may still be processing at the time the user is presented
    with the logon dialog box or with the desktop, but hopefully the GP
    environment isn't so convoluted that this ends up happening).

    When the user logs on, group policy processing continues as follows:

    9. User logs on.

    10. The aforementioned .dlls fire up to process group policy for the user.

    11. The computer determines the user object's location in Active Directory
    and assumes that the user is in the same site, because, simply put, the user
    is always in the same site as the computer as far as group policy is
    concerned.

    12. Machine parses local policy and applies any settings contained in the
    *user* configuration portion of the policy.

    13. Machine parses each policy linked to the site of which it and the user
    are members and parses user configuration settings in those policies. Policy
    parse order is based on the order determined by the administrator who linked
    the policies to the site. Any policies marked "user configuration settings
    disabled" or marked disabled altogether is ignored.

    14. Machine parses each policy linked to the domain of which the *user* is a
    member and parses user configuration settings in those policies. Policy
    parse order is determined by the policy order defined by the administrator
    who linked the policies to the domain.

    15. Machine follows the OU path to the OU in which the *user* account is
    located, parsing any policies linked to any OUs in the path. At each OU
    level, policies are parsed in the administratively-defined order, but OUs
    are processed in parent-child order down to the OU containing the user
    object.

    16. Machine re-crawls the tree and reprocesses any "no override" settings
    and "unimplements" any settings due to inheritance blocking as mentioned
    above. No override settings are never reversed by a "block inheritance"
    setting.

    17. Desktop is presented to user (although, again, this may actually happen
    while policy is still processing because Microsoft changed the behavior in
    XP due to customer complaints about the amount of time it took to process
    group policy and present the user's desktop, so by processing
    asynchronously, the desktop is presented faster even though the desktop may
    still be in a state of flux because of GP processing.

    Just to throw something else into the pot, this is what happens when
    loopback processing is enabled for a computer (which is typically set at the
    OU containing the computer)

    If loopback processing is enabled and set to "merge":

    Steps 1-17 are performed as above.

    18. Computer *again* locates its own computer object's location in Active
    Directory and it repeats steps 1-8, but this time, instead of processing the
    computer configuration portions of the policies, the *user* configuration
    portions are processed instead. This allows an administrator to configure
    user-specific portions of the registry based on the location of the computer
    object in AD rather than just the user object location. Any settings that
    had been defined for the user in steps 9-17 would still be applied, but if
    in the policies processed over again (as in steps 1-8), there are user
    configuration portions of the policies that conflict with the user
    configuration portions that had been defined based on the location of the
    user object in AD, the computer-object-location policies would "win".

    If loopback processing is enabled and set to "replace":

    Steps 1-8 are performed as above.

    Steps 9-17 are skipped.

    Step 18 is performed. The user configuration portions of the policies
    leading to the user object's location in AD are never processed except in
    the case that those policies are "in the path" leading to the computer
    object location.

    I know this all sounds really convoluted, and trust me, it's a lot easier if
    it's drawn on a whiteboard, but this is essentially how group policies are
    processed. There are nuances I didn't touch on such as permissions to read
    and apply group policy, but this has already gone on long enough. :-)

    Last- RSoP (which is represented in a somewhat cleaner way as "Group Policy
    Results" and "Group Policy Planning" in GPMC) has NOTHING to do with how
    group policy is processed. All RSoP does is simulate the processing of group
    policy and show you what the end results either *are* based on what happened
    when user x in location y logged onto computer a in location b (resultant
    mode in RSoP or "Group Policy Results" in GPMC) or what they *would be* if
    you put user x in location y and they logged onto computer a in location b
    (planning mode in RSoP or "Group Policy Planning" in GPMC). RSoP does not
    change how group policy is actually processed regardless of whether you use
    it in planning mode or reporting mode. RSoP/GPMC planning/results are merely
    tools to allow an administrator to build scenarios (planning) or to
    troubleshoot where specific settings came from "results".

    Laura

    P.S. I was asleep until just before I wrote this, so please forgive any
    typos or lack of clarity. :-)

    > -----Original Message-----
    > From: Derick Anderson [mailto:danderson@vikus.com]
    > Sent: Friday, October 21, 2005 7:58 AM
    > To: matthew patton; focus-ms@securityfocus.com
    > Subject: RE: security policy 'not specified' option
    >
    >
    >
    > > -----Original Message-----
    > > From: matthew patton [mailto:pattonme@yahoo.com]
    > > Sent: Thursday, October 20, 2005 4:57 PM
    > > To: focus-ms@securityfocus.com
    > > Subject: security policy 'not specified' option
    > >
    > > Some time back I used a security policy editor that had 3 options:
    > > enabled, disabled, and 'unset'. By not setting it either way, the
    > > machine inherited the domain settings. Unfortunately the standard
    > > system policy editors shipped with 2K/2K3/XP don't appear
    > to have that
    > > 3rd option which means now I've got all kinds of machine
    > running with
    > > who knows what setting and ignoring the domain policy. And
    > once you've
    > > selected en/disabled via the radio box, there isn't a way
    > to unset it.
    > > How do I dig myself out of this?
    > >
    > > I probably can play Registry Magic and accomplish what I need but I
    > > could have sworn I had a tool that would let me do what I
    > used to be
    > > able to do.
    > >
    > > any ideas?
    > >
    >
    > I use Microsoft's Group Policy Management Console (GPMC) so I
    > can't verify my recollection on the standard Windows 2003
    > Group Policy editor, but as I recall, there are usually three
    > options: "enabled", "disabled", and "not defined". When you
    > choose "not defined", the local security policy looks up the
    > Group Policy chain by default (you can change it) in the
    > following order:
    >
    > 1. Enforced Policies from top-level down 2. Local OU GPOs 3.
    > Parent OU GPOs from the bottom-level up 4. Microsoft defaults
    >
    > By default, the Resultant Set of Policy (RSoP) for the domain
    > is applied to the local computer. I don't know if you can
    > turn this off (and why?) but by default it works. I would
    > advise getting the GPMC as it makes the whole Group Policy
    > process easier to understand and implement.
    >
    > http://www.microsoft.com/downloads/details.aspx?FamilyID=0a6d4
    > c24-8cbd-4
    > b35-9272-dd3cbfc81887&DisplayLang=en
    >
    > If you think that the machines aren't getting the group
    > policy (and they are Windows XP/2003-based) you can run
    > gpupdate /force to apply the domain group policy and then
    > check the event log to see if there were any errors. Also you
    > should run netdiag and dcdiag on your domain controllers to
    > make sure things are working happily.
    >
    > As a test, set the Computer Configuration -> Windows Settings
    > -> Security Settings -> Local Policies/Security Options -> Interactive
    > Logon: "Message text for users attempting to log on" to
    > something and then see if your domain computers start
    > displaying the message.
    >
    > Derick Anderson
    >
    > --------------------------------------------------------------
    > -------------
    > --------------------------------------------------------------
    > -------------
    >

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

  • Next message: Derick Anderson: "RE: security policy 'not specified' option"

    Relevant Pages

    • Re: Parts of GPO not working.
      ... If your users use other browsers like firefox from an usb stick/drive or whatever medium your policy will not help. ... I have a request that all of those computers not have Internet ... The settings in this GPO can only apply to the following groups, ... Group Policy refresh interval for computers Enabled ...
      (microsoft.public.windows.server.active_directory)
    • Re: Assigning File and Folder Permissions Via Group Policy
      ... A few policies with a lot of settings in each policy may not be the best ... permissions changes into one group policy that gets pushed out to everyone, ...
      (microsoft.public.windows.group_policy)
    • Parts of GPO not working.
      ... I have a request that all of those computers not have Internet ... The settings in this GPO can only apply to the following groups, ... Group Policy refresh interval for computers Enabled ...
      (microsoft.public.windows.server.active_directory)
    • Re: Registry tatooing
      ... I'm working on a utility that will clean up GP policies and preferences. ... Speed Group Policy Troubleshooting with the NEW GPHealth Reporter tool at http://www.sdmsoftware.com/products.php ... Administrative policies work very similar to NT4 System Policies. ... Well, to his disliking, the settings remained. ...
      (microsoft.public.windows.server.active_directory)
    • Re: Local GPO refreshes outside of refresh interval
      ... I looked through my GPO's Windows Settings section ... > Some policies, including IE policies, have a checkbox that defines if this ... > it should apply EVEN if the value defined in GPO did not change since the ... we are talking about one particular policy: ...
      (microsoft.public.windows.group_policy)