Solved

Attaching GPO to OU does not work, attaching to root of domain does work ?

Posted on 2010-09-17
10
1,327 Views
Last Modified: 2012-05-10
Hi,

I have never had to attach a GPO to an OU container, I normal have just had to create policy and link it to the domain root.

I have an OU, inside my OU in AD users and computers I have a Group, and memebrs to that group are users.

I cleared all default and other GPO that have been created on a test server(clean install),
I created a GPO policy and attached it to the OU in Group Policy Management Console.

When i log onto XP machine which has been registered to the above server, nothing is applied.
If I go and cancel linking on OU, and attach it to the Domain Root, all works?

My GPO, only has filtering set to the Group Container that is within the OU in question, it does have read and apply GPO permission.

Can anyone help ?
0
Comment
Question by:spiraldav
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 3
  • 2
  • +2
10 Comments
 
LVL 22

Accepted Solution

by:
Joseph Moody earned 167 total points
ID: 33702420
If the GPO has a computer setting in it, it must be linked to the OU containing the computer.
Policies can not be linked to an OU containing just a security group.
0
 
LVL 57

Assisted Solution

by:Mike Kline
Mike Kline earned 167 total points
ID: 33702425
The GPO has to be linked where it applies to users or computers (depending on what is being set)
So if that GPO contains user settings and your OU doesn't contain any users then nothing will happen
If the GPO contains computer settings and yoru OU doesn't contain machines then nothing will happen so in your case you only have that group inside that OU so that is why nothing is happening.
When you linked it at the domain level it is applying to users/computers, but being filtered only to that group using security filtering.
Thanks
Mike
0
 

Author Comment

by:spiraldav
ID: 33702752
Hey Guys,

Thanks so much for that, Id love it if that info was in my microsoft books, as I have double checked my self etc and couldn't find a resolve showing I need users in that OU and not just a Group thats linked to users from users container.

Ok Mike, so if i understand correctly the following should happen :
If I attach a policy to an OU, that OU cant have a Group as the policy will not be applied to users of that Group, but if I have users in the OU then the GPO will be applied to them.

How do I get past the computer policy application ? do I add machines to the OU as well ?
What if the users move to other machines that are not in the OU, then will the machines not get the computer policy applied ?
and by that happening then they will get whatever default computer policy you have at the root of the AD.?

And if i understand this correctly quote : "When you linked it at the domain level it is applying to users/computers, but being filtered only to that group using security filtering. "

by filtering we mean, filtering to the groups or user under the security tab, and not WMI filtering.

Thanks for the help to both who posted.
Dav
0
Does Powershell have you tied up in knots?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 
LVL 40

Assisted Solution

by:Adam Brown
Adam Brown earned 166 total points
ID: 33703062
"If I attach a policy to an OU, that OU cant have a Group as the policy will not be applied to users of that Group, but if I have users in the OU then the GPO will be applied to them."

Just a slight technical correction here, a GPO *can* be attached to an OU with groups in them, it's just that the policies aren't processed by the groups. Only the users.

Also: "I cleared all default and other GPO that have been created on a test server(clean install),"
I'm not sure if I'm reading this correctly, but it seems to say that you removed the Default Domain Policy and Default Domain Controllers Policy. If that is the case, I should warn you that this can cause a lot of problems. Those policies are configured with some important operational settings that are necessary for AD to work properly, including default user rights and server communication settings.

But, to clarify, there are two pieces to any GPO. Computer Configuration, and User configuration. If you set a policy in the Computer Configuration section, the Policy won't do anything unless it's linked to an OU with computers in it. If you set a policy in the User Configuration setting, it won't do anything unless it's linked to an OU with users in it, with one very important exception. If you enable Loopback Policy Processing (Info here: http://support.microsoft.com/kb/231287 ) you can link User Configuration policies to an OU with just Computers in it and the policy will be applied to users that log in to those computers. So if you want users that log in to specific computers (but not all the computers and users) to have a certain type of setting that exists in User Configuration, you can set Loopback Policy settings to allow that to happen.
0
 

Author Comment

by:spiraldav
ID: 33703332
Thanks for clearing all up and thanks for reminding me about loopback, just have never needed to use it, so falls out of memory if you know what i mean.

about your question to my statement ""I cleared all default and other GPO that have been created on a test server(clean install),"

I unlinked the default domain policy from the root of the domain, but I had made a copy of default domain policy and modeled my GPO setting on the copy that i renamed.
and the Default Domain Controller policy from what I can see is not linked, and from looking at what settings are applied in it are practically nothing at all ? but if I have more than one domain controller then only will that come into play ?

As a best practice should I rather do the following :
Leave Default Domain Group Policy, set security settings on that file GPO and apply it to authenticated users.

Then create whatever restrictive policies i need in a new GPO, and apply that to OU's, in the OU's have users and create groups for those users, (the reason for groups if for when applying NTFS permissions, makes applying to group rather than users much easier to maintane )

Then if I apply computer policies in a GPO but users move around the network, create a link from the GPO using a Loopback Policy to the computers container, where all authenticated machines are placed.

again thanks for all the help.
Davin
0
 
LVL 22

Expert Comment

by:Joseph Moody
ID: 33703466
Your default domain policy is best left unaltered and linked to your domain. Your default domain controller policy is very important and should be left linked to your domain controllers OU.
0
 
LVL 40

Expert Comment

by:Adam Brown
ID: 33703468
Well, you should try to use Loopback policy as sparingly as possible. It's mostly just useful if you want to have user configuration settings like desktop background and screen saver time out to be applied when users log in to certain computers, but not all the time. If you want user configurations to be applied to all users (or groups of users), create a GPO with only User configuration settings and apply that to the OU the users are in. You can save yourself from having lots of GPOs all over the place if you use Loopback policy and only attach to the Computer OUs, but it has the potential of increasing headaches during GPO troubleshooting down the road.

Generally, the best practice for Default Domain Policy and DDC Policy is to just leave them alone. If you have additional security settings that you want to use, build a new GPO and attach it to the Domain or OUs that need it applied and make sure it is set with the highest priority. That will allow the settings you have to be applied instead of the Defaults if you want. There aren't a lot of settings in the Default Domain Policy at the start, but the settings that are there are very important.
0
 
LVL 12
ID: 33716585
You CAN create a group policy object and link it via groups instead of by OU.

However, to do so you must put it at the root of the OUs where ALL of the users who may ever be members of the group will exist (Therefore it's best practice to put these GPOs at the DOMAIN level).

Then you simply change the groups it applies to in the group policy's Security tab.

To do this you

 1st you would create a new GPO at the domain level, then you would edit the GPO's Properties by right clicking on the GPO and selecting properties.

 2nd you would go to the 'Security' tab and remove the 'Apply Group Policy' setting from "Authenticated Users"

 3rd You would Add the specific groups which should have the GPO applied to them, to the policy and give them "Read" and "Apply" Permissions for the Group Policy.  (NOTE: It's best practice to create a single new group for this GPO and add this on the Security tab instead, and then add the appropriate users/groups to hat group.
0
 
LVL 40

Expert Comment

by:Adam Brown
ID: 33717159
QCubed: That still isn't linking a GPO to a group. That's linking a GPO to the Domain and *filtering* policy application with a security group. At the low level, security filtering applies an ACL to the policy, making it so only the members of that group have permission to read and apply the policy. There's a very important technical distinction there.

And it isn't really a best practice to apply filtered GPOs to the Domain. If all the users or computers (or if a small subset of users in an OU) that are filtered exist in a single OU or OU branch, linking it to the top of the branch or the OU itself serves as a visual reminder to administrators. This prevents admins from having to look through the Filter settings of all GPOs to find the one that is affecting users that have issues. In addition, each computer in the domain still has to process the policy if it's linked to the domain, meaning that you have some amount of time (however small) where the computer has to communicate with the Domain Controller to view the Policy and its attached ACL. It's not a big deal in small environments, but if you have 100 GPOs in AD and they're all attached to the Domain, it will seriously hamper logon performance and potentially bring a DC to its knees during periods of high logon traffic.
0
 

Author Comment

by:spiraldav
ID: 33717349
Thanks all for all the comments and help.
0

Featured Post

[Webinar] Code, Load, and Grow

Managing multiple websites, servers, applications, and security on a daily basis? Join us for a webinar on May 25th to learn how to simplify administration and management of virtual hosts for IT admins, create a secure environment, and deploy code more effectively and frequently.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

A project that enables an administrator to perform actions within a user session context not just at the time of login but any time later on day(s) or week(s) later.
This article demonstrates probably the easiest way to configure domain-wide tier isolation within Active Directory. If you do not know tier isolation read https://technet.microsoft.com/en-us/windows-server-docs/security/securing-privileged-access/s…
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles from a Windows Server 2008 domain controller to a Windows Server 2012 domain controlle…
Microsoft Active Directory, the widely used IT infrastructure, is known for its high risk of credential theft. The best way to test your Active Directory’s vulnerabilities to pass-the-ticket, pass-the-hash, privilege escalation, and malware attacks …

740 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question