Introduction
The SAP Security Audit Log (SAL) is a critical security component used to monitor and record security-relevant activities within SAP systems as depicted below,
Traditionally, Security Audit Logs are:
Configured using SM19
Reviewed using SM20
Stored in the file system
However, with the evolution of SAP S/4HANA, the Security Audit Log framework has undergone significant architectural changes.
This blog explains the common confusion scenario which I recently faced.
The Scenario
In an S/4HANA we configure the security audit logs by enabling the filters and setting the parameters we require in SM19. After activation, we review logs using SM20.
Observation
Only critical system-level logs, such as – System settings changes and Client settings changes were visible. Other configured events were not appearing in SM20, despite being properly enabled.
At first glance, this felt like some Configuration issue, Incomplete activation, Authorization problem or system malfunction. However, the actual cause was related to the new SAL architecture in S/4HANA.
Root Cause
In S/4HANA systems, SAP introduced new transactions:
RSAU_CONFIG – for Security Audit Log configurationRSAU_READ_LOG – for reading audit logs
Architecture
Now-a-days, by default the Audit logs are stored in the database instead of the file system.
The relevant configuration can be found in:
RSAU_CONFIG → Parameters → Recording Target
The recording parameter would be set to “Record in Database” to make the Logs to store in database tables.
Behaviour
SM20 can only display logs stored in the file system. It cannot read logs which are stored in the database. As a result, when the recording target is set to database, SM20 may appear to show no results — even though logging is functioning correctly.
Why Does SM20 Still Show Some Logs?
Certain critical events are classified as “permanently active events.” These events are still written to the file system by default. That is why SM20 still displays system-level and client-level configuration changes
SAP_BASIS Version Information
You can use RSAU_CONFIG and RSAU_READ_LOG in any S/4HANA release that includes:
SAP_BASIS 7.50 or higher
Starting from SAP_BASIS 755, the old Security Audit Log environment (originally accessed via SM19 and SM20) is switched off and cannot be used anymore and the system redirects us to the new t-codes
SM19 → It calls RSAU_CONFIG
SM20 → It calls RSAU_READ_LOG
Conclusion
If SM20 does not show all configured logs in S/4HANA:
Check the Recording Target in RSAU_CONFIGIf set to “Database,” use RSAU_READ_LOG instead of SM20Understand that SM20 reads only file-based logs
IntroductionThe SAP Security Audit Log (SAL) is a critical security component used to monitor and record security-relevant activities within SAP systems as depicted below, Traditionally, Security Audit Logs are:Configured using SM19Reviewed using SM20Stored in the file systemHowever, with the evolution of SAP S/4HANA, the Security Audit Log framework has undergone significant architectural changes.This blog explains the common confusion scenario which I recently faced.The ScenarioIn an S/4HANA we configure the security audit logs by enabling the filters and setting the parameters we require in SM19. After activation, we review logs using SM20.ObservationOnly critical system-level logs, such as – System settings changes and Client settings changes were visible. Other configured events were not appearing in SM20, despite being properly enabled.At first glance, this felt like some Configuration issue, Incomplete activation, Authorization problem or system malfunction. However, the actual cause was related to the new SAL architecture in S/4HANA.Root CauseIn S/4HANA systems, SAP introduced new transactions:RSAU_CONFIG – for Security Audit Log configurationRSAU_READ_LOG – for reading audit logsArchitectureNow-a-days, by default the Audit logs are stored in the database instead of the file system.The relevant configuration can be found in: RSAU_CONFIG → Parameters → Recording TargetThe recording parameter would be set to “Record in Database” to make the Logs to store in database tables.BehaviourSM20 can only display logs stored in the file system. It cannot read logs which are stored in the database. As a result, when the recording target is set to database, SM20 may appear to show no results — even though logging is functioning correctly.Why Does SM20 Still Show Some Logs?Certain critical events are classified as “permanently active events.” These events are still written to the file system by default. That is why SM20 still displays system-level and client-level configuration changesSAP_BASIS Version InformationYou can use RSAU_CONFIG and RSAU_READ_LOG in any S/4HANA release that includes:SAP_BASIS 7.50 or higherStarting from SAP_BASIS 755, the old Security Audit Log environment (originally accessed via SM19 and SM20) is switched off and cannot be used anymore and the system redirects us to the new t-codesSM19 → It calls RSAU_CONFIGSM20 → It calls RSAU_READ_LOGConclusionIf SM20 does not show all configured logs in S/4HANA:Check the Recording Target in RSAU_CONFIGIf set to “Database,” use RSAU_READ_LOG instead of SM20Understand that SM20 reads only file-based logs Read More Technology Blog Posts by Members articles
#SAP
#SAPTechnologyblog
