CA PAM fails to discover accounts in Service discovery in CA PAM Proxy
search cancel

CA PAM fails to discover accounts in Service discovery in CA PAM Proxy

book

Article ID: 143421

calendar_today

Updated On:

Products

CA Privileged Access Manager (PAM)

Issue/Introduction

While integrating CA PAM with Active directory (AD) by using CA PAM Proxy to manage accounts on servers there are difficulties discovering accounts.

The environment has a parent domain example.com which holds 1 (or more) subdomains dc1.example.com. The UserPrincipalNames (UPN) being used contain the parend domain, not the root domain, that is UPN is [email protected] for all accounts. However, the accounts can change their password at the subdomain, that is dc1.example.com, as it is the only place where they are defined.

With this setup CA PAM Proxy id being used to manage Domain accounts. We have set up an Administrative account in domain DC1, PAMProxy, with Password reset privilege on the specific OU containing the accounts and given him Local Admin Privileges on part of servers where the use case is being tested. The CA PAM Proxy service in the servers where discovery must be run is configured to run using the UPN [email protected]

In CA PAM, Service discovery has been configured using CA PAM Proxy. For the target account the SAMAccountName is specified in the target account name.

Under these premises, doing the service discovery in CA PAM it fails to find any service.

However, if the account name is changed to the UPN, that is [email protected], then the services are discovered. However, they cannot be managed, as the when specifying the account with account name [email protected] there is an error saving/verifying the password.

 

Environment

CA PAM versions 2.8.X and 3.X

Cause

If SAMAccountName is used as the account name in the the target account configuration, then on discovering servers in the different machines under domain dc1.example.com, CA PAM it will try to append their domain to the SAMAccountName value defined in the account name definition, that is it will try to use [email protected] to resolve the discovered services in the machines, but this is not what is configured for the service accounts, for which the [email protected] account is used, so it will end up with 0 accounts discovered.

This is also why if in the target account configuration one uses [email protected], it is able to see the discovered services, as the account name is looking for is exactly the one configured in the CA PAM Proxy definition in the servers being managed. The problem here is that example.com is not really the domain where the passwords may be stored or changed, as account passwords can only be viewed/modified/changed when connecting directly to the specific domains, that is dc1.example.com and besides the way that CA PAM is working, it will try to append the current domain name for which the target account is defined to the user name, resulting in a format mismatch and an error (i.e. it will try to change the password for [email protected]@dc1.example.com)

Resolution

For the time being there is no solution. This type of configuration is not supported. Make sure to configure the target accounts using SAMAccountNames only and to make sure that the CA PAM Proxy services are running in the target machines by logging in with their SAMAccountName and not the UPN.