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

  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 😉

Skip to main content