Working with user roles
Applies To: Forefront Client Security
You can divide Client Security administrative tasks among different roles that users can fulfill, and then you can grant users the permissions necessary to perform tasks appropriate to their assigned roles. If your organization combines the responsibilities of some roles, you can combine the permissions as needed. For example, if a particular user is responsible for performing the tasks of a Policy Author and a Policy Deployer, you can grant that user the permissions necessary for both roles.
Client Security tasks fall into the roles summarized in the following table. Each of the roles is discussed in greater detail in later sections.
| Role | Description |
|---|---|
Client Security Administrator |
|
Policy Author |
|
Policy Deployer |
|
Alerts Manager |
|
Reports Viewer |
|
Permissions per role
The following table summarizes the permissions needed for each role.
| Role | View reports | Access MOM Operator console | Access collection database | Work with GPOs | Access MOM Administrator console |
|---|---|---|---|---|---|
Client Security Administrator |
Yes |
Yes |
Yes |
No |
Yes |
Policy Author |
Yes |
No |
Yes |
No |
No |
Policy Deployer |
Yes |
No |
Yes |
Yes (for details, see Policy Deployer role) |
No |
Alerts Manager |
Yes |
Yes |
No |
No |
No |
Reports Viewer |
Yes |
No |
No |
No |
No |
Permissions for accessing the Client Security console
Permissions for using the dashboard are divided into three parts, as follows:
Collection database access—The most critical permission for having access to the console is permission to access the collection database. Without this permission, users receive a database connection error when they access the console.
View reports permission—To see all charting data on the dashboard, users need permission to view reports. Without this permission, the dashboard charts show less data. In particular, the 14-day History chart shows no data.
MOM Operator console access—To open the links under Notifications on the dashboard, users need permission to access the MOM Operator console. Without this permission, the MOM Operator console denies access to the user. For user roles that don't require access to the MOM Operator console, you can deny this permission.
Additional permissions are required if you need to deploy policies by GPO, OU, or security group. For more information, see Policy Deployer role.
Client Security Administrator role
The Client Security Administrator role allows users to perform all Client Security tasks except deployment of policies to OUs, security groups, and GPOs. Thus, Client Security Administrators require all of the permissions of other Client Security user roles, with the exception of the Group Policy permissions granted to users with the Policy Deployer role.
Client Security Administrators use the MOM Administrator console to perform these tasks:
Modifying Client Security alert parameters, such as the Auto-approve pending computers parameter in the Flooding Detected event rule.
Manually approving new or disconnected clients.
Creating and modifying MOM notification groups.
Additionally, the ability of Client Security Administrators to start on-demand scans depends partly on permissions to access the MOM Administrator console, because the administrator must have permission to use MOM to queue and schedule the scan events.
For information about granting the permissions required for the Client Security Administrator role, see the following topics:
Policy Author role
The Policy Author role requires access to the Client Security console, because you use the console's Policy Management tab to create, edit, and delete Client Security policies.
Policy Authors create, edit, and delete Client Security policies, which define Client Security agent behavior, such as when scheduled scans occur, whether the Client Security agent checks for definition updates before scans, and how much control end users have over the Client Security agent. The Policy Author role is appropriate for users whom you want to allow to work with policies (and to deploy policies to registry files), but to whom you do not want to grant permission to deploy policies to OUs, security groups, or GPOs.
Because the console displays reporting data and provides the means to update policies, a Policy Author needs permission to view reports and to update the collection database.
For information about granting the permissions required for the Policy Author role, see the following topics:
Policy Deployer role
The Policy Deployer role requires access to the console because Policy Deployers must use the Policy Management tab to deploy and undeploy policies.
Policy Deployers deploy Client Security policies to one of the three deployment target types that use Group Policy. Depending on the targets, the permissions required for the Policy Deployer role vary, as shown in the following table.
| Deployment target | Permissions required |
|---|---|
|
Policy Deployers must have permission to create, modify, delete, and link GPOs. For OU deployment, Policy Deployers must have these permissions at the OU level. For security group deployment, Policy Deployers must have these permissions at the domain level. To deploy to OUs and security groups in remote domains, Policy Deployers must have, in each remote domain, permission to create, modify, delete, and link GPOs; however, you cannot add Policy Deployers in the Client Security domain to the Group Policy Creator Owners global group in remote domains. Instead, you can:
|
|
Policy Deployers must have permission to edit the GPOs that distribute the Client Security policies to client computers. |
Client Security supports deploying a policy to more than one target, including targets of different types. It is recommended that you keep your deployment strategy straightforward; however, you can deploy to GPOs, OUs, or security groups if you choose. Granting the Policy Deployer permission to deploy to OUs and security groups may include the permissions to edit the necessary GPOs; however, you should verify this to ensure successful GPO-based deployment.
Permission to view reports allows a Policy Deployer to use the Deployment Summary report, in addition to enabling a Policy Deployer to see reporting data in the Client Security console.
For information about granting the permissions required for the Policy Deployer role, see the following topics:
Delegate policy-related permissions on a domain, OU, or site using GPMC (https://go.microsoft.com/fwlink/?LinkId=78985)
Delegate creation of Group Policy objects using GPMC (https://go.microsoft.com/fwlink/?LinkId=78986)
Alerts Manager role
The Alerts Manager role allows users to access alerts in the MOM Operator console and resolve them. The ability to view reports allows an Alerts Manager to view alert-related reports, which is particularly useful when an Alerts Manager doesn't have immediate access to a computer with the MOM Operator console installed.
Resolving some alerts, such as a "Malware Outbreak" alert, may require an on-demand scan of a client computer or of all managed computers. Alerts Managers, however, do not have access to the Client Security console, where the Scan Now button is located. It is recommended that Alerts Managers work with Policy Authors or Policy Deployers so that an Alerts Manager can request on-demand scans.
For information about granting the permissions required for the Alerts Manager role, see the following topics:
Reports Viewer role
The Reports Viewer role allows users to access the Web-based Client Security reports, which can be viewed using the Report Manager on the reporting server. This role is appropriate for users who have an interest in the security state of your organization but who do not need to perform any other Client Security tasks.
For information about granting the permissions required for the Reports Viewer role, see Controlling report-viewing permission.