Privileges being removed automatically

[former_member586836]

We have a a couple of similarly configured privileges which appear to be being deleted by the system.  The deletions are always occurring at 2am or shortly thereafter.  I have searched our configuration and I can't find any job running at 2am that might account for this.  Equally if I check the audit table the audit ID of the deprovision task (triggered by the privilege delete) has a REFAUDIT entry that relates right back to the original provision event a number of days prior.  I'm 99% sure there is no pending value object at play here, not least because the provision process (it's attached to the repository) completes as expected.

Does anyone have a suggestion of how I can deprovision event back to its trigger point?

Interestingly I don't believe this was not an issue in 7.1, we've only started to see this issue since we moved to 7.2 sp7 a couple of months ago.

Thanks!

[Steffi_Warnecke · Accepted solution]

Hello Pete,

do you have the history tab enabled, when looking at the details of a user in the web UI? There you could look for the attributename "MXREF_MX_PRIVILEGE" and in the next column for you priviledge, that gets deleted (by looking for the delete-operation in the following column). In the last column you'll see, who or what did this. Per task-id you could search for the "guilty" one. ^^

Since you can order the tasks and jobs in the status page in the Identity Center Console, you should find the task easily and could go on from there. At least that's the way I normaly start the hunt. ^^

Regards,

Steffi.

[former_member586836]

Thanks for the good pointers!  I think I've made progress, there is reconcile job triggering at the right time (thanks Steffi for the pointer to Status node to find that) and despite the log saying it has done neither modification or delete there are entries in the ascii file it creates saying it's performed clean up via uIS_PrivReconcile.

What I'm not sure about now is why the role/privilege assignment to users is not clean.  There are no errors in the provisioning process.  This is looking similar to an issue we had post upgrade (7.1 to 7.2) where one of our roles failed and had to be recreated.  If it is the same issue that would be pain as I'd have to create a new role and run a mass deprovision/provision event to switch all the users over....anyone got a better idea?

Thanks again for the help!

[former_member190695]

Hi Pete,

I have seen your issue before and this occurs in case an assignment failed due to some reason. The system will then try again until the assignment has been reconciled.

Do you have MX_RECONCILE set to TRUE? Are these GRC related privileges?

Also check the Dispatcher logs and options as dispatchers could also trigger tasks as part of the evaluation or housekeeping actions.

Please check the idmv_link views and ensure the link is not broken between the privilege and the user. You could also enable trace providing the MSKEY of  a user in the global constant MX_TRACE_ENTRY. You can then view the trace either in the view idmv_trace_data or in the UI.

Regards,

Ridouan

[former_member2987]

Trace is definitely the way to go to look at the information that exists for the entry.  You might want to augment this, Pete, by putting a task on the modify of MXREF_MX_PRIVILEGE with a script that puts the changes in the log.  This might help give more visibility to the issue.

Matt