CyberArk Containers in IdentityIQ

Which IIQ version are you inquiring about?

8.4p2

We’ve installed the PAM module and configured the integration with the CyberArk SCIM service, and I see the accounts and entitlements from CyberArk listed as links on the relevant identity cubes. I also see the Privileged Account Management tile on the dashboard that takes me to a list of containers (safes?) that can be manipulated.

What I don’t see is a way to connect the identity cubes to the safes.

I also don’t see anything in the debugger that would allow me to look at the representation of a container/safe within IIQ.

Is there a way to see the containers via the debugger or console? Is there a way to query the list of containers/safes IIQ obviously knows about programmatically?

@michael_bullock

When you click on Manage Access → Privileged Account Management, you can see all the containers and you can add identities to it. You need to be a PAM Administrator. Example snaps are as below.


Also, you can not see details of container in debug. They are using SCIM calls at backend to present data at UI

Wow! This seems really short-sighted.

So, if we wanted to report on a comprehensive list of containers, their owners and correlate them to another enterprise app, we’d have to extract the data from CyberArk, IIQ and the other app, then manually compile. Ugh!

Also, it seems like an opportunity missed. If we have team safes, it would be useful to be able to present them in a pick list for access request.

Ah, well. I guess I’ll just have to figure out the SCIM calls to pull the safe data on demand.

Thank you for confirming my fears.

I might be mis-understanding what you are looking for but - you should be able to do some connecting of the various objects in IIQ to get what you are looking for. Users and Groups are associated to Containers via something called a TargetAssociation and Target.

Basically Containers and PrivilegedData are aggregated as ManagedAttributes (can view them in debug). Association of identities/accounts to these ManagedAttributes are done via reference in the TargetAssociation->Target->ManagedAttribute from what I’ve seen. All of these objects should be visible in debug, and then if you wanted to programmatically build up the graph you could do so using context.search, as well as the ManagedAttributer:

Iterator it = context.search(Target.class, QueryOptions qo)
or
Iterator it = context.search(TargetAssociation.class, QueryOptions qo)

ManagedAttribute ma = sailpoint.api.ManagedAttributer.getEntitlementOrObject(context, application, groupAttributeName, value, type);

Here name, value, and type are all properties of the ManagedAttribute (although if you look at the ManagedAttribute in debug, I think groupAttributeName==attribute)

1 Like

Oh, yes! That’s exactly what I was looking for. I had not paid the ManagedAttributes any attention before.

Thank you for pointing this out and saving me from running down a weird custom build!

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.