Planning integration into your Active Directory environment

Applies To: Forefront Client Security

Using Group Policy to deploy Client Security policies

Client Security uses policies to define the settings for the Client Security agent on managed computers. These policies determine when malware and SSA scans are performed, when alerts are raised, when definition updates are downloaded, and how much control your users have over the Client Security settings.

You can deploy policies to the domain, organizational units (OUs), security groups, or existing Group Policy objects (GPOs) by using the Client Security console.

Note

Client Security policies are applied at the computer level, not at the user level.

After assigning client computers to OUs or security groups in the Active Directory, you can use the console to deploy a policy to specific OUs or security groups.

Important

A client computer can have only one Client Security policy deployed to it at a time. If you deploy a Client Security policy to an OU or security group that already has a Client Security policy deployed to it, the original policy will be removed from the OU or security group. For example, if you deploy Client Security policy A to OU 1 and OU 2, and then deploy Client Security policy B to OU 1, policy A is removed from OU 1.

For more information about working with policies in Client Security, see Working with policies in the Client Security Administrator's Guide (https://go.microsoft.com/fwlink/?LinkId=88415). For more information about Group Policy, see Windows Server 2003 Group Policy (https://go.microsoft.com/fwlink/?LinkId=73340).

Important

You should not use the GPMC to manage policies created by Client Security for deployments to domains, OUs, or security groups. Doing so can result in lost information in the policy and other significant errors.

Note

In addition to using Active Directory Group Policy to deploy Client Security policies, you can also deploy Client Security policies to a file and process them into a managed computer's local policy using fcslocalpolicytool.exe. Client Security does not support using the file deployment method and the GPO deployment methods on the same target computers.

Organizational unit structure

When planning your deployment of Client Security, you must consider your current organizational unit structure within Active Directory.

Group Policy in Active Directory can be linked to Active Directory sites, domains, and OUs. OUs are the lowest-level container in Active Directory and are used to organize your computers, users, and groups according to administrative and Group Policy needs. OUs can contain computers, users, and groups, in addition to providing the ability to nest an OU within an OU.

Important

Deploying Client Security policy at the site level is not supported.

Group Policy is inherited based on the target user or computer's OU location in Active Directory. The following diagram illustrates the inheritance order of Group Policy.

GPOs closest to the target computer take precedence over GPOs farther out in the organizational structure.

Because Client Security uses Group Policy for Client Security policy deployment, your OU structure affects the way you configure your Client Security policies. Client Security policies apply as a single discrete unit; they are applied as a whole and replaced as a whole. Therefore, the inheritance of Client Security policies is a complete override. For example, consider the following illustration.

Managed Computer 1 is located in OU 2. The Client Security administrator has created Client Security policies and linked them to OU 1 and OU 2. However, because Client Security policies apply as a discrete unit, the effective Client Security policy for Managed Computer 1 will be Client Security policy 2.

As illustrated in the previous example, OUs can contain OUs; this is called OU nesting. For example, you may have an OU that contains computers that require two different Client Security configurations. You can create OUs nested within the parent OU, move each computer into the appropriate child OU, and then deploy your Client Security policies to the child OUs. The more well organized your target computers and OU structure, the easier the Client Security policy deployment will be.

An alternative to creating nested OUs is to use the security group deployment method for Client Security policy. This deployment method uses the functionality of security group filtering in Group Policy. By choosing Add Group in the Deploy dialog box of the Client Security console, you are choosing the security group that will be granted Read and Apply Group Policy permissions on the Client Security policy.

The result of using the security group deployment method is that the Client Security policy is deployed to the root of the chosen domain, the Authenticated Users default group is removed from the access control list, the group chosen with the Add Group button is added to the access control list and granted Read and Apply Group Policy permissions, and the policy is marked as Enforced. In the GPMC, you can verify this behavior by selecting your domain name under Domains. The Client Security policy will be listed below the domain name, named with FCS-policyname-{guid}-deploymentmethod.

There may be instances where you need to deploy different Client Security policies to security groups that share one or more members. In this case, the link-order of GPOs for the domain will determine which Client Security policy the managed computer will receive. Link-order is managed within the GPMC.

To set the link order for GPOs

1. In the GPMC, select domainame in the tree.

2. In the results pane, on the Linked Group Policy Objects tab, select the GPO to take precedence and use the double down-arrow button to move it to the bottom of the list.

The GPO with the lowest link-order is processed last and therefore has the highest precedence. As a result, the GPO with the lowest link-order is the one that becomes the managed computer's Client Security policy.

Important

Do not add additional settings to Client Security–created GPOs. When Client Security policy is undeployed, the Client Security-created GPOs are deleted from Active Directory and you will lose any settings you added to the Client Security-created GPOs. Also, if the Client Security GPO contains additional settings, modifying the link order of the GPO could have serious consequences.

For more information about Group Policy deployment of Client Security policies, see Working with policies in the Client Security Administrator's Guide (https://go.microsoft.com/fwlink/?LinkID=88415).

Blocking and enforcing inheritance

You can prevent inheritance of GPOs from parent containers by using the Block Inheritance feature in the GPMC. Block Inheritance allows you to prevent GPOs at a higher level from being inherited. Inheritance is blocked for the OU that the block is placed on and all OUs nested within. However, any GPO marked as Enforced will still be inherited.

Enforced allows a higher-level administrator to make certain that a GPO is applied to all targets lower in the inheritance tree even if they have enabled Block Inheritance. Any GPO marked Enforced will be inherited to all OUs within the inheritance path.

Important

Use this setting with caution; any settings within the GPO that conflict with settings in lower-level GPOs will override those lower-level GPOs.

Important

Overuse of Block Inheritance and Enforced can complicate any future Group Policy troubleshooting that may need to be done. Use these options selectively.

Client Security–created GPOs

When deploying the Client Security policy in the Client Security console, the Add OU button allows the administrator to select a target Active Directory domain or OU. This selection procedure actually performs two separate functions: creating the GPO and linking the newly created GPO to the targeted OU. To successfully accomplish this, the Client Security administrator must have permissions to both create GPOs and link the GPO to the relevant OU.

Important

Deploying Client Security policy to a site-linked GPO is not supported. A GPO can be linked to more than one container; before deploying to your chosen GPO, verify that it is not linked to a site. Deploying to a site-linked GPO may have unintended consequences, such as deploying Client Security to computers or servers that are not intended targets.

The permissions to create and link GPOs can be granted using Active Directory. The first permission, creating GPOs, is granted by adding the user account to the Group Policy Creator Owners group in Active Directory. Adding users to this group gives them the ability to create GPOs. After a member of the Group Policy Creator Owners group creates a GPO, that member becomes the owner of that GPO and has full control over it. However, membership in the Group Policy Creator Owners group does not grant the user any additional permissions or rights; the user has full control only to those GPOs they have created. Furthermore, they cannot link the GPO they created to any container.

You can grant the ability to link an existing GPO to a domain or OU in the GPMC.

To allow the ability to link GPOs

1. In the GPMC, browse to and select the domain or OU to which you want a GPO linked.

2. In the results pane, click the Delegation tab and verify the Link GPOs permission is displayed in the Permission list box.

3. Click the Add button and in the Select User, Computer or Group dialog box, type the user account or group name. Click OK.

4. In the Add Group or User dialog box, in the Permissions drop-down list box, select the level to which you want permissions to apply for this group or user, and then click OK.

Granting the ability to both create GPOs and link GPOs has security implications. A rogue GPO administrator could delete a previously created GPO, maliciously link a GPO to the wrong OU, or create a GPO with malicious intent.

It is highly recommended that you carefully consider whom to grant these permissions to, as well as the scope of the permissions granted. For example, if the Client Security administrator only needs the ability to deploy Client Security policies to certain OUs, granting that user the ability to link GPOs only to those relevant OUs is the appropriate security decision.

Delegated GPOs

It may be undesirable to grant a non-domain administrator the ability to create and link GPOs in the domain. In this case, Client Security can use an existing GPO to deploy its settings. The Add GPO button allows the administrator to choose an existing GPO to merge the Client Security policy into.

Clicking the Add GPO button merges the Client Security policy settings into an existing GPO; to successfully accomplish this task, the user deploying the Client Security policy must have the permission to edit the targeted GPO.

To grant edit permissions on a GPO

1. In the GPMC, browse to Forest name/Domains/Domain name/Group Policy Objects.

2. Select the appropriate GPO under Group Policy Objects and in the results pane, click the Delegation tab.

3. Click the Add button and in the Select User, Computer or Group dialog box, type the user account or group name. Click OK.

4. In the Permissions list of the Add Group or User dialog box, select the appropriate permissions from the drop-down list, and then click OK.

Multiple domain environments

An Active Directory environment can be composed of multiple domains in a trust relationship called a tree. This tree of domains can be one of many in a trust relationship called an Active Directory forest. GPOs are created in domains and replicated only between the domain controllers for the domain in which they were created. GPOs can be shared between domains in a tree or forest, but they still reside in the domain in which they were created. Due to latency in application, it is not recommended that you deploy Client Security polices by deploying GPOs across domains. Instead, create GPOs for a domain in that domain. This also allows you the ability to manage each domain's Client Security settings separately.