Your company has an organizational unit named Production.
The Production organizational unit has a child organizational unit named R&D.
You create a GPO named Software Deployment and link it to the Production organizational unit. You create a shadow group for the R&D organizational unit.
You need to deploy an application to users in the Production organizational unit.
You also need to ensure that the application is not deployed to users in the R&D organizational unit.
What are two possible ways to achieve this goal?
(Each correct answer presents a complete solution. Choose two.)
A. Configure the Block Inheritance setting on the R&D organizational unit.
B. Configure the Enforce setting on the software deployment GPO.
C. Configure security filtering on the Software Deployment GPO to Deny Apply group policy for the R&D security group.
D. Configure the Block Inheritance setting on the Production organizational unit.
Correct Answer: AC
Explanation/Reference:
Answer: Configure the Block Inheritance setting on the R&D organizational unit.
Configure security filtering on the Software Deployment GPO to Deny Apply group policy for the R&D security group.
Explanation:
http://technet.microsoft.com/en-us/library/cc757050%28v=ws.10%29.aspx
Managing inheritance of Group Policy
..
Blocking Group Policy inheritance
You can block policy inheritance for a domain or organizational unit. Using block inheritance prevents GPOs linked to higher sites, domains, or organizational units from being automatically inherited by the child- level. By default, children inherit all GPOs from the parent, but it is sometimes useful to block inheritance.
For example, if you want to apply a single set of policies to an entire domain except for one organizational unit, you can link the required GPOs at the domain level (from which all organizational units inherit policies by default) and then block inheritance only on the organizational unit to which the policies should not be applied.
Enforcing a GPO link
You can specify that the settings in a GPO link should take precedence over the settings of any child object by setting that link to Enforced. GPO-links that are enforced cannot be blocked from the parent container. Without enforcement from above, the settings of the GPO links at the higher level (parent) are overwritten by settings in GPOs linked to child organizational units, if the GPOs contain conflicting settings. With enforcement, the parent GPO link always has precedence. By default, GPO links are not enforced. In tools prior to GPMC, "enforced" was known as "No override."
..
In addition to using GPO links to apply policies, you can also control how GPOs are applied by using security filters or WMI filters.
http://technet.microsoft.com/en-us/library/cc781988%28v=ws.10%29.aspx
Security filtering using GPMC
Security filtering
Security filtering is a way of refining which users and computers will receive and apply the settings in a Group Policy object (GPO). Using security filtering, you can specify that only certain security principals within a container where the GPO is linked apply the GPO. Security group filtering determines whether the GPO as a whole applies to groups, users, or computers; it cannot be used selectively on different settings within a GPO.
..
Notes:
GPOs cannot be linked directly to users, computers, or security groups. They can only be linked to sites, domains and organizational units. However, by using security filtering, you can narrow the scope of a GPO so that it applies only to a single group, user, or computer.
..
The location of a security group in Active Directory is irrelevant to security group filtering and, more generally, irrelevant to Group Policy processing.
Further information:
http://technet.microsoft.com/en-us/library/cc731076.aspx
Block Inheritance
http://en.wikipedia.org/wiki/Active_Directory#Shadow_groups
Active Directory Shadow groups
In Microsoft’s Active Directory, OUs do not confer access permissions, and objects placed within OUs are not automatically assigned access privileges based on their containing OU. This is a design limitation specific to Active Directory. Other competing directories such as Novell NDS are able to assign access privileges through object placement within an OU.
Active Directory requires a separate step for an administrator to assign an object in an OU as a member of a group also within that OU. Relying on OU location alone to determine access permissions is unreliable, because the object may not have been assigned to the group object for that OU.
A common workaround for an Active Directory administrator is to write a custom PowerShell or Visual Basic script to automatically create and maintain a user group for each OU in their directory. The scripts are run periodically to update the group to match the OU’s account membership, but are unable to instantly update the security groups anytime the directory changes, as occurs in competing directories where security is directly implemented into the directory itself. Such groups are known as Shadow Groups. Once created, these shadow groups are selectable in place of the OU in the administrative tools.
Microsoft refers to shadow groups in the Server 2008 Reference documentation, but does not explain how to create them. There are no built-in server methods or console snap-ins for managing shadow groups.[5]
The division of an organization’s information infrastructure into a hierarchy of one or more domains and top- level OUs is a key decision. Common models are by business unit, by geographical location, by IT Service, or by object type and hybrids of these. OUs should be structured primarily to facilitate administrative delegation, and secondarily, to facilitate group policy application. Although OUs form an administrative boundary, the only true security boundary is the forest itself and an administrator of any domain in the forest must be trusted across all domains in the forest.[6]
