The request is trying to send an email object and the email object contains type, primary and value.
"emails": [
{
"type": "work",
"primary": true,
"value": "[email protected]"
}
],
In the provisioning policies of the connector, it seems like it only accept string, but the endpoint API is expecting an array object
How does it work in this case? I am not able to find any thread to discuss about this issue
Hi Ricky!
What connector are you using, OOTB CyberArk or a Web Services/SCIM connector?
The API link you provided is for CyberArk. There are 2 OOTB IDN-CyberArk connectors, one for on-prem and one for cloud. In looking at the documentation for each one, they both have the Account Schemas listed. In both cases, emails does not seem to be a standard attribute and unfortunately, it doesn’t look like any additional attributes can be added to these account schemas. This is the note listed for each of the connectors (with the connector name being different):
"The following is the limited list of account attributes supported by SailPoint CyberArk Privilege Cloud. This list can’t be extended.
If you are using a custom Web Services/SCIM connector, this might be able to be accomplished, but it would require more info/research so I wanted to clarify what connector you are using first.
Thank you,
Zach,
The connector is CyberArk Privilege Cloud, which is the one for cloud. To create an account in CyberArk that does not need an email, but it would not be searchable.
Email is a required attribute in CyberArk in order to assign the entitlement. Here is the screenshot of the creating the account with assigning the entitlement
I was able to update the account schemas by calling the API
The question would be how to convert it into an array of objects. it seems like IDN is only support an array of String.
This provisioning workflow is not able to create an account successfully with the entitlement without adding the email attribute. It means the standard attribute excluding the required attribute (email), but this will not be able to complete the access request with the standard attributes.
Hi RIcky,
Yes, you can update the account schema of the connector to include additional attributes and the provisioning policy. However, since this is an OOTB connector and it states that additional attributes are not supported, this would most likely cause issues with the account provisioning. I can’t say for certain since we can’t see exactly how the calls are being constructed and executed on OOTB connectors, but since the documentation says this is unsupported, it doesn’t seem like it will work.
I would recommend opening a ticket with SailPoint Support to ask about this question since it is for their OOTB connector to see if they can determine any kind of work around to have an additional attribute added to this connector.
Thank you,
Zach,
Thanks for your quick response. Yes, the SailPoint Support’s ticket has been opened and they suggest to get the expert services. According to the CyberArk doc, the email attribute is not required to create the account, but it needs the email attribute to assign the entitlement.
I suspect this is a bug from the connector because the access request can’t be completed successfully without updating the provisioning policies. I have been trying to resolve this issue asap, but there was no luck so far. I can’t even get in the VA to see the log. It means I am trying to fix the issue in dark.
I am not super familiar with CyberArk’s user management best practices or API, but I did some more digging into their API.
According to their API documentation for CyberArk Privilege Cloud, the only parameters that are required in the body for adding/removing members are memberId, memberType, and domainName. It does not look like email address is a required field for managing group membership.
In looking back at your previous link, it looks like your are trying to manage users through CyberArk Identity, which is a different product than CyberArk Privilege Cloud. As such, using the CyberArk Provilege Cloud IDN connector would not work in this use case. Since CyberArk Identity seems to utilize SCIM, I would recommend trying either the IDN SCIM 2.0 connector, the IDN SCIM 1.1 connector (I can’t find which SCIM version is supported by CyberArk Identity), or the IDN Web Services connector if neither of these connectors work for CyberArk Identity
Thanks for suggesting to use the IDN SCIM 2.0.
Long story short, IDN SCIM SaaS connector is able to provision the account with the email address, but the default provisioning workflow is also not able to provision the account without updating the provisioning policies. It needs to add the password in the provisioning policies, otherwise, it won’t work neither, but adding a password attribute that would be a piece of cake.
On the other hand, both connectors pull the two different sets of entitlements and I am still trying to figure out why and how it pulls the different set. I got the “Member of” not found error might be because there is an issue of the selecting entitlement. I will keep on researching why it is working
According to the CyberArk guideline, the connector should be the CyberArk Privilege Cloud instead of SCIM 2.0 SaaS. At this moment, the groups (safes) are not listed. I will keep on looking on this issue. Once, I figure out everything and I will post the solution in here
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
