GPO Processing Order and OUs

[Yuppie]

I have been having some problems getting some GPOs to process when
linked to specific OUs. Here's a basic rundown of our domain setup:

OURORGANIZATION.COM
-Default Domain Policy
-Site Workstations OU
-site login policy
-Group Policy Objects
-Default Domain Policy
-site login policy

Basically, policys linked to OUs are not processed unless they are
also linked to the Domain as well. Is this correct? I was under the
impression that GPOs are processed in a top down order under the
Domain, including OUs with linked GPOs.

Please explain. Thank you.

 

[Florian Frommherz [MVP]]

Yuppie!

Basically, policys linked to OUs are not processed unless they are
also linked to the Domain as well. Is this correct? I was under the
impression that GPOs are processed in a top down order under the
Domain, including OUs with linked GPOs.

The behavior you describe, that policies need to be linked to BOTH the
domain AND the OU is weird. Where are the workstation computer objects?
Are they in the workstation OU you link the policy to? Only linking the
policy to the workstation OU (NOT the domain) - what's the output of
rsop.msc and gpresult.exe? Is the policy listed?

cheers,

Florian

 

[Yuppie]

The behavior you describe, that policies need to be linked to BOTH the

domain AND the OU is weird. Where are the workstation computer objects?

The GPO applies to a Security Group specified in the Security
Filterign section of the OU (the user is a member of the security
group so should have the setting applied). The GPO has only one
setting enabled, a User Configuration setting to run a logon VB
script.

Is the policy listed?

The policy is not listed when I run gpresult.exe

A better rundown of the setup is:

OURORGANIZATION.COM
-Default Domain Policy (computer and user settings)
--Shared Drive Mappings
---Map L Script (user settings)
---Map P Script (user settings)

 

[Florian Frommherz [MVP]]

The GPO applies to a Security Group specified in the Security
Filterign section of the OU (the user is a member of the security
group so should have the setting applied). The GPO has only one
setting enabled, a User Configuration setting to run a logon VB
script.


The policy is not listed when I run gpresult.exe

A better rundown of the setup is:

OURORGANIZATION.COM
-Default Domain Policy (computer and user settings)
--Shared Drive Mappings
---Map L Script (user settings)
---Map P Script (user settings)

Did you put the user accounts into the OU you linked the policy to? Once
you did so, the policy will apply. It's not only permissions you need
for group policy application - you need the target objects as child
objects of the OU.

cheers,

Florian

 

[Yuppie]

Did you put the user accounts into the OU you linked the policy to? Once
you did so, the policy will apply. It's not only permissions you need
for group policy application - you need the target objects as child
objects of the OU.

Do the actual user accounts need to be in the OU? Can a security
group with user accounts as members be added to the OU and the Policy
will apply to all members of the security group?

 

[Florian Frommherz [MVP]]

Yuppie,

Do the actual user accounts need to be in the OU? Can a security
group with user accounts as members be added to the OU and the Policy
will apply to all members of the security group?

The actual user accounts need to be in the OU - security groups will not
work.

cheers,

Florian

 

[Yuppie]

The actual user accounts need to be in the OU - security groups will not
work.

This is incorrect.

As shown here, GPOs can be applied to groups with the use of Security
Filtering.
http://www.windowsnetworking.com/articles_tutorials/Group-Policy-Security-Filtering.html

In addition, my GPOs are being applied when linked directly under the
domain. But when I create an OU under the domain and link to the GPO
from within the OU, it stops being applied. Am I missing a permission
or something? This is rather discouraging.

 

[Florian Frommherz [MVP]]

Yuppie!

This is incorrect.

As shown here, GPOs can be applied to groups with the use of Security
Filtering.
http://www.windowsnetworking.com/articles_tutorials/Group-Policy-Security-Filtering.html

Group Policies only apply to user and computer objects that are child
objects of the OU they are linked to - period. Security Filtering only
is a further filtering of the (already being) targets of the policy to
for example create a subset of those users or computers. GPs still only
apply to user and computer accounts.

Without user and computer objects being child objects of the OUs you
linked the policy to - how would they now they have to apply a Group
Policy?

cheers,

Florian

 

[Yuppie]

Group Policies only apply to user and computer objects that are child
objects of the OU they are linked to - period. Security Filtering only
is a further filtering of the (already being) targets of the policy to
for example create a subset of those users or computers. GPs still only
apply to user and computer accounts.

Without user and computer objects being child objects of the OUs you
linked the policy to - how would they now they have to apply a Group
Policy?

Excuse me. My misunderstanding.

That being said, why is it that a policy is applied when linked
directly to the domain but not when linked to an OU beneath the
domain? That is my main question and I have yet to find an answer. I
feel like I am missing something critical here. What am I missing?

The GPO I have created knows to apply the settings to the child
objects (user accounts) as they are members of the Security Group
which is defined in the Security Filter. But when linked to an OU,
they are not being applied.

 

[Florian Frommherz [MVP]]

Howdie!

That being said, why is it that a policy is applied when linked
directly to the domain but not when linked to an OU beneath the
domain? That is my main question and I have yet to find an answer. I
feel like I am missing something critical here. What am I missing?

Let's see if I can get this clearer for you: Group Policy processing is
divided in two things: the AD structure and permissions (on the GPlink,
SYSVOL, ...). Both those things need to be in a "good state" for a user
to apply a Group Policy.

From the Ad structure and its parent OUs, a user or computer knows what
policies to apply. It applies given policies in the following order:

Local - site - domain - OU - second level ou, third level ou, ...

The set of policies to apply is the sum of all those stations.
Contradicting settings are solved through the "last writer wins"
principle (if OU and 2nd level domain have a GP with the same setting
configured but with different states like enabled vs. disabled, 2nd
level OU wins as it gets applied later).

In order to apply the policies, target objects (again speaking of user
and computer objects) need appropriate permissions to the GPs (the link,
the SYSVOL...). They basically need "Read" and "Apply Group Policy"
permissions to apply a policy. Only if both conditions are true - the
object is target of policy X by a (child-) membership of the OU the
policy's linked to AND it has sufficient permission to apply the policy,
the object does apply it.

So -- coming to the GPO you linked to the domain - the domain is the
"parent" of all OUs, so to speak. It therefore applies to all objects
(even to those objects that reside in the "Users" and "Computers"
default containers you cannot link GPs to!).

Any clearer? Feel free to ask if I missed your point.

cheers,

Florian

 

[Yuppie]

Thank you for the very concise yet in-depth explanation. I don't
think you missed my point, but maybe I missed yours. I have taken 2
screenshots of my GPO Manager. Perhaps that will help my cause a bit
more (I should have done this in the beginning).

The GPO in question is "Logon Script For Testing"

In the first screenshot (http://picasaweb.google.com/chouse2507/
ChristopherHouseITBlog?authkey=KuE3ytCFckw#5243716024578668258), the
GPO in question is linked directly to the domain. Its setting is
applied when users who are members of "Domain Users" log in.

In the second screenshot (http://picasaweb.google.com/chouse2507/
ChristopherHouseITBlog?authkey=KuE3ytCFckw#5243716079097844098), the
GPO is now linked to an OU beneath the domain. Its setting is no
longer applied when users who are members of "Domain Users" log in.

Any suggestions as to why the GPOs behave in this manner?

 

[Yuppie]

I just noticed the links didn't work.

1st Screenshot:
http://tinyurl.com/6afoes

2nd Screenshot:
http://tinyurl.com/5h2ydr

 

[Florian Frommherz [MVP]]

Yuppie,

In the second screenshot (http://picasaweb.google.com/chouse2507/
ChristopherHouseITBlog?authkey=KuE3ytCFckw#5243716079097844098), the
GPO is now linked to an OU beneath the domain. Its setting is no
longer applied when users who are members of "Domain Users" log in.

For the second GPO (Logon script test) to apply, the corresponding users
need to be in the Logon script test OU. Otherwise part 1 of the two
things I mentioned in the other post would be fulfilled.

Also note that you normally don't have to change the security filtering
of a GPO (I see you put "Domain Users" there. Authenticated Users is
just fine).

You don't use the permissions to filter GPO application, you do that
when putting user and computer objects into OUs and link the policies to
them. Users you want the logon script to apply, you put (their user
objects in AD) into an OU and link the policy to it (nothing more - no
security filtering or permission tweaking, it works like that!).
Computers you want to have setting X applied, you put into an OU and
link the settingX-GPO to it (again, no security tweaking).

You'd only use the security filtering part where you can't organize your
objects in an OU structure that fits your needs. GP processing can
really slow down when you mess around with permissions excessively.

cheers,

Florian

 

[Yuppie]

Perhaps I have been missing a huge step when creating these GPOs and
OUs. When you say a user account or computer account needs to be a
child object of the OU, you mean add the object to the OU from within
Active Directory Users and Computers, correct?

Like this:
http://tinyurl.com/6negrb

If so, I have not been doing that and have assumed the Security Filter
setting within the GPO was the same thing.

 

[Florian Frommherz [MVP]]

Yuppie,

Perhaps I have been missing a huge step when creating these GPOs and
OUs. When you say a user account or computer account needs to be a
child object of the OU, you mean add the object to the OU from within
Active Directory Users and Computers, correct?

Like this:
http://tinyurl.com/6negrb

Yes, that was what I was trying to say. Maybe still not clear enough.
Putting the user account into the OU should make the policy work. I
suggest you start investigating how that works -- and leave the security
filtering alone (as for starts). That really for "advanced" GP
administration if you can't get away with OU structuring alone.

cheers,

florian

 

[Yuppie]

What a relief! Thank you so much for your time, patience and help.