PRIVs Not Showing Up in SAP Systems, IDM Shows OK Status

I have a project I’m working on right now where the system is attempting to provision to an SAP repository before the user’s account is created. When this happens, you’d think that IDM would show a, “Failed” status next to the privilege in question but it’s showing an, “OK” status instead. This originally led us to believe that IDM was provisioning to the target system but the SAP function was somehow dropping the request without issuing an error to IDM. When we looked at the change documents on the user’s account, we’d see the privilege wasn’t present and there was no history of the privilege ever being present so the research would support faulty handing on the SAP side.

The user’s account privilege and the access privileges were being assigned at the same time so at some point in the provision queue, the assignment of the rights went through before the account privilege which creates the account. Thus, we have an account with no privileges assigned but the PRIVs on the IDM side show, “OK”. How do we fix this?

Two things can be done here. First, you could use the MX_REQ_PRIV constant. This is an undocumented constant so, you’re welcome. This can be placed as an attribute on the privileges themselves or as a repository constant. Either way, the value should be the MSKEY of the PRIV:$rep.name:ONLY privilege. In theory, you could put any privilege a user must have before they can be provisioned to the target repository. If you want to get creative and use it that way for some other custom work you’re doing, have at it. Whatever repository level add task you have assigned will NOT fire until the user has this required privilege! This is important to note because if you’ve inserted something custom in your provisioning framework, those tasks will never be reached until your user has this required privilege.

Second, if you’re assigning a system privilege to a user who doesn’t have an account in that target repository, you might just be assuming you also want the account privilege assigned so the user is created. Write a task to do this and then use the repository constant MX_REQ_PRIV_NOMASTER_TASK, assuming you don’t have a master task assigned at the privilege level, then set the PRIV:$rep.name:ONLY as the master privilege for this repository. The system will check for a master task at the privilege first. If there’s nothing there, this task you created will assign the account privilege and you’re in business. This occurs before the MX_REQ_PRIV constant is checked as well, FYI. Lastly, this task is executed on a timed basis, not at the moment a privilege is assigned to a user in this repository. Any assignments to this repository will queue up and when the timed interval is reached, anything in that proverbial queue will run through the task.

I tried to describe this as clearly as possible but I realize some might not follow. Please let me know if you have any questions and perhaps suggestions on how to improve my writing. As always, likes and ratings of this post are appreciated as they just help me get better at blogging! Happy trails y’all!