cancel
Showing results for 
Search instead for 
Did you mean: 

IDM 7.2 Deprovisioning

Former Member
0 Kudos

Hi Idm Experts,

I am looking for some help and advice in regards to user deprovisioning.  I am trying to get a clear understanding of the user deprovisioning process and was wondering if anyone knows of any good documentation on this which I can review.

The issue I am having is that the user is being deleted before all of the deprovisioning of roles has occurred and the ABAP subsystem have had there memberships revoked.

So when a user is terminated in HCM and is written to the identity store with MX_DISABLED and MX_LOCKED set to 1, all of the assigned roles are removed straight away, also including all of the PRIV:$rep:ONLY privileges. IDM starts going through the modify process but does not seem to complete successfully

and the user is deleted before all of the deprovisioning has taken place.

I have been using the standard Provisioning job via the framework and when IDM gets to switch task "Check for account privilege" it returns 0  as the User ACCOUNT%rep have been removed, so in the ABAP subsystem it still shows the roles that the user had assigned, this may be normal behaviour but I am unable to find any documents which detail the process.

What I am trying to achieve is that when a user is terminated in HCM that in IDM their account is disabled and the position is removed but leaving the PRIV:$rep:ONLY privileges so that IDM will then deprovision the roles and lock the relevant subsystems.

Thanks for your assistance in advance!

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi Andrew

This is a common problem with the framework - when its deactivated the user the standard deprovisioning jobs have issues dealing with InActive users.  If the user is inactive before the deprovisioning finishes, it may fail to remove them from ABAP.

There are a couple of ways around it.

Change the job from ABAP so that it sets a temporary attribute rather then MX_INACTIVE.  The temporary attribute has a linked task that removes all roles and privileges and finally sets MX_INACTIVE with a delay of, say, 10 minutes.  This should allow the deprovisioning to go through without failing and then set the inactive flag properly.

Peter

former_member2987
Active Contributor
0 Kudos

Peter,

That's a brilliant idea. I think I'll be stealing that one

Only change I would make is to extend the wait to about 15-20 minutes to account for AD replication, or put a error task on just in case.

Matt

terovirta
Active Contributor
0 Kudos

Matt Pollicove wrote:

Peter,

That's a brilliant idea. I think I'll be stealing that one

Only change I would make is to extend the wait to about 15-20 minutes to account for AD replication, or put a error task on just in case.

If you make it as an event task for the HCM-supplied employment status, MX_FS_EMPLOYMENT_STATUS_ID, you won't need any extra attributes.

Add a switch-task that differentiates between the different employment statuses and you can have (or reserve) special logic for Withdrawal, Hire/Re-hire and Long Absence.

Former Member
0 Kudos

Apologies folks, as Steve and I have both posted this query.  We shall close one shortly.  Still not answered though!

former_member2987
Active Contributor
0 Kudos

Andrew,

Can you post a screenshot of your current workflow?

Based on what you're saying the user should not be deleted just disabled (and maybe locked) Can you verify (via SQL I would assume) that the user is no longer in the Identity Store?

Are you receiving any error messages?

Are the roles being dropped? Do the users no longer appear in the target systems?

Matt

Former Member
0 Kudos

Hi Matt,

Thanks for the response.  I guess the first question is 'what should be the standard behaviour?'....ie when we terminate through HR, the identity is being deleted in the IC, and we have amended the business suite delete BS jobs to simply change user groups and end dates and locck in the backend.  So we have the required result in the backend, it is simply the frontend deletion that seems strange....and yes, the identity is gone at the table level.  Also, it is a combination of the modify and delete jobs that update our abap users.

Interesting occurence today though as we accidentally errored the sap_core_checkModType script running under 'Process Modifictaion Type within the modify job, and as a result of this failing, the identity remains in the IC, with a 99999999 position, no roles, and the correct end date, and with MX_DISABLED set.  Strange.  I guess what I am asking here is which of these is expected, and how do we control this outcome, as ideally I would like to keep the identity either as disabled or inactive.

So in summary:

* HR recod is terminated.  OK

* Identity is deleted. ??

* ABAP user account is locked and end dated and roles removed. OK

keith_zhang
Active Participant
0 Kudos

Hello Andrew,

I checked the standard SAP provisioning framework and job "Write HCM Employee To SAP Master". From this HCM transfer job side, it seems when the received "P0000-STAT2" is not 3, attribute MX_LOCKED will be set. There is no change to MX_DISABLED in this job standard.

Then from SAP provisioning framework side, as you may also noticed, script sap_core_checkModType is used to verify which kinds of modify happened to the user. Attribute MX_LOCKED is not checked in this scripte, instead it will check MX_DISABLED. And MX_DISABLED will be used by relevant hook task for locking the user in target ABAP system, instead of MX_LOCKED.

So, in standard HCM transfer job template, there is no change to the user-privilege assignment, and so I think it should not trigger task "601/provisioning" or task "1345/Deprovisioning", instead "751/Modify" should be triggered. Then, maybe in your case you have:

-  Added/enabled attribute MXREF_MX_PRIVILEGE from HCM job, which will then change the privilege assignment and trigger the provisioning/deprovisioning task?

-  Added change to MX_DISABLED somewhere?

You may then adjust the attributes changed by HCM transfer job, according to your requirement.

BR, Keith

Former Member
0 Kudos

Hi Andrew,

As far as I know, and certainly in our system, the extract of a "Withdrawn" employee from HCM does not trigger and identity deletion.

We have added some config as an event task on MX_FS_EMPLOYMENT_STATUS_ID to eventually set the identity to inactive, but I don't think standard does anything.

Hopefully this gives you an avenue to explore? If not, switch on the trace for an identity and exit them. You should then see the sequence of events that leads to the identity becoming deleted.

Cheers,

Ian