Failed AD privileges

[Ckumar]

Hi Experts,

Presently I am working on SAP IDM 7.2 SP9. Need your help to fix one issue.

In my current project there are so many users whose AD privileges status is failed due to CN/DN issue while their account already exist in AD.

Is there any way to find all those users whose AD privileges status is failed in IDM. All these privileges are assigned under the IDM Attribute MXREF_MX_PRIVILEGE.

Could yopu please share the steps to fix these issue. I can not delete those AD account as they are already in use.

Thanks in Advance

Regards,

C Kumar

[terovirta · Accepted solution]

You can find the assignments in idmv_link_ext. The example query below returns all failed assignments.

mcThisMSKEYVALUE, mcOtherMSKEYVALUE, mcExecState, mcExecStateHierarchy, mcAssigner from idmv_link_ext where mcExecState = 4 or mcExecStateHierarchy = 4

You can find more information in this forum with search about the statuses (mcExecState or mcExecStateHierarchy).

You can for example create the job with toGeneric-pass that fetches all the failed privilege assignments and call the uRetryPrivilegeAdd in an entry script.

The first parameter of uRetryPrivilegeAdd is the user's MSKEY and next is the MSKEY of privilege: uRetryPrivilegeAdd(Int MSKey, Int Privilege)

regards, Tero

[jaisuryan · Accepted solution]

Hi Kumar,

Please retry as per Tero's suggestion but I would assume it should fail again as they already have account in AD.

If it fails again, then suggestion would be a 'fix' job with 4 passes.

1) Create a temp table (something Z_TEMP) with list of users who has failed assignments. SQL would be a

select mcThisMSKEYVALUE, mcOtherMSKEYVALUE, mcuniqueid from idmv_link_ext with (nolock) where mcothermskeyvalue like 'PRIV%AD_rep%' and mcExecState = 4 or mcExecStateHierarchy = 4

2) Create a "to identity store" pass to remove the existing privs. now you query the temp table.

select mcthismskeyvalue as MSKEYVALUE, mcuniqueid as LINKID, mcOtherMSKEYVALUE from z_temp

in destination tab, you remove the priv using bypass task as below,

MXREF_MX_PRIVILEGE = {D}{LINKID=%LINKID%!!BYPASS_MEMBER_TASK=1}<%mcOtherMSKEYVALUE%>

3) delay the execution for sometime may be 15 or 30 seconds using usleep() function

4) Assign the privs back to those users using to identity store pass. Query the Z_TEMP again.

MXREF_MX_PRIVILEGE = {A}{BYPASS_MEMBER_TASK=1}<%mcOtherMSKEYVALUE%>

P.S: You should set up a recon job set up in your environment which corrects this data.

Kind regards,

Jai

[terovirta · Accepted solution]

Jai Suryan wrote:

Hi Kumar,

Please retry as per Tero's suggestion but I would assume it should fail again as they already have account in AD.

Good point Jai, AD is pickier to existing users and memberships than for example ABAP.

regards, Tero

[jaisuryan]

Hi Kumar,

Can you please confirm if you have resolved this and if so, how? for the benefit of community. Thanks.

Kind regards,

Jai

[Ckumar]

Thanks All for your reply

Hi Suryan,

I was little busy with some other high priority issues so couldn't worked on the solution provided.

Most probably tomorrow i will work on this and confirm the same.

Thanks & Regards,

C Kumar

[Ckumar]

Hi All,

Thanks for your prompt reply!

Now I have fixed the issue. Special thanks to Jai and Tero to explain the solution step by step.

A small modification i have done in first pass of my job to fix the issue.

Jai Proposed that

1) Create a temp table (something Z_TEMP) with list of users who has failed assignments. SQL would be a

select mcThisMSKEYVALUE, mcOtherMSKEYVALUE, mcuniqueid from idmv_link_ext with (nolock) where mcothermskeyvalue like 'PRIV%AD_rep%' and mcExecState = 4 or mcExecStateHierarchy = 4

here query output was all failed privileges and roles as and operation was working between mcothermskeyvalue like 'PRIV%AD_rep% and mcExecState = 4 only; not with the mcExecStateHierarchy = 4.

I have corrected the query as

select mcThisMSKEYVALUE, mcOtherMSKEYVALUE, mcuniqueid,mcExecState,mcExecStateHierarchy  from idmv_link_ext with (nolock)

where mcothermskeyvalue like 'PRIV%' and (mcExecState = 4 or mcExecStateHierarchy=4)

and now its working perfectly.

Thanks everyone once again.

I will appreciate if somebody will explain my few doubts or link me the URL where i can find the answer of my doubts-

• What is the difference between mcExecState and mcExecStateHierarchy?

I have got below value for few users. PRIV:XXXXX and PRIV:XXXXX status is same (failed) then why values are different.

mcThisMSKEYVALUE	mcOtherMSKEYVALUE	mcuniqueid	mcExecState	mcExecStateHierarchy
ABC123	PRIV:XXXXX	123456	4	0
ABC123	PRIV:XXXXX	123489	1	4

• What is mcuniqueid and LINK ID and how SAP IDM creates these fields?

• Why we need to use BYPASS_MEMBER_TASK=1 while deleting and then adding the privilege back to the user.

Regards,

C Kumar

[jaisuryan]

Hi Kumar,

All your doubts are very well explained in help file. If you click on "help" button in right bottom of your MMC, you will get the help file related to your release. Below is the web version and I'm not sure if its the latest.

SAP NetWeaver Identity Management

Kind regards,

Jai

[Ckumar]

Hi Jai & Tero,

Above solution is working fine for those failed AD privileges which are assigned manually.

Today I have found few users whose Dynamic roles status is failed in IDM. These Dynamic roles have AD privileges so users having these dynamic roles got AD privilege as automatic privilege but again ststus of these AD privilege is failed and it seems that due to this failed AD privilege, Dynamic roles status is failed in IDM. All these users already has AD account.

When I ran the job (Which I used to fix the status of failed AD privilege), It assigns the AD privileges as manual privilege and status remain failed.

I tried the same with Role too. After running the job, dynamic role status gets changed to Pending but after few minutes its again changed to Failed.

Could you please suggest how to fix this.

Regards,

C Kumar

[Former Member]

Hi Kumar,

For already failed AD privileges you can use my first suggestion, to create a script that on error(already exists) to set the privilege to OK and then to retry the privilege with error state. Or you can directly update the privilege state into the DB, after you have selected the correct AD privileges(mcuniqueid) from idmv_link_ext table(you can use something like the select below):

select mcuniqueid, mcThisMSKEYVALUE, mcOtherMSKEYVALUE, mcExecState, mcExecStateHierarchy, mcAssigner , mcothermskey from idmv_link_ext where  mcothermskeyvalue not like '%:ONLY' and  mcuniqueid in (

  select mcuniqueid from idmv_link_ext where mcExecState = 4 or mcExecStateHierarchy = 4 and mcothermskeyvalue like '%:AD:%' );

and from the result you can get the needed mcuniqueid, then to update the mcExecState&mcExecStateHierarchy, directly into the DB(table mxi_link).

BR,

Simona

[jaisuryan]

Hi Simona,

Thanks, this info on updating mxi_link is what I was looking for. I was removing and then adding privs as a work around these days. What is the best way to update state in mxi_link table? Do I use "to database" pass with SQL updation or do you know any user function to do this?

And I suppose we should not filter out ONLY privs. If you try to create a user (without any group assignments) thru IDM who is already there in AD, then Priv:AD:ONLY will be in failed status and we need to reset the status for that as well.

Kind regards,

Jai

[Former Member]

Hi Jai,

You can use a SQL update directly from you SQL Developer tool(or some similar tool), below is an example:

update mxi_link set mcExecState = 1  where mcuniqueid in (

  select mcuniqueid from idmv_link_ext where  mcothermskeyvalue not like '%:ONLY' and  mcuniqueid in (

  select mcuniqueid from idmv_link_ext where mcExecState = 4 or mcExecStateHierarchy = 4 and mcothermskeyvalue like '%:ACTIVE_D:%' ) );

or you can list the mcuniqueid:

update mxi_link set mcexecstate = 1  where mcuniqueid in ('1111','22222','121212','333333');

and do the same for mcExecStateHierarchy.

But you have to be sure, that these are the correct mcuniqueids!

BR,

Simona

[former_member2987]

Simona,

I would be VERY hesitant to do this in production. At least not without a full database backup and making sure I had tried everything else.

Updating the back end tables like that is not a recommended best practice at all, and should really only be done on the advice of support.

Yes, I know there are people that do this all the time, but if you are going to suggest such an action, please make sure that you also include the safeguards.

Just my opinion...

BR,

Matt

[Former Member]

Hi Math,

As I said before, the first thing to do is not select the correct privileges(mcuniqueid) and to be 100% sure that the mcuniqueid is the correct one. Before executing the update you can always export the results from the select and then update the (mcuniqueid).

So as you asked, here are some safety notes:

  If you decide to use direct update into the DB you should:

• make a select to get the correct values for update
• check the results from the select
• export the results that you will update
• check the number of rows, that will be updated
• after you execute the update, before committing the results check, if the numbers of updated rows matches the ones you have from the select(if the numbers are different revert the update)

Note: yes, you should be very careful when updating into the DB, it's not recommended, but sometimes it's needed.

As I sad before, for me the better way is to create a script, that on error(already exists) to set the privilege to OK and to retry already existing AD privileges.

BR,

Simona Lincheva

[former_member2987]

Hi Simona,

While I am aware that YOU know this. I just wanted to make sure EVERYONE does.  There are too many out there that leap before looking and knowledge like this can be dangerous in their hands.

Matt

[Former Member]

Hi Matt,

Thanks , I assumed that no one will execute DB updates, before making the needed backups. But you are right, the direct DB updates are very powerful and dangerous tool, so I should have mentioned the needs safety notes.

BR,

Simona

[Former Member]

Hi Kumar,

As the privileges are already assigned into the back-end, the best way is to get the error message and in case that the error is for already existing AD group you can set the privilege to OK. So you will have the privilege OK in IdM, you can add the script into the job logging(Call script in case of error).

BR,

Simonna

[Former Member]

Hi Kumar,

There are two ways to get the currently attached privileges in IdM. First way is to use a custom SQL select. The IDMV_LINK_EXT2 view is appropriate to use because you can access the MSKEY,MSKEYVALUE, privileges and the context togeter.

The second way is to use a pass like to Identity Store to get not to set the values from MXREF_MX_PRIVILEGE attribute.

I think the custom SQL select is simpler and it could be something like this:

select mcothermskey, mcothermskeyvalue,mcExecState, mclinkstate from idmv_link_ext2 where mcExecState =4 ; (4 is fail 1 Ok)

mcothermskey is the mskey of the role/priv

mcothermskeyvalue  is the mskeyvalue of the role/priv

mcExecState shows the state of the assignment

mclinkstate shows the state of the entry 0 Ok 1 Pending 2 Deleted

You can check the documentation as well

Views for reference attributes

Regards

Kiril