Has anyone transitioned user ids to employee ids?

[Former Member]

HI,

The company I currently work for is wanting to transition from <First Initial><Last Name> logons for SAP to an 8 digit employee ID.  They want to do this to try and level IDs across systems to better identify users.

Have any of you done this?

What were the problems associated with the change?

How did you convert employee ID to actual names for standard screens and reports?

What would you have done differently?

How do you currently track users across multiple systems, SAP landscapes? When, userIDs may be different across those systems?

Thanks,

[Former Member]

What we are planning on doing is:

1. Setup SAP's Central User Authorization (CUA)

2. Implement LDAP with Active Directory

What this will accomplish is one logon ID and Password for both the Microsoft file server and SAP.

When the user runs SAP, the SAP system will "connect" with the Active Directory server to verify the user ID and password.

In our case what we are going to do in SAP is set the persons SAP alias in SU01 to their employee number which is their Active directory user ID.

LDAP is used by a lot of different application so you can setup your VPN software to use LDAP, or your document management systems. This way you have the same user ID across all platforms and it is only 1 place to go to reset or change a password.

CUA basically syncs user information across all SAP systems.

Our basis and systems folks are going to do this. I'm only doing the requirements so please don't ask me for the "How-Tos" of it.

[Former Member]

Philip Noah wrote:

When the user runs SAP, the SAP system will "connect" with the Active Directory server to verify the user ID and password.

...and...

I'm only doing the requirements so please don't ask me for the "How-Tos" of it.

This, is not a good omen... 🙂

[Former Member]

Is there a specific reason for asking this in the general banter, whining and moaning forum? Would the security forum not be more appropriate? Or was it Philip's tragically funny answer which you could foresee? How did you do that?  🙂

Could some moderator with sufficient powers please move it a better forum space area thingy?

Cheers,

Julius

[Former Member]

I thought I might get a broader audience here.  Too broad it seems.

[Former Member]

I asked the mods to move it, but for the moment see SAP Note 1694357 -> it can create a big mess because of all the places where the user name is stored.

So it will be a bit like a year end closing in SU01: workflows, approvals, variants, batchjobs, infotype 0105, hardcoded names in programs, transport ownership, master data fields declared as "sensitive" for double-verifications, validations, check tables, org. structure, personalizations, etc... depending on how much of these applications you use which have the user name as a hardwired attribute to using the application.

There is also no way to "bend" the ABAP stack login modules to ask for an AD password. You can only use the local password (which will have to be new) or the SCN API for SSO or trust chains (such as login tickets) from upstream SAP systems.

I can strongly recommend that you get yourself some consulting help for it from someone experienced. SAP has a team specialized in "Landscape optimization" (search for that term or check service.sap.com/slo) which include this as a service. But they will first want to take a look at the systems in the landscape before they commit to anything, as the size of the construction site can vary significantly.

I have also done it once. I can't say that it is fun, but it is very challenging and interesting.

If I had to do it again, then I would not assume that XUBNAME is the only data element to use for verifying user names in custom program check tables and IF SY-UNAME is not the only syntax to compare the logged on user ID to the ZUSER field. Lesson learnt is that you cannot rely on documentation or consistent coding - you must think a lot and do a few dry runs.

Good luck!

Julius

[mvoros]

Hi,

I don't have answers for many of your questions. But one of my customers uses employee ID as user name. It works flawlessly because they have IdM. So HR department creates new employees, they get exported to IdM and then provisioned to all required back-end systems. Every employee knows it's employee ID because it's on their badge as well as on they paychecks. The head office users used to have different naming convention. They did not migrate these so some people still use old user accounts.

With IdM you could have different user names for different backends. It would create some complexity so I am not really sure if it's a good idea.

Cheers,

Martin

[Former Member]

I suspect that Drew wants to head toward unique identities for users (and possibly other identity types in the landscapes), but needs to fix the legacy problems first.

Generally it makes sense to fix design problems and some processes first (eg Roles...), before you implement them in IDM. Otherwise you just pass the buck on to IDM and experience the same problems / complexity there.

I cannot honestly recommend customers to use IDM to map user naming problems to identities. It is best to fix the problem and define data sources for IDM as identities (AD), and then only attributes from HR etc to enrich the business roles.

IMO it is best to first clean / simplify / harmonize the data for IDM, then implement IDM.

Cheers,

Julius

[Former Member]

Well, here we are at the crux of the problem where I am currently.  I won't bore you with that so...

No, I would not look to change existing users.  I would say let them stay until the are turned over by attrition.  New users coming in would use their EmpID.  AD and HR would be the 'systems of record', enhancing each other and have the other systems controlled by an IDM using the HR/AD tandem as its source.

Clearly, we have more to do than change a user ID. The overall design needs to be addressed first.  Without clean data to rely on, any change will just carry over the original issues as pointed out by Julius.

I also agree with Martin, despite what our functional teams say, users will get used to numbers instead of alpha IDs.

Thank you both for your replies.