What You Need to Know About Dynamic Access Control for Windows Server

Dynamic Access Control is a Windows Server feature that makes it possible to establish conditional access control based on criteria of your own choosing. As an administrator, you might, for example, choose to allow a particular user to access a certain file while working in the corporate office but not not while traveling. The Dynamic Access Control feature, which has been a part of Windows Server since the days of Windows Server 2012, has a lot of moving parts. As such, a successful deployment and smooth ongoing operations depend heavily on proper planning. While much of the planning process is straightforward, there are a few things that can be easy to overlook.

Client Support

Because Dynamic Access Control is a Windows Server feature, the planning and deployment process tends to quite naturally focus on server resources. However, your clients play a major role in how Dynamic Access Control will need to be deployed and configured.

As previously mentioned, Dynamic Access Control was introduced in Windows Server 2012. This means that the first desktop operating system to support the feature was Windows 8. Of course there are plenty of organizations that are still running Windows 7. Windows 7 does not natively support Dynamic Access Control, so you will probably want to consider upgrading your Windows 7 machines to use a newer operating system. Windows 7 and other non-supported operating systems can be used in an environment that utilizes Dynamic Access Control. However, according to Microsoft, “When Dynamic Access Control is configured in environments with supported and non-supported versions of Windows, only the supported versions will implement the changes.

Another important detail to keep in mind is that the way your Active Directory will need to be configured varies depending on whether you have legacy clients (such as Windows 7) on your network. If you plan to continue using legacy clients after implementing Dynamic Access Control, you will need to establish a two-way trust among all of your Active Directory forests.

Additionally, if you support Windows devices that do not use claims or compound identity to protect resources, you will need to disable the Kerberos protocol’s support for Dynamic Access Control.

Legacy Domain Controller Use

Dynamic Access Control is only supported on Windows Server 2012 and higher domain controllers. With Windows Server 2008 reaching its end of support date, most organizations are probably running newer versions of Windows that natively support Dynamic Access Control. For those organizations that have some older domain controllers, however, there are a couple of important considerations that must be taken into account.

One pertains to the use of multi-forest topologies in which users are in one forest, while file servers reside in a different forest. If this type of topology is used, the domain controllers in the file server’s forest root must be configured to use a Windows Server 2012 or higher functional level.

As you plan for Dynamic Access Control, you will also have to think about capacity planning. While it is true that dynamic capacity planning allows you to maintain a mix of both compatible and incompatible (legacy) domain controllers, only the domain controllers that are running Windows Server 2012 or higher will be able to perform Dynamic Access Control-based device authentication. This means that you are going to have to make sure that each domain that will be involved in the process contains enough Dynamic Access Control-compatible domain controllers to comfortably handle the authentication workload without the assistance of the incompatible domain controllers.

In addition, If you have domains that will support user claims, but that also include legacy domain controllers, you will need to use group policy to make Windows aware of the domain controller mixture.

The group policy setting that you will need to configure is found in the local security policy, and it will need to be configured individually on each domain controller. You can find this policy setting at Computer Configuration | Administrative Templates | System | KDC. The policy setting is named KDC Support for Claims, Compound Authentication, and Kerberos Armoring. This policy setting should be enabled for all domain controllers, regardless of whether they are Dynamic Access Control-compatible or not. The setting includes options for Supported and Not Supported, as shown in the screen below. If all of your domain controllers are supported, then set the policy setting to Always Provide Claims.

Direct Access Control Configuration

Figure 1

If a domain contains a mixture of supported and unsupported domain controllers, use this option within each domain controller’s local security policy to designate the domain controller as either supported or unsupported.