JIT Accounts linger for very long - Some of these ghost target accounts never get deleted

Products

• CA Privileged Access Manager (PAM)

Issue/Introduction

We are seeing MSSQL target accounts left behind that were created by PAM as part of a custom workflow, which includes the "-Account" action (delete account) in the Check-in action. These accounts cannot be removed. 

API:

(200, '{"error":{"code":200,"message":"OK: PAM-CMN-2279: Unable to delete target account  for API Key - error was PAM-CWF-0034: Dynamic account cannot be deleted. com.cloakware.cspm.server.app.ApplicationException: Dynamic account cannot be deleted.."}}')

GUI:

As per screenshot  - the 'Delete' button is greyed out. The Action column shows that this account is not checked out. In fact it's several weeks old and should have been deleted by PAM when the account was checked in.

Environment

Release : 4.1

Cause

When an account is created as part of a custom workflow, a job is created that will check the account in once the check-out expires per password view policy and perform the configured Check-in actions. If the scheduled job runs into an error, the target account will be left behind. Note that the user may check the account in prior to the scheduled job run time. If that manual action runs into an error, the account will remain checked out and the check-in can be retried.

There are two known potential causes of the problem:

1. The SQL server is not accessible from PAM at the time of Check-in.

2. The account was used to create a database. In that case SQL will fail an attempt to delete the account. The PAM tomcat log, which can be downloaded from the Configuration > Diagnostics > Diagnostic Logs > Download page, will show an error similar to the following:

2023-10-12T15:38:26.788+0000 SEVERE [TP67] com.cloakware.cspm.server.app.impl.ForceCheckInAccountPasswordCmd.invoke ForceCheckInAccountPasswordCmd.invoke application exception
    com.cloakware.cspm.server.app.ApplicationException: Login '<RDP User Name>' owns one or more database(s). Change the owner of the database(s) before dropping the login.

Resolution

If there was a temporary problem connecting to the database, a PAM administrator can try to view the password of the account, which will check it out again. This action will report that the account existed already. Then the account can be checked in to get it deleted.

If the Check-in continues to fail, view the tomcat logs and look for errors from a "ForceCheckInAccountPasswordCmd" command. If the error suggests that the account owns the database, change database ownership. A valid database owner account should not be used with JIT provisioning in a custom workflow, but should be configured as a permanent target account.

Additional Information

The database owner may show with the SID only, which may make it difficult to associate ownership with the account name seen in PAM. The following query lists database owners by name:

SELECT d.name, sl.name FROM sys.databases as d JOIN sys.syslogins AS sl ON d.owner_sid = sl.[sid]