Share via

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

  • Article

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

  • Anonymous
    June 19, 2017
    Hi Willem,Please could you explain the difference between Shadow Security Principals and Foreign Security Principals?
    • Anonymous
      June 20, 2017
      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.
      • Anonymous
        June 20, 2017
        Thank you Willem for your explanation!I think it is worth that once somebody writes a post about Shadow Principals vs Foreign Security Principals ;-)
  • Anonymous
    June 29, 2017
    The comment has been removed
    • Anonymous
      June 30, 2017
      The comment has been removed
      • Anonymous
        July 03, 2017
        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 :)
        • Anonymous
          January 22, 2018
          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.
          • Anonymous
            September 10, 2018
            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.
  • Anonymous
    January 08, 2018
    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.
    • Anonymous
      January 20, 2018
      The comment has been removed
      • Anonymous
        January 22, 2018
        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?
        • Anonymous
          January 25, 2018
          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.
  • Anonymous
    January 28, 2018
    The comment has been removed
    • Anonymous
      January 29, 2018
      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.
    • Anonymous
      January 29, 2018
      The workaround is here: check the last, updated, bit of the post: https://blogs.technet.microsoft.com/fieldcoding/2017/05/09/privileged-access-management-demystified/
  • Anonymous
    September 10, 2018
    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.
    • Anonymous
      September 10, 2018
      The comment has been removed
      • Anonymous
        November 05, 2018
        The comment has been removed
        • Anonymous
          November 05, 2018
          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.
          • Anonymous
            November 06, 2018
            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. Why?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.