Dynamic Access Control: Cross-Forest Access Control
In the fourth and final part of this series on Dynamic Access Control (DAC), I’ll introduce you to claim transformation policies that are used to traverse claims across trusted forest boundaries.
(Need to catch up? In part one, get an introduction to Dynamic Access Control (DAC) in Windows Server 2012, and in part two, learn to enable Kerberos support for claims and how to define claim types and resource properties. In part three, discover how to configure central access rules and policies and how to apply a central access policy to a folder.)
Cross-Forest Claims-Based Authorization
There are three requirements that need to be in place before claims-based authorization can be used cross forest. For simplicity in this article, I’ll refer to two forests as Forest A and Forest B. The requirements are as follows:
- A trust must be established between Forest A and Forest B.
- The root domain in both forests must be set to the Windows Server 2012 domain functional level.
- Claim transformation policies must be created in both forests.
If a user in Forest A wants to access a resource in Forest B, a claim transformation policy must be created in both forests to process the request. Whereas in intra-forest requests to access data, all claim information is shared for the same forest, that isn’t necessarily the case when a request is sent to a trusted forest. For a claim to be accepted in a trusted forest, it needs to have a recognized name, value, and format.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
This can present various problems, such as claim definitions not matching between the two forests where different attributes are used, or values differ in the same claim type. Organizations may also be reluctant to reveal what AD attribute values are used to store certain types of information, or simply not want to share a particular claim across a trust. And vice-versa, you may not want to accept certain claim information from a trusted forest. Claim transformation polices in both forests contain rules that determine what information is allowed in and out of each forest.
Claim transformation policies
Claim transformation policies are used across inter-forest boundaries and are based on rules that modify user or device claims as they traverse a forest. Claim transformation policies ensure that certain types of information can’t traverse to a trusted forest or accidentally provide a user in a trusted forest with unintentional access to resources across a trust link.
Transformation rules can be used to perform different types of operations on claims to ensure that they will be either accepted or rejected in a trusted forest.
Value-based filtering allows administrators to ensure that domain controllers block claims with specific values received from a trusted forest to prevent potential elevation-of-privilege attacks. Claim type-based filtering identifies claims by name to prevent sensitive information from being sent to a trusted forest. Claim type-based transformation changes the claim type, value, or both, before it is sent to a trusted forest.
Inbound and outbound claims
Claims that enter a forest must be checked carefully as they could compromise security. If there are no transformation policies in place, Active Directory will automatically drop all incoming claims. Additionally, if a transformation rule creates a claim that is not defined in the receiving forest, it is dropped.
Outbound claims don’t present the same risk, and can leave a forest even if there is no transformation policy in place. A claim doesn’t need to be defined in the sending forest, but it must be defined in the receiving forest, or transformed into a claim that is defined.
Create Claim Transformation Policies Using PowerShell
The claims transformation rules language forms the basis for claim transformations. There’s no way to author claims using the GUI or the Active Directory Administrative Center, but Microsoft does provide PowerShell cmdlets for creating rules based on some simple scenarios. Claims transformation policies are automatically created by the cmdlets and stored in AD.
You don’t need to understand the claims transformation rules language yourself to use the PowerShell cmdlets, although it is possible to add a rule using the language and have the cmdlet verify the rule before it gets committed to Active Directory. Whenever possible, it’s best to use the PowerShell commands discussed in this article to define transformation policies, as they will always be validated before being written to Active Directory. If you need to write very complex rules, it’s possible to access Active Directory directly using an LDAP editor.
Create a New Policy
Let’s start by looking at how to create a transformation policy. This process only gets complicated if you want to create specific rules of your own. Otherwise, you can specify an allow all or deny all filter.
Allow all claims across a cross-forest boundary without transformation
Without a simple -allowall rule, all cross-forest claims would be dropped.
new-adclaimtransformpolicy allowallpolicy –allowall
The allowallpolicy above is the simplest policy you can create. Directly after the cmdlet, you can give the policy a name. If you were to write the –allowall rule in the claims transformation language, it would look like this:
C1: => Issue (claim = C1);
The above rule has two parts, a condition statement and an issue statement, separated by =>. The condition statement matches against all claims, and the issue statement allows the claim to pass without any transformation.
If you want to list all the policies in Active Directory, run the following command:
get-adclaimtransformpolicy -filter *
Or if you want information about a specific policy by name:
The -allowallexcept switch and -denyallexcept switches let administrators create more complex policies without using the claims transformation language.
new-adclaimtransformpolicy allowallexceptcompanyanddepartmentpolicy -allowallexcept country,department
In the above command, I’m allowing all claims that don’t use the Country and Department claim types. The rule would be as follows if written in the claims transformation language, where the claim types are identified by ID, which you can find listed in the Active Directory Administrative Center under Claim Types.
C1:[Type !="ad://ext/c:88d06ac5abdb0b36",Type !="ad://ext/department:88d06ac587e96025"]=>Issue(claim=C1);
Apply a Transformation Policy to a Trust Link
Now that we have a simple policy in place, we need to attach it to a link that connects two trusted AD forests. The set-adclaimtransformlink cmdlet can be used to apply a transformation policy to one or more forest trusts as shown below:
set-adclaimtransformlink "ad.contoso.com" -policy allowallpolicy -trustrole trusted set-adclaimtransformlink "ad.contoso.com" -policy allowallpolicy -trustrole trusting
You’ll notice that I’ve run the command twice, once specifying trusted as the –trustrole parameter, and again with trusting. This applies the allowallpolicy to the ad.contoso.com trust link for both incoming and outbound claims.
DAC Complexity and Third-Party Solutions
As you will have probably gathered, DAC implementation can become quite complicated, especially in complex environments that involve multiple forests. There are several ISVs that provide products to help simplify DAC setup and management, such as Quest Security Explorer. If you have anything but the simplest environment to manage, I’d recommend looking at third-party management solutions before jumping in at the deep end.