MIM PAM 2016 SP1 Installation and Admin Role Separation

  • Article

Now that SP1 of MIM 2016 is out, I've been tasked to install and configure it. Simple, I thought. I've done this before. No Problem.

No problem? What was I thinking?

I want to install this application in a secure fashion - utilizing an environment that was built on the philosophy of administrative role separation and least privileged access. That's nice, right? I mean - who wouldn't want that these days? Let your Domain Admins only do Domain Admin stuff (like create OUs, delegate user rights, administer group policies, etc.) and your server administrators administer and install applications on servers. Doesn't that sound like the way it should be?

It doesn't quite work that way. The installation of the Privileged Account Management component of MIM will require the use of Authentication Silos (read about them here). In order to create/manage silos, you need Domain Admin rights, or the proper delegation of those rights. Running the install with only local administrator rights on the server returns an error. When verbose logging is enabled, the error is:

 Failed creating authentication policy/silo.
The user has insufficient access rights.

This means that to install the application with the least amount of effort, the installer needs to be a member of the Domain Admins group.

But, don't do that. There's a better way.

Let's delegate those rights in a targeted way instead. Grant the specific rights required for the installation (either directly to the installer account or a group that the installer is a member of) on the directory objects in order to enable the install. I'm hoping that once the install is complete that the rights can be removed, but I haven't gotten that far in my testing. The required commands to set the permissions are as follows and must be run by a domain admin:

 dsacls "CN=AuthN Policies,CN=AuthN Policy Configuration,CN=Services,<the DN of PRIV Domain’s Configuration NC>” /g <user name>:RPWPRCWD;;msDS-AuthNPolicy /i:s
dsacls "CN=AuthN Policies,CN=AuthN Policy Configuration,CN=Services,<the DN of PRIV Domain’s Configuration NC>” /g <user name>:CCDC;msDS-AuthNPolicy
dsacls "CN=AuthN Silos,CN=AuthN Policy Configuration,CN=Services,<the DN of PRIV Domain’s Configuration NC>” /g <user name>:RPWPRCWD;;msDS-AuthNPolicySilo /i:s
dsacls "CN=AuthN Silos,CN=AuthN Policy Configuration,CN=Services,<the DN of PRIV Domain’s Configuration NC>” /g <user name>:CCDC;msDS-AuthNPolicySilo

The <user name> should be in the form of DOMAIN\userid and can be a group as well. Once these permissions are set, a non-DA account with local server admin rights can continue to install the applications.