When Deprovisioning Does Not Equal Delete

[former_member2987]

When I am working on IDM projects, one of the things that I commonly find is that there is insufficient emphasis placed on the deprovisioning process. I have found this to be the case for a number of reasons, all of which usually come out during the requirements and discovery process, prior to determining a final design.

It's not that organizations don't know that users need to be deprovisioned, rather it's the policies that need to be acknowledged during the process. Let's talk about three common types of systems found in a SAP IDM project: Active Directory, Email, and the SAP System of your choice.

For various reasons, we may want to ensure that the person leaving the company might have information that we will need to hold on to some of their information. Information held on individual drive shares, emails, etc. could be required for legal or compliance reasons.  Also there's the chance that the termination is not actually a termination, access might be suspended for various types of leaves or sabbaticals. So how do we handle this? The first thing is that we need to understand what happens during the process.  For example, typical things I see are:

• SAP IDM - Password is to be set to a random value, The MX_DISABLED attribute is set to a non-null value. (Note that MX_INACTIVE has some more far reaching effects. Please refer to page 92 in the document SAP NetWeaver Identity Management Identity Center - Identity Store Schema - Technical Reference.)
• Active Directory / Exchange - User is to be disabled, moved to a separate, specific Organizational Unit, password to be reset to a random value.
• SAP Systems - Login disabled, Password is to be set to a random value.

Typically this state is kept for a period of 14 to 180 days after which the accounts are permanently deleted, unless they have been reactivated.

One of the effects of these Business Processes, is that the SAP IDM Provisioning Framework needs to be updated.  Before considering any actions on the framework it is important to remember:

• Make sure the original Framework install is backed up (I recommend a copy and paste to another part of the configuration and doing an export)
• When editing specific tasks and jobs, make a back up copy.

Now you can go ahead and extend the framework. Note the following example where I have updated the Delete Plugin of the AD Connector:

Note that I make a copy of the "3 Delete AD User" task and then made a few changes, linking in the disable user task and moving the user to "ou=disabled" (for more information on this move, look here.)

You can use this same other approach for any other SAP IDM Connector. I suppose a more full-featured change for some connectors  would have have a conditional task to evaluate what kind of termination event this was and then either disable or straight out delete, but I have to leave some topics for future writing :smile: . 

Please let me know if this helps you or if you would take this a different way.