MIM PAM 2016 SP1 Installation and Admin Role Separation

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.

Comments

• Anonymous
  October 19, 2016
  Hi Jeffrey, The PAM Deployment Scripts here https://www.microsoft.com/en-us/download/details.aspx?id=53941grant these permissions for you...CheersJames
  • Anonymous
    October 27, 2016
    The comment has been removed
    • Anonymous
      December 01, 2016
      Well, as you say, the delegation can only be done if you are a domain admin. The script delegates the permissions to the MIM administrator, precisely so that the MIM admin does not have to be a domain admin:function SiloConfig{ #Let's get the configDN $configDN = (get-adrootdse).ConfigurationNamingContext $authPolicyDN= ""CN=AuthN Policies,CN=AuthN Policy Configuration,CN=Services,${configDN}"" $authSiloDN= ""CN=AuthN Silos,CN=AuthN Policy Configuration,CN=Services,${configDN}"" $adminUser = Get-AccountForRole "MIM" "AdminAccount" Write-LogsAndDisplay -EventID 1 -ErrorLevel Information -Message "Performing ACLing for AuthN Policy" $retVal = RunProcess "dsacls" "${authPolicyDN} /g "${adminUser}:RPWPRCWD;;msDS-AuthNPolicy" /i:s" Write-LogsAndDisplay -EventID 1 -ErrorLevel Information -Message "dsacls returned ${retVal}" $retVal = RunProcess "dsacls" "${authPolicyDN} /g "${adminUser}:CCDC;msDS-AuthNPolicy"" Write-LogsAndDisplay -EventID 1 -ErrorLevel Information -Message "dsacls returned ${retVal}" $retVal = RunProcess "dsacls" "${authSiloDN} /g "${adminUser}:RPWPRCWD;;msDS-AuthNPolicySilo" /i:s" Write-LogsAndDisplay -EventID 1 -ErrorLevel Information -Message "dsacls returned ${retVal}" $retVal = RunProcess "dsacls" "${authSiloDN} /g "${adminUser}:CCDC;msDS-AuthNPolicySilo"" Write-LogsAndDisplay -EventID 1 -ErrorLevel Information -Message "dsacls returned ${retVal}" Write-LogsAndDisplay -EventID 1 -ErrorLevel Information -Message "Completed ACLing for AuthN Policy"}
    • Anonymous
      December 01, 2016
      But I grant you that it is non-ideal for all installers to have to run as domain admins! The installation scripts for PAM do lots of domain level stuff, however...