Service accounts are dead. Long live MSAs! But where can you actually use MSAs/gMSAs? One place that often pops up is Advanced Group Policy Management (AGPM) from the Microsoft Desktop Optimization Pack (MDOP).
The installer for AGPM requires that you create a service account and enter its password manually. In a correctly configured AGPM GPO environment, no one will have access to edit the GPOs except this account. So knowing its password is a bad thing. But how can we get past the installer, so we can run AGPM using an MSA/gMSA?
Here’s how. Note this isn’t an official endorsement. I did this in my lab and it works fine. I checked with a few trusted colleagues and they think it’s fine too. If you really are moving away from manual service accounts, then try this out in your lab. You’ve now been warned.
There are 2 scenarios:
- A fresh install of AGPM
- An existing install of AGPM
The steps are almost identical. I’ll call out the differences as we go though the core steps.
1. Create the KDS rootkey for gMSAs if one doesn’t exist in the forest:
- Only needed if using gMSAs in Windows Server 2012 or later AND the key hasn’t already been created
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))
2. Create a gMSA called gMSA-AGPM$ with samaccountname = gMSA-AGPM$
3. Create a temporary user account (for use during AGPM installation) called svc-AGPM (if AGPM is already installed, you skip this step)
4. Assign both svc-AGPM and gMSA-AGPM$ “Logon as a Service” right on the AGPM server.
- Note that this right may be defined a GPO, so local policy changes may be ignored. Set this right on the PO if needed.
5. Install AGPM using svc-AGPM (if AGPM is already installed, you skip this step)
6. Once the installation is done, stop the service “AGPM Service”
7. Remove the ServicePrincipalNname (SPN) for AGPM from the AD users ‘svc-AGPM’ and place it on gMSA-AGPM$ instead
8. Set the registry value at HKLM\Software\Microsoft\AGPM\ArchiveOwner to have the SID of gMSA-AGPM$
- Use psgetsid.exe from Sysinternals to convert a username to a SID
9. Set the permissions on the AGPM data folder (by default this is C:\ProgramData\Microsoft\AGPM) and on the folder %windir%\temp to grant ‘Full Control’ on these 2 folders and all sub files and folder to gMSA-AGPM$
10. Set permissions on all GPOs to grant gMSA-AGPM$ full control using:
Set-GPPermission -All -PermissionLevel GpoEditDeleteModifySecurity -TargetName CONTOSO\gMSA-AGPM$ -TargetType Computer
11. Set permissions to the root of each domain to all gMSA-AGPM$ to have “Link GPO” rights to all OU objects:
$agpmserviceaccountname = “gMSA-AGPM$”
$domaindn = (Get-ADDomain).distinguishedname
$agpmaccountsid = (get-adserviceaccount $($agpmserviceaccountname)).sid
$newsddl = "(OA;CI;RPWP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;;$($agpmaccountsid))"
$objsecurity = get-acl -Path "ad:\$($domaindn)"
Set-Acl -Path "ad:\$($domaindn)" -AclObject $objsecurity
12. Remove all other accounts as having Editor rights to all GPOs.
- Take care with this step in production as many files ACLs will be changed causing SYSVOL to re-replicate all data. Also, when you are removing permissions you may also accidentally remove “Apply GPO” and “Read” rights where they have been specifically set as a way of targeting GPOs to specific users, groups and computers.
13. Add gMSA-AGPM$ as a member to the AD group “Group Policy Creator Owners” and “Backup Operators”
14. Install the Service Account gMSA-AGPM$ as a managed account on the AGPM server using this cmdlet:
Install-ADServiceAccount -Identity gMSA-AGPM$
- Note that you will need the feature for AD PowerShell Module installed first to run the cmdlet Install-ADAccount
15. Set service properties for AGPM Service to logon as CONTOSO\gMSA-AGPM$ (keep the password fields blank)
16. Start the service “AGPM Service”
17. Remove “Logon as a Service” right for the temporary account svc-AGPM
18. Delete/disable the account svc-AGPM in the domain
19. Delegate rights in AGPM to domain users/groups to be admins/editors/approvers/reviewers as normal in AGPM
20. Delegate “Link GPO rights” for OUs to Admins in AD as normal