We are facing an issue while running a certification campaign for ServiceNow roles in SailPoint. The campaign runs successfully, but the revocation of entitlements fails with the following error:
sailpoint.connector.InsufficientPermissionException: [ InsufficientPermissionException ]
[ Possible suggestions ] Furnish appropriate permissions to the user.
[ Error details ] Insufficient privileges detected. Status: 403 , Output: Operation Failed, Detail: ACL Exception Delete Failed due to security constraints, Status: failure
Currently, the functional user in our connection settings has the user_admin role in ServiceNow, which should include the permission to remove roles. However, the revocation only works if we elevate the permissions to admin in ServiceNow. Granting admin access seems excessive and doesn’t align with the principle of least privilege.
Could someone guide us on the specific permissions or roles that should be assigned to the functional user in ServiceNow to ensure successful revocation without overprovisioning access?
Does the user connecting to servicenow also have the x_sapo_iiq_connect.admin role assigned? I think I had the same issue when setting this up and had forgotten to add that in addition to the user_admin role
Thank you for the response. Those permissions are assigned.
If you see the connector documentation, it says removal of entitlement is not supported out of the box.
Just a sanity check, but does the ServiceNow ACL for sys_user_has_role table delete operation include the user_admin role? It should out of the box, but sometimes people like to modify ACLs
Ok, I think I see why this is mentioned in the documentation.
This particular connector makes use of Import Sets in ServiceNow. At a high level, these are only used for create/update operations, not delete (in general).
I traced a transaction and found that SailPoint will perform a POST to the API endpoint /api/now/v1/import/x_sapo_iiq_connect_sysuserhasrole
From what I can tell, the only thing that’s going to happen here is it’s going to attempt to insert a new record into the sys_user_has_role table, which it cannot since that record already exists. I’m not sure why there is an ACL exception that’s returned, but I get the same one when I try and run that operation in Postman
{
"error": {
"message": "Operation Failed",
"detail": "ACL Exception Insert Failed due to security constraints"
},
"status": "failure"
}
Frankly, I’m not sure why they decided to design the connector this way. I saw a post in the ServiceNow community forum that ServiceNow will not certify applications that perform delete operations on tables in the global scope, so that could be why.
I suppose you could accomplish this use case by building a custom SaaS connector… hey… I might consider doing that myself
@krunal_sshah another sanity check, have you tried revoking ServiceNow roles that SailPoint provisioned? I was just able to do that.
Also, one thing to check is to see if the role you’re trying to revoke from ServiceNow was inherited or not, because I have seen doing a revoke request via the access requests API will not do that
{
"detailCode": "400.1 Bad request content",
"trackingId": "040804dda9ae4ba89eaac2c471bdc18a",
"messages": [
{
"locale": "und",
"localeOrigin": "REQUEST",
"text": "The request was syntactically correct but its content is semantically invalid."
},
{
"locale": "en-US",
"localeOrigin": "DEFAULT",
"text": "The request was syntactically correct but its content is semantically invalid."
}
],
"causes": [
{
"locale": "en-US",
"localeOrigin": "DEFAULT",
"text": "Some items are not revocable: debab85bff02110053ccffffffffffb6"
}
]
}
One more thing to check… can you perform a direct delete using the table API with that user? Try it in Postman and make sure it works with the user your source is using
Yes. The access provisioned through Sailpoint are being revoked successfully. This is interesting observation.
I dont have visibility about the record in ServiceNow table. WIll need to check with our ServiceNow colleagues, Will look into that and get back to you.
Here are some observations that I noticed over the last few days
Role/Group removals are technically not done in the application installed in your ServiceNow instance, mainly because that would require deleting records from the sys_user_has_role and sys_user_grmember tables. In general, deleting from tables outside of your application scope is not something that’s allowed for applications in the ServiceNow store. So the application on your SN instance is only used for add/update operations (the majority of them being add)
As a workaround for this, it appears that the SDIM connector on the SailPoint side is removing access via direct table API calls into your ServiceNow instance, specifically the Table API DELETE operation. That’s why I was asking if you could make those calls using Postman to see if they work, because that’s what the SDIM connector is doing
I’ve had some email exchanges with the product management team, and I’m trying to get more clarification around what is supposed to be supported with this connector and why the documentation specifically mentions removal of entitlements is not supported.
I’m not following the workaround suggestion. Are you saying there are endpoints that do allow snow group removal? Just not through the OOTB connector right ?
