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 (6)

  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 🙂

Skip to main content