Remove priv associated with user only ID Store

[Former Member]

I am trying to remove a privilage that looks like it was orphaned after we removed all of a user associated Business Roles.    The Business Roles and all associated privs were removed except for 1  (we are seeing this with a number of users)

I have tried creating a job to remove the privileges but the job when it does work states it has modified the MSKEY successfully but the PRIV still shows assigned to the users in the backend Database and the Web Admin screen.

first the user with the priv that I can't remove in the Web Console:

as you can see it is not a direct assign, and when I select it, I do not have option to remove access.

Next we see that it is associated with the users account on the backend.

I created the following job to try and remove it, and it completes successfully but nothing happens.  The priv just stays there.  I have tried all types of switches on the MX_Privilage (d, D, e, E) to no avail.

I have also used the changetype of Delete and it still does not update the account.   Any input on this would help as the orphaned privs seem to be stopping me from re-provisioning a user back to their roles. It usually fails and if I remove the BR again more privs get listed as not being removed (note the users account does not even exist in the backend system the priv is associated with).   

[Chenyang]

Hi Michael,

Which IDM version are you running on? Have you tried the function uIS_PrivReconcile ?

Cheers,

Chenyang

[Former Member · Accepted solution]

You could try using

MXREF_MX_PRIVILEGE={BYPASS_VALIDATE_TASK=1!!BYPASS_MEMBER_TASK=1!!BYPASS_MODIFY_TASK=1}[D}PRIV:....:...

And see if it makes a difference. If not you need to give us more details of the assignment. Such as the mcOrphan, mcDirectAssign, mcLastAudit and other columns that I can't remember anymore 🙂

Btw: ChangeType=DELETE will delete the entry given by MSKEYVALUE, so careful with that. You should probably check that the entry itself is not marked as Pending Delete in the MXI_ENTRY.mcState column (think the value is 3 for pending delete) which could be blocking other operations to the entry.

[Former Member · Accepted solution]

@Chenyang =   we are using 7.2 sp8

@ Per Krabsetsve =  

I ran the above job and in test mode it said successful, but again when I ran in update nothing happened.   The orphaned priv is still listed associated with the users account.

below is what is listed for the users MSKEY.

mcMSKEY

mcEntryType

mcEntryState

mcDisplayName

mcMSKEYVALUE

mcIdStore

mcLastModified

mcCreated

mcDirty

mcChangeNumber

mcChangeCreated

mcEntryOwner

mcLastChangeOwner

mcEntryTypeId

mcDirtyDate

mcOperation

mcReconRun

mcReconStartTime

mcReconEndTime

mcFromMSKEY

mcToMSKEY

mcNumRoleAdds

mcNumPrivAdds

mcNumRoleDels

mcNumPrivDels

mcTrace

mcApprovalsChecked

mcACEntry

241772

MX_PERSON

3

Tang Leyna

e4000038

1

08:22.3

32:29.1

0

19770995

18317341

NULL

NULL

4

NULL

0

0

NULL

NULL

0

0

0

0

0

0

0

32:29.1

0

[Former Member · Accepted solution]

When the entry is in state 3 it is pending deletion, so the changetype=delete you ran earlier had an effect. As long as it is in state 3 you won't be able to add or modify the user or its assignments much. It could be that you have a lock, where the delete is not working because of the orphan privilege, and the orphaned privilege is stuck because the entry is marked for deletion.

You can also try the built in repair procedures that take mskey as input and see what they report. See this entry f.ex:

The safe way to go forward is to inform SAP Support about the states of both the assignment and the user and see what they recommend.

Me, depending on the criticality and how much effort it is to restore the user again, I'd be very tempted

- to manually set the entrystate to 0, then try the {bypass ...} again

- or clearing the orphan flag and settting the assignedDirect flag on the assignment.

Especially if there's nothing in the provisioning queue for the entry (select count(*) from mxp_provision where mskey = 241772) and no pending values (select count(*) from mxi_values where parentmskey=241772)

You could also set the same values on an entry/assignment in another system (dev) and see if the behaviour is identical and if resetting any of the values solves the issue.

Br,

Chris

[Former Member · Accepted solution]

Thank Per,

We have tried the Repair solutions provided by SAP as well as reconcile to no avail, and this is starting to affect more and more users.

Currently there is an SAP support ticket that has been open for going on 4 weeks now and we have recieved very little support in the matter.    This process worked perfectly pre-sp7 but once we moved to 8 none of our Business role updates work and users are now being left in this limbo state.

[Former Member]

Hi Michael,

Let me give you the suitable solution to fix orphan entry issue, Orphan entries are created when we set user role provisioning via Business role to Business role (Ex. MX_ROLE to MX_ROLE) or Business role to Privilege (Ex. MX_ROLE to MX_PRIVILEGE), when we assigned a Business role to the user the roles will be set within attribute MXREF_MX_ROLE and the privileges within the business role are set for attribute - MX_AUTOPRIVILEGE.

If you want to remove the privilege, you can use attribute MX_AUTOPRIVILEGE instead of MXREF_MX_PRIVILEGE to remove the orphan entry.

Regards,

Kishor

[Former Member]

Hi Michael,

There might be multiple reasons why using delete action in IDM UI might not work.

Most of reasons are corrupted assignments  - active links with disabled flag on.

( check select mcthismskey, mcothermskey, mcexecstate, mcdisabled from mxi_link where mcthismskey = user-mskey and mcothermskey = priv-mskey // active links shouldn't have disabled flag (mcdisabled=1))

This is just one example, reasons might be in tens.

To delete your privilege, you can first try to repair already assigned links, so provisioning framework will catch your deprovisioning actions in UI or you can try to delete it directly from database:

delete from mxi_link where mcuniqueid in(

select mcuniqueid from mxi_link where mcthismskey = user-mskey and mcothermskey = priv-mskey) and then remove it from backend manually which is not likely recomended, but it works.

Lukasz