Using Google Chrome?

Download my
free Chrome Extension, Power Notes Searcher, to make searching for and evaluating SAP notes, much easier.

Recent Posts

Saturday, October 15, 2011

To Delete or Not To Delete (an SAP user account)

Print Friendly and PDF
Having read around the SDN forum recently, I was surprised that no one had done any particular research into the consequences of deleting SAP user accounts.
This is probably quite a common question when you first get your shiny new SAP system implemented.
Generally, auditors prefer that you delete IT accounts. It's a nice catch-all and means that they can tick the box that says "done", knowing that what happened was the most secure option. But it might not be the best option.
Most procedures require locking the account for 1-2 months before eventually deleting it, therefore catching rogue background jobs etc.

After some heavy procrastination I have come up with the following reasons why it might always be better (safer) and actually more audit-friendly to just lock the account and not actually delete it:

- Adding a new user of the same user id as the one just deleted, will attempt to re-use the old address details.
This is really bad and could cause awful confusion. It could also cause a problem with regards to auditing.

- Customer modifications/code in programs and workflows that utilise the user id.
If the user is deleted, then re-created later on for a new employee of the same name, that new user may inherit authority, receive SAP Office emails or any other actions that were previously meant for the old owner of the user id.

- When a user creates a transport, this is recorded in the code version history for the objects transported and the transport co-file and a file in one of the the /usr/sap/trans sub-directories (off-hand I think it's called sapnames...).
Deleting the user removes the tie between the user id that created the code version, and their real name/details. In a large organisation it can be difficult to find the right "Smith" that made that change.

- When a user is deleted, you can not see what authorisations the account used to have.
Once again, how can you prove that some malicious action happened if the account has been deleted, removing the evidence that the user had access to perform the crime.
Alternatively, someone may have legitamately left the company, but recruiting didn't find a replacement for 6months. Guess who will need to create a new user id where the request form says "same roles as Joe who left 6 months ago".

- If you delete a user account after they leave, then re-create a new one for a new employee, what if you've missed an account on a system somewhere.  Nobody will know if it should be for the user who currently exists.  This is a major security risk.

This may lead you to thinking about a better user id naming scheme that could provide a unique name for every account created.
That really would be a worthwhile exercise.

Don't forget, locking the account does not mean that you need to pay a license cost for it, it's not usable.

4 comments:

David Berry said...

Hi

Deleting is one of my pet hates in 'housekeeping' due to the points you listed (plus there are more!)

Not too sure this is totally corrct though "- When a user is deleted, you can not see what authorisations the account used to have." as SUIM can report the deleted profiles on a delete user ID.

I'm for locking and delimiting as well but found you can quickly make enemies in an existing security team as the 'that's not the way we work!' is voiced :-)

Luckily a contractor can advise, discuss and then walk away at the end of the contract I suppose.

Thanks for the blog.

Cheers
David

Darryl Griffiths said...

Hi David,

That's an interesting point.
I forgot about SUIM and the "Change Documents" bit at the bottom.

I guess you could also include the logs within CUA if you have CUA implemented.

Regards,

Darryl

Anonymous said...

Darryl wrote: "Don't forget, locking the account does not mean that you need to pay a license cost for it, it's not usable."

Comment:
Unfortunately I can't confirm this completely. Locked user IDs seem to be still counted by USMM/SLAW. We observed that some weeks ago on our SAP systems. USMM stops counting users only if their Valid-until date (SU01) shows a date in the past.

A SAP user who was locked by an administrator is still counted by USMM until his individual "valid until date" has come. All users who locked their accounts accidentally by entering wrong passwords as well. :-)

Cheers

John Harry

Darryl Griffiths said...

Many thanks found the clarification John.