Symantec Privileged Access Management

I have a question on Compound target account.

https://docops.ca.com/ca-privileged-access-manager/3-2-4/en/implementing/protect-privileged-account-credentials/add-target-accounts-to-target-applications#AddTargetAccountstoTargetApplications-AddaCompoundTargetAccount(Optional)

We have a scenario where we need to manage access to 1700 Unix servers. In this scenario, we don’t want to create 1700 Target Applications and 1700 Target Accounts to manage access to these serves. Instead we thought of using Compound Target Accounts. If we use Compound Target Accounts, then we can add all the other Unix devices under Compound Servers of Target Account, so that the password gets synced to all the Unix servers.

Example:

But I am seeing a limitation here. I am not sure what will happen if I add more than 100 servers in Compound Target Account.

Do you have any recommended approach to follow in this scenario?

Hello Lakshman, Compound accounts are not meant to be used with a large number of devices. This has a very high risk of causing problems. When the password is changed, a task would have to sequentially run an update job for each of the target devices. If there is a problem with any of them, all the ones that had the password changed already will have to be rolled back. Some devices may not allow this, e.g. if they don't allow reuse of an old password within X days, or if there is a minimum password age. Now you are in a situation where you have mismatched passwords that will be very hard to resolve.

Also, password updates typically take a few seconds. E.g. if we assume an average of 5 seconds, the job would run for 8500 seconds, well over two hours. There is just too much risk that the job will get interrupted, or that one of the devices in the list is not available at the time, causing the update to fail and all processed devices to be rolled back. And while the job is running, access would fail to all the devices that had the password changed already, potentially causing accounts to get locked out. Having local accounts with the same password on thousands of devices doesn't look right to me either, it doesn't allow for granular access control.

We have APIs available for creation of target applications and accounts. Once you get this going for one device, it is fairly easy to publish target applications and accounts for hundreds or thousands of devices.

Hi Ralf,

Thanks for your suggestion.

I tried creating Target Application using JAVA API, and I could succeed in that, but I am facing errors while creating Target Account using JAVA API.

Code snippet:

//getting target application id

request = new Request();
request.setCommand(AdminAPICommandNames.SEARCH_TARGET_APPLICATION);
request.setParameter(AdminAPIParameterNames.SEARCH_TARGET_APPLICATION_NAME, "UNIX-Application");
result = adminAPI.execute(request);
int targetApplicationID = result.getValueAsTargetApplication().getID();
System.out.println("Target Application = " + result.getValueAsTargetApplication().getID());

//creating target account

targetAccount = AdminAPIFactory.createTargetAccount();

targetAccount.setTargetApplicationID(targetApplicationID);

targetAccount.setUserName("root");

targetAccount.setPassword("dummy");
targetAccount.setPrivileged(false);

targetAccount.setSynchronize(false);
targetAccount.setExtendedAttribute("useOtherAccountToChangePassword",String.valueOf(false));
System.out.println("targetAccount---\n" + targetAccount);
result = adminAPI.add(targetAccount);
System.out.println("addTargetAccount:=> "+ result.getStatusMessage());
targetAccount = result.getValueAsTargetAccount();
System.out.println("addTargetAccount " + result.getValueAsTargetAccount().getUserName());

Error I am seeing:

Target Application = 1056
targetAccount---
TargetAccountImpl[ID=0]{
 UserName=root, TargetApplicationID=1056, Owner User Id=-1,
 Access Type=null, PVP ID=-1, unsynchronized, not verified,
 LastVerified=null, LastUsed=null, A2A, Aliases=null, Cache allowed, Behavior=1, Duration=30,
 Attributes[Count=1]{
  AttributeImpl[0]{null:0 useOtherAccountToChangePassword=false,
   CreateUser=null (1970-01-01 05:30:00.000), UpdateUser=null (1970-01-01 05:30:00.000), Hash=null
  }
 },
 CreateUser=null (1970-01-01 05:30:00.000), UpdateUser=null (1970-01-01 05:30:00.000), Hash=null
}
addTargetAccount:=> Success. An invalid or unrecognized value is assigned to the 'Attribute.protocol' parameter.

In CLI method protocol is not a parameter for creating Target Account. Not sure what I am missing here. Can you please suggest?

Thanks

Lakshman

Hi Lakshman, Our online documentation states for UNIX target accounts on page https://docops.ca.com/ca-privileged-access-manager/3-2-4/en/implementing/protect-privileged-account-credentials/identify-target-applications-and-connectors/add-a-unix-target-connector/unix-target-connector-cli-configuration the following:

Attribute.protocol

Specifies the protocol to use for communicating with the remote host.

You set Attribute.useOtherAccountToChangePassword to false, therefore Attribute.protocol is required.

Thanks Ralf, this one helped!!