Windows Proxy account update fails with 5-ERROR_ACCESS_DENIED over SPN validation

Products

• CA Privileged Access Manager (PAM)

Issue/Introduction

We are managing local Windows target accounts in various environments using Windows Proxy agents. The servers are configured with IP addresses in PAM. On target servers where the IP resolves to an FQDN with a different domain name than on the Windows Proxy, we see the Windows Proxy running into "Operation not successful, message: 5-ERROR_ACCESS_DENIED" errors when one local account with administrative rights tries to update another local account's password on the remote server. Running a network trace, we see that the Windows proxy is trying to access the ADMIN$ share on the remote server using username <domain>\<user>, where <domain> is the domain that a reverse lookup of the IP address resolves to on the PAM Proxy host. This domain name is not accepted on the remote server when security option "Microsoft network server: Server SPN target name validation level" is enabled, which is a requirement in our environment.

Environment

Release : 4.0

Component : PRIVILEGED ACCESS MANAGEMENT

Cause

If an IP address is configured in PAM for a target server, the PAM Windows Proxy on purpose will do a DNS lookup to get the FQDN of the server. Use of the IP has caused problems in some customer environments, including problems to manage services run by the local accounts. There are also scenarios where an IP can be used on the PAM server to connect to a target server for access, but the same IP does not work on the Windows Proxy server, while the FQDN works there.

Resolution

Either change the DNS configuration on the Windows Proxy to resolve the IP configured in PAM to the FQDN that is accepted on the target server, or configure the device in PAM with the correct FQDN, rather than an IP, as device address.

Additional Information

For one affected customer we provided a debug build that skipped the reverse lookup and just used the IP address configured in PAM, but that did not work in all cases. Therefore it was decided to not make a change to the Windows Proxy code, but resolve the problem with consistent usage of FQDNs as device addresses.