Using Managed Service Accounts to manage Domain and Enterprose Admin accounts in PAM

book

Article ID: 210488

calendar_today

Updated On:

Products

CA Privileged Access Manager (PAM)

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. According to documentation

https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/privileged-access-manager/3-4-3/implementing/protect-privileged-account-credentials/identify-target-applications-and-connectors/add-a-windows-proxy-connector/how-to-install-a-windows-proxy-for-credential-manager.html#concept.dita_4ed67626f7faac520895c4dd5755d4d34d8e8a1c_WindowsProxyConfiguration

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 3.4.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

https://social.technet.microsoft.com/Forums/lync/en-US/c06c2ec3-36ed-4c1d-a1ae-837d732a3a00/addkdsrootkey-fails-with-quotrequest-not-supportedquot-error?forum=winserversecurity

  • 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 of MSA to create, for instance wpsa> -DNSHostName <DNS server> -SamAccountName <name of MSA to create, for instance wpsa> -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>

  • Please make sure the “Set-ADServiceAccount” command with “PrincipalsAllowedToRetrieveManagedPassword” is successful with the target server (on which proxy is deployed). Be sure to include the $ at the end of the hostname.

Set-ADServiceAccount -Identity <name of MSA to create, for instance wpsa> -PrincipalsAllowedToRetrieveManagedPassword <Machine_where_MSA_will_run>$

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

To do so, install the PAM Proxy in the member server and configure the service to run as the MSA. you won't need to specify any password, as this is retrieved directly from AD and never stored locally

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"