The Active Directory 2016 PAM Trust: how it works, and why it should come with a safety advisory

We have long been working on increasing security in the design and operations of Active Directory. In each release from Windows Server 2003, 2008 and up to 2012 R2 you can see steps taken: better encryption, additional Kerberos features, deprecation of old protocols, etc. With Windows Server 2016 we have taken a next step, and introduced deep-seated support for privileged access management (PAM). We give the admin the access that he needs, but nothing more. He gets this access when he needs it, but not before or after. With this, the window for a security incident is minimized.

PAM is not a new concept at all. What I'd like to do is to describe what Active Directory for Windows Server 2016 brings to the table to support PAM, how these new features work technically, and to discuss some interesting security consequences. Let me start with describing the new features, as documented here, and then move on to an example.

  1. Temporary Group membership. Using this, you can add a user to a group such as Domain Admins, and have this membership expired by Active Directory itself. This means that if you specify the membership to end by 11:30 PM, the user's Kerberos tickets will expire at that exact moment and can no longer be used to access resources. This powerful security feature is enabled by the underlying technical change: expiring LVR links. Any relationship expressed by an LVR link can now be expired at a predefined time. Another example besides group membership (attributes: member, memberof) would be the relation between a manager and his direct (attributes: manager, directReports).
  2. Shadow Security Principals. A Shadow Security Principal is an object representing a user, group or computer account from another forest. To use such a principal in another forest to access resources, a new type of trust relation is needed: the PAM trust. This is an extension of the well-known forest trust, and requires the trusting Active Directory to run on Windows Server 2016 or higher, or Windows Server 2012 R2 with a required hotfix rollup. Note: Shadow Security Principals are not to be confused with shadow groups, the usual term for groups representing all users in an OU.

Both features require a Forest Functional Level of 2016 or higher in the trusted forest, with the optional feature "Privileged Access Management Feature" enabled. Together, they enhance Privileged Access Management (PAM) implementations. A basic example implementation is provided by Microsoft Identity Manager (MIM) as documented here. Some relevant use cases include a red/blue forest construction, or an admin forest used to manage many resource forests.

Let's work out a simple example with a user forest called sol.local, and an admin forest named andromeda.local. They are joined by a one-way PAM trust, with the admin forest trusted. Conceptually, there could be multiple user forests in this architecture. The goal of this construction is to allow the admin forest to manage the user forest, with some important conditions:

  1. We want to avoid creating new groups or setting extra permissions in the user forest. This used to be a hard problem, because many important groups like Domain Admins are of type Domain Global, meaning that they do not accept users/groups from other domains as members. The PAM trust solves this, and I will explain exactly how it does this.
  2. We really do not want to expose administrative credentials from the admin forest to the user forest. This means: no interactive logon from an admin in the user forest. The PAM trust solves this partially.
  3. We want to minimize admin permissions and access times. This is solved by thinking carefully about group relations, tasks, roles, and giving only access when needed. The last bit is enforced by temporary group membership. Although technically very interesting, this is not something I want to explore further in this article.

So here is the core of the problem: how do I give a user in the admin forest permissions to resources in the user forest without changing groups or permissions? A possible approach is to simulate group membership: we pretend that the admin is a member of Domain Admins in the user forest. How? We must find a way to inject the Security Identifier (SID) for Domain Admins into the admin's token. The Shadow Security Principal feature combined with a PAM trust enables this. Have a look at the diagram below.

We have two forests with a single domain each: the user domain called sol.local, and the admin domain andromeda.local. Each of these domains has its own domain SID, represented for instance as s-1-5-21-{sol}.  There is a one-directional forest trust between the two domains, with andromeda.local trusted. The trust has two non-default settings enabled: the switch enableSidHistory to allow tokens coming from andromeda.local that contain SIDs from sol.local, and the switch enablePimTrust to allow even SIDs from highly privileged SOL groups such as Domain Admins.

The goal of the configuration is to give the admin user called sol-admin the effective group memberships of security principals in sol.local. In this example, the principals are:

  1. test6, a normal user account. Its RID is 14690.
  2. Domain Admins, the well-known group. The RID is 512.
  3. Enterprise Admins, another well-known group with RID 519.
  4. s6, a computer account with RID 16106.

These principals have their SID copied to the andromeda.local domain. Each SID gets is own Security Shadow Object. The object type is "msDs-ShadowPrincipal", and is stored in the Configuration Partition as a child object of CN=Shadow Principal Configuration,CN=Services,DC=andromeda,DC=local. The SID is stored on this object in the attributed named "msDs-ShadowPrincipalSid". The next step is to associate the Shadow Security Principals with the admin user account. This is simply done using the member/memberOf linked attributes, which is exactly the same as a group membership representation. So, the admin user sol-admin becomes member of four Shadow Security Principals, each named for the principal it mirrors from sol.local.

Let's see this theory work in practice. For a nice how-to article look at this blog from my friend Michael Frommhold, who gives it his usual extremely thorough treatment. Note that we did not use Microsoft Identity Manager (MIM): the entire configuration was done with straight-up Powershell. So, I built the environment following the diagram above. Next, I logged on to a DC of the sol.local domain to show that this is possible in the first place (think about it, sol-admin is not an explicit member of Domain Admins but does have the SID in his token), and to demonstrate the groups on his token:

Take a good look: the logged-on user is soladmin, with a SID corresponding to the andromeda domain. It has the usual SIDs belonging to an interactive logon, and it has the additional SIDs for Domain Admins, Enterprise Admins, a computer(!) S6 and a user test6 from domain sol.local. It also gets a number of Domain Local groups that these four principals are member of -- that's how a user gets Domain Local SIDs after a referral token from the trusted domain. So far so good, this is great and very useful functionality when you are creating an admin forest to manage other forests.

This is a seriously cool and powerful feature: I can inject any SID that I need to access resources in a trusting feature. But there is a downside; the security impact is high. From a functional point of view this is almost identical to the (in)famous sidHistory injection attack that was discovered in 2001 and still exists in a number of forms. The trick was to inject the SID for a privileged group like Domain Admins into the sidHistory attribute of a user in the trusted forest by editing the AD database directly. This attack was the very reason why Microsoft declared that the forest is the security boundary, not the domain. It led to a fundamental shift in the way we design forests and domains. But look carefully: the PAM trust is the same thing. On steroids.

Is this a bad security problem then? No. Of course not. The fundamental starting point here is that the admin forest is part of your security boundary, which is the complete opposite of not wanting to trust domains in the same forest. But I want you to be very clear about the extent of this security boundary: anyone with the (delegated) ability to manage Shadow Security Principals in the admin forest has permissions on almost all resources in the user forest, and there is nothing you can do about it. Basically, you have just extended the security boundary of the user forest to include the admin forest. The only thing needed to enable this access is the PAM trust; after you have set this, the admin forest is in control.

This also shows why you need a mature management solution for the admin forest: change and incident management, auditing, PAM workflows, 4-eyes for privileged operations, etc. Don't step into this lightly: give the keys to the kingdom only to the trusted guardians.

Many thanks to Ruud van Velsen, Dirk-Jan van der Vecht and Michael Frommhold for reviewing and improvements!



Comments (20)
  1. Hi Willem,
    Please could you explain the difference between Shadow Security Principals and Foreign Security Principals?

    1. Interesting observation, Luc. You mean that both objects take a SID to represent an object from another forest, correct? This is true, but this is where the similarity stops. An FSP represents a member-of from another forest, enabling a DC from the resource domain to assign the group SID for incoming authentications. Also, it is a system-managed object that requires no manual intervention. In contrast, a SSP represents a member (not member-of) of a group for another forest. Its behavior is close to that of a normal group. Additionally, the SID population is done manually, up to the point that you can actually manufacture any SID you like. So the DC from the account domain takes this SID to pass it along to the trusting domain, who needs to accept this coming from the trusts. This explains that you need to lower the security settings from the trust dramatically: allow sidHistory and PIM.

      1. Thank you Willem for your explanation!
        I think it is worth that once somebody writes a post about Shadow Principals vs Foreign Security Principals 😉

  2. Hi Willem,

    For some time on Microsoft websites and materials we can observe the promotion of the concept ‘red AD forest’ which is very well presented in Your article.
    But from my observations and conversations with other ITPros and Microsoft MVP’s ‘red AD forest’ is utterly pointless idea. Why?
    First of all – If you do not know what it’s all about, it’s about money – No different in this case. Microsoft want sell MIM licenses and of course CAL’s for another AD Forest (not to mention the system licenses) under the cover of increased security.
    Second – What are real pros of ‘red AD forest’?
    1. Just-in-time higher privileges? No – You can have the same effect in one AD forest (powershell scripts, automation, using built-in “Administrator” account etc.), especially with temporary group membership.
    2. Better Accountability of events and privileged access? No – You can have audit enabled and well SIEM, you can buy “Change Auditor”, you can record admin sessions etc.
    3. Less Vulnerabilities? No – You have exactly the same in your current AD forest and you will have the same in your ‘red AD forest’
    4. Lover privileges? No – You (should!) have exactly the same in your current AD forest and you must have the same in your ‘red AD forest’ for administrative purposes.
    5. Shorter Kerberos Ticket Lifetime? No – In your current Active Directory you have Authentication Policies and you should set secure non-renewable Kerberos TGT Lifetime.
    6. Better security for Privileged Access Workstations (PAW)? No – You mustn’t log-in as Domain Admin (Schema Admin, Enterprise Admin as well) onto any other machine than Domain Controllers. Second, you should have another account for administrative purposes like creating AD users, gorups, resetting passwords etc. And third – you should work on Your standard user account as a standard user – without any special privileges, without local admin access and so on. You should work in separated VLAN, behind hardware firewall. You should have actuall antivirus, antimalware and Advanced Threat Protection. Of course, it’s just the basics
    7. Better Security against Pass-The-Hash and Pass-The-Ticket? No – You are exposed to the same attacks.
    8. Better Security on Remote Access? No – again it’s pretty the same. You can (and should!) use Remote Guard, Credential Guard, Code Integrity Policy, Restricted Admin Mode in your current AD forest as well.

    So to sum up – there is no rational reason to build your Active Directory Infrastructure with ‘red AD forest’ because the same (or even better) security level you can easy acheive in your current Active Directory forest.

    And what about confs of ‘red AD forest’?
    1. Price. (CAL’s, licenses for OS’es, another PAW’s, probably another firewalls and network devices).
    2. Single Point of Failure without any access, which is MIM oraz your powershell scripts, automations or other mechanism granting access in production AD forest, in case when it break down.
    3. Uncomfortable administration – you get just one another Wokrstation, credentials (or all of Your IT Department with higher privileges to workstations, users account, resetting passwords will use this model?), you must connect to your production environment in an uncomfortable way and so on… At the end
    4. Waste of your time – you probably spend a long weeks building your ‘red AD forest’ which doesen’t really protect you agains nothing 😉
    5. You still have backdor – “Administrator” account in Your production environment. So, you want tell me that your administrator doesn’t know password to this Account and can’t enable it? Yeah, for sure… 🙂
    6. Delays in case of disaster on your production environment. First continuity of your production, security only later. Never the other way round! Because production earns for business money. If you are 100% secure but you production breaks down you don’t have money. It’s a simple rule often forgotten by ITSecurity…

    And could you defend somehow a position of Microsoft with ‘red AD forest’? Or we can finally assume that this is useless idea? 🙂
    Because if one more IT Security guy which after reading the Microsoft brochure will come up with the idea of implementation ‘red AD forest’… – It will be an exaggeration.

    Do not take this as an attack on your article because it is great, but Microsoft idea is completely unnecessary…

    1. Hi Marcin,

      I think there are two arguments in favor of the red forest. Firstly, it supports the “assume breach” mentality. You can build a red forest from clean, known-good sources in such a way that it is not influence by any compromise in the main forest. The PAM trust especially is helpful in this. Specifically, you say: “Better Security against Pass-The-Hash and Pass-The-Ticket? No – You are exposed to the same attacks.”. Especially for T0 you can do without interactive or service logon, meaning no PtH and limited PtT. For T1 this is harder, I admit.

      Secondly, the red forest can double as an admin forest for those companies that want to manage multiple forests from one central forest. And personally, this is what I foresee as the main usage for PAM trust and Shadow Security Principals.

      1. Hi Willem,

        you write – “can build a red forest from clean, known-good sources in such a way that it is not influence by any compromise in the main forest”, so you want tell me that in current AD forest You can’t biuld good security, you doesn’t know sources, dependencies, but in new AD forest you can? Really? No – If you can’t do it now, you will not be able to do it in the future. Such is the truth. There is no really such thing you couldn’t build in the current AD forest (secure AD forest).
        T0 without interactive or service logon? Windows Updates, promoting new Domain Controller, restoring AD database, extending Schema, installing Exchange Organization and so on…? Maybe it is possible, but it is must be unimaginably hard in day-to-day administration, where losing anytime is a waste of money. And again – There is no such thing you couldn’t build in the current AD forest. There are exactly the same limitations and the same security practices.
        Daily Active Directory administration isn’t only creating new AD Objects and changing group memberships, especially in Enterprise.
        Unfortunately, it is often forgotten about the role Exchange Organization Administrators, and for example you want installing all new Cumultavie Updates on all Exchange servers in Your organization from PAW without interactive logon? (and with .Net conflicts) – Try it… 😉

        In multi AD forest environment OK – it could make sense, but I would be happy if someone from Microsoft finally wrote officially that the red AD forest concept makes no sense in the one AD forest environment. Only so much and so much.
        Thank you in advance. And I hope that you will end up writing this 🙂

        1. Andreas says:

          You miss the point regarding ‘the “assume breach” mentality’. You don’t _know_ that no breach has occurred in your 12 year old domain. You can however with some certainty assume that the new forest you install, configure and harden has not yet been breached, thus making it more trustworthy.

          “so you want tell me that in current AD forest You can’t biuld good security, you doesn’t know sources, dependencies, but in new AD forest you can? ”

          Yes. This is exactly what he’s saying.

          1. Ross says:

            Ok, let’s imagine existing environment is compromised. You have to do a cleanup and reviews to make sure that only accounts with business need privileges that are in concern. If you then decide to make a Red Forest – how in a world is it going to help? If the breach exists and will sustain a cleanup – it will still exist in a production forest, no matter what you do with the Red one.

            So I tend to agree with Marcin, that the security value of this solution is yet to be determined.

  3. Fredrik J says:

    It the PAM-trust really a new kind of trust or is it just a one way forest trust with PIM and SIDHistory enabled? Reason I ask is because the New-PAMTrust cmd-lets is part of MIM2016 and not part of the optional AD feature “Privileged Access Management Feature” and I don’t plan to use MIM integration.

    Also could you elaborate on how you provisioned the SSPs in the priv forest in your examle using PowerShell with no MIM-integration.

    1. Hi Fredrik,

      Yes, its a new type of trust. The new part is that allows the SIDs of builtin groups such as Domain Admins to pass the trust. Other trust types won’t do this, even with sidhistory filtering disabled.

      > Also could you elaborate on how you provisioned the SSPs in the priv forest in your examle using PowerShell


      $prodDomain = "sol.local"
      $prodGroupName = "Enterprise Admins"
      $shadowGroupName = "SOL-EA"
      $shadowUserName = "soladmin"

      # get prod group and SID
      $targetDC = (Get-ADDomainController -DomainName $prodDomain -Service PrimaryDC -Discover:$true).hostname[0]
      $prodGroup = Get-ADGroup -Server $targetDC -Identity $prodGroupName
      $prodGroupSid = $prodGroup.sid

      # create shadow object with prod group SID
      $shadowContainer = "CN=Shadow Principal Configuration,CN=Services,$((get-adrootdse).configurationNamingContext)"
      New-ADObject -Name $shadowGroupName -Path $shadowContainer -Type 'msDs-ShadowPrincipal' -OtherAttributes @{ 'msDs-ShadowPrincipalSid' = $prodGroupSid }

      # assign admin user to shadow object. This user will have the prod group SID in his token.
      $shadowUser = Get-ADUser -Identity $shadowUserName
      $shadowGroup = Get-ADObject -Filter { name -eq $shadowGroupName } -SearchBase $shadowContainer
      Set-ADObject $shadowGroup -Add @{ member = $shadowUser.DistinguishedName }

      1. Andreas says:

        No, it’s not a new trust as such, is it? It’s just configuring a one way incoming forest trust (New-PamTrust), then New-PamDomainConfiguration configures the trust flags using netdom with /EnablePimTrust, /EnableSIDHistory and /Quarantine. Right?

        1. Hi Andreas, you’re right of course: technically it’s new functionality on an existing type of trust, in this case a forest trust supporting Kerberos. But from a functional perspective the PAM trust is different: it is dedicated to PAM scenario’s, and not intended for anything else. Compare knives vs. surgical knives.

  4. Auro_vg says:

    can we add Child domain’s DA in msDS-ShadowPrincipalSid, in the context of forest child domain scenario? (Is it a limitation / not allowed?)

    1. Hi Auro_vg,

      So you discovered that it doesn’t work, correct? Yes, we are sort-of aware of it. Reports are trickling in, and we have a partial workaround. But that’s about all I can say right now. However, it seems likely that this limitation is not by design. If you are a Premier customer you can help by logging a case which helps building the business case for any follow-up action we might need.

  5. Ross_1 says:

    Willem, thank you very much for this article. It was incredibly difficult to find an article on how PAM works and this is by chance how I found this one.

    Our customer wants to implement the Red Forest, but I have similar concerns to what Marcin has brought up already.

    Can you suggest 1 or 2 case scenarios of breach / break-in attempt, which would fail in the environment with properly implemented PAM Forest, but would be a successful intrusion in case of a single production forest scenario with additional hardening and tier model?

    And if I may, a bit of relevant complaints. Recently we had to update Azure AD Sync and we have come across the following issues:
    – It needs to run with account from Forest root domain, new feature apparently.
    – Access to database must be given directly. When given through the group, setup fails to validate access.

    It is impossible to delegate installation and configuration of Azure AD Sync server to a person without Enterprise Admins rights, which is so frustrating. And this is why I don’t think that PAM solution can be effective in the real world.

    1. Hi Ross,

      The RED forest has a very specific purpose: it gets your Tier-0 admins in the clear when you “assume breach” for the blue forest. Even then, you must have a full tiering structure in place in the BLUE forest to stop credential leak. There is little value in having a RED forest when your BLUE is still a mess.

      Suppose BLUE is compromized with a golden ticket, and the adversary sits there waiting on a BLUE DC until you pass by and drop your hash with an interactive logon. With a RED account behind a PAM trust you avoid this and can administer the DC with nothing more than service tickets, limiting exposure to silver ticket attacks (and similar) instead of fullblown PtH.

      In your AAD Connect example: in the tiering model there is no difference for Tier-0 between domains in the same forest. Same Tier, same people. Yes, that proably means that you need to re-think the administration of your forest. Nobody said that this was easy.

      1. Willem,
        First of all – You cannot just “move” all Administrators into red forest, it always will stay accounts like built-in “Administrator” or DSRM which you can use.
        Red forest doesn’t fix production AD security issues like too high permissions, delegations, vulnerability and so one – they will still remain in production AD unitl you just clen up!
        Red forest doesn’t resole expansive rights on workstations and servers in production AD – maybe the same local-Admin passowrds in whole AD…
        Red forest doesn’t resolve security issues with production service account, inproper delegations, weak passwords, SPNs etc.
        Finally Red forest doesn’t resolve security issues with agents running on Domain Controllers (monitoring, patch management, event-collectors, BACKUP!, anivirus) – each of that can be used to get control over production AD without using “red forest” 🙂

        With mess in production AD even Service Ticket can compromise production Environment ( Kerberoasting attack with offline password cracking).
        So I am still convinced that the time and money should be invested to clean up and protect production AD and not wasting it to utopian ideas like “Red forest”

        1. Hi Marcin,

          I don’t think I said that the Red Forest concept will bring world peace. It is absolutely true that it make most sense only after you have done the cleanup work. But I think you are doing the concept an injustice when you call it “utiopian”. Let me give you two examples. Firstly, it is used in “recapture the flag” scenarios where you have to start from a known-good, uncompromised environment. Secondly, because a Red Forest implementation is hard, time consuming and expensive you need serious management buy-in to pull it off. And that attention in itself is critical to improve security throughout the AD environment, probably after years of neglect. Thanks for your comment.

          1. Willem,
            the main problem is that almost nobody of ITSec’s, auditors and security advisors at enterprises isn’t interested to make celan-up and really secure Active Directory. There are in most cases people who just read articles like yours about Admin forests and return to the company with recomendations for implementation MIM, Admin forests and other stuff for milions of dollars, which paralyze the work of Admins without any security improvement.

            Because purchase of MIM and implementation for only Administrators is relative cheap and fast for enterprises in relation to a comprehensive security approach in whole organization. Unfortunately whole conception of Admin forest ends at that stage without production Active Directory celan-up and any really security improvement. What’s worse after Admin forest implementation company is proud that is compliant with the Microsoft recommendations… That`s why I think it’s utopian and it’s a pity that Microsoft is not putting pressure on cleaning AD, securing production AD and instead promotes MIM under the cover of security at Admin forest.

            Personally I think that if someone can do a really AD clean-up in terms of security – it will not need Admin forest, because can just do a new secure AD forest and re-create or migrate resources into it. On the other hand if someone cannot do that at production AD, Admin forest will not help him and production infrastructure can be still easy compromised.
            Also thank for your comment.

Comments are closed.

Skip to main content