Security Archives » Page 6 of 7 » Musings of an IT Implementor

SAP FBL5N and Change Document Authorisation

After spending tedious amounts of time in SU24 and performing an authorisation trace I was unable to work out how users got “Change Document” access in FBL5N (Customer Line Item Display).

Access to change documents via transaction FBL5N, which is inherently a display only transaction, is controlled by giving transaction FB02 to the user.
You have to look in the source of program RFITEMAR:

Adding transaction FB02 (plus maintaining the subsequent authorisation activities) to a users role, as well as FBL5N, provides the “Change Document” button on the menu bar in FBL5N:

Disabling Change or Deactivation of SAP Audit Logging SM19 – SAL

To disable changing or deactivation of the SAP Audit Logging (SAL) settings via transaction SM19, you can remove the authorisation object S_ADMI_FCD activity AUDA.
(see https://wiki.sdn.sap.com/wiki/display/SMAUTH/S_ADMI_FCD).

This would prevent “normal” BASIS administrators from being capable of changing or disabling audit logging, but permit you to provide an emergency user with this capability (you will need to change SAL settings in SM19 at some point!).

Populate User Groups into SU01 Authorization Group

If you have followed my previous post on how to create SAP user groups en-mass, then you may wish to know how you can assign one of these groups as the security group (as per the security group box in SU01).

Simply setup your groups as per my previous post, then use the following SQL at the database level to perform the assignment to the user account in SU01.

NOTE: The script will apply each group it finds to the user accounts. If more than one group is assigned to a user, then only one of those groups will be used. The order will depend on the order of records returned in the inline cursor.
set serveroutput on size 1000;


DECLARE
   CURSOR c_ug IS SELECT BNAME,USERGROUP,MANDT FROM USGRP_USER;
BEGIN
FOR ug IN c_ug LOOP
UPDATE USR02 SET CLASS=ug.USERGROUP WHERE BNAME=ug.BNAME and MANDT=ug.MANDT;
DBMS_OUTPUT.PUT_LINE ('User: '||ug.BNAME || ' Group: '||ug.USERGROUP);
END LOOP;

END;

Transporting SAP User Groups

I’ve blogged about SAP user groups before: https://www.it-implementor.co.uk/2011/09/sap-user-groups.html
Let’s say you’ve set them up in your DEV system and now you’re expecing to just transport them. Well, as with all things SAP, it’s never quite that easy.

Create a new workbench transport request in SE01, SE09 or SE10 (doesn’t matter which).
Then open the request at the request level by double clicking it.
Switch to change mode by clicking the pencil button:

Now manually type in the program Id, object type and object names as follows:

R3TR TABU USGRP
R3TR TABU USGRPT

Click Yes at the prompt:

On each item, click the Function button (key symbol):

Enter * in the Table Keys field:

Save the request again.

That’s it!

Release the transport and import into the next system.
This is a farily generic process that can b used to transport any table values.
NOTE: You should be aware that the “*” in the table key, means all items specific to the current client.

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

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.