Introduction
Privileged Access Management (PAM) is a security model aimed at reducing the risks associated with high-privilege accounts in enterprise environments, especially those running Active Directory. Rather than giving administrators constant, standing access to critical systems and groups like Domain Admins, PAM enables temporary, auditable, and time-bound access.
Microsoft provides a native implementation of PAM through Microsoft Identity Manager (MIM). This solution is designed to integrate directly into the Windows ecosystem, using components such as a bastion forest, shadow principals, and SIDHistory to manage and control privileged access.
This article breaks down, in detail, the mechanics, components, and technical underpinnings of PAM using MIM, no hand-waving, just real, actionable understanding.
Bastion Forest: The Isolated Control Plane
At the heart of Microsoft’s PAM model is the concept of a bastion forest, sometimes referred to as a Red Forest. This is a dedicated Active Directory forest used solely to manage privileged access. It is isolated from the production environment and protected with stricter policies, logging, and access controls.
A one-way selective authentication trust is established from the bastion forest to the production forest. This means accounts in the bastion forest can authenticate to the production forest, but not the other way around. The selective authentication flag ensures that users must be explicitly allowed to authenticate to specific resources.
This trust is configured using the Trust Attributes in AD, including TRUST_ATTRIBUTE_CROSS_ORGANIZATION, which allows cross-forest authentication, and TRUST_ATTRIBUTE_FOREST_TRANSITIVE, which makes the trust transitive across forests. The selective authentication setting denies authentication to all by default unless AllowedToAuthenticateTo permissions are explicitly configured on the resource.
This trust setup is the foundation of PAM’s isolation and control model.
Shadow Principals and SIDHistory Mapping
Instead of assigning privileges directly to production accounts, PAM uses what are called shadow principals. These are user accounts in the bastion forest that mirror users from the production forest.
These accounts do not carry any rights on their own. Instead, they are granted a SIDHistory attribute that contains the Security Identifier of a privileged group in the production domain, for example, the SID of the Domain Admins group.
The SIDHistory attribute in Active Directory is normally used to maintain access across domain migrations. However, in PAM, it’s used as a mechanism of privilege inheritance. When a shadow principal authenticates, and the production domain sees that its SIDHistory contains the SID of a privileged group, it grants access accordingly, even though the user is not a direct member of that group.
This is both powerful and dangerous: if attackers manage to write arbitrary SIDs to SIDHistory, they can impersonate high-privilege accounts. This is why controlling write permissions to the SIDHistory attribute is absolutely critical.
Role Requests and the MIM Portal
Users who need temporary elevated access do not directly log in as privileged users. Instead, they use the MIM PAM portal to request access to specific roles. These roles are mapped to Active Directory groups, such as Backup Operators, Server Admins, or Domain Admins.
Each request includes metadata such as the user requesting elevation, the target role, a business justification, and the requested duration. MIM uses internal workflows to route this request for approval. Approval policies can include multi-factor authentication, manual review, or integration with ticketing systems like ServiceNow.
Once approved, the system updates the shadow principal account with a reference to the necessary group SID via the SIDHistory attribute and sets the TTL (Time-To-Live) on the Kerberos ticket to define how long access is granted.
Time-Limited Group Membership and Kerberos TTL
One of the core mechanisms that enables time-bound access is Kerberos ticket TTL. When a user is granted access, MIM issues a Kerberos ticket that includes a PAC (Privilege Attribute Certificate) listing group memberships, a logon session time, and a TTL flag indicating when the session should expire.
This TTL is enforced using the msDS-Entry-Time-To-Die attribute, which is part of the msDS-GroupManagedServiceAccount object or user ticket policy. Additionally, Kerberos Armoring, also known as FAST (Flexible Authentication Secure Tunneling), may be used to protect the ticket request from tampering and replay attacks.
Key Kerberos flags involved include forwardable, which defines whether the ticket can be forwarded, typically set to true. The renewable flag should be disabled for PAM sessions to prevent reuse beyond the authorized window. Finally, the ok-as-delegate flag determines whether the ticket is valid for delegation scenarios, which could pose risk in privileged contexts if enabled.
SID Filtering and SIDHistory Protections
To prevent misuse of SIDHistory, Active Directory includes several protections such as SID Filtering. This mechanism examines the SIDs in the SIDHistory attribute and removes any that are deemed invalid or originating from untrusted domains.
In PAM scenarios, this filtering is selectively disabled for the trust between the bastion and production forests. This allows the shadow principal’s SIDHistory to be honored, but only across this tightly controlled and explicitly configured trust.
Critical trust flags influencing this behavior include SID Filtering Quarantined, which is enabled by default to block external SIDs. The Enable SIDHistory option must be manually configured to allow SIDHistory mapping between the forests. The TreatAsExternal flag causes the trust to behave as if it were external, impacting how SID filtering is enforced.
If these flags are misconfigured, PAM may either fail to function or open serious security vulnerabilities, especially if SIDHistory injection becomes possible.
Authentication and Authorization Workflow
Here’s how the full flow typically works in practice. A standard user in the production domain requests access to a privileged role via the MIM portal. Upon approval, MIM updates a shadow principal account in the bastion forest. This shadow account is then assigned a SIDHistory containing the SID of a privileged group from the production forest. The user logs into a resource using the shadow account, and Kerberos issues a ticket containing both their actual SID and the SIDHistory. The production domain receives this ticket, checks the SIDHistory, and authorizes access as if the user were a member of the privileged group. Once the TTL expires, the shadow principal is stripped of elevated capabilities, and access is revoked. All of this is logged and auditable, ensuring transparency and control.
Creating the PAM Trust Between Forests
Before the PAM architecture can function properly, it is critical to establish a secure trust relationship between the bastion forest and the production forest. In Microsoft’s implementation of PAM, this relationship is configured as a one-way, forest-level trust with selective authentication enabled. This trust allows accounts in the bastion forest to authenticate into the production forest, but not the other way around, thereby enforcing a strict separation of privilege and reducing lateral movement risk. The concept is simple: the bastion forest is where privileged identities live and are tightly controlled; the production forest is where resources reside. The trust is necessary so that the bastion identities can temporarily act with elevated privileges in production.
To configure this trust using PowerShell, one would typically run the New-ADTrust command from a domain controller within the bastion forest. The command might look like this: New-ADTrust -Name "prod.local" -TargetName "prod.local" -TrustType Forest -Direction Outbound -TrustAttributes 8 -AuthenticationType Negotiate. Let’s break this down. The -Name and -TargetName specify the DNS name of the production forest. The -TrustType being set to Forest indicates this is a forest-level trust, which is required for Kerberos authentication and SIDHistory to function properly across forests. The -Direction set to Outbound means that the bastion forest trusts the production forest, this is the essence of the PAM model. The -TrustAttributes 8 is the numeric representation for Selective Authentication, which is crucial for PAM. This ensures that no account from the bastion forest can authenticate to any system in the production forest unless explicitly allowed via the AllowedToAuthenticateTo permission on the target computer or resource.
The -AuthenticationType parameter, often set to Negotiate or Kerberos, defines how authentication traffic will be handled. Using Kerberos ensures secure ticket-based authentication and compatibility with SIDHistory validation. After this trust is created, an administrator must go into Active Directory Domains and Trusts on both forests and validate the trust. It’s also important to go to the Trust Properties, under the Authentication tab, and select “Selective Authentication” explicitly. This ensures that only approved shadow principals from the bastion forest can reach production resources.
Once the trust is created, SID filtering must be configured properly. On the production forest side, SID Filtering Quarantined should be disabled for this specific trust to allow SIDHistory to pass through. This is typically done via the netdom command or GUI under trust properties, and it must be handled with extreme care. If filtering is disabled globally or across inappropriate trusts, attackers could abuse SIDHistory to escalate privileges. Done correctly, however, this step enables the SIDHistory from the bastion’s shadow principals to be interpreted as legitimate membership in production domain groups, enabling the PAM system to function as designed.
Conclusion
Microsoft’s PAM architecture using MIM is one of the most powerful native tools available for managing privileged access in AD environments. It requires a deep understanding of Active Directory, Kerberos, SIDHistory, and trust configurations to implement securely.
When done right, it dramatically reduces the risk surface. When done wrong, it creates a single point of failure that, if compromised, can lead to full domain dominance.
Always follow the principles of least privilege, explicit trust, defense in depth, and auditing everything. In future articles, we’ll explore common PAM abuses, including how attackers may forge SIDHistory, bypass TTL constraints, or exploit misconfigured trusts to gain permanent access.
