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 (4)

  1. Hi Jeffrey, The PAM Deployment Scripts here

    https://www.microsoft.com/en-us/download/details.aspx?id=53941

    grant these permissions for you…

    Cheers

    James

    1. Yes – they grant them if you install as a Domain Administrator. My point is that we need to have a way to properly delegate and separate roles. I would not want Domain Admins to install every service or application, nor every application installer to have DA rights. The above commands are some that you can give your DA team while maintaining role separation integrity on the part of the domain admins. Further, I’m attempting to more fully document what the install routines require or actually do on behalf of the installer – which is something that in my experience is sorely missing with many products. Customers usually like to know what security settings are being done to their domain on behalf of an installation script.

      1. James Cowling says:

        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”
        }

      2. James Cowling says:

        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…

Skip to main content