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!

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Steffi Warnecke

    Hello Brandon,

    I use MX_REQ_PRIV on some of my repositories and in 7.2 it’s simple to assign the “only” privilege, because it’s a field on the repository tab “Privilege”.


    If you select a privilege the constant will be added to the repository and contain the mskey of that privilege (as you wrote).



    PS: Nice write-up! I could follow you.

    If you are unsure about the complex stuff (that it’s comprehensible explained), just use some flow charts or screenshot to underline your words. My experience shows, that helps. 🙂

    1. Brandon Bollin Post author

      Thank you Steffi. You’re also right. Taking some screenshots and making diagrams would go a long way to better explain complex topics. You’re also right that 7.2 has those fields as part of the repository setup and I should have mentioned that. I will say though that it is possible to have the MX_REQ_PRIV_NOMASTER_TASK repository constant in place without a master privilege assigned. If you use the GUI, you have to specify a master task before the no master task filed un-grays and allows you to edit it.

  2. Ridouan Taibi

    Hi Brandon,

    Nice writing!

    I am not sure why someone wants to do this differently, as this functionality was introduced to prevent the assignment task being executed before the account was created in the backend system.

    If you have some requirements to check something before performing the assignment, then it’s a best practice to use the validation tasks.

    Good luck!

    Best Regards,

    Ridouan Taibi


Leave a Reply