Hello All,
After having a support ticket open for 2 weeks and still not getting any type of response or feed back from SAP I am again coming to the community for some insight.
background: Because of multiple issues with IDM resources not cleaning injesting users from our backend repositories and merging them with the acccounts that were loaded via HCM during go-live as well as jobs being set up incorrectly that caused failures that crashed the provisioning process we have a large number of users that are constantly failing to be assigned privs and business roles because their identities do not match what is not only in the IDSTORE but also the backend.
I have had a couple of discussions here about how to update missing privs in the database and though those have been successful on the database side they still have not resolve what is displayed in the web gui for the user and thus items still fail to provision.
I have a couple of types of issues:
1. When I Role or Privalage is removed via the web admin it does not fully remove the associated privs on the users table associated with the mskey and thus does not remove the backend access. Even though the process states completed items are still there. This causes issue when we try to re-apply the acccess it fails as accounts or pivs are already there.
2. backend access is not correct with whats in the users table and also whats listed in the user admin screen. When you go to remove assocaited Business roles and readd to see if it will correct itself the business role shows completed but if you go to the change screen of the user the BR is there but none of the sub roles are listed (failed, pending, ok...nothing is listed)
I have tried running the reconcile and repairentry stored procedures but so far they just run for hours, start up multiple Runtime tasks that dedlock each other and crash the dispatchers and then finally fail and don't fix the users. (note the msdirty key table has been filling up and we have a nightly job that is sceduled to run but nothing happens and yes we have a housekeeping dispatcher set up)
We are now in a position where we have 100's of users in PRD that can't get access because of provisioning problems from the go-live and with SAP Support ignoring us I am not sure what else to do.
If the reconcile and repair jobs are not actually cleaning the entries from a user, is there anyway to remove all entries from a users table and have that reflect to the web admin screen. Also, is there a change that can be made on the provisioning jobs that if an account already exists in the backend that it will not through the whole provisioning process into a failed state and just over write the account or just continue on with the rest of the tasks (this is our biggest problem by far).
I thought we had a solution in a previous topic for the users having an account in the ECC system but not listed in IDM failed (updated the ECC only and system only objects on the MSKEY) but even with that being updated for all users that had the issue, IDM still will not process fully when I perform a retry.
Not sure where to start but looking for some input from the community on what to provide from my end to help me work through this situation. (please note I have no SQL and Java scripting background)
post screen shots next
3 Answers
-
Best AnswerPosted on Dec 06, 2014 at 04:42 AM
Hello Michael,
for your questions, below is my reply. :-)
If the reconcile and repair jobs are not actually cleaning the entries from a user, is there anyway to remove all entries from a users table and have that reflect to the web admin screen.
-> All required user/privilege/role entries can be removed from IDM table MXI_LINK .
-> Can you tell what status privileges/roles(which need to be removed) have for the users.
you can get the list using below query
select mcthismskeyvalue, mcothermskeyvalue, mcorphan, mcexecstate, mcassigneddirect, mclinkstate from idmv_link_ext where mcthismskeyvalue in ('<user1mskeyvalue>', '<user1mskeyvalue>',...)
you can narrow down list by putting more into where condition.
Normally entries with mcexectstate = 1/2/1026/4 and mcorphan = 0 can be removed via UI or custom job.
other mcexecstate (ex. 1536/1537/1025 etc.) can be removed after changing their status to 1026 and then removing it.
Also, is there a change that can be made on the provisioning jobs that if an account already exists in the backend that it will not through the whole provisioning process into a failed state and just over write the account or just continue on with the rest of the tasks (this is our biggest problem by far).
-> I think this you would mean for user creation provisioning job.
-> If so, then kindly check if createabapuser prov job does not have "changetype" attribute in its pass.
Regards,
Pradeep
Add a comment
-
Former MemberPosted on Oct 28, 2014 at 04:33 PMhere is a typical issue:
IDM Admin screen error:
error log of user job:
IDSTore showing it thinks all privs are assigned:
sometimes if I delete the user in the backend it works...sometimes it doesn't. When it doesn't my everybody business role assigns OK but if you open it on the user it contains no associated privs (even though if you open the business role itself you see all privs)
RepairIdentify: below is image of log on job, but I have also attached DSE file.
For the clean dirty MSKey's job I don't know what to provide, but if I run it manually via the dispatcher tab it just starts multiple Runtime engines and runs for 12+ hours and either crashes or removes an MSKey entry..but when you do validate an entry that it did finally clean it still doesn't have the right assignments.
I have a couple of changes that I need to make to major business roles because of our ongoing ECC FI and MM, SD implementation and right now I cannot update anyones roles with out causing all users to get stuck inthe Dirty key table and never cleaned and provisioned the new access.
Add a comment
4 Comments-
Former Member Former Member
as a side note to this issue we currently have been trying to run the IS_repairEntry proceedure to clean some of this up and with no success.
the job I created for this is:
which calls the following script per SAP documentation:
// Main function: z_repairIdentity
function z_repairIdentity(Par){
//Example calling DSE internal function
//uStop("Terminated by user");
var usermskey=Par.get("MSKEY");
//var output=uIS_RepairEntry(163082);
var output=uIS_RepairEntry(usermskey);
uWarning(output);
return "";
}The job runs and the store procedure triggers multiple runtimes that lock the database for hours, causes cookie errors and then fails. No users are cleaned.
-
Add a comment