When talking about security in Active Directory a big challenge is the delegation and how to protect the admin accounts and groups. Microsoft has release two whitepapers about this subject.

• Best Practices for Delegating Active Directory Administration
• Best Practices for Securing Active Directory

The delegation highlights the security model in Active Directory which is important to understand and have in mind to get the best out of it. It’s not an easy task to manage and has many dependencies of administrative users and systems to keep in mind when setting this up.

This goes hand in hand with securing your Active Directory environment since you have very high privileged accounts, and if the wrong persons gets on hold of it, it can do some great damage to the whole company.

Today when the cyber-attacks increases and everything is more connected to the internet and the mix of all types of devices with users on the run it becomes more important to protect your systems. In a Windows network Active Directory has the highest security value since everything is tight integrated and should be your number one identity store giving you access to everything with the right privileges.

Two important points that is highlighted in the Best Practices for Securing Active Directory white paper.

• Eliminate permanent membership in highly privileged groups
• Implement controls to grant temporary membership in privileged groups when needed

This is a really good practice to minimize the exposure of accounts with high privileges. I liked the idea to delegate a group of users to be given the access to grant a user the membership of e.g. Enterprise Admin, Domain Admin when needed and only for a period of time. When using the principle of least privilege there is no need for users to have 24/7 access to the high privileged accounts and other admin accounts granting you access to sensitive information and resources.

But, the problem with this, for me: The delegated group of users has the same value of protection as the DA, EA groups. It feels like you move the ability to add members to only another group.

With Microsoft Identity Manager (MIM) and Active Directory in vNext, Microsoft has taken this points in action developed an automated way to manage this in a much better way.

This article will be about a new, really cool feature called Just In Time (JIT) Admin Access. JIT automates the provisioning of temporary admin access using a shadow high security admin forest.

Microsoft has released a Customer Technology Preview (CTP) which can be downloaded here.

In Active Directory vNext there is two new features:

• Time To Live on groups. A user will be member of a specific group for a fixed value of time, after the time has passed ADDS will remove the users membership of that group. This removes the risk of users keeping the delegated rights longer than needed.
• Foreign Principal Groups. This functionality will be used with a shadow forest where your secured groups will be located. This has not yet been released to the public.

When using MIM you can request the group memberships you need to be able to do your work in the scheduled service window, and when the TTL has expired, you are no longer a member of that group.

The request is managed by the Privileged Access Management (PAM) module in MIM, and it requires a shadow forest where the MIM instance, users and groups will exist. The ADDS in the shadow forest will manage the TTL group membership.

I will not describe the installations steps since the CTP has a good step by step guide for installing the MIM PAM functionality. A few things that needs to be in place for this:

• Corp lab forest with 2008 Domain Controllers or higher
• A shadow forest with vNext Domain Controllers
• Two way forest trust with SIDHistory enabled and SID filtering disabled
• MIM PAM installed in the shadow forest
• A test client in the corp forest

The CTP is a Proof of Concept and the final product isn’t yet released. The Foreign Principal Groups as I mentioned, isn’t released. To simulate the JIT functionality and give you a picture of the concept Microsoft has chosen to take advantage of the SIDHistory attribute.

NOTE: The SIDHistory attribute is usually used when migrating to a new Domain or Forest. During the migration, to make it possible for users to keep their access to resources in the source domain the SIDs of the users and groups is also copied to the users and groups accounts in the destination domain. In the Kerberos PAC the SIDs of the new and old domain will be in it which makes it possible for the users to access all resources needed during the migration.

If we fast forward to a succeeded installation of a CORP LAB forest and a PRIV shadow forest with the trust, the MIM PAM is installed like this:

Now the cool part begins. To migrate the administrative groups and users to the shadow forest, logon to the MIM server and start PowerShell.

Import AD and MIM modules:

Import-Module MIMPAM

Import-Module ActiveDirectory

Start a new PAM session and get the admin credentials in the CORP LAB Domain:

$session = New-PAMSession

$cc = get-credential –UserName LAB\Administrator –Message “CORP LAB forest domain admin credentials”

Migrate the ADMINS_FileShare group with SIDHistory:

$pg = New-PAMGroup –Session $session –SourceGroupName “ADMINS_FileShare” –SourceDomain LAB –SourceDC labdc01.lab.secid.se -Credentials $cc –CloneSIDHistory 1

Migrate the admin user account:

$sj = New-PAMUser –Session $session –SourceDomain LAB –SourceAccountName adm_tony

Create a new PAM role in MIM linked to the newly migrated group with TTL value of 600 seconds and granting the adm_tony account the possibility to be a member:

$pr = New-PAMRole –DisplayName “ADMINS_FileShare” –TTL 600 –Privileges $pg –Candidates $sj

Open ADUC in the PRIV domain and you will see the migrated user and group with the LAB domain netbios name in the Display Name and account name to clarify this is a shadow object of the LAB domain.

If you look at the group members you can see that it is empty:

Back in PowerShell the SIDHistory attribute can be verified by following command:

Get-ADGroup –Identity LAB.ADMINS_FileShare –properties SIDHistory

Also, verify that the ADMINS_FileShare group has no members in the CORP LAB Domain.

Logon to a client PC in the LAB domain and open PowerShell.

Enter following command:

Whoami /Groups

Notice that the users has no special memberships other than defaults.

Run the following commands:

Import-module MIMPAM

$r = Get-Roles | ? { $_.DisplayName –eq “ADMINS_FileShare” }

New-PAMRequest –role $r

This will trigger MIM (if allowed) to add the shadow user in the PRIV domain to the shadow LAB.ADMINS_FileShare group. If we try another group where we didn’t add the adm_tony account the possibility to be member of, it will fail.

If we look in the group membership in the CORP LAB domain the group is still empty, but if we look in the shadow domain the shadow account LAB.admin_tony will temporary be member of that group.

In the PowerShell command prompt logon with the shadow user credentials and open a new PowerShell prompt:

runas /user:LAB.admin_tony@priv.secid.se powershell.exe

In the new window run the whoami /groups command again and you will see two new group memberships.

The first is the shadow group LAB.ADMINS_FileShare and the second one is the ADMINS_FileShare group. And this is because of the SIDHistory, the user is a member of the shadow group and when the user is authenticated to the shadow PRIV domain it will get a Kerberos ticket with both SID in it. The one of the SIDs has been migrated from the CORP LAB domain it will be resolved as the ADMINS_FileShare group.

This is really cool!

After 10 minutes ADDS in PRIV domain will remove the group membership and the user will need to do the request again if the sessions has been closed. And notice IF the session been closed. This is an old Kerberos problem, when authenitcated you will get a Kerberos ticket containing all the SIDs of group memberships. And it won’t be updated until TGT renewal.

I think this is a really cool demo and gives you an idea how this will work in the future, since the Foreign Principal Groups isn’t released yet I’m really eager to see how it will work. Hopefully that will be released soon.

A few points:

• Delegation in the CORP domain is still very important since this doesn’t disable admin users to add themselves or other users to these groups. I would like to see a more constrained feature like what Authentication Mechanism Assurance gives you.
• In the PRIV forest you will only have a very few users managing it which makes it a bit easier since the shadow users has no admin rights in that domain.
• All the admins in the CORP domain needs to be able to authenticate against the shadow forest on their admin clients/server. Will we need to build a shadow Site topology as well? What about replication then?
• I would appreciate an approval workflow when users request admin privileges, and a more dynamic TTL. If the Role owner grants the request he should be able to set a more current TTL related to the planned service window. If the job isn’t planned to take more than 1 hour, and the default TTL is set to two hours, it kind of misses the point.

Another thing to think about is how this redraws the way we think about the security boundary. The forest is the security boundary. Suddenly, we have another forest holding those privileges, and it’s maintained by an MIM instance. If you enable this on the EA, DA and Administrators groups, the MIM instance has pretty high power and has the same value of protection.

Well that’s almost all for this time. I have just one more thing to mention. Since there is no constraints on the groups in the CORP domain I couldn’t resist of enable AMA on the groups. Now it got a little harder to add members in the CORP domain 🙂