cancel
Showing results for 
Search instead for 
Did you mean: 

Issue with Provisioning using Stored procedure : mxpt_check_isprivilege_account

deepakkg86
Participant
0 Kudos

Hello Experts

We have installed SAP IDM 7.2 SP8 with SQL Server 2008 , While using standard SAP provisioning framework we are getting issue in Provisioning task. This tasks check for a stored procedure : mxpt_check_isprivilege_account as in below screenshot and always returning 'FALSE' result and execute user role assignment tasks although user doesnt exist in backend system.

Below is the screenshot of Provisioning Task and my repsotity even tasks:

Regards

Deepak Gupta

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

This check is to see if the processed PVO is for the master privilege (PRIV:<REP>:ONLY) which has the attribute MX_IS_ACCOUNT set. If you have privileges running through this workflow and into the false node you probably have them set up without the master privilege reference (MX_REQ_PRIV).

The master privilege should have been set by the initial load jobs. You can start by checking the privileges and make sure they have the MX_REQ_PRIV set correctly, and if not, check your initial load jobs to see why not. If you've created the privileges outside the initial load you need to make sure they include a reference to the repositorys master privilege.

Br,

Chris

deepakkg86
Participant
0 Kudos

Hello Per

I checked, Repository master privilege is already setup correctly in Privileges with MX_REQ_PRIV attribute.

The same stored procedure is being used in Deprovisioning also and there also it create the same issue and never goes into True to delete the user account when last privilege is removed.

Any other thing which I need to check ?

Regards

Deepak Gupta

Former Member
0 Kudos

If you have a master privilege set on a privilege, the privilege will not start its Add Member "provision" task unless the master privilege is already assigned to the user. If you have set a "No Master Task" this will be run when you assign a privilege which has a master privilege that is not (yet) assigned. The No Master Task should do whatever logic is required and then assign the master provilege to the user (or don't have a no-master task set at all) so that the Provision task is run for the master privilege. When the master privilege runs through the "Provision" task THEN the procedure will return TRUE.

So when you say that when the user is assigned a privilege the provision task starts on that very same privilege, then the master privilege is already assigned to the user and the account creation should have taken place already.

If the master privilege is the one being provisioned or deprovisioned the procedure will return TRUE. In no other situation will it return TRUE. The procedure does not check if the current privilege is the first or the last assigned to the user in the repository, this only happens in deprovision when the master privilege is the one being removed and is done by the SQL statement in the "Check for any noaccount privileges"  task. If its not the last assignment in the repository it will trigger deprovision for the remaining privileges, wait for the tasks to finish, and then remove the users account.

This should be outlined in the Provision Framework documentation in better detail than what I can write up here.

br,

Chris

deepakkg86
Participant
0 Kudos

Thanks Chris

I am getting issue with couple of more things, Can you please help with below :

1. While removing direct assignments I am getting Error :

Unable to set value for attribute Assigned Privileges. Detailed information (may not be translated): Entry does not exist

2. I am geting some warnings in System logs, They are not affecting any jobs but still I am curious to know what these are :

Syslog warning: MXP_PROV_BASIC: Task not activated or undefined entry

Syslog Warning: mxi_create_PVO: neither MX_APPLICATION_ID for 5455 (During priviege assignment)

Syslog Warning: Constant ENABLED_FOR was not defined in the repository (8) (While apply pending on Group job)

Regards

Deepak Gupta

Former Member
0 Kudos

The first could be several problems and is not easy to pinpoint. You could have an entry with a broken reference to an inactive user causing problems. This issue should probably be a separate topic or a css ticket.

neither MX_APPLICATION_ID for 5455 is related to grouping and indicates that grouping multiple entry types in a group (roles + privileges for example) is not allowed with application grouping.The repository probably has grouping/Separate by application selected. The number should be the role or privilege the user is added to.


Task not activated or undefined entry means that you have a script trying to run uProvision on a task that is private (not public). The entry in the syslog should also contain the taskid in question formatted as TASKID=<taskid>.

Syslog Warning: Constant ENABLED_FOR was not defined in the repository (8) means that the job that reported this is using %$rep.ENABLED_FOR% somewhere or trying to read the constant in a script, but the constant is not defined in repository with ID 8.

Br,

Chris

Message was edited by: Per Krabsetsve

Answers (1)

Answers (1)

deepakkg86
Participant
0 Kudos

Thanks Chris.