Privileged Access Management in Windows 2016 Active Directory

So this PAM (Privileged Access Management) stuff is something I thought I need to write it in English since there is not so much information about it. This feature is something that Microsoft is making a big fuss on how to use it with MIM (Microsoft Identity Manager) but not on how to leverage at least part of it if you don’t have MIM.

Some info on this new technology is here:

https://technet.microsoft.com/en-us/library/dn903243.aspx

And from this link let’s look a little bit at the problems PAM is trying to solve:

A real concern for enterprises today is the uncertainty regarding resource access within an Active Directory environment. Particularly troubling is news about vulnerabilities, unauthorized privilege escalations, and other types of unauthorized access, including pass-the-hash, pass-the-ticket, spear phishing, and Kerberos compromises. All of these attack capabilities are a concern for enterprises.

Could their Active Directory environment already be compromised? If not, how long can it take an attacker to find and then compromise a Domain Admins account? After attackers achieve such access, what can stop them? How long can they lurk on the network with that access? How long can the environment be at risk before the compromise is detected? Attackers can leave backdoors (create a way that allows them to get back in but not using the normal procedures), perform data exfiltration, and carry out other exploits.

The goal of PAM is to change the timeframes in which these vulnerabilities can be exploited. Today, it’s too easy for attackers to obtain Domain Admins account credentials, and it’s too hard to discover these attacks after the fact. Along with other investments, PAM will make it harder for attackers to penetrate a network and obtain privileged account access. PAM adds protection to privileged groups that control access across a range of domain-joined computers and applications on those computers. It also adds more monitoring, more visibility, and more fine-grained controls so that organizations can see who their privileged administrators are, and what are they doing. PAM gives organizations more insight into how such administrative accounts are used in the environment.

So … here’s a quick look on how this new PAM is going to work:

– a new Active Directory forest will be created

– all privileged accounts will be created in the new forest (let’s call it a bastion Active Directory forest)

– the old production forest doesn’t require any upgrade (for now)

– a new type of trust will be created between these two forests (PIM Trust)

– shadow groups (a new type of objects available in WS 2016) will be created in the bastion forests

– each time an admin will need to execute his/her work, the account in the bastion forest will be used (and that account will have access in the production forest, without being a member of any privileged groups)

The following picture will give some more insight of the workflow:

And let’s get started. We have the new bastion forest. We have the trust set between these two forests and we’ll need to enable one more thing over this trust. Using NETDOM with the /ENABLEPIMTRUST option:

Note:My production forest is called WINDEV.NET and my bastion forest is called WINADM.NET (sorry if this is confusing, but initially I had these set for another purpose).

In the bastion forest, if we look in Active Directory Sites and Services console, we can see a new container called Shadow Principal Configuration and if we right click on it we have the option to create some new objects.

What we are interested in is the msDS-ShadowPrincipal (we can create these type of objects in some other parts of AD using Active Directory Users and Computers but for the scenario I am trying to show right now it doesn’t seem to produce the desired results; so let’s create this using Sites and Services).

The new object will need a name. The object will be a shadow of an existing object from the production forest. And I am trying to shadow the Server Admins group.

 

Find out the SID of the production group (get-adgroup should be simple enough – in the production forest).

Just two steps and we have the shadow created.

Let’s inspect the attributes of the new object:

Now let’s add members to this shadow group. The members need to be accounts from the same forest as the shadow group (the bastion forest). So, my admins we’ll get new accounts that we’ll be regular accounts in the bastion forest, but through the shadow group they’ll be able to get privileges in the production forest.

And I have such an account that I will use for this:

After this, the shadow group membership can be seen through the regular Active Directory Users and Computers console:

And now the test. I am logging on using the my “admin” account created in the bastion forest (WINADM), on a computer from the production forest (WINDEV).

Running whoami /groups will show me that in my token, I have the SID of my Server Admins group from the production forest (WINDEV).

Combine these with time limited group membership and you will make a big change in your Active Directory security. Please note that for now this is beta software. Do not use it in production environments.

For now I am still waiting for the official product documentation …