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.
