This will will explain the SAP audit log.
Questions that will be answered are:
- What is the intended goal of the SAP audit log?
- How to switch on the SAP audit log?
- What are the recommended settings for the SAP audit log?
- What are the common issues with audit logging?
Goal of SAP audit log
The goal of the SAP audit log is to capture all audit and security relevant actions. The audit logging function can capture failed logon attempts, dangerous actions like debug & replace, execution of transactions and programs, and many more.
SAP has a note for the frequently asked questions: 539404 – FAQ: Answers to questions about the Security Audit Log.
Audit log and privacy
The audit log will capture actions performed in the system. It will not only capture the actions, but also the user ID and terminal ID. This makes the tool a bit of a big brother is watching you tool. Auditors are normally used to dealing with sensitive topics. But next to answering audit questions the audit can also be misused to check ‘is this person doing a lot of work in the system’. For this reason access to audit log should only be given to persons who understand the sensitivity and people privacy. This includes in giving information to managers extracted from the audit log.
Switching on the audit log
For switching on the audit log first the corresponding system parameters must be set:
- rsau/enable: set to 1 to enable
- rsau/local/file: set the file location in format “/usr/sap/<SID>/<instno>/log/
audit_<SAP_instance_number>” (yes, unfortunately audit log still uses a file)
- rsau/max_diskspace_local: max disk space (set to at least 1 GB)
- rsau/selection_slots: default is 2, but typically this is set to 10 slots
Unfortunately these parameters are not dynamic, which means a system restart is required to activate these parameters.
After the activation you can go to transaction SM19 (or in newer version to RSAU_CONFIG) to switch on the audit logging in detail.
First step is to create a profile and activate it.
Next step is to setup the filters.
Audit log filters
The audit log filters are used to filter events. If you select all events this will cause logging shadow and make the function unreliable.
To configure the filters use transaction RSAU_CONFIG (this is replacing old SM19 transaction).
Main client versus 000, 001 and 066 client
SAP has multiple clients. The 000, 001 and 066 client are only used by system admins. For these clients you can setup a special filter and log ALL actions for ALL users. This will not cause too many entries.
Main client logging settings
In the main client you have to be selective on the checks.
The audit log has 3 classification of checks:
- Critical (always switch these on!)
- Severe (if possible swithc on as well)
- Uncritical (be very selective for switching these on)
Key filters recommendations
ALWAYS switch on the critical checks. This will include:
- Debug & replace actions
- Debug start
- Changes to audit log configuration itself
- User creation
- Failed logon attempts
- User locks due to wrong password
From the severe and uncritical sections the following checks are useful:
- Logon failed: this can help to detect logon attempts with standard users (see blog on SAP standard users): the audit log will capture the terminal ID from which the attempt happened
- Start of report failed: will avoid discussions if people really could start or not
- Report started: though in many productive systems SE38 etc is not allowed for directly starting a report outside a transaction code, this still will happen by admins and firefighter. This check will log which direct report is started
- Transaction locked and unlocked: caputure locking and unlocking of transactions with SM01 in old systems (and SM01_DEV and SM01_CUS in newer systems)
- Transaction started: this will avoid discsusion if people key in the tcode or not (do remember that audit log captures the start; it can still be user is not authorized to continue with the transaction). And many RBE (reverse business engineering) type of tools rely on this audit log tracing rather than the ST03 logging. Reason is that the audit log is on user level rather then aggregated level and is usually kept longer.
- User deleted, user locked and user unlocked
- Password changed for user
SE92 audit log details
Using transaction SE92 you can get a more easy overview of the settings definitions as provided by SAP for the audit log details.
RSAU_CONFIG configuration overview
Using transaction RSAU_CONFIG you can get a more easy overview of the actual activation and configuration.
Audit log reporting
Transaction codes SM20 or RSAU_READ_LOG can be used to view the audit log results.
Be carefull to whom you give the rights to read the audit log.
With every new SAP release SAP improves the audit log. By default the audit logging is not updated after an upgrade. Therefore it is wise to check for new items added to the audit log after an upgrade.
Determining changes to audit log settings
OSS note 2680888 – SAL | Report for determination of differences in event parameters is delivering new report RSAU_READ_LOG_DIFF to show changes done to the audit log configuration:
Delete SAP audit log files
Start transaction RSAU_ADMIN and start the option for log file reorganization:
Or you can run/schedule program RSAUPURG.
Restricted access to this function is a must.
Issues with audit logging
There are some known issues with the audit logging.
If too much items are selected in the filters the audit logging will grow very fast. If the audit log is full, it will start to overwrite the earlier entries. The earlier entries are then lost. This is called logging shadow. Depending on your requirements, you have to increase the disk space, and better: check which item in the audit log settings you don’t need, but do cause extensive amount of logging.
Large SAP systems with multiple application servers
On large SAP systems with multiple application servers, the file handling can cause issues. If the system is setup using shared files and the names of the profile configuration per application server for the file name is identical, this will cause nasty issue. The issue is that the audit logging from several application servers will overwrite each other entries. This is hard to detect. Solutions: don’t use shared file, or change the profile parameter per application server to include the application server name into the audit log file name. To do this set the FN_AUDIT parameter to this value: SQL_++++++++.AUD. Upon runtime the +’s will be replaced with the application server name.
Be sure to read OSS note 2367475 – “Profile parameter FN_AUDIT contains an invalid pattern” in system log in this case as well.
See also point 25 in the audit log FAQ note 539404 – FAQ: Answers to questions about the Security Audit Log.
Audit logging integrity
Based on the settings in OSS note 2033317 – Integrity protection format for Security Audit Log, you can switch on the audit logging integrity. This way you can prove nobody tampered with the audit log. But this also means you cannot read the audit logfile on file level or by any third party tool. Please consider this carefully and read the note about other effects and prerequisites first before switching on.
Background OSS notes and blogs
Useful background OSS notes and blogs are:
- Audit log FAQ note 539404 – FAQ: Answers to questions about the Security Audit Log.
- 2360334 – Security Audit Log does not work after setup
- 2414468 – Analysis of SAL log data in the background
- Blog on recommended security audit log settings
Known bugs and bug fixing OSS notes
Bug fixing OSS notes: