14 Aug ESAE series part 3 – Privileged access management & the shadow principal feature
As already announced in the last article (LINK) of the ESAE series, in this article we would like to give you a more in-depth description of the technical core of the ESAE-oriented environment which makes the just-in-time administration possible. This core consists of the shadow principals, temporary group memberships and the new Microsoft Identity Manager (MIM) module ‘Privileged Access Management (PAM)’.
Conceptual functionality
Firstly, we’d like to briefly describe how temporary group memberships and shadow principals Work on their own before we explain the interaction with MIM in more detail.
Temporary group memberships
Temporary group memberships are part of the optional AD feature ‘Privileged Access Management’ of Windows 2016. As the name implies, it allows for user accounts to only be members of a group for a limited time.
The Active Directory ensures that the group membership expires at exactly the requested time by setting the Kerberos Ticket Granting Ticket (TGT) lifetime to the same runtime as the shortest time to live (ttl) of a group membership.
An example: at log-in, user René has a remaining time of 5 minutes in the Domain Administrators group and a remaining time of 10 minutes in the Enterprise Administrators group. The domain controller then issues a TGT with a runtime of 5 minutes.
Temporary group memberships could also be used independently, without shadow principals and MIM-PAM and configured via PowerShell (see below).
Shadow principals
A shadow principal is an object that represents a user, group, or computer account from another forest. The shadow principals are also part of the PAM feature. In order to use a shadow principal for the access of resources, a new kind of trust is required: the PAM trust. The PAM trust is an extension of the well-known forest trust.
In order to be able to use the shadow principals for our purposes, a so-called admin forest (or red forest) is set up in addition to the production forest and a PAM trust is established. The production forest trusts the admin forest.
Shadow principals can subsequently be created in the admin forest which contain the SID of groups, e.g. the Domain Administrators group, in the production forest. In the next step, users in the admin forest are added to the ‘memberof’ attribute of the shadow principals. If the user of the admin forest from the example then logs in to a resource in the production forest, he or she carries the SID of the domain admin group along with the ticket and is able to perform respective privileged activities such as DCPromo, scheme extensions, etc.
Shadow principals can also be used without temporary group memberships and MIM-PAM and can be configured via PowerShell.
MIM-PAM
Bearing in mind that you can receive privileges in the production forest through the shadow principals without having a user account in this forest, there are some advantages. For example, there is no way for tools like Bloodhound to identify users with these rights. However, this technique also poses dangers. With Active Directory tools, it is very difficult to monitor who used the elevated rights and when. This is where the MIM with PAM functionality comes into play to bring together the other two technologies for just-in-time administration with appropriate governance.
When MIM-PAM is implemented, no user account in the admin forest is a member of a shadow principal per se. Via MIM-PAM, roles are defined which regulate who can request which privileges and for how long. An approval workflow can also be defined.
As an example, there might be a role called ‘domain admin’ which adds users to the shadow principal ‘domain administrators’. The role may be requested by users Fabian and Manuel between 8am and 4pm. User Alexander has to approve the request. The role has a runtime of 60 minutes.
The roles can be requested either via PowerShell or via an optional portal. The request and assignment of the roles will be logged accordingly.
Technical functionality
Temporary group memberships
For temporary group memberships, the optional feature ‘Privileged Access Management’ must be activated, as mentioned above. For this, the Forest Functional Level has to be at least 2016.
The feature can be activated using the following command:
Enable-ADOptionalFeature ‘Privileged Access Management Feature’-Scope ForestorconfigurationSet -Target corp.customer.de
Subsequently, we can add a user to a group for a limited time:
Add-ADGroupMember -Identity ‘Domain Admins’ -Members ‘Rene’ -MemberTimeToLive (New-TimeSpan -Days 5)
In order to display the TTL of group memberships, the following command can be used: Get-ADGroup ‘Domain Admins’ -Property member -ShowMemberTimeToLive
Shadow principals
Here, too, the optional feature ‘Privileged Access Management’ has to be activated.
Enable-ADOptionalFeature ‘Privileged Access Management Feature’-Scope ForestorconfigurationSet -Target red.customer.local
The trusting production forest must also have Forest Functional Level 2016 or Windows Server 2012R2 with the patch KB3156418 (https://support.microsoft.com/en-us/help/3156418/may-2016-update-rollup-for-windows-rt-8-1-windows-8-1-and-windows-serv ).
After activating the feature, there are some relevant objects and classes:
msDS-ShadowPrincipalContainer:
In this container, all shadow principals are stored. The default container is created here:
CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=customer,DC=de
In principle, further containers can be created, but these then do not function with Kerberos.
msDS-ShadowPrincipal:
This class represents an object from an external forest. Objects of this class can only be created in a shadow principal container and the attribute msDS-ShadowPrincipalSid must have a value.
A shadow principal can represent any user, security group, or computer. As with temporary groups, you can set a time to live for the member attribute.
When the shadow principal is created in the default container CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=customer,DC=de, the membership of a user in this shadow principal will be inserted into the Kerberos ticket, just like with any other group membership. However, the restriction applies that only users of the same forest can be members of a shadow principal.
msDS-ShadowPrincipalSid:
This attribute contains the SID of the object from the external forest. You cannot add a SID from the same domain or the same forest. Naturally, the respective trust has to exist in order to add the SID.
Usage of the shadow principals
Before the shadow principals can be used appropriately, a respective trust has to be created first (prerequisite: name resolution between the forests has to work). The trust attributes ‘SIDHistory’ has to be configured to ‘Yes’ and ‘Quarantine’ to ‘No’:
The following commands must be executed in the productive domain:
netdom trust corp.customer.de /Domain:red.customer.local /Add /UserD:administrator@red.customer.local /PasswordD:* /UserO:administrator@corp.customer.de /PasswordO:*
netdom trust corp.customer.de /domain:red.customer.local /ForestTRANsitive:Yes
netdom trust corp.customer.de /domain:red.customer.local /EnableSIDHistory:Yes
netdom trust corp.customer.de /domain: red.customer.local /EnablePIMTrust:Yes
netdom trust corp.customer.de /domain: red.customer.local /Quarantine:No
In the red forest, the following command is to be executed:
netdom trust red.customer.local /domain:corp.customer.de /ForestTRANsitive:Yes
Subsequently, the shadow principals can be used via PowerShell, as seen in the following example.
Using the following commands, a shadow principal for the domain admin group from the production forest is created:
$CORPPrincipal = “Domain Admins”
$CorpDC = “corpdc02.corp.customer.de”
$ShadowSuffix = “CORP-”
$CorpShadowPrincipal = Get-ADGroup -Identity $CORPPrincipal -Properties ObjectSID, SamAccountName -Server $CorpDC
$ShadowPrincipalContainer = “CN=Shadow Principal Configuration,CN=Services,”+(Get-ADRootDSE).configurationNamingContext
New-ADObject -Type “msDS-ShadowPrincipal” -Name “$ShadowSuffix$($CorpShadowPrincipal.SamAccountName)” -Path $ShadowPrincipalContainer -OtherAttributes @{‘msDS-ShadowPrincipalSid’= $CorpShadowPrincipal.ObjectSID}
We can now add a user from the admin forest to the member attribute and give them temporary rights in the production forest, if desired:
Set-ADObject -Identity “CN=CORP-Domain Admins, CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=red,DC=customer,DC=local” -Add @{‘member’=”<TTL=3600, CN=Manuel,CN=Users,DC=red,DC=customer,DC=local>”}
MIM-PAM
The depiction of the installation of MIM-PAM would go beyond the scope of the article which is why we only refer to the documentation by Microsoft at this point (https://docs.microsoft.com/de-de/microsoft-identity-manager/pam/configuring-mim-environment-for-pam).
However, we would like to show you how to create and request roles, as well as demonstrate the log entries mentioned above.
Firstly, add the user to PAM:
$user = New-PAMUser -PrivOnly -SourceDomain red.customer.local -SourceAccountName “Manuel”
$user
Then, add the group to PAM:
$cred = Get-Credential
$group = New-PAMGroup -SourceGroupName “Server Admins” -SourceDomain corp.customer.de -SourceDC corpdc02.corp.customer.de -Credentials $cred
Finally, define the new role:
$role = New-PAMRole -DisplayName “CorpAdmins” -TTL 00:03:00 $group -Candidates $user
Now, the user can request the role as follows:
New-PAMRequest -RoleDisplayName “CorpAdmins”
However, the rights can also be restored prematurely as follows:
Close-PAMRequest -RoleDisplayName “CorpAdmins”
If a user requests the role, but isn’t authorised to, the following, somewhat misleading, error message is received:
In conclusion, you could say that with shadow principals, Microsoft has given us a powerful tool to make credential theft attacks more difficult, but that the red forest needs special protection for misuse to be prevented. In the next article, we would like to describe what we have done to achieve this in a specific customer scenario.
Special thanks goes to Holger for the MIM-PAM screenshots :-).
Below are some sources and follow-up links:
https://secureidentity.se/msds-shadowprincipal/
https://blogs.technet.microsoft.com/fieldcoding/2017/05/09/privileged-access-management-demystified/
https://docs.microsoft.com/en-us/powershell/module/mimpam/?view=idm-ps-2016sp1
Source: freepik.com
LATEST POSTS
-
(E) SAE DEEP DIVE SERIE Part 2 – Secured VMs in an ESAE environment with VMWare
In our January blog, we started an SAE deep dive series and explained how to use Hyper-V as a secure hypervisor in an (E)SAE scenario. Since by far not all our customers use Hyper-V, but many also use VMWare...
15 June, 2020 -
(E) SAE Deep Dive Series Part 1: Hyper-V Host Guardian Service (HGS) and Shielded VMs in an EASE Environment
After the success of the first ESAE series, we decided to launch a deep dive series in which we go into a little more detail on various measures....
16 January, 2020 -
(E) SAE DEEP DIVE SERIES Part 3 – Separate admin accounts
After Hyper-V HGS and VM protection with VMWare, now the third part of our (E) SAE Deep Dive Series follows. Maybe you follow us on LinkedIn, Xing, Facebook, Instagram or Twitter and ...
15 July, 2020
