Plan for a Central Access Policy Deployment

Updated: March 10, 2012

Applies To: Windows Server 2012

The need to control the information in enterprise-level organizations for compliance and business regulations is one of the drivers in the consolidation trend where large amounts of information from users’ desktops and departmental file shares are moved into centrally managed file servers.
The initiative to deploy and enforce an authorization policy may come for different reasons and from multiple levels of the organization:

  • Organization-wide authorization policy: most commonly initiated from the Information Security office, this authorization policy is driven from compliance or very high level organization requirement and would be relevant across the organization. For example: High Business Impact files should be accessible by full time employees only

  • Departmental authorization policy: each department in an organization has some special data handling requirements that they would like to enforce. This is very common in distributed organization. For example: the finance department might want to limit all access to finance servers to the finance employees

  • Specific data management policy: this policy usually relates to compliance and business requirements and is targeted at protecting the right access to information that is being managed. For example: Preventing modification or deletion of files that are under retention or files that are under eDiscovery

  • Need to know policy: This is a catch all authorization policy type and most probably used in conjunction with the policy types mentioned above. Examples include: Vendors should be able to access and edit only files that pertain to a project that they are working on.
    In financial institutions, information walls are important so that analysts do not access brokerage information and brokers do not access analysis information

Process to map a business request to a central access policy

  1. Understand and translate business intent

  2. Express access policy in Windows Server 2012 constructs

  3. Determine the user groups, resource properties and claim types

  4. Determine the servers where this policy should be applied to

Understand and translate business intent

Business determines that a central access policy is needed. The next step is to decide on the content (resources) that you want to apply policies. Then create a list of all the policies you want to apply to your content. For example some of the common policies that apply to the finance department of an organization would be:

  • Archived finance documents should only be read by members of the Finance department.

  • Members of the Finance department should only be able to access documents in their own country.

  • Only Finance Administrators should have write access. An exception will be allowed for members of the FinanceException group. This group will have read access.

Express access policy in Windows Server 2012 constructs

The next step in the planning process is to translate the policies you require into expressions. A central access policy is targeted at providing an easy interpretation from a business requirement language to an authorization language.
A central policy in Windows Server 2012has the following distinct parts:

  • Applicability: A condition that defines which data the policy applies to
    (Example: Resource.BusinessImpact=High)

  • Access conditions: A list of one or more Access Control Entries (ACE) that defines who can access the data
    (Example: Allow | Full Control | User.EmployeeType=FTE)

  • Exception: An additional list of one or more access control entries that define an exception for the policy
    (Example: MemberOf(HBIExceptionGroup)

Determine the user groups, resource properties and claim types

In this step, the expressions that were created for the policies are broken down and analyzed to figure out what resource properties, security groups as well as potential user claims need to be created to deploy the specific policies. Note that before using user claims, you should review the relevant section on user claims in this topic. Remember that you can always use security groups in case that you do not have the appropriate user claim attribute available in your environment.

Determine the servers where this policy should be applied to

The next step is to determine what file servers you want to deploy the access policies you have decided on. For example you can have a finance access policy that you want to roll out only to the finance file servers.

Planning Guidelines for Deploying Central Access Policies

There are multiple ways to deploy central access policies, based on different configurations in your environment. You can choose to have a simple deployment with security groups or have more advanced central access policies using user claims and device claims. The following sections in this topic discuss the different deployment options available to you base on the configuration you choose. The design and deployment guidance for each of these is discussed in further detail:

  • Using Security Groups for Dynamic Access Control

  • Using User Claims

  • Using Device Claims and Device Security Groups

For a list of all configuration options and guidance on which configuration to choose, see the section, Configuring central access policies with different options

For a high-level view of the different deployment options, requirements and configurations, see the Appendix: Deployment Configurations for Central Access Policies

Using Security Groups for Dynamic Access Control

You don’t have to use user claims in order to implement Dynamic Access Control in your organization. In fact, you can use security groups with very minimal upgrade requirements to your current environment. You can use security groups in conjunction with central access policies and conditional expressions in Windows Server 2012. This way you can use Dynamic Access Control to limit access to specific data using the existing security group mechanism.

To use Dynamic Access Control with security groups you need the following in your environment:

  • A Windows Server 2012 File Server

  • A domain with a Windows Server 2012 schema (so that you can define central access policies)

Using security groups to limit access to data

Dynamic Access Control can help you limit access to data to the specific groups of people. The steps to achieve this are:

  1. Tagging the data by marking the folders that contain confidential data

  2. Configuring a Central Access Rule that specifies that only specific security groups can access data that are tagged in a specific way

  3. Applying a Central Access Policy to the appropriate Windows Server 2012 File Servers in your organization

For a detailed walkthrough of using security groups, see the Dynamic Access Control Blog.

Using conditional expressions to reduce complexity of security groups

You can use Dynamic Access Control to considerably reduce the complexity of a combinatorial number of security groups (for example, from 2,000 to less than a 100) so that you can have a clear understanding of who can access what data and you are able to easily adjust access when people move between different roles in the company.

In a typical enterprise environment there are a large number of users, departments, security groups, and thus, a large number of access control lists (ACLs). Also, if a person moves from one department to the other, that involves updating a large number of security groups. This results in a lot of IT overhead and Dynamic Access Control can help with reducing the workload of IT admins for managing security group. The steps required for this are:

  1. Tag all the folders with the appropriate values, for example, department, country, and sensitive.

  2. Decide on the combinations of expressions to be used in in Windows ACL. For example, you would use MemberOf (Spain_Security_Group)ANDMemberOf (Finance_Security_Group)ANDMemberOf(Sensitive_Security_Group) to limit access to Spain’s finance department sensitive information.

  3. Create specific central access rules with these expressions that target certain security groups and specific folders on the files servers.

For a detailed walkthrough of using Dynamic Access Control to reduce the complexity of security groups, see the Dynamic Access Control Blog.

Using User Claims

As a rule of thumb, you should use user claims (vs. security group) when:

  • You want to be able to use conditions such as User.Project = File.Project in your policy so that you can compress thousands of conditions to a simple expression (avoiding conditions such as File.Project=Cosmos AND User.Memberof(Cosmos_security_group)).

  • The user attribute in Active Directory that you are sourcing the user claim from has the appropriate security setting on who or what can set that attribute.

  • High integrity of the attribute value in Active Directory and the system that sets this value has operational procedures that take into consideration the use of that value for authorization decisions.

  • No foreseeable changes to the values in the attribute. For example if the attribute is a department name and these often change due to re-organization, then it is not fit to be used as a user claim.

When using user claims, you should make sure that you have the appropriate Windows Server 2012 domain controller environment to support these user claims. The two main domains of interest are the User domain and the File Server domain.

  • Both domains cannot include Windows Server 2003 (or earlier version) domain controllers.

  • Have adequate number of Windows Server 2012 domain controllers in the user domain to support the number of Windows 8 clients deployed in that domain or alternatively set the Windows 8 clients to not require claims in which case having at least one Windows Server 2012 domain controller in the user domain will be sufficient (see more details below

  • If the User domain and File Server domain are in a different forest, you need to:

    • Have two-way trust relations between the two forests.

    • Have all forest root domain controllers for both domains be Windows Server 2012

Operations to enable user claims

  • Enable the domain controllers to provide claims and compound authentication on request

Enable the domain controllers to provide claims and compound authentication on request

To enable the domain controllers to provide claims and compound authentication on request

  1. Open Group Policy Management and navigate to Domain Controllers OU in the domain.

  2. Right-click the Default Domain Controllers Policy and select Edit.

  3. In the Group Policy Management Editor window, navigate to Computer Configuration, > Administrative Templates, System, and KDC.

  4. Select KDC support for claims, compound authentication, and Kerberos armoring.

  5. Under Claims, compound authentication for Dynamic Access Control and Kerberos armoring options select Supported.

  6. Click OK. Close Group Policy Management.

Important

Until the Kerberos Group Policy Kerberos client support for claims, compound authentication and Kerberos armoring is enabled on all Windows 8 devices, claims and compound authentication will not be requested and claims-based and device-based access will fail.

Warning

Windows 8 devices enabled to support requesting claims and compound authentication will fail authentication when a Windows Server 2012 DC cannot be found in domains configured to support claims and compound authentication.

Considerations for using user claims in the file server discretionary ACLs without using Central Access Policies

Windows Server 2012 File servers have a group policy setting (On/Off/Automatic) that specifies whether it needs to get user claims for user tokens that do not carry claims. This setting is by default set to “automatic” which results in this group policy setting to be turned On if there is a central policy that contains user and/or device claims for that file server. If the file server contains local access policy (Discretionary ACLs) that uses user claims, you need to set this group policy to “On” so that the server knows to request claims on behalf of users that do not provide claims when accessing the server (For example, non-Windows 8 clients.

Using Device Claims and Device Security Groups

Windows 8 introduces the concept of compound identity that allows for the user token to include both the user details (ID, security groups and claims) as well as the device details (ID, security groups and claims) so that you can use these details in the authorization decision such as: Only specific users using a specific device can access highly sensitive data.

Much like user claims, device claims are sourced from the device object attribute in Active Directory (claim source) that contains the value of the claim.

Important

Device claims are supported in Windows 8clients only.

Considerations for using static device claims

To configure static device claims the administrator needs to:

  • Apply the appropriate security on the device attribute

  • Enable the claim definition – This operation will result in the claim to be available in the Kerberos ticket with the value sourced from the device attribute.

  • Enable domain controller support for Dynamic Access Control – This operation will result in the directory service returning claims to the KDC and the KDC creating TGTs containing claims

  • Apply the appropriate mechanisms to populate the device attribute in Active Directory.

  • Set Windows 8 clients and Windows Server 2012 to request compound tokens.

Operations to enable device claims

  • Enable the Windows 8 devices in domain to request claims and compound authentication

  • Enable the Windows 8 devices to request claims and compound authentication using custom policy

  • Enable the Windows 8 device to receive compound authentication

Enable the Windows 8 devices in domain to request claims and compound authentication

To enable the Windows 8 devices to request claims and compound authentication

  1. Note

    Apply the group policy on the domain.

    Open Group Policy Management and navigate to Domain.

  2. Right-click the Default Domain Controllers Policy and select Edit.

  3. In the Group Policy Management Editor window, navigate to Computer Configuration, > Administrative Templates, System, and Kerberos.

  4. Select Enable KDC support for claims, compound authentication, and Kerberos armoring.

  5. Click OK. Close Group Policy Management.

Enable the Windows 8 devices to request claims and compound authentication using custom policy

To enable Windows 8 devices to request claims and compound authentication using custom policy

  1. Note

    Apply the group policy on the domain, site, OU or object scope.

    Open Group Policy Management and navigate the appropriate policy.

  2. Right-click the Default Domain Controllers Policy and select Edit.

  3. In the Group Policy Management Editor window, navigate to Computer Configuration, > Administrative Templates, System, and Kerberos.

  4. Select Enable KDC support for claims, compound authentication, and Kerberos armoring.

  5. Click OK. Close Group Policy Management.

Enable the Windows 8 device to receive compound authentication

This group policy setting must be applied on the local group policy.

To enable the Windows 8 device to receive compound authentication

  1. Open Local Group Policy Editor.

  2. In the Local Group Policy window, expand to Computer Configuration, expand Administrative Templates, expand System and click Kerberos. Select Enable and Support compound authentication.

  3. Click OK and close the Group Policy Management Editor.

Configuring central access policies with different options

As mentioned before, if you are using security groups, you do not have any specific domain consideration other than the need to upgrade your schema to the Windows Server 2012 schema.

If you decide to use user claims or you would like to use user/device compound identity, your deployment design for Windows Server 2012 can be any of the following three configurations:

  • Configuration 1: Domains providing claims and compound authentication have all Windows Server 2012domain controllers.

  • Configuration 2: Only user claim-based access control, so file servers retrieve user claims and domains providing claims have Windows Server 2012 DCs in all the file server sites.

  • Configuration 3: Device-based access control needed, but cannot wait until all domain controllers can be upgraded.

Configuration 1: Domains providing claims and compound authentication have all Windows Server 2012 DCs

This configuration provides complete infrastructure for claims and compound authentication for Dynamic Access Control and is the easiest to support. It requires that:

  • If a cross-forest trusts exist, then root domain have all Windows Server 2012 domain controllers.

  • Domains that provide claims and compound authentication have all Windows Server 2012 domain controllers

  • All Windows 8 devices must be enabled to support requesting claims and compound authentication

Configuring forest root DCs

Simply upgrade all the domain controllers in the forest root to Windows Server 2012 and configure egress and ingress claims transformation.

Note

This will help ensure that claims are not lost from trusted forests. If pre-Windows Server 2012 domain controllers exist, those domain controllers will discard claims which will result in intermittent access control failures. Additionally pre-Windows Server 2012 domain controllers do not transform claims so the claims data is disclosed to all trusting forests

Configuring domains which provide claims and compound authentication

First identify which domains will be providing claims and compound authentication. These will be the account and resource domains. If all the domains in the environment have Windows Server 2012DCs then configure all.If claims-based access is required then claims will need to be provisioned.

Configure each domain which provides compound authentication and claims to DFL and Enable the DCs to support compound authentication and always provide claims.

Configuring devices to request claims and compound authentication

Update the default domain policy to Enable the Windows 8 devices in domain to request claims and compound authentication or Enable the Windows 8 devices to request claims and compound authentication using custom policy which applies to all the Windows 8 computer objects.

Note

This configuration that you set up to enable Windows 8 devices to request claims and compound authentication is ignored by versions of Windows which do not support it.

Configuring resources to receive compound authentication

If the resources are using CAP, then simply apply the CAP. Otherwise, Enable the Windows 8 device to receive compound authentication.

Configuration 2: Only user claim-based access control, so file servers retrieve user claims and domains providing claims have Windows Server 2012 domain controllers in all the file server sites

This configuration provides limited infrastructure for only user claims for Dynamic Access Control. It requires:

  • If a cross-forest trusts exist, then root domain has all Windows Server 2012 DCs

  • For each domain which provides user claims on request has Windows Server 2012 DCs in the sites with file servers and no Windows Server 2003 domain controllers.

  • Enable all Windows 8 file servers to support requesting claims on the behalf of users.

Important

Authentication mechanism assurance-based universal groups and device-based access control are incompatible with file server retrieval of user claims.

Configuring forest root DCs

Simply upgrade all the domain controllers in the forest root to Windows Server 2012 and configure egress and ingress claims transformation.

Note

This will help ensure that claims are not lost from trusted forests. If pre-Windows Server 2012 domain controllers exist, those domain controllers will discard claims which will result in intermittent access control failures. Additionally pre-Windows Server 2012 domain controllers do not transform claims so the claims data is disclosed to all trusting forests

Configuring domains which provides claims and compound authentication

  1. First identify which domains will be providing claims and compound authentication. These will be the account and resource domains.

  2. Configure and provision claims as explained in Deploy a Central Access Policy (Demonstration Steps)

  3. Configure each domain to Enable the domain controllers to provide claims and compound authentication on request.

Configuring file servers to request claims on the behalf of users

If the resources are using a central access policy, then simply apply the policy. Otherwise, Enable the Windows 8 devices to request claims and compound authentication using custom policy which applies to Windows 8 file server computer objects.

Note

This setting is ignored by versions of Windows which do not support it.

Configuration 3: Device-based access control needed, but cannot wait until all domain controllers can be upgraded

This configuration will be unique to your environment and can be difficult to support when Windows 8 devices have different configurations.

General requirements for all environments:

  • If across-forest trusts exist, then root domain must have all Windows Server 2012domain controllers

  • For each domain which provides claims and compound authentication on request, there cannot be Windows Server 2003 domain controllers

  • For resources using device-based access control, receiving compound authentication must be enabled unless a central access policy is being used.

Considerations for using smartcards for Central Access Polices

In Windows 7 and Windows 8 clients, smart card logon is mapped through security groups. In order to create this mapping, the domain administrator needs to:

  • Create a security group that will represent the smart card logon.

  • Create a mapping from the smart card certificate OID to and smart card security group.

  • Domain controllers need to have Windows Server 2008 R2 Domain Functional Level

Note

This group membership will be lost if the server performs S4U2Self on behalf of the user

Best Practices for Deploying Central Access Policies

The following sections provide additional guidance for best practices for delegation of administration, setting up exception mechanisms, and so on.

Delegating of administration for Dynamic Access Control

Ideally, you should delegate permissions for all Dynamic Access Control containers in the forest root of your domain controller. You would need to grant read-write permissions for to specific security groups that have access to certain objects. For example, you can create universal groups like:

  • DAC Claim Admins

  • DAC Resource Property Admins

  • DAC Central Access Rule Admins

  • DAC Central Access Policy Admins

You can then delegate the corresponding rights to these groups.

Following are the built-in Dynamic Access Control containers in Windows Server 2012. To access these containers, browse to configuration partition-> system->services->claims configuration.

  • Claim Types

  • Resource Properties

  • Central Access Rules

  • Central Access Policies

You can set up delegation of policies from Active Directory Administrative Center (ADAC).

To set up delegation of permissions from ADAC

  1. From Server Manager, on the Tools menu, select Active Directory Administrative Center.

  2. Select Dynamic Access Control on the left pane, and select the container that has the object that you want to delegate permissions to. For example, select Central Access Policies and select a policy from the list.

  3. Right-click and select Properties. In the Policy Properties window, select the Extensions tab.

  4. Select the Security tab. Click Advanced. In the Advanced Security Settings dialog box, click Add. In the Permission entry dialog box, click Select a Principal and type the name of the security group to which you want to grant access to. Click OK.

  5. In the Permission entry dialog box, select the permissions you want to grant for the group. Click OK three times.

Exception Mechanisms for Planning Central Access Policies

Exceptions to the common access rules are a key component of every access policy and in particular a central access policy. For example, if a central policy for the organization protects access to high business impact data (HBI) so that only full-time employees can access this data, what happens if a vendor in the finance department requires access to financial information that is considered to be HBI so that he can do his job?

There are several valid answers ranging from using one security group in the central access policy to grant access to HBI data (which would then allow the vendor in this example to access both financial HBI data and other HBI data such as HR or engineering) to having multiple security groups for exceptions to having per file- or user-specific exception mechanisms.

Exception Mechanism Central Access Policy scenario Description Pros Cons

Security group

Any access rule where we are OK with providing access to all the information covered by the central access policy when granting the exception

Example is a central access rule for department data that implements a safety net over ALL of the departments data (e.g.: Resource.Department=Finance)

One security group managed by the department IT or Information Security personal with a delegation to allow department senior personal to add / remove (manage) users from the group.

Content owners from the department will be able to manage the exception group so that they control who can access information to the department data

Simple to implement

Provides a good delegation model with existing tools to manage groups

Exception is wide and grants access to information that might not be relevant for this specific user

Multiple security groups

Central access rule for access to a range of countries with a finite (e.g.: <20) number of permutations where we would like to have each one controlled by a different content owner

Example is a central access rule for access to country data Resource.Country = User.Country

A security group for each of the countries. Each security group is managed by the content owners of that country

Simple to implement

Provides a good delegation model with existing tools to manage groups

The more groups there are, the more complex the access conditions becomes.

Each time a new instance is added (for example, a new country), the administrator needs to create a new group to manage the exception for it

Tools for Deployment

Data Classification Toolkit : The Data Classification Toolkit for Windows Server 2012 is designed to help organizations identify, classify, and protect data on their file servers. The out-of-the-box classification and rule examples help organizations build and deploy their policies to protect critical information in a cost-effective manner.The toolkit supports both Windows Server 2012 file servers and Windows Server 2008 R2 file servers. In addition to configuring file classification infrastructure, the latest version of the toolkit allows you to manage a Central Access Policy across the file servers in your organization. It provides tools for you to provision user and device claim values, and manage Central Access Policy across the forest to help simplify the configuration process of Dynamic Access Controls in Windows Server 2012. The toolkit also provides a new report template that you can use to review existing Central Access Policy on file shares.

Appendix: Deployment Configurations for Central Access Policies

Deployment Option Requirements and Configuration Options Guidance

Using Security Groups

  • Windows Server 2012 File Server

  • A domain with a Windows Server 2012 schema

Using Security Groups for Dynamic Access Control

Using User Claims

  • Configuration 2: Only user claim-based access control, so file servers retrieve user claims and domains providing claims have Windows Server 2012 domain controllers in all the file server sites

    For cross-forest claims deployment, you need a two-way trust been the user domain and a resource domain. For more information, see Deploy Claims Across Forests

  • Configuration 1: Domains providing claims and compound authentication have all Windows Server 2012 DCs

Using User Claims

Using Device Claims

  • Configuration 2: Only user claim-based access control, so file servers retrieve user claims and domains providing claims have Windows Server 2012 domain controllers in all the file server sites

  • Configuration 1: Domains providing claims and compound authentication have all Windows Server 2012 DCs

  • Configuration 3: Device-based access control needed, but cannot wait until all domain controllers can be upgraded

Using Device Claims and Device Security Groups