A large number (200+) entitlements in our environment have remained marked as requestable after properly executing the PATCH /beta/entitlements/:id to make them not requestable.
The error returned is: The server did not find a current representation for the target resource.
We believe these entitlements have been moved or renamed in the various affected sources - for example in AD, moved to a different OU. They are still assigned as entitlments to individual AD accounts, and therefore are in a state where IdentityNow has lost track of them. (aside: this wouldn’t happen if SID were used as the value instead of distinguishedName).
If the API that detects requestable entitlements can display these as requestable, we need the API that updates the requestable status to function so that we can turn this undesired state off.
Any thoughts? I’ve entered a ticket and engineering is trying to figure out how to disable requests for these entitlements in this undesired state. If an entitlement can be shown on the request center, it seems like the update API should be at least able to update that one requestability portion.
I’m thinking if the entitlements moved from one OU to another, it’s possible they were deleted and new ones were created with different Ids, which would explain the 404 response you’re getting when trying to patch them.
That’s exactly what happened with the AD ones - a little less clear on ServiceNow and Azure. The cause of the 404 isn’t the major concern. It’s that these invalid entitlements are requestable and there’s no way to turn off the requestable status.
We are less interested in prevention than in repair at this time. These invalid entitlements are preventing us from actually using the requestable entitlements feature.
That’s actually how I found the issue. When we decided we wanted to try requestable entitlements, we found about 80,000 of them had been set to requestable by the system. I used the /beta/entitlements/bulk-update API to work through those, but found some stragglers. I worked through the remaining entitlements one by one with the /update API.
The /beta/entitlements/bulk-update executes without error, but has no effect on these entitlements.
In short, they’re requestable and they’re staying that way until either the API can handle entitlements in an error state or these entitlements leave the system - hint, I also tried deleting the entitlements.
Support has noted that these entitlements are in an invalid state because they may have been renamed or moved but are still associated with user accounts. The majority of them are distribution lists in AD - these get renamed and moved to a deleted OU pretty commonly in our org.
So the what happened is pretty clear - but I’ve got 250 “bad” entitlements. IdentityNow knows something about these entitlements. They show up in search - which is fine. They show up in request center - but they shouldn’t.
Support and engineering are trying to devise a workaround to directly modify the requestable property, but from my perspective, if the search API sees them as requestable, I should be able to mark them not requestable via an API.
That’s a bummer, but like you mentioned before, the connector preferring DN over something immutable like SID is problematic. Same issue with accounts exists
Ultimately, the services team had to code something special to hunt these entitlements down for us and correct them on the back end. Hopefully recurrences don’t happen unless the API gets addressed.