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
--------------------------------------------------------------
-------------
--------------------------------------------------------------
-------------
---------------------------------------------------------------------------
---------------------------------------------------------------------------
