Problem with privilege assignment in IDM

[Former Member]

Hi everyone,

I'm facing an issue with SAP Identity Management, and I would need advices.

I connected an ABAP system to IDM, and I'm able to create a user with a productive password.

My problem concerns privilege assignment.

Case 1 :

Via IDM UI I create a new user for my backend system and I affect him the required role.

The user is well created in the ABAP System but without any role.

In the Job Log (Management console) I don't see any task trigered concerning the privilege assigment

Case 2 :

However when I try to modify a user which was loaded with the Initial Load, I'm not facing any issue.

In the job log I can see all the step concerning the privilege assignment. But in this case in IDM UI, I can´t see the affected role. But in the backend system the privilege are affected.

In the two cases, PRIV:<Repository>:Only is affected to the user.

Identity Management version : 7.2 SP 9

I didn't perform any modification to the hook configuration.

Thank you in advance for your help.

[Former Member]

Hi,

You can check if the privileges(ABAP roles) are loaded correctly(if the needed triggers are set), as the privileges themselves have a triggers (in most of the cases they inherit the repository settings).

Or you can check if the access is pending for some reason.

BR,

Simonan

[Former Member]

Hello Simona,

Thanks for your reply.

The privileges are well loaded, the privileges are all in Inherited mode.

I don't have any pending values.

I think I need to clarify my problem.

For example :

If I want to add the Privilege PRIV:PROFILE:<REPOSITORY>:SAP_ALL to a user

The affectation works only with a loaded (Initial Load) user, not with a new created user (per IDM UI)

For a same role I have two different results.

[Former Member]

Hi,

Ok, so your problem is only with users created after the initial load(directly from the UI), for the rest of the users the access is provisioned (again you can trigger provisioning from the IdM UI for those users).

If that is the case:

1 - check the creation process - if the SYSTEMS privilege is assigned okay(check if the provisioning did assign the SYSTEM privilege)

2 - check again the link view: select * from idmv_link_ext2 where mcothermskeyvalue = 'YOUR_USER_ID'; and confirm that there is no pending access for this user.

Please, try the steps and replay with the results.

BR,

Simona

[Former Member]

Hi,

I tried to create a new user.

1- The system privilege is well assigned.

2 - The request select * from idmv_link_ext2 where mcothermskeyvalue = 'YOUR_USER_ID'; returned a line concerning my created user. But the line doesn't appear anymore.

mcUniqueID

mcLinkState

mcLinkType

mcThisMSKEY

mcOtherMSKEY

mcThisEntryType

mcOtherEntryType

mcContextCategory

mcContextMSKEY

mcContextEntryType

mcContextStr1

mcContextStr2

mcContextAuto

mcAssigner

mcAddedTime

mcModifyTime

mcValidFrom

mcValidTo

mcReason

mcAssignedDirect

mcAssignedDynamicGroup

mcAssignedInheritCount

mcAssignedMasterPrivilege

mcOrphan

mcSoDViolation

mcNotAllowedFor

mcUnsupportedContextType

mcMissingConditionalContext

mcChangeNumber

mcAttrId

mcDirty

mcCheckLink

mcExecState

mcProvAudit

mcDeprovAudit

mcModifyAudit

mcModifyVal

mcAddAudit

mcDelAudit

mcValidateAddAudit

mcValidateModValAudit

mcNotifyAudit

mcProvisionAudit

mcDeprovisionAudit

mcModify

mcModifyValidity

mcModifyNewValidFrom

mcModifyNewValidTo

mcAuditID

mcGroupGUID

mcRepository

mcProcessInfo

mcRequestId

mcDirValidFrom

mcDirValidTo

mcModifyReason

mcExecStateHierarchy

mcValidateDelAudit

mcDisabled

mcLastAudit

mcDelRequestId

mcMasterPrivMSKEY

mcNoMasterAudit

mcMasterPrivLinkId

mcAttrName

mcThisOcName

mcOtherOcName

mcCtxOcName

mcThisMSKEYVALUE

mcOtherMSKEYVALUE

mcCtxMSKEYVALUE

60318

0

0

48491

48490

16

14

0

NULL

NULL

NULL

NULL

0

29481

18.01.2016 16:51

18.01.2016 16:51

NULL

NULL

NULL

1

0

0

0

0

0

0

0

0

1001742

565

0

NULL

1

NULL

NULL

NULL

NULL

NULL

NULL

NULL

NULL

NULL

NULL

NULL

NULL

NULL

NULL

NULL

720

NULL

NULL

29481

NULL

NULL

NULL

NULL

1

NULL

0

720

NULL

NULL

NULL

NULL

MX_ENTRY_REFERENCE

MX_PENDING_VALUE

MX_PERSON

NULL

MX_48491

TST_USR

NULL

BR

Nico

[Former Member]

Hi Nico,

I can see that in the idmv_link_ext2 view you have only one record: MX_48491 - TST_USR(if your user is MX_48491, I can't see the account and the system privileges attached to him),

so can you check in table:  select * from mxi_link where mcthismskey=48491; - here you will have all of the information for the user's access.

BR,

Simona

[Former Member]

Hi Simoa,

Sorry for the previous result

mcUniqueID    60318

mcLinkState    0

mcLinkType    0

mcThisMSKEY    48491

mcOtherMSKEY    48490

mcThisEntryType    16

mcOtherEntryType    14

mcContextCategory    0

mcContextMSKEY    NULL

mcContextEntryType    NULL

mcContextStr1    NULL

mcContextStr2    NULL

mcContextAuto    0

mcAssigner    29481

mcAddedTime    18.01.2016 16:51

mcModifyTime    18.01.2016 16:51

mcValidFrom    NULL

mcValidTo    NULL

mcReason    NULL

mcAssignedDirect    1

mcAssignedDynamicGroup    0

mcAssignedInheritCount    0

mcAssignedMasterPrivilege    0

mcOrphan    0

mcSoDViolation    0

mcNotAllowedFor    0

mcUnsupportedContextType    0

mcMissingConditionalContext    0

mcChangeNumber    1001742

mcAttrId    565

mcDirty    0

mcCheckLink    NULL

mcExecState    1

mcProvAudit    NULL

mcDeprovAudit    NULL

mcModifyAudit    NULL

mcModifyVal    NULL

mcAddAudit    NULL

mcDelAudit    NULL

mcValidateAddAudit    NULL

mcValidateModValAudit    NULL

mcNotifyAudit    NULL

mcProvisionAudit    NULL

mcDeprovisionAudit    NULL

mcModify    NULL

mcModifyValidity    NULL

mcModifyNewValidFrom    NULL

mcModifyNewValidTo    NULL

mcAuditID    720

mcGroupGUID    NULL

mcRepository    NULL

mcProcessInfo    29481

mcRequestId    NULL

mcDirValidFrom    NULL

mcDirValidTo    NULL

mcModifyReason    NULL

mcExecStateHierarchy    1

mcValidateDelAudit    NULL

mcDisabled    0

mcLastAudit    720

mcDelRequestId    NULL

mcMasterPrivMSKEY    NULL

mcNoMasterAudit    NULL

mcMasterPrivLinkId    NULL

mcAttrName    MX_ENTRY_REFERENCE

mcThisOcName    MX_PENDING_VALUE

mcOtherOcName    MX_PERSON

mcCtxOcName    NULL

mcThisMSKEYVALUE    MX_48491

mcOtherMSKEYVALUE    TST_USR

mcCtxMSKEYVALUE    NULL

The request select * from mxi_link where mcthismskey=48491; returns me no result.

[Former Member]

Hi Simona,

Finally, the privilege PRIV:REPOSITORY:ONLY is in error for my user.

That's why I can't assign other roles. I found this document and assigned a mater privilege to my repository. But it doesn't change anything.

[Former Member]

Hi Nico,

First check why your only-privilege is in error state : select * from mcmv_audit where auditref in (select mcaddaudit from mxi_link where mcthismskey=%user_mskey% and mcothermskey="only_mskey"); - as well you can check directly into the global log and see if you have an error there.

As for the current users (the ones that are already in error state), setting the repository master privilege won't fix them, but you can try and sync a new user.

BR,

Simona

[Former Member]

Hello Simona,

Thanks to your request I could see that, as you said I have a trigger problem.

The request returns me "!ERROR:Trigger_onFail"

I looked at my configuration.

Here is the Repository configuration :

Here the PRIV:REPOSITORY:ONLY configuration

Sould I modify something ? I don't see where the problem comes from.

Thanks and Regards

Nico

[Former Member]

Hi Nico,

If the AD creation was triggered, then the problem is not in the trigger itself, but in some of the connection tasks(you should check if you have an error inside the AD connector).

Please, check the connector tasks local logs and check if the user didn't failed in some of the creation steps(Create AD user, Enable AD user, if you have an exchange - Create AD exchange.. and so on) or you can check if HOOK_TASK_1 - is set correctly (check if you have the correct plugin for AD - Create AD User).

BR,

Simona

[ganesh_s7]

Hi Nico,

Master privilege in PRIV: REPOSITORY: ONLY should be the System privilege. PRIV: SYSTEM: REPOSITORY.

Also check if the reconciliation job (syncing the roles from backend) has run properly. If not, run it once.

As mentioned by Simona, please check the  attribute triggers at System PRIV level, modify trigger attribute at individual PRIV level.

MSKEY 48491 mentioned above seems to be referring to Pending values.  Don't see any entries of system PRIV assignment for required user (tst_usr).  Please check if system PRIV had been aligned for required user.

[Former Member]

Hi Ganesh,

No, the master privilege is the Repository ONLY privilege.

The idea of the master privilege is to trigger the provisioning/deprovisioning (User Creation, termination and the access provisioning).

The idea of the SYSTEM privilege is to trigger the master data modification (back-end updates - master data update and the lock/unlock of the users), so if you change the first name of the user and you have listed this attribute inside the SYSTEMS privilege triggers, the modification task will be triggered.

BR,

Simona