IIQ integration with CyberArk PAM-SCIM

IdentityIQ (IIQ) IIQ Discussion and Questions
1

Which IIQ version are you inquiring about?

Version 8.3

Share all details related to your problem, including any error messages you may have received.

We have been told by both SailPoint and CyberArk PAM-SCIM that…

  1. SailPoint will only create local users on CyberArk PAM-SCIM
  2. For AD users to show up in the CyberArk PAM-SCIM user list, they have accept an invitation
  3. Users expect to have their Containers (safes) and Accounts (Privileged items) in place (provisioned by SailPoint) when they login the first time
    How do we provision AD users with Containers (safes) and Account (Privileged items) in SailPoint if we are unable to see AD users until after they login?
2

I have had a couple of experiences with this integration. One went pretty well which used the original Java based SCIM connector (Marketplace). The other went not so well due to the newer SCIM architecture via CyberArk Privileged Cloud (Set up SCIM for PAM - Self-Hosted). We ran into a few blockers one of which was a couple of the aggregations always timing out and a few other small things. If you are doing this with CyberArk Privileged Cloud you may run into issues.

  1. SailPoint will only create local users on CyberArk PAM-SCIM

Technically this is true, you will always be creating users directly in CyberArk as opposed to your AD/LDAP integration in CyberArk creating accounts automatically when a user logs in, however, there is a way to tie newly created accounts via SCIM to an AD account. In your PAM applications creation policy, there are two attributes that need to be set up:

  • nativeIdentifier - the DN of AD account you want to link to
  • source - the name of the AD/LDAP config in CyberArk

I think you also need to make sure your SCIM mappings account for these as well if not there OOTB. When these two are set properly, when the user logs in for the first time via AD, they should already be associated with access you have provisioned them before they have ever logged in.

I think we may have not been able to achieve this with the newer SCIM connector on Privileged Cloud. Can’t remember specifics.

  1. For AD users to show up in the CyberArk PAM-SCIM user list, they have accept an invitation

This doesn’t seem like a true statement. Even without this integration you don’t need to accept an invite to get in. You just need to be in some base authorization group from my experience.

  1. Users expect to have their Containers (safes) and Accounts (Privileged items) in place (provisioned by SailPoint) when they login the first time
    How do we provision AD users with Containers (safes) and Account (Privileged items) in SailPoint if we are unable to see AD users until after they login?

Given my response to your first question, you should be good to set things up ahead of time before they ever log in.

Curious what your use case is? Are you wanting to grant access to shared credentials in existing safes or is this more of a personal admin account safe you’d be setting up from scratch?

Also keep in mind that if your CyberArk environment is already heavily integrated with AD (groups granting safe access), you might not get a ton of benefit from doing this direct integration except for a couple of use cases such as personal admin account set up.

3 Likes
3

Thanks Patrick for the quick response.

Our first use case is as you said, setting up a personal admin account for and AD user.

  1. We established from both SailPoint and CyberArk that create only works fro local accounts
  2. We are connecting through SCIM to the CyberArk Privileged Cloud. Even when using Postman and supplying the
    • nativeIdentifier - the DN of AD account
    • source - the name of the AD/LDAP config in CyberArk
4

The response is a 200, but the user type (AD) does NOT change:
“urn:ietf:params:scim:schemas:cyberark:1.0:User”: {
“authenticationMethod”: [
“AuthTypePass”
],
“changePassOnNextLogon”: true,
“passwordNeverExpires”: false,
“directoryType”: “Vault”
}

This is what I expect to see:
“urn:ietf:params:scim:schemas:cyberark:1.0:User”: {
“authenticationMethod”: [
“AuthTypeLDAP”
],
“changePassOnNextLogon”: false,
“passwordNeverExpires”: false,
“directoryType”: “LDAP”
},
“urn:ietf:params:scim:schemas:pam:1.0:LinkedObject”: {
“source”: “LDAP”,
“nativeIdentifier”: “CN=XXX YYY,OU=Users,OU=Common,DC=AD,DC=COM”
}

5

(3 of 3) Sorry about the piecemeal responses. Nothing I have tried so far produces the desired outcome in the original response:

I think you also need to make sure your SCIM mappings account for these as well if not there OOTB. When these two are set properly, when the user logs in for the first time via AD, they should already be associated with access you have provisioned them before they have ever logged in.
<<<

Thanks in advance for any suggestions to get past this issue.

**CW

6

Yeah I think we ran into the same with Privileged Cloud SCIM. Not sure if there is a resolution.

1 Like