Conditional Task for Master Privilege when provisioning

[paul_abrahamson_sap]

Hi All,

For our Active Directory LDAP repository and also another database repository we have a problem where the repository's 'Provisioning' task chain is being initiated multiple times by the assignment of privileges associated with these repositories. One of the privileges assigned in a batch is the master, the others are all 'secondary' privileges for the repository.

We want a framework which only does the account creation parts of a provisioning task group for the 'MASTER' privilege for that repository.

We did explore privlege assignment grouping on the repository, but in the case of our AD, each privilege does actually need to be provisioned (they are distinct AD security groups) but we only want the AD account creation steps to be performed for the Master privilege. We have set up the privilege policy settings to wait for the master privilege, but because all privileges are added at the same time, this doesn't seem to work.

There is a stored procedure mxpt_check_account for a conditional task which allows you to only provision if the ACCOUNT<repository> attribute is not set yet. This is ok, but if you have 5 privileges all added at the same time and they all start running before the step which sets the ACCOUNT<repository> attribute, then all five of these task chains will already be in the wrong part of the conditional processing in the provisioning queue.

So what we need is another stored procedure which can be put in a conditional task to return if the current audit record is for the repository's Master privilege. This way we can control which tasks are done for the main account creation in that repository and which tasks are simply additional groups, or services in that repository.

I had created a stored procedure which based its logic on the idea SAP used in their global script sap_getGroupDN which uses the attribute id and bchecksum value from the userid field in the current audit record and then reads the matching mxiv_sentries record. However from this [Note 1540835 - LDAP group assignment fails due to ambiguous bchecksum|https://service.sap.com/sap/support/notes/1540835] it seems this logic is flawed. Their solution is to use context variables in the JavaScript, but I'm not sure how context variables can be processed within a stored procedure on a conditional task.

I have seen these other threads related to repeating and grouping of tasks see:

SAP IDM : Master privilege and Grouping

Privileges not Grouping when Provisioning to ABAP Systems - I'm not too keen to go down the route which suggests of modifying the SAP Standard mxi_validate stored procedure.

We're on IdM 7.1 SP05 Patch Level 3

Thanks

Paul

Edited by: Paul Abrahamson on Apr 18, 2011 11:47 AM

[Former Member]

Hi Guys,

You can use Master privilege to fix this problem.

With the Master Privilege, you use the framework as it is delivered by SAP, which is nice in case there is an update from SAP.

Please let me know if you need more detail

Thanks

Lahcen

[paul_abrahamson_sap]

Hi Lachen,

We've tried with Master Privilege and told the repository to wait for the master privilege, however as the master privilege and all our AD Group privileges are assigned at the same time, they all get placed in the provisioning queue in parallel. In 7.1 we believe that the 'wait' for master privilege will only wait for the approval tasks to be completed and not provisioning tasks. Is my understanding correct?

If SAP have changed this could you provide details e.g. SAP Note etc.

We've been told by SAP that in 7.2 this does work according to our understanding.

Thanks

Paul

[Former Member]

Hi,

Any tasks waiting for the master privilege, will wait until the privilege is actually assigned within IdM (i.e. until the MX_ADD_MEMBER task has completed successfully).

The MX_PROVISION task is executed after the assignment takes place in IdM, and will as such, run in parallell with the privileges waiting for the master privilege.

In the provision framework of 7.1, the MX_ADD_MEMBER is actually used for approvals, while the PROVISION is used for provisioning to the target system. (This also means that you will get the privilege in IdM, before it is confirmed created in the target system).

In 7.2, we've introduced a MX_VALIDATE_ADD_TASK, which is used for approvals. The provision framework will then use the validate-add for approval, and the add for provision, Therefore, waiting for the master privilege in 7.2, will acutally wait for the assignment to be successfully done towards the target system. The MX_PROVISION task is no longer used (but could for example be used for alerting of a successfully assigned privilege).

Hope this helps.

Best regards

John Erik Setsaas

Development Architect IdM

[Former Member]

Paul,

The issue you are describing is one that we had as well, even AFTER modifying the mxi_validate script. The problem is that the account creation check and the account creation are two seperate operations. As you mentioned, it will group all the checks simultaneously, which say "no account created yet" and then it will group all the creations, of which all but one fail.

The solution we implemented was to make the check and the setting of the "created" flag into one single atomic operation. We did this by making our own version of the stored proc "dbo.mxpt_check_account_bs", which is used on the CheckUserCreate task to see if account creation is necessary.

This is our version of the script (had to pastebin it, as it is apparently too long for code tags here):

http://pastebin.com/raw.php?i=chqYZRKm

We basically are now just setting "TEMPCREATION" as the TEMPACCOUNTxxxxx flag, so the next check will think the account is being created!

I believe it involved flipping the truth values around, so the task had to be reorganized with "CreateADSUser" swapped into the True branch, and anything already in the True branch swapped to the False branch (in our case, just some basic logging). It looks like this:

http://min.us/mvnEzVd

The first image is just an overview of the new structure, and the second image is showing that we changed that task to use our custom stored proc.

This might be a somewhat viable solution for you? If you have any questions, let me know!

[paul_abrahamson_sap]

Thanks Adam for the complete reply.

This has definitely given us food for thought. Does the setting of attribute values in this way place subsequent 'Modify' events in the provisioning queue?

[Former Member]

I believe so, but we've modified the script that handles that too (sap_modifyUser) and added a few things to the list of attributes to ignore, so it doesn't really do anything when we change just that attribute.