Effect of Keeping User IDs

[Former Member]

Hello Gurus,

I have a question regarding SAP IDs which we deactivate in the system, does those IDs considered in the License. Or should we delete those IDs, what would be the effect of deleting IDs?? Both system and Business wise???

[Former Member]

Look at mamy other threads about this issue in this forum!

1 one should never delete, but lock , take roles away and put them in a seperate usergroup.

2 when doing as suggested in point 1 you do not pay license fees for these users!

[Former Member]

The user ids not required should never be deleted, in fact, they are locked, assigned to Expired user group, roles deleted.

In business perspective, this reflects on the billing from client, and acts as a proof when required in the organisation.

And, when in case the user returns again, same user id can be assigned to him for the access, which is the advantage.

When the roles are deleted, this helps in finding out the roles assigned to the user id.

[WolfgangJanzen]

I agree with what has been stated previously (lock account, remove authorizations / roles / ..., but do not delete the account) and only want to add the comment that you should set the account validity (end date) accordingly.

[Former Member]

Wolfgang

i agree, one should do everything possible to overcome the reuse of the UID. So every extra step is better.

Main point however is that one should not delete these UID's and make certain they are not counted anymore for licence fee. In this also make sure that they will not be unlocked again (either on purpose or accidentely)

[WolfgangJanzen]

Well, I'm aware that the license auditing tools (USMM) are evaluating the account validity attribute.

I'm not sure about the account lock. Definetly, the password lock (set due to too many failed password logon attempts) is not of any interest regarding license evaluation.

Using the account validity attribute also helps you to document the exact date when the account has expired.

Otherwise you'd have to evaluate the change documents (e.g. to determine when the account was locked, and by whom).

Cheers, Wolfgang

PS: wishing you a Happy New Year

[Former Member]

What I like about using validity dates (on users and on role assignments for that matter) is the expiry date can be set in advance if known - for example at the time of creating or unlocking the ID. That way, should the user remain active or the admin be forgetfull / absent, the access will fall away without any human activity being required.

All the best for 2008!

[Former Member]

And when HR is being used you will see that the validity date is the thing that is changed for users that left the company!!

The program RHPROFL0 does not delete UID's.

All the best to everyone for 2008 and lets keep up the good work!!!

Edited by: Auke Visser on Dec 29, 2007 4:29 PM

[Former Member]

Yes, that was my thought before as well, as my (planned) retirement date is known now already (for the user ID validity for logon to expire automatically) and my transfer from the Finance Deprtament to the Security Department is known to the HR Department too (for the role validity changes at midnight on 31st January 2008 - or when ever RHPROFLO might run next after that... ;-).

Cheers,

Julius

[Matt_Fraser]

We just started using HR this past September, but we've had SAP for over seven years. So, we are only recently using RHPROFL0. I am not aware that it is doing anything at all with respect to terminated employees, though I wish it would. Certainly it does not delete the user account (nor would we want it to), but if it would update the end validity date on the user that would be marvelous! Even better if it would be CE aware, but alas I'm sure I'm hoping for too much there.

--Matt

[Former Member]

Hi

1. There is a validity date assigned to the user.

2. User goes on a holiday, returns to find that he is expired.

Question :

A> How can we notify the user say three weeks or six weeks in advance that the user will expire ? so that remedial steps can be taken?

Cheers

George

[Former Member]

George

normally one should not need this, as it is not an authorisation problem, but an organisational problem:

Why was the user delimited and still returns on the job.

that is where this problem should be solved. For the validity dates of each user look into table usr02

[WolfgangJanzen]

> 1. There is a validity date assigned to the user.

> 2. User goes on a holiday, returns to find that he is expired.

>

> Question :

> How can we notify the user say three weeks or six weeks in advance that the user will expire ? so that remedial steps can be taken?

I'm not sure whether we are referring to the same issue.

Up to now we have been discussing the account validity.

You seem to refer to "periodic password change required".

Well, an account of an employee normally terminates because his work contract terminates. And in that case the user is pretty much aware of this deadline (at least he should be).

[Former Member]

Matt

if the evaluation path is set correctly ( i currently have no access to a system running RHPROFL0 so can not tell you exactly how) it will set an end date to obsolete userid's. But be sure also not to remove infotype 105, only end the contract of the person in HR of SAP. Or move the person from a valid position to position 99999, as that should also do the job.

Edited by: Auke Visser on Jan 4, 2008 1:22 PM

[Former Member]

It sets the valid to date on the user master record if the user does not exist - when created by RHPROFL0.

It does not retro-fit existing users with valid to dates on the user master record.

It sets the valid from date and valid to date on role assignment changes.

[SAP note 862098|https://service.sap.com/sap/support/notes/862098] might be of interest if patch level are not reasonably up-to-date.

In both cases, if not specified, it sets valid from date = sy-datum and valid to date = the end of the year 9999.

Something to think about for the upcoming Y10K conversions? As they say, the worm catches the earlybird as well...

Cheers,

Julius

[Former Member]

Julius

i thought it also changed the end date when the assignment is continued after the initial enddate? As long as the change is applied in HR

Anyway the message of this whole discussion should be that the limitation should be in the licence type change so the user will not be counted for licence cost anymore. and this including most of the other things mentioned must be done manually.

[Former Member]

Hi Auke,

I did not see anything like that.

It would also be illogical to me, as it would require a change to the "end date" for all existing employees to activate the change to the user validity "end date". You might as well change the user end date once, in stead to the employee end date twice (once again to change it back...).

Cheers and enjoy the weekend,

Julius

[Former Member]

Julius

i believe you, as mentioned i do not have a system here to test this.

So a lot of manual work for every one or have an abap writen to do it for you.

I once was in a company were we checked the Office pass system to revoke uid's

as soon as the office pass was no longer valid a ABAP ran to delimit the uid's This program ran every night before RHPROFL0

nice weekend to you to and to all

[Former Member]

Hello Auke,

There might be a different report for doing a retro-fit? Do you know it?

Certainly, if the termination date is known and available in HR, you could quite easily without "a lot of manual effort" BAPI the retro-fit.

After that, the update of a change would make sense if there is an activation possibility for it. Do you know one?

On the other hand, the user might still want to access the system to see their post employment benefits and (ex)employee stock scheme options. In this case (as mentioned above), it makes more sense to validate the role access (from - to) after the termination of the contract, but dependent on the TYPE of termination.

Re: Deleting ID's ~ how long do pensioners want to have post employment benefits?

Tricky stuff...

Julius

[Matt_Fraser]

Well, checking the records of all users whose validity end-date has changed since we implemented HR, I can see that not one has been changed by RHPROFL0. All of them were manual. Based on documentation I've read and comments made earlier in this thread, I expect that for the pre-existing users, not created with RHPROFL0 (i.e., before implementing HR), but in fact I have several thousand users created at the time of the implementation with RHPROFL0, and many of these have since been terminated by HR, but none of them show in this list. There is nothing automatically updating the user's validity end-date, even when the position assignment in the org plan is changed to an inactive ('withdrawn') status.

I think what's happening is that RHPROFL0 is looking for the end-date on the user assignment in IT0105 to be changed, but it doesn't change automatically (and HR is not updating this infotype... at least, not yet). Even when an employee is terminated and the position is inactivated and the last action on the personnel number is termination, the user assignment in IT0105 still shows and end-date of 12/31/9999, and thus the user account itself remains valid.

As for license usage, yes, this is a driver (as well as security, of course) for figuring out a way to automate this. A user who is beyond their validity end-date is not counted by the license audit, so it is sufficient to set that date properly for purposes of both the license audit and security (the user is not usable if not valid). It's also a good idea to lock the account, change user groups, remove roles, etc etc, but that's more for ease and visibility to the system administrator. Changing the end validity date is sufficient for technical purposes.

So, the problem becomes, how to get this to be automated, especially in a Concurrent Employment environment? I think the answer is going to start with training the HR department to pay attention to infotype 0105 (and this will be a hard job). Potentially some sort of ABAP could be developed, as Julius and Auke were hinting, to update the user assignment validity based on the pernr validity, then let RHPROFL0 do its job from there, but of course our developers already have full task lists with other jobs to do.

--Matt

[Former Member]

Hello Matt,

In addition to the end-validity of the user, the end validity of their assignment to a role is a possibility => the user could still logon, but could not do anything without any role, hopefully... (see

[this thread|; for an example why).

I would think that this might be an even more usefull approach for you for "real time" access management, as the CE assignments would be likely to change more often than the termination (in many cases only once).

Cheers,

Julius

[Matt_Fraser]

You're right, the CE assignments change much more frequently than actual terminations occur (too frequently, in my opinion). It happens on a near-daily basis that I get a support call about an ESS user with "no portal roles assigned." This equates to a user who is still valid, but as you describe, has no roles assigned at all. It happens because their CE assignment with the user assignment in IT0105 is terminated, but they still have another active assignment. Since the user can only be assigned to one PERNR at a time, and it's now assigned to one that is no longer active, the nightly RHPROFL0/PFCG_TIME_DEPENDENCY job strips the user of all their roles (but does not update the end validity date of the user). They can still logon, but in ESS via the Portal they get an error and can't do anything. They're also still counted as a valid user for license audit purposes.

Partly this is a training issue in HR -- if they are going to terminate a CE assignment, they need to move the relevant information on that assignment to the new or additional active assignment. This is not just the IT0105 information, but information about Qualifications, etc. The HR Director is aware of this problem and is taking steps to get her department to change a decades-old business practice to something that works better, but it's a slow process.

In an ideal world, at least an ideal CE world, the user assignment would be to the Person ID, not the Personnel Number. Of course, I can see the problems associated with that, too, especially in the area of structural authorizations, but still it needs to somehow head in that direction. Then, perhaps, when a substitute gets that coveted full-time teacher position, and her assignments change, she won't suddenly lose access to ESS. Then, when an accountant retires, his user validity will simply end. What a glorious day that would be....

... but then maybe I'd be out of a job?

--Matt

[Former Member]

Hi Matt,

I am sure there is a way of doing these things, but not sure what the mix of concurrent employment (I had to look it up first...), structural authorizations, backend users, portal roles etc would make the solution look like with all of them together.

For example, you could move all users from your "CE" user group who do not have a role to an "obsolete" user group and then do the validity etc changes there. But what about the others?

>

> ... but then maybe I'd be out of a job?

You could schedule the job under your own ID and go home earlier, like I am going to do now...

(except, it is late already and we don't schedule job steps under dialog user ID's ).

Cheers,

Julius

[Former Member]

Thanks that helps!

[Former Member]

For Best practice or sap recommends not delete the IDs, some times we need this details for audit purpose , instead of deletng User , change the valid through of the user to current date , remove the roles assigned , change the user group to Terminate and finally lock the user.