MIM and Privileged Access Management

Recently Microsoft released Microsoft Identity Manager 2015 (MIM) Customer Technology Preview (CTP). Those expecting a major revision of the FIM product should brace themselves for disappointment. The MIM CTP is more like a service release of FIM. MIM CTP V4.3.1484.0 maintains the existing architecture of the FIM Portal (still integrated with SharePoint), FIM Service, and the FIM Synchronisation Service.  Also maintained are the separate FIM Service and FIM Sync databases. Installation of the CTP is almost identical to FIM 2010 R2 SP1, including the same woes with SharePoint 2013 configuration. The MIM CTP package available from Microsoft Connect contains an excellent step by step guide to install and configure a lab to test out PAM, so I won’t repeat that here.

In brief, the CTP adds the following features to FIM.

1. Privileged Access Management

This feature integrates with new functionality in Windows Server 10 Technical Preview to apply expiration to membership in Active Directory groups.

2. Multi Factor Authentication

FIM Self-Service Password Reset can now use Azure Multi-Factor Authentication as an authentication gate.

3. Improvements to Certificate Management

Incorporation of a Modern UI App, integration with ADFS, and support for multi forest deployment.

After installation, first thing that is evident is how much legacy FIM branding is maintained throughout the CTP product – yes this is MIM, please ignore the F word!:

 Privileged Access Management

For this blog I’ll focus on Privileged Access Management (PAM), which looks to be the biggest addition to the FIM Product for this CTP. PAM is actually a combination of new functionality within Windows Server 10 Technical Preview Active Directory Domain Services (ADDS) and MIM. MIM provides the interface for PAM role management (including PowerShell CMDLETS), whist Windows Server 10 ADDS adds capability to apply a timeout for group membership changes made by MIM

PAM requests are available from the MIM Portal – however for the CTP lab, PowerShell CMDLETS are used for PAM requests. These CMDLETS are executed under the context of the user wishing to elevate their rights. For the CTP lab provided, there is no approval applied to PAM requests, so users could continually elevate their rights via repeated PAM requests – however this would be trivial to address via an approval workflow on PAM request creation within the MIM Portal. At this stage there appears to be no way for an administrator to register a user for a PAM role – e.g. requests for PAM roles are done by the end user. The CMDLET usage is covered in detail by the PAM evaluation guide.

The PAM solution outlined for the CTP solution consists of a separate PAM domain in its own forest, containing the MIM infrastructure. Also present in this domain are duplicates from the production domain of privileged groups and user accounts for staff requiring PAM rights elevation.

The not so secret sauce of PAM is the use of SID history between the duplicate PAM domain groups and privileged production groups. SID history enables user accounts in the PAM domain residing in the duplicate PAM domain groups to access resources within the production domain. For example, a share in production secured by group “ShareAdmins” can be administered by a PAM domain account with membership in the duplicate PAM domain group “PROD.ShareAdmins” containing the same SID (in the SIDHistory attribute) as the production “ShareAdmins” group. When the PAM user account authenticates and attempts access to the production resource, it presents membership in both the duplicate PAM domain group and the production group.

PAM controls access to production domain resources via controlling membership in the duplicate PAM domain groups. To elevate rights, users authenticate with their duplicate PAM domain account which MIM has granted temporary membership in the duplicated privileged groups present within the PAM domain, and then access production domain resources.

What is new to PAM, and Windows Server 10 is the ability for a timeout to be configured for memberships in groups. When PAM adds users to groups, a Time-to-Live (TTL) is also applied. When this TTL expires, the membership is removed. For the PAM solution, MIM controls the addition of users to PAM groups and application of the TTL value, Windows Server 10 ADDS performs removal independently of MIM. MIM does not have to be functional for removal to occur.

TTL capability is enabled in Windows Server 10 ADDS via the following command line, for the technical preview a schema modification is also required – refer to the PAM evaluation guide in the MIM CTP distribution package:

Enable-ADOptionalFeature "Expiring Links Feature" -Scope ForestOrConfigurationSet -Target <PAM Domain FQDN>

During my testing of the PAM CTP, all worked as expected. MIM added users to PAM managed groups with a TTL, Windows Server 10 ADDS duly removed said users from PAM groups when the TTL expired. However the fundamental issue with group membership retention in user Access Tokens remains, e.g. a user must re-authenticate for group changes to apply to their Access Token. So any elevated sessions a user has open essentially retain their elevated rights long after PAM has removed said rights. However PAM does assist with segregation of duties, auditing, and addresses issues where there is a proliferation of accounts with high levels of access.

All in all the MIM CTP is a bit of a mixed bag. I am surprised to see the changes to Certificate Management prioritised above native integration of the Azure Active Directory (AAD) Management Agent and implementation of AAD password synchronisation functionality. The PAM implementation is quite heavy architecturally, e.g. an additional forest, two-way Forest trust, and SID History Filtering disablement. It will be interesting to see how the product develops in future CTPs, however with a scheduled MIM product release first half 2015, I don’t anticipate more deviation from the classic FIM architecture.