...for those of you already familiar with group policy you will know this already. This post is for those new to working with group policies. If you were sent here by a question I participated in then feel leave a comment if this helps you out.
This entry will serve to supplement Microsoft's article http://technet.microsoft.com/en-us/library/cc781988.aspx
I will first assume you are using GPMC to manage your group policies.
First thing is that group policies can't be applied directly to groups. You link a group policy at the site, domain, or OU level. The policies apply to either users and/or computers.
So suppose you have a policy that you only want to apply to a subset of users or computers. The first thing is to create a group and place the users or computers you want this policy to apply to into that group (I'll use a global group in this example). We will call that group testgroup1.
In GPMC select your group policy object. In GPMC you will see the Scope tab. Notice that by default the policy will apply to Authenticated Users
You will remove authenticated users. Then you can add your testgroup1. Now the policy will only be applied to your testgroup1
So what really happens in the background when you make that change?
If you go to the delegation tab you will see an Advanced button.
As you can see testgroup1 now has "read" and "Apply Group Policy" set to Allow. So the policy will apply to that group. Read and Apply group policy are both needed in order for the user or computer to receive and process the policy
...at this point some of you may be asking, what if I wanted to "deny" the policy to a group or user. If you instincts tell you to apply set Read & Apply Group Policy to "deny" then you would be correct.
In the following screenshot I've set deny permissions for Read & Apply Group Policy and testgroup1 will not receive the policy.
That is really all there is to security filtering and group policies...not so hard after all. Please feel free to contact me if you have any questions about this.
Thanks
Mike
Posts
I try to avoid doing this. It's dangerous. Put a Kiosk Policy linked to your desktops OU and filter to to the Kiosks group and that's great until you accidentally pull the filter and turn your 100K desktops into bricks with the Kiosk policy.
ReplyDelete@Brian -- I understand that concern but that could happen if just the wrong setting is set on a domain level GPO.
ReplyDeleteA lot of times what we use this for is for "pilot users". We will first test the policy in the lab. Then with a group of 5-10 pilot users in production. We filter the policy to only apply to those users instead of putting those pilot users in an OU and linking the policy there.
When is it approperate to use Authenticated Users under the Sevurity Filtering section?
ReplyDeleteIt is appropriate to use Authenticated users if you want the policy to apply to everyone. If you are using authenticated users (that is the default) then you are really not filtering the GPO as everyone gets it.
ReplyDeleteMike, I believe, If you have to deny a policy to a specific set of users,groups, or computers, you should minimally allow Read and Deny Apply. If the pertinent target can't read the GPO then it won't deny itself from applying it. Thoughts ?
ReplyDeleteIn fact, (regarding my previous) comment. There seems to be conflicting information floating on technet. In the context of where you are wanting to exempt a Security Group from a GPO, if you set the "Deny Read" and if the intended group has Delegated Admins, than you could be shooting yourself in the foot from being able to modify the GPO as well. GPMC will tell you insufficient permission if you try to get into that GPO.
ReplyDeleteOn (http://technet.microsoft.com/en-us/library/cc759506(WS.10).aspx) it clearly states, that If the policy object should not be applied to the security group, user or computer, the minimum permissions should be set to allow Read and deny Apply Group Policy.
ReplyDeleteAnd on (http://technet.microsoft.com/en-us/library/cc786636(WS.10).aspx)it states, that If the policy object should not be applied to the security group, user or computer, the permissions should be set to Deny Read and deny Apply Group Policy.
I need to test this out, but it should be pretty simple to, lets say save your delegated admins from getting WSUS setting that blocks their WU access (its a user specific setting), without killing their rights to modify the pertinent GPO.
Good point about the Admins, in the example I was assuming that TestGroup didn't have admins, great catch!!
ReplyDeleteI also saw the back and forth between you and Darren on activedir about this. Very good discussion!
Can anyone answer this one:
ReplyDeleteIf you use security groups to do the security filtering (After removing authenticated users) it works fine with users but not with targeted computers. Everywhere I have read (including MS TechNet etc) it clearly states that you can use security groups to target specific computers. But it does not work. It does however work if you add the individual computer accounts directly into the delegation tab....
@Dylan,
ReplyDeleteDid you reboot the PC after added the computers to the security group.
Thanks
Mike
No where in the documentation says reboot is required. How do you find out such hidden trick? What if this server is a DC and can't reboot, then how do you apply?
ReplyDelete@Kris you need to reboot a computer if you add it to the group and want it to pick up the new group membership. Darren has a nice trick if you don't want to reboot
ReplyDeletehttp://www.sdmsoftware.com/general-stuff/picking-up-computer-group-membership-changes-without-a-reboot/
Similar if you add a user to the group but for a user all they need to do is log off and log back on.
So if you have a VIP user or server that can't be rebooted/logged off. You can add an individual user/computer object here too. You don't have to use a group but groups are easier to manage.
Same thing with NTFS permissions for example. You can add groups or computer/user objects to ACLs.
As a general rule security filtering is not usually done for DCs.
This comment has been removed by a blog administrator.
ReplyDelete