Account Management » Active Directory How-To pages It's not possible to apply a group policy to a security group . However, you can change the permissions on group policy so that only certain users/groups have read and apply privileges. Step 1:Select the Group Policy Object in the Group Policy Management Console (GPMC). Click on the Delegation tab and then click on the Advanced button. Step 2:Click on the Add button and select the security group that you wish to apply to . Then select the group (e.g. “Accounting Users”) and scroll the permission list down to the “Apply group policy” option and then select the Allow permission. This Group Policy now applies to only users or computers that are a member of the Accounting Users security group. However you still need to remember that the user and/or computer should be part of the site/domain/OU to which this Group Policy Object is linked.  Using GPO’s to apply settings to users and computers have always been a great way to make administration and deployments more seamless for admins and users. Working with many different customers, where IT has various experience with this, I see a lot of misconfigured Group Policies, so why not write a post about it. Group Policy is a powerful tool, and if a GPO gets incorrectly configured it can have dramatic impact on both users, computers and servers for the organization, this can happen by simple human error as well as lack of understanding how to configure this correctly. Now, if you want to limit the impact ration for what the GPO settings applies to, you have a few options. I will walk through the basics here. WMI filtering Group Policy WMI filters were introduced with Windows XP, and are supported in Windows Server 2003, Windows Vista, and Windows Server 2008. They are not supported in Windows 2000 . WMI filters makes it possible to set common criteria for when the GPO should take effect. They can be useful if your AD structure is relatively flat and not organized with separate OU’s for different objects in AD. They also give the possibility to apply settings based on OS version, network, server roles and various criteria. For creating WMI code you can use the following tool (WMI Code Creator) to help you out: For instance, you could create a policy for deploying Citrix Receiver to the computers in the organization. With WMI filter, you can then put this policy on the top level of the domain – along with the Default Domain Policy, apply a WMI filter so the GPO only applies to computer objects with a desktop operating system. This will ensure that all computers in the domain, regardless of OU placement for the Computer Account in AD, gets the GPO applied, while servers do not get the gpo. Simple example. Filters are evaluated in the following order – top to bottom.
So, we find all the policies that exist in the user/computer’s Local, Site, Domain, and OU hierarchy. Then we determine if the WMI filter evaluates as TRUE. Then we verify that the user/computer has Read and Apply Group permissions for the GPO. This means that WMI filters are still less efficient than hierarchical linking, but we can use filters to make decisions in a non-hierarchical Active Directory design. OU link with Security Filtering This is perhaps the most wildly used option, and the one where I personally see the most misconfiguration. When you create a GPO, the default security filtering is set to Authenticated Users – and this is where the mistakes often happen. So, what exactly is Authanticated Users? The following article gives some insight to this. The Authenticated Users group contains users who have authenticated to the domain or a domain that is trusted by the computer domain. Authenticated Users will contain all manually created user accounts in all trusted domains regardless of whether they are a member of the Domain Users group or not. Authenticated Users specifically does not contain the built-in Guest account, but will contain other users created and added to Domain Guests. The following list shows the members who are fall under this group
This makes a GPO with authenticated users as the security filtering, pretty much apply to anything within the linked OU, meaning this could cause some serious mayhem if the GPO gets linked to the wrong OU, or even worse, at top domain level. It is ok to to this if you want the GPO to apply to everything in the linked OU, but be certain about the settings in the GPO and the expected audience, before you enable the link. If you wish to edit the Security Filtering to apply only to a selected AD Group containing users/computers/server, I regularly see that the admin just removing the Authenticated Users group from the Security Filtering like so:
And then adds the other group they want to apply the settings to, they then get surprised that the GPO is not applying to their user/computers. The reason for this is that when you remove the Authenticated Users group from Security Filtering, both read and apply permissions are removed from that group. This can be controlled by going to the Delegation tab after you have selected a GPO. In the security tab, select authenticated Users, and check that Read is allowed, and that the box for allow under Apply Group policy is unchecked. After you have removed the Apply checkbox, you can go back to the Scope tab, and will see that authenticated users group no longer exists under Security Filtering, and you can add the wanted group here. Now Authenticated Users group still has Read permissions, and your GPO will apply as expected. Another example of things I see regularly is when the Security filtering contains both authenticated users group and the administrators selected groups. Group Policy Preferences – Item level targeting The 2 previous options revolve around how you can use different approaches to apply a Group Policy to selected objects. Now, with Group policy Preferences you can have the same GPO apply different (or same) settings to different objects based on different criteria. A common example of this is drive mappings: Fill out as needed, and click the common tab. Click the Item-level targeting checkbox, then the Targeting button You then come to the Targeting editor where you can specify the criteria for when the setting should apply/not apply, and the options give you a fair share of flexibility To make a meaningless example, you could add something like this Making the drive only get mapped if the user is a member of Domains users, and the users computer has 512MB of free ram or 80GB free disk space on his/her computer. This makes it possible to reduce the number of needed GPOs for similar settings, and rather use the same GPO with Item-level Targeting to specify when where and on what the polciy is to go in to effect. As you can see there are a lot of options available for customizing GPO’s in a flexible way. Some other pages with information around the subject: https://blogs.technet.microsoft.com/grouppolicy/2009/07/30/security-filtering-wmi-filtering-and-item-level-targeting-in-group-policy-preferences/
|
How to apply group policy to specific computers
zusammenhängende Posts
Urheberrechte © © 2024 frojeostern Inc.
