Questions Around IDM 8.0
We are thinking about using IDM 8 with HCM as the leading source for onboarding and offboarding for AD and SAP users and we have the following questions:
1. Once data is loaded into the HCM Staging Area how is it cleaned-up and moved to the productive identity store?
2. How do you clean up initial loads if users are listed with Unique ID (Display Name from AD and Username from SAP) in the identity store?
3. Would the IDM web UI be the required user interface for AD Admins and SAP Admins or can they still use their regular tools and if so how is the delta handled.
4. Is there no real time data read from HCM as it seems you have to schedule exports and load them via VDS configuration into the Identity Store
5. Is there a way to kick off provisionning (user creations/changes) without using the privilages (PRIV:REPO:ONLY).
Thanks and I look forward to your responses.
Dominik Trui replied
I hope I can help you with the following.
In most projects I did it we used the provided way with some adaptions regarding the scripts. I once had to add a script which combines two attributes into one and than process them like in the importTimeValues script. I had to use an own written scripts because the time slices of both attributes might be different (all possible combinations over time had to be covered).
Some customers wanted to start processes according to the different actions performed in the HR. Like onboarding, offboarding, org changes (new department, new manager, new company). In these cases we provided an own entry type similar to the SAPC_REQUEST.
Whether you have to use the cutDate or the importTimeValues script depends on your processes and what you want to do with each attribute. It could be that for different attributes one script can be useful while the other would be bad. E.g. while starting a request from the staging area I only use the cutDate script for the org attributes to write the now valid values. The values are not changed until the request has been processed by the managers. The requests holds both the actual and the new values and displays them in an approval task.
In most cases we just assumed that the same username in SAP and AD belongs to the same person. In "my system" (where I work now), after 6 years we are still facing duplicate / shared identities about once a month. To match the HR stems with the AD/SAP users I set up some tasks and a job which wrote out all information needed for comparison. I gave the excel file containing about 4000 HR stems (out of 26000 identities) to two colleagues who than verified / matched the users manually. Well, alot of work but we could get rid of some duplicate / shared accounts. And of course mismatched some, too (we have three guys with the same name, two of them in the same company).
Our matching criterias:
- username SAP/AD
- Sysuname from HR
- mail address
- Personal number (we had it stored in AD in employeeNumber and as a part of SAP's logondataAccnt / MX_ACCOUNTING_NUMBER)
=> If the Sysuname in the HR is stored pretty well, this helps a lot. Another good matching criteria was the personal numbers which were already stored in the AD / SAP.
The IdM should be the leading system, in theory. In the projects I was involved this was not every time the reality though.
I differ between attributes and privs.
They really should be leading in the IdM (after you get them from HCM).
An exception to this could be the mail address. If you only have one mail domain the mail addresses can be generated in the IdM based upon the same rules like they are generated in the mail system. In our case we have 80+ rules for generation which will always remain in the Exchange server. I simply read out the mailaddress after creation and write it to the identity.
I can't remember clearly how Lotus Notes handles the mail address creation.
Privs of AD - groups:
Groups are provisioned one at a time.
No real problem for the AD, but for the IdM. When the IdM tries to add an already existing group an error occurs. Same if IdM tries to remove a group which is already removed. We have a script for this (using a u function to read out the AD group), yet it does not work in all cases (large groups with 1500+ members) by now (on my ToDo list since ages...). The AD will be correct, in the IdM there will occur priv assignments with errorneous states which have to be handled in some way (I use a batch job in addition to the mentioned script).
Privs of SAP ABAP - roles and profiles:
Roles and profiles are provisioned en bloc. In the connector there is no possibility to set up some "delta handling" which only provisions the new / removed roles. At least I do no know it.
No problem for the IdM, big problem for the SAP. As IdM provisions the roles / profiles en bloc all changes made in the SAP are overwritten by the IdM. What the IdM doesn't know will be deleted / added again.
In a project we had to set up an "instant sync" using batch jobs (read out the roles from SAP, compare them and add / remove the freshly requested roles). Don't even try to think of that, it is pure hell!
Privs of other systems:
AD and SAP show the two different possibilities how the privs are provisioned. En bloc vs. each priv individually. For every other system you can think likewise. Eiter AD or SAP.
You can handle each system differently. E.g. we manage the AD groups inside the IdM and AD (nightly resync plus that script). We do not manage SAP roles / profiles in the IdM. Yet, we have a process of requesting business roles of a 3rd party GRC which than handles the SAP roles by itself. Soon to be replaced by the SAP GRC though.
There is no direct access for ANY target system. Every system has to be read out in tables and then into the leading identity store (attribute values, privs).
The only other possibility to access the HCM system would be table reads with jobs having FromSAP passes (look at the read ABAP help value passes as an example) and ToIdentityStore passes.
Well, I do that for some 3rd party systems. I cannot recommend it for the provided standard systems like SAP ABAP, SAP Java, AD, etc. However a system where you only need to fill some database table or put some csv file on a server can be provisioned without the Only and System privs. In each case I decide upon what fits the solution best.
In one case (provisioned using csv files) I provision the users and their access rights (I have not added them as privs though) without the Only priv, but I do the attribute modifications with the System priv (after provisioning I add the Only and System priv using DIRECT_REFERENCE=1). That is, because the users and their access rights are always depending on a request, which has to be either issued by the manager or approved by the manager. The attribute modifcations like telephone number may come from everyhwere.