This is a follow-up chapter to The Other Book: Authentication Policies. If you’re not sure you understand all the concepts around Authentication Policies, Silos and Claims and how to apply them, please read that chapter first. In this chapter we will look at how to utilize claims if authentication and access happen over a forest trust. In particular, we’ll be looking at the following scenarios:
- A user logs on interactively to a device in another forest to access resources in that forest
- A user logs on interactively to a device in their own forest to access resources in another forest
Of course, there is always that super generalized scenario where a user from one forest logs on to a device in another forest, only to access resources in a third forest, but you will be well-equipped to harden that one as well once we’re done with the first two.
NOTE: Wherever you find me using “Red Forest” and “Golden Forest” in this chapter, I will be referring to a pair of forests with a unidirectional trust between them (Golden trusts Red but not the other way around). Some scenarios only apply to bidirectionally trusting forest pairs, in which case I will just use “trusting” and “trusted” to designate in which direction the authentication happens in a particular case.
Where are the policies defined?
A policy that governs ticket issuance for a principal must be linked to that principal – this was the case within one forest and is still the case in cross-forest authentication flows. So the policy that governs TGT for a particular user has to be created in that user’s forest. However, the conditions within the policy rely on information provided by the forest where the other parts of the authentication/authorization flow reside. Especially in Red Forest/Golden Forest scenarios this is something to keep in mind – an attacker with sufficient permissions within the Golden Forest may be able to modify the claims your Red Forest policy relies on to allow or deny ticket issuance!
Scenario 1: Red Forest user accesses Golden Forest
Policies that only rely on information from the Red Forest itself will work over the trust just like they did within the forest – an authentication-denying policy based on a nonexistent silo will not allow logon to a foreign device either, an unconditional policy that just sets the TGT lifetime to a different value will happily do it for a logon session initiated from the Golden Forest, and so on. But what if we want to restrict the Golden Forest devices a certain Red Forest user is allowed to log on to?
Device restrictions in the user policy are not going to work
At least not in a uni-directional trust! Remember, in the previous chapter we said the AuthN Policies work with claims? Well, claims only ever get passed in the direction of a trust but not the other way around. And the KDC needs all the information to make a policy evaluation decision.
The implication of this for the privileged administration design is, by the way, to keep Tier 0 PAWs – and Tier 0 jumphosts, if any – strictly in the Red Forest. For the rare cases an admin has to log on interactively to Tier 0 systems in the Golden Forest, use a different account without device restrictions and roll its password after use. Or, better still, use a Smart Card, then you don’t have to worry as much about credential compromise.
User/Group restrictions in the device policy work as expected
If you are trying to restrict who can log on to a certain device on the Golden Forest side, by adding user or group filters to the ComputerAllowedToAuthenticateTo attribute, all scenarios will work as expected:
- Red Forest user added explicitly to a “MemberOfAny” or “MemberOfAll” clause
- a Domain Local group from the Golden Forest containing the Red Forest user added to a member clause
- a Universal group from the Red Forest containing the Red Forest user added to a member clause
For these member clauses, you can mix and match principals from both forests as you like it! But what about other claims?
Claims in cross-forest AuthN/AuthZ flows
Within one forest, claims are created when a principal authenticates and passed to everyone who may need them (claims were created primarily for Dynamic Access Control, i.e. authorization, rather than for supporting authentication decisions!). When passing authentication over a forest trusts, both the trusting and the trusted forest can control what happens to the claims (except, as we saw earlier, those that represent a principal’s identity or groups it is a member of). The mechanism in AD that supports that are “Claim Transform Policies”. A policy must be explicitly linked to a particular trust, and the linking also includes the designation of whether the policy is to be applied to outgoing claims (that would be in the trusted forest) or to incoming claims (in the trusting forest). Only one incoming and only one outgoing transformation policy can be linked to a trust object at any given time.
By default, i.e. if no policy is linked to a trust,
the trusted forest will PASS ALL CLAIMS over the trust,
but the trusting forest will DROP ALL INCOMING CLAIMS.
To enable claims across forests, we therefore need to create and link at least one policy. In the simplest case, this policy will just pass any incoming claims from the trusted forest. Claim transform policies do not have any visual representation in ADAC or elsewhere, but they do come with PowerShell cmdlets. Let’s get to work!
Passing all claims over the trust
To create the simplest of all possible claim transports, just run the two commands in the trusting, or Golden, forest:
New-ADClaimTransformPolicy -AllowAll -Name "AllowAllOverTrust"
Set-ADClaimTransformLink -Identity "trusted.domain" -Policy "AllowAllOverTrust" -TrustRole TrustingThe first command creates an object of the type msDS-ClaimsTransformationPolicyType in the CN=Claims Transformation Policies,CN=Claims Configuration,CN=Services, CN=Configuration container. The actual transform rule is stored in the msDS-TransformationRules attribute as XML:
<ClaimsTransformationPolicy>
<Rules version="1">
<![CDATA[C1:[]=>Issue(claim=C1);]]>
</Rules>
</ClaimsTransformationPolicy>The second command populates the msDS-IngressClaimsTransformationPolicy attribute of the trustedDomain object (in the trusting forest’s root domain!) with the DN of the policy, Once these changes have replicated, next time a Red Forest user logs on to a Golden Forest machine, the claims passed from the Red Forest over the trust arrive in the user’s session:
However, if we look at the same user’s claims in its home forest, we will realize that not all claims have arrived:
The reason for this is that the claim with the ID department-OrgWide is not defined in the Golden Forest! The ID can be specified both in PowerShell and in ADAC, but only at creation time:
Primitive policy rules you can deploy without digging into the rule language include AllowAll, DenyAll, AllowAllExcept (list of claim names) and DenyAllExcept (list of claim names). But the transform rules are way more powerful than just filtering, For example, if the same attribute has different nomenclatures in different forests, you can have transform rules translate the outgoing values into the correct incoming ones – on either side of the trust. The transform rule language has been adapted from ADFS and is documented here: https://learn.microsoft.com/en-us/windows-server/identity/solution-guides/claims-transformation-rules-language.
Scenario 2: Cross-Forest access over a bi-directional trust
If you have a bi-directional trust in place AND configure the outgoing claims transform policy on each side of the trust to let the claims out, you can operate your AuthN Policy framework pretty much like you would within one forest. The policy applied to the user and the one applied to device or service will still reside in different forests, and the claims supplied by the user and the device will ALSO come from their respective forest, but that’s the risk you are going to have to take.
You can work with claim transform rules to only allow certain claims to pass through the trust, and only if they have certain values (the claim transform rules are very powerful!), but ultimately it’s up to the forest’s administrators to decide what claims they will send over which trust and what values those claims will bear.
If you absolutely want to govern interactive logon restrictions for a certain user from within that user’s forest, a bi-directional trust offers you one additional capability you wouldn’t get in a Red Forest/Golden Forest scenario. Create a Domain Local group in the user’s forest, add the allowed devices from any trusted forests to it, and filter the user’s TGT issuance by membership in that group. This way, all control is exerted from within the user’s own forest!
Happy Hardening!