Share all details about your problem, including any error messages you may have received.
We’re trying to investigate a curious issue we’re seeing. We have contractors on hand to help us solve the issue, but so far they haven’t been able to answer the main question regarding our issue.
During a certification, what we’re seeing is that for a specific application, if a manager revokes some access on the target application, we will randomly see provisioning transactions filtered with the reason ‘Does Not Exist’. The end user definitely has the entitlement/s being revoked - verified on the target application and the cube - and there were no issues during account and group aggregations. My question to our contractors is what process does the certification use for revocations? The behavior (to me) is different than normal provisioning. Revocations don’t appear under the identityRequest objects in the object explorer - just under provisioning transactions after the fact. As well, we’re seeing what we’ve dubbed ‘the loop’, where if a user has multiple entitlements on the target application, we’ll see a transaction for the first entitlement, then another transaction for the first entitlement plus the next, and then another transaction for 1 and 2, plus the next…and so on. The reason I suspect that certifications use another process is we don’t see this type of behavior for normal remove requests where multiple entitlements are selected to be removed. Am I looking at this the wrong way, or is my instinct guiding me in the right direction?
I hope this all made sense - please let me know if I need to clarify anything further.
The target application where we’re seeing this problem is RACF. There are no issues with removing entitlements using the normal request page - just in certifications. And it’s totally random - we haven’t been able to find any kind of pattern.
There is no different provisioning for Certification, it is same as others. It won’t display under identity cube because there is no Access Request created for it.
Every Provisioning activity will be displayed under Provisioning Transactions, Success and Failures. You can avoid Provisioning Transactions for Success with some configuration as well, to avoid a lot of objects, as there will be many successful transaction where as failures would/should be a very few.
As per the error message, the entitlement might have been deleted already.
Is this the way we suppose to remove entitlements in RACF, I don’t think so. I have worked a little in RACF that too 5 years back, do we need to process entitlement revocation like this ?
I don’t think so, since first entitlement is already removed in first transaction, in 2nd transaction 1st entitlement revocation will return as doesn’t exist which make sense.
We need to check if there is any Before Provisioning Rule or a logic implemented in your LCM workflow specifically for Certification something like this, if source is certification (for Access Requests, source will be LCM) follow this logic.
Good morning,
Thanks for the reply! So - we do have a before provisioning rule specifically for our RACF connectors. I had no hand in it, but as far as I can tell, depending on the account request operation, either:
Account Request Operation Disable - set the default RACF group to a predefined group used only to indicate a terminated user, and continue to disable the account
Account Request Operation Modify - if the Attribute Request Operation is Revoke/Remove, check if the revoke/remove is for the default RACF group of the user. If so, do something different.
There’s not much else other than logging. I looked at LCM Provisioning workflow and not seeing anything that changes the behavior depending on the source. It appears to be OOTB.
You mentioned ‘as per the error message, the entitlement might have been deleted’. We have a daily audit that checks for all provisioning transactions with certification as the source that bear the message ‘Does Not Exist’, and while the issue seems to be sparse, I can definitely confirm that regardless of the ‘Does Not Exist’ message, the identity did indeed still have the entitlements that were revoked. Excluding entitlements being already removed, what else could cause provisioning to throw this message? Is this specific to RACF?
One other thing to note, the daily audit also recently returned that an identity did not have entitlements that they definitely did have. The audit looks directly at the application link and returns entitlements for that link. Is there any process that would give the appearance of a lack of entitlements at one moment, but then show true data at another moment?
