Using Managed Service Accounts to manage Domain and Enterprise Admin accounts in PAM
Article ID: 210488
Updated On:
Products
Issue/Introduction
There are situations where stringent security requirements force administrators to provide enhanced security for accounts used to run some of the critical PAM applications.
One such use case is managing Credentials of users by using PAM Proxy.
4.2.x : https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/privileged-access-manager/4-2-2/protect-privileged-account-credentials/identify-target-applications-and-connectors/add-a-windows-proxy-connector/how-to-install-a-windows-proxy-for-credential-manager.html
One can use a third machine to manage passwords of an account in Active Directory, but the account that the PAM Proxy service must be running us must have Domain Admin rights
This poses a problem in some highly restrictive environments, where Administrators will not allow a service in a third machine to run as a Domain Administrator, due to the risks associated to such configuration: should the machine be compromised there is a service, whose account is configured with its password, which might be employed to breach security.
There is one solution to this: to use Managed Service Accounts, a concept introduced by Microsoft in Windows 2008R2. A Managed Service Account is an hybrid of a user and machine account in active directory whose particularity is that it does not save the password locally.
The concept of Managed Service Account as well as a procedure to configure a member server running PAM Proxy to rotate Domain User passwords is described here.
Environment
CA Privileged Access Manager version 4.2.x
Resolution
We will hereafter work with two machines: A Domain Controller and a Member machine. The goal is to make the member machine able to rotate the Domain User passwords without having to configure PAM Proxy on this machine with Domain Admin privileges
The procedure is the following:
In a Domain Controller carry out the following operations:
- Make sure that the commands will be run as a user who is a member of the Domain Admin group to prevent issues, see
- Install the Active Directory Module for Windows PowerShell on both the domain controller and the member server where PAM Proxy will run. To do that, on bot machines open the Server Manager and Go to Roles and Features, and in the Features Menu install the Active Directory Module for Windows Powershell
- Next make sure to import into the Domain Controller and the member server the Active Directory Module for Windows Powershell. To this effect you need to open a PowerShell shell with elevated privileges (Domain Admin or Enterprise Admin) and issue the following command:
Import-Module ActiveDirectory
- Always running as Domain Admin or Enterprose Admin, you need to run the following command at the root of the forest where this deployment will take place:
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))
Once this operation is readied, the account must be created at the Domain Controller and Associated properly at the Member server, so there are actions to carry out on both
Running always as a Domain Admin or Enterprise Admin, the Managed Service Account, MSA needs to be created
- New-ADServiceAccount -Name <name of MSA to create, for instance wpsa> -DNSHostName <DNS server> -PATH "<DN of the Managed Service Accounts container>" -Enabled $true
- Set-ADServiceAccount -Identity <name of MSA to create, for instance wpsa> -PrincipalsAllowedToRetrieveManagedPassword <Machine_where_MSA_will_run>$
- Set-ADServiceAccount -Identity <name of MSA to create, for instance wpsa> -KerberosEncryptionType AES128,AES256
- Once done, the new MSA must be associated with a target computer in Active Directory
- Add-ADComputerServiceAccount -Identity <Machine_where_MSA_will_run> -ServiceAccount <name of MSA to create, for instance wpsa>
- Once created make sure the MSA is a member of the Domain Admins group
In the Member Server
- If the Active Directory Module for Powershell is not installed, install it from the Roles and Features menu and import it via Powershell commands, as indicated before
- Next install the MSA account just created in this member server
Install-ADServiceAccount -Identity <name of MSA to create, for instance wpsa>
The following commands will verify that the MSA account has been correctly installed at the member server:
Test-ADServiceAccount -Identity <name of MSA to create, for instance wpsa> |fl
Get-ADServiceAccount -Filter *
Once these commands have run successfully, you will be able to configure the Member Server to run password rotations in Active Directory using the PAM Proxy server in the Member server
If the MSA needs to be uninstalled, the following command will remove it
Remove-ADServiceAccount -Identity <name of MSA to create, for instance wpsa>
However, please take into account that the removal will wipe out the account from AD and therefore you will have to reconfigure it
The next step to install the PAM Proxy in the member server and configure the service to run as the MSA. To do that go to Services, once PAM Proxy is installed and stop the Proxy service, then go into the Logon details and specify:
<Domain>\<name of MSA to create, for instance wpsa>$
and leave password blank. Password must not be specified as it is retrieved directly from AD and never stored locally. Save configuration and start windows proxy. All should be fine.
Once the PAM Proxy service is running as the MSA you can configure a target application in CA PAM corresponding to this Windows Proxy and rotate any AD account's password using this PAM Proxy, by specifying to "Use PAM Proxy Credentials to change the password"
Additional Information
Once a PAM Proxy is installed to run with a MSA, the PAM Proxy Service has the Logon option greyed out. That is, you cannot change the user that PAM Proxy is running as (this user being the MSA). If this needs changing, reinstallation of PAM Proxy is required.
A MSA will be associated with a given machine for as long as it is not removed.
The MSA is a "per machine" concept. If one needs to have several servers using the similar service account the concept of Group Managed Service Account (gmsa) may be useful, and setup should be similar. Please consult Microsoft documentation to design the procedure in this case
Feedback
