How to handle automatic deprovisioning while SAP system is down?

[thomas_go1]

Hey there!

At the moment we have a problem with our IdM 7.2 SP9 which causes a loop error in deprovisioning of SAP roles.

The reason for that is the automatic deprovisioning combined with retry task function.

For example:

1.) User A have a SAP role which is valid to "2017-08-30".

2.) One day after "2017-08-31" IdM wants to deprovision that role because it's not valid anymore.

So far so good.. but if that kind of SAP system is down at the moment - where IdM wants to revoke the role - you will get a neverending error loop (every 30 seconds, retry task time) because IdM will try it as long till it's removed successfully.

We also have a "Maintenance Mode" in IdM 7.2 but that won't change anything because every audit (so every run of the deprovisioning task) will get saved in a temp table. If we would remove the "Maintenance Mode" for that SAP system - after it's reachable again - our system explodes because this deprov task would run a thousand of times.

In other way...

If you try to revoke manually a SAP role of an user while that SAP system is down, only two error tasks (depending on our retry tasks) will appear. After that the role will change the code from "1537" (Pending remove) to "4" (failed). In this state it's possible to retry or change the validity. In state "1537" (like it's permanent in the error loop) you can do absolutely nothing. No job with any removing operator {e},{E},{d},{D} can remove that privilege. Also removing the direct_reference doesn't work.

At the moment I have two working options:

1.) Removing the repository and connecting it again when SAP system is reachable.

-> We have over 50 SAP systems connected to our productive IdM. It would take a lot of time to remove and connecting them every time when a system is down.

2.) Directly deleting the link of the privilege in our IdM SQL-Database and revoking the privilege later manually on SAP system - when it's back online.

-> This way would work too, to stop the loop error, but sql delete statements on IdM tables are never a good idea. Also it's really not a best practice solution.

Both solutions are not even good anyway.

The next thing is...

We are starting working more and more with IdM Business roles - which could be a problem in future. In our IdM Business roles will be many different roles, of different SAP systems. So if only one SAP system is down meanwhile the valid to is reached or the IdM Business role is revoked because of other reasons automatically... then the whole IdM Business role can't be removed.

I hope you understood my problem and maybe you have some tips for me, how to handle this problem. Thanks anyway for your attention!

Best regards,

Thomas

Additional update #1:

Forgot to mention another problem caused by the loop error tasks. Every time the deprovisioning task starts a pending MSKEY is generated. That means our MSKEY counter is getting higher and higher.. and our counter is already very high due to problems like this.

Additional update #2:

Does anyone know if the standard implemented Maintenance Mode in IdM 8.0 solves the problem automatically? So... setting maintenance mode in IdM 8.0 on a repository - which is offline - prevents this kind of error?

[Steffi_Warnecke · Accepted solution]

Hello Thomas,

two things come to mind:

If an SAP system is down (for maintenance or what have you) and it will be down for a longer time, I deactivate the provisioning to that system (delete all the event tasks on the repository), so that my log isn't flooded with error messages everytime IDM tried to send something to that system (be it modify or role assignments etc) or read from it.

The downside of course is, that every action in IDM will be in "OK" status then and there is a mis-match between IDM and the backend. Normally, when a lot of stuff happened (because of automatisms), I just run two jobs, that send the current data from IDM to that system. By modifying a specific attribute, the account data gets updated and we have a dummy role, that can be assigned to all users of a specific system and this will synchronize all the role assignments.

So all is well again.

That should be easier to maintain than deleting the whole repository each time. 😉

.

I had an issue with a loop, too (but for LDAP), but that was because the retry counter for "Modify" was set to "1000". I changed that to "2", the retry count we have on almost all tasks.

.

Regards,

Steffi.

[thomas_go1 · Accepted solution]

Hey Steffi,

thank you for the clearly instruction of how do you handle that kind of problem.

I have noticed it as an idea for our system! 🙂

Best regards,

Thomas