Renaming or Changing a User ID in Production

[Former Member]

Iu2019m researching on how other SAP shops are dealing with a request for a user ID rename or change in Production. Our user IDs are based on the employeeu2019s last, first and middle names. I know technically the User Master Record canu2019t be renamed; it has to be deleted then re-created.

Our Production environment runs ECC 6.0, SRM 5.0 and BI 7.0. ECC 6.0 is the master CUA and the child systems are SRM 5.0 and BI 7.0. We also have HR position based security in place.

These are some of the issues that were raised if we changed or renamed a User IDs:

*Historical Records u2013 we lose historical records. * I suggest not to recycle the old user IDs*

*Workflow u2013 If a workflow was triggered and the user ID for the approver was changed the workflow has to be restarted.

*Other Tables u2013 Besides updating the IT 105, ST 0001 other functional tables have to be updated.

In my opinion it can be done but the change will take some of effort from different groups.

================================================================================

Question: How do you currently deal with active user ID change request in the Production system?

[Former Member · Accepted solution]

Hi John,

Every user in SAP system should have unique user id. When a employee leaves the organization, the roles in the user id should be removed, the logon validity date should be set to a past date, should be locked & added to locked user group. At no case the old user ids should be recycled.

Only in case where the administrator created user id with wrong id (eg: mispelled) should be renamed, I don't think so there could be any other case where you need to rename any user id

You can track the change history of wrong user id that was renamed in "Change documents for user" in SUIM or SU01and also for new renamed user id in "Change documents for user" in SUIM or SU01

[Former Member · Accepted solution]

>

> Hi John,
> 
> Every user in SAP system should have unique user id. When a employee leaves the organization, the roles in the user id should be removed, the logon validity date should be set to a past date, should be locked & added to locked user group. At no case the old user ids should be recycled. 
> Only in case where the administrator created user id with wrong id (eg: mispelled) should be renamed, I don't think so there could be any other case where you need to rename any user id
> You can track the change history of wrong user id that was renamed in "Change documents for user" in SUIM or SU01and also for new renamed user id in "Change documents for user" in SUIM or SU01

I agree and we currently also don't recycle user IDs.

Do you allow user's to change their user ID if they have a name change?

[Former Member · Accepted solution]

> Do you allow user's to change their user ID if they have a name change?

Hi John,

I got your question. I had this experience earlier, where in a user's last name changed as a result of her marriage.

In that case we created a new user id with new last name & terminated (process as explained earlier) the earlier user id

In this way, the user history -of old user id- could be maintained as well

[mvoros]

Hi,

I doubt that there is a better way than locking user and creating a new one. The following section is more musing than stating facts.

IdM and SSO might be useful for this case. IdM is a central repository of identities identifies by main user name (e.g. email address) and all systems have link between main user name and account in their system. So for example in case of SSO implemented via SAML for web application the user is redirected to authentication provider where she enters her email address and password. The authentication provider issues a SAML ticket for entered email address. The service provider maps email address to internal account. You can easily remap service provider user name to new email address after change. This allows you to change user name in the system. But it can be confusing for users. For example locking in SAP system. The user will get a message that document is already locked by other user. The name displayed in the message will be confusing because it will be an original user name not the latest one. So I am not sure if it's a good idea.

Cheers

[Former Member]

Hi

*Historical Records u2013 we lose historical records. * I suggest not to recycle the old user IDs*

your suggestion not to recycle the old user id is correct

*Workflow u2013 If a workflow was triggered and the user ID for the approver was changed the workflow has to be restarted.

security and functioanl team can make note of the userid changes and reconfigure the approver names.

*Other Tables u2013 Besides updating the IT 105, ST 0001 other functional tables have to be updated.

Changes have to revisited wherever required

In my opinion it can be done but the change will take some of effort from different groups.

Yes, how many users have these kind of corrections ?

[Former Member]

>

> Yes, how many users have these kind of corrections ?

There have been some request for user ID change but they haven't been processed. We are still on the fence and we would like to find out what other SAP shops are doing to address this problem. We would have like to use Employee Numbers for user IDs but it's too late now.

[Former Member]

Few of the bigger projects especially with HR structure, employee id is what most of the customers follow

to overcome security and privacy issues.

[Former Member]

Hi John,

I completely agree with Martin here that IdM is a very valid option to consider simply relabelling the identities and not changing all the mapping and user ID's when someone gets married.

You can get a fair idea how to do this from:

To completely revamp your user naming convention you can consider the Landscape Optimization services of SAP ( https://service.sap.com/slo ) but this is a major project and involves many risks. For example, where has the user ID been used in custom coding without dataelements using XUBNAME (length 12!) but rather some other domain of (possibly) shorter lengths. It is very difficult to find all of these.

Also see [SAP Note 1222807|https://service.sap.com/sap/support/notes/1222807] for some of the other known side-affects of getting married...

Cheers,

Julius

[Bernhard_SAP]

... simply forbid marriage and divorcement. That's it.

[Former Member]

>

> 
> Also see [SAP Note 1222807|https://service.sap.com/sap/support/notes/1222807] for some of the other known side-affects of getting married... 
> 
> Cheers,
> Julius

That note helps a bit, it justifies why it's not just an easy delete and create.

>

> ... simply forbid marriage and divorcement. That's it.

[Former Member]

Yep, and no more '06' activity for the users either...