This post has been republished via RSS; it originally appeared at: Core Infrastructure and Security Blog articles.
First published on MSDN on Jun 21, 2018I want to review a huge blocker that held up one of my recent installations of MIM PAM using the MIM Service and Portal installer. There are times where you may be under the impression that your MIM Portal pre-installation configuration work is sufficient to allow the installer to complete without rolling back everything it had tried to do.
- SPNs are set
- Service accounts are created with the correct delegations
- The MIM install account has the correct permissions on the local server and target database including the ability to create Authentication policies and silos (more info here )
- The MIM service account has the appropriate permissions to control msDS-ShadowPrincipal objects.
Additional information on the point above can be found in the PAM Installation Microsoft Docs: here .
However, the installer aborts the installation procedure and rolls back all the changes that were made.
Enable Verbose Logging for Installer
Without verbose logging enabled, I was not going to get anywhere with troubleshooting. Make sure to run the installer with the following parameters and specify your desired file location.
msiexec /I "Service and Portal.msi" /L*v C:\MIM-Install-Artifacts\log.txt
Searching for Return Value 3 places you in the most likely sections of the log that contain the error. The log had failure messages such for the step
Doing action: UpdateADForestFunctionalLevel
Snippet of detailed error:
Calling custom action Microsoft.IdentityManagement.PAMRelatedCustomActions! Microsoft.IdentityManagement.ManagedCustomActions.PAMRelatedCustomActions.Set
ADForestFunctionalLevel
Access is Denied
Troubleshooting
My first thoughts were that my installer account didn't have the permissions to update the forest functional level. I did not give the installer account domain admin nor enterprise admin. But why would the installer be trying to do this in the first place? I was sure the forest functional level was correct. I verified that I had the correct forest functional level in my environment by running the command
(Get-ADForest).forestmode
PowerShell returned the expected ForestModeLevel 7 and ForestMode of Windows2016Forest
Solution
It turns out the MIM PAM install procedure attempts to create an OU in the root of your bastion forest called PAM Objects . I could bump up the privileges of the MIM install account as a quick workaround though, in many situations, that is not desirable or even allowed. So, to continue without granting the account unnecessary privileges, I manually added the PAM Objects OU into the root of my bastion forest. I re-ran the installer and, lo and behold, it completed successfully! This solution was carried out in a lab environment, proceed at your own risk.
Additional Comments
It is important to note, since I created the PAM Objects OU outside of the installation process, that the mimservice account that handles creating PAM users (i.e. New-PAMUser) needs to have create, delete, and modify permissions on user objects for this new OU.
Be careful with the service or administrative accounts you create in your bastion forest. If you manually create a user in the bastion forest and try to have the New-PAMUser cmdlet create a PAM user that ends up taking the same account name, you will get an error such as
System.InvalidOperationException: A constraint violation occurred .
