Active Directory Target account password rotation fails in CA PAM
search cancel

Active Directory Target account password rotation fails in CA PAM

book

Article ID: 273982

calendar_today

Updated On:

Products

CA Privileged Access Manager (PAM)

Issue/Introduction

An Active Directory (AD) target account AccountA which is configured to rotate its password by means of another account, AccountB, fails to do so

In the CA PAM Tomcat logs set to INFO, there are the following entries at the time of the password rotation attempt

2023-09-20T09:57:34.332+0000 INFO [com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager] com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager.getDistinguishedName Derived the Distinguished Name (DN) 'CN=AccountB,OU=myou, DC=mydomain,DC=com' from the Target Account having ID '5001'
2023-09-20T09:57:34.332+0000 INFO [com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager] com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager.loginToActiveDirectoryServer JNDI provider URL= 'ldaps://<my_ip>:636'; JNDI security principal= 'CN=AccountB,OU=myou, DC=mydomain,DC=com'

... omitted for brevity

 com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager.getUserPrincipalName Derived the User Principal Name '[email protected]' from the Target Account having ID '17527001'
2023-09-20T09:57:34.390+0000 INFO [com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager] com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager.getDistinguishedNameFromLDAP Base DN = DC=mydomain,DC=com
...

2023-09-20T09:57:34.391+0000 INFO [com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager] com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager.getDistinguishedNameFromLDAP DN = AccountA,OU=myou, DC=mydomain,DC=com, User Principal Name = [email protected], Current DN = CN=AccountA, OU=myou, DC=mydomain,DC=comCurrent UPN [email protected]@mydomain.com


... omitted for brevity


2023-09-20T09:57:34.393+0000 SEVERE [com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager] com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager.updatePasswordInActiveDirectory Failed with Naming Exception
    javax.naming.NoPermissionException: [LDAP: error code 50 - 00000005: SecErr: DSID-031A11CF, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
 ]; remaining name 'CN=AccountA,OU=myou,DC=mydomain,DC=com'

 

 

 

Environment

CA PAM 4.X multiple releases

Cause

The process through which CA PAM tries to rotate the password of an account, AccountA in Active Directory, using AccountB is the following, as of version 4.1.4

* Firstly an attempt is made to log in in Active directory using AccountA and the password which we will try to change. This is made to ensure that the account password had previously has not been already changed to the one we are trying to use. If the process is unsuccessful using the Distinguished name, CA PAM derives the UPN from the data it has and it tries with that one. Logically both attempts must fail and there should be errors in tomcat. This is normal behaviour

* Next CA PAM tries to log in to Active Directory using the account which will be used to change the password of AccountA, AccountB. First step is for AccountB to authenticate itself in Active Directory, after which it can proceed with the password change using standard ldaps queries

The problem is if AccountB does not have enough rights to change the password of AccountA. This may be because- for instance- the accounts are in a specific container which over which AccountB must have enough rights and it does not.

In this case the error shown above is reported in the tomcat log and the password is not rotated.

 

Resolution

Enough rights must be given to AccountB to be able to reset the password of AccountA.

There are many complex deployments, so one way to proceed is to make AccountB a member of the Domain Admins group, verify that it works, then start taking some permissions from it until it has the minimal set required to perform the password change operation.

It is unfortunately not possible to give a concrete list as it may depend highly on the combination of AD policies, groups and AD permissions.