SAP Login History Tables. The SAP Login history tables used to track user login are: USR02: Logon Data (Kernel-Side Use) TRDAT: SAP Last Logon Date; LTIME: SAP Last Logon Time; WCRUSERSTAT: login log for Portal; Custom/Exit SAP Login History Track. SAP Transaction Code SM20N (Analysis of Security Audit Log) - SAP TCodes - The Best Online SAP Transaction Code Analytics.

As we know it is being mainly used with the SAP GRC-AC (Access Control in GRC) component which is coming under GRC module (Governance, Risk and Compliance). GRACAUDITLOG is a SAP standard transp table used for storing Security Audit Log table related data in SAP. It comes under the package GRACSUPPERUSERACCESS. Table GRACAUDITLOG technical data. General SAP Audit Checklist. The following are the common checklist during auditing: 1. Obtain a company organizational chart. Obtain a copy of all security policies and procedures. Obtain a diagram of the SAP application architecture.

the Security Audit Log [SAL] contains information about important system events and should, therefore, better not get lost unintentionally!
Let’s see, how the Audit Log can be erased and what we can do to prevent this and maximize its protection.

The Audit Log is stored in log-files that are located in the file system (see parameter DIR_AUDIT) and is either rotated daily or when the current file is full (see parameter rsau/max_diskspace/per_file).

Access to these files is possible via kernel functionality (from within the SAP system) or on operating system level (e.g. via an external OS command). We’ll focus on access via the SAP application server and won’t take a deeper look at manipulations directly from OS level (i.e. from the command line).

Sap Audit Log Table 2019

Ways to delete the Security Audit Log

From inside the SAP system, three variants of deleting the SAL files exist.
Below we’ll check them and see, which measures exist to protect the logs.

Variant 1: SM18 (or function module RSAU_CLEAR_AUDIT_LOG or system function C_REMOVE)

SM18 is the SAP standard way of removing old SAL files.
The transaction is protected by an authorization check for S_ADMI_FCD with value AUDA (= AUDit log Administration). The minimum age of files to be erased is 3 days − a nice feature because an attacker cannot remove fresh logs and hide what he/she did moments ago.

Protection
SM18 is not really problematic… S_ADMI_FCD with value AUDA is a critical authorization, which nobody should be assigned to on production.

Diving a bit deeper…
A clever developer might try to copy the code that is responsible for the deletion to a customer report − fortunately, this does not work… see below:

Sap Security Audit Log Table

In this blog, we’ll focus on the possbile ways to log and trace user activities in SAP HCM system for Infotype changes, transactions, programs, tables, user activities,…

Log for Personnel Administration – Infotypes Changes (PA)

This log is used to get history of the PA infotypes. When you delimit or create a new infotype, the records are still existing in the database. But when you modify or delete records, the information is gone. This applies to R/3 activities and ESS/MSS or portal activities.

Solution is to log all the infotype changes with a view on the old and new data.

The customizing can be done for a change on the infotype or at a field level.

• Configuration Views: V_T585A, V_T585B, V_T585C
• Display Result Program: RPUAUD00
• Display Result Transactions: PC00_M16_UAUD, S_AHR_61015505, S_AHR_61016380, S_ALR_87014081
• Data are stored in Cluster PCL4

Remark: Read or Display access is not taken into account in this log. Solution would be a custom enhancement in the infotype user-exit (ZXPADU01 or BADI).

This log is “technically” actived by default on the system level but not running until the config tables are filled.

Log for Organizational Management and Personnel Development – Infotypes Changes (OM/PD)

Infotype changes for objects (e.g. O, S, P, C, K,…) is also possible. This means that we can trace, for example, the object creation or the relationships modifications.

Technically this means all data under the HRP* tables.

• Configuration Views: T77CDOC_CUST
• Display Result Program: RHCDOC_DISPLAY

The same remark applies here as for the PA log.

Program Log

In specific cases, we want to monitor some specific programs. Reports that are needed on the system but that are “dangerous”, accessing directly tables, providing mass process, etc

For each logged report, you can decide to trace dialog activities (foreground) or batch activities (background).

Sap Audit Log Tables

By default, more or less a thousand of standard reports are in the table but not active. You should also add your critical customer reports there.

• Configuration Table T599R or View V_T599R

• Display result Program: RPUPROTD
• Display result Transactions: S_AHR_61015506, S_AHR_61016381, S_ALR_87014082

Table Log

In some cases, reports change directly tables. Sometimes, we don’t know which report/transaction and user modified a table.

It is possible to trace all activities related to a database table using the technical log.

• Set the parameter “rec/client” in the system profile. (Transaction RZ10 or RZ11)
• Activate the log (“Log data changes”) in the “Technical Details” of the DB table definition (transaction SE11)

• Display the results with transaction SCU3 & Select Evaluated Logs, then the table with option “evaluation for Table”

I have faced 2 specific uses of this log:

1. For the Sarbanes-Oxley (SOX) audit, we had to log the T000 table. Because this table changes the system type (Prod, Dev, Test,…) and there are several ways to changed the values: SCC4, SE16N, …
2. Table PA0003 is the technical table behind the infotype 0003 “Payroll Status”. Altough the infotype was logged with the PA log, some changes were made to the infotypes. How was this possible? This is because this particular infotype is not really modified by users in dialog mode but by programs. The Payroll program (RPCALC*), the Time program (RPTIME00) and the mass update program (RPUTRBK0) are directly accessing the database table. With this trace we could find from which source the change came: Infotype changes (payroll or time relevant), payroll or time run, etc

User Log

The user log is really often by default actived on the system. What depends is the logging period. Most of the time, the period is set to the 3 last months.

With this log we can know what program or transcation each user started.

• Transaction ST03N in Expert Mode, Workload on Total, User Profile

• Function Module SAPWL_WORKLOAD_GET_STATISTIC is retriving all results as raw data

This is a nice way to retrieve log for one user at a time. Because we have to double-click on each line and there is also a mix of report and program, so not really usable as report.

An alternative would be to create a custom report based on this function module such as this one:

This is a really nice tool to play Big Brother 😉

We used this functionnality for the SOX audit and the GRC Segragation of duties. In order to decrease the number of conflicts, we used this log for a year, saving the results by user, user group, date (month) and transaction. We did a reengineering of the roles. We grouped the users by type of job/roles and compare their accesses, tranaction in the roles with the transaction that they really used.

This was a long process but with this we solved 95% of the conflicts without impacting (too much) the users and the company processes.