Analyzing HTTP 401 errors in SAP Business Suite using Security Audit Log

Analyzing HTTP 401 can be challenging many of the times. HTTP 401 errors can have many reasons in an integration environment specially if the calls are coming from an external system, example a cloud system. The reason is mostly due to no of infrastructure and application components involved.

Some of the typical cases

  1. User is locked
  2. Password is incorrect
  3. User Certificate mapping missing
  4. The client certificate has expired.

There can be many other reasons.

HTTP 403 errors are easier to analyze in comparison, which means the user is authenticated but missing the role to execute the desired service (i.e not authorized), one possible reason the role that is assigned to user does not permit the action for the service.

There are various ways of analyzing the HTTP 401 error, SEC_TRACE_ANALYZER is one of the new and recommended way of tracing and troubleshooting security events in HTTP communication with the AS ABAP. Refer to the note 2181120 for more information.

That said, the aim if the blog is to talk about how to analyze 401 error, using Security Audit log, which I find quite useful and almost in all cases helps in identifying the root cause even in lower NetWeaver releases.

For this blog I am consuming the service COD_SALESORDER_SIMULATE via Client certificate authentication. But the steps remain same irrespective of the service and the authentication method.

Please note, I am using a S/4HANA system based on SAP_BASIS 755 SP 0, so you might have a different screen layout and selection screens depending on your system release.

The steps are as follows:

Step 1 :Activate the security Audit log in transaction SM19 (Restrict the selection by providing the client no)

You can select all Audit class, for our use case I have selected the below

Once the Filter is active, it will be distributed to all app server. Check SAP Note 495911, for release dependent options.

Step 2: Activate the Security component trace in transaction SM50 – This step needs to be performed on Application servers (unless you can use a specific server for reproducing the error, for example, by excluding the load distribution)

Note: Use transaction SM51 to navigate to application servers

Select all work processes (F5) and then navigate to Administration->Trace->Active Components (Ctrl+Shift+F7)

Set the trace level to 2, select the Security Component as shown below and save the selection.

Now trace is active, reproduce your scenario.

Make sure to reset SM50 trace on application servers to their Default Values and deactivate SM19 Filter settings.

Step 3 : Analyze the Security Audit log.

Use transaction SM20 (In case of older NetWeaver release you need to do it for each application server) to read the Security Audit log. For Web-based logon procedures as in our case, the selection can be restricted to report SAPMHTTP

For this blog I have 2 use cases based on client certificate authentication, one negative test and one positive test. For the negative test the user certificate mapping was removed via transaction CERTRULE

Now let’s look at the Security Audit log.

The 1st Row is for the negative test, and next 2 entries are for the positive test.

Let’s first analyze the positive test

  1. The 2nd row says, it is an HTTP call (type H) with Client certificate authentication (Method X) and the logon was successful
  2. The 3rd row is for Successful WS Call (service = COD_SALESORDER_SIMULATE, operation COD_SALESORDER_SIMULATE)

Now let’s analyze the negative test.

Here the message text is Logon failed (reason=34, type=H, method=X). Check SAP note 320991, for all possible values of reason, type and method in Audit log.

We have already seen above what type H and method X means, now we have additionally a reason available. Here the reason 34 means No matching SAP account found for X.509 certificate, this was expected as the user certificate mapping has been removed.

In above case (Reason 34 Type H) we can clearly see that a client certificate has been received and accepted from ICF. So we can be sure that the client certificate was trusted and no further entries in STRUST are required. The kernel will now search with the provided certificate for a user mapping. Therefore a kernel function checks all kind of parameters: Certificate Subject, Issuer but also the client in which the vusrextid mapping was done. Details of this search and reasons for failure can be found in kernel trace log dev_w#, where # is the work process id.

We can find the work process id by navigating to the details of the corresponding entry in SM20.

As shown above, the WP (work process no is) 25. Now we can check the corresponding error log file using transaction ST11.

As shown below, in this case the system could not find any mapping for the client certificate.

For reference below is the snapshot of trace data in case the certificate to user mapping is found


The classic transaction for mapping a client certificate to user is EXTID_DN (same as SM30, VUSREXTID). However there is a newer logic implemented from NW 7.31 which should be used if available. Transaction is CERTRULE for maintenance and CERTRULE_MIG for migration of old vusrextid entries. Within CERTRULE you can create a rule based mapping. This is extremely helpful in case the certificate contains already the user id (e.g. as some part of the subject field). In case of technical user this won’t be the case therefore you can also use “explicit mapping” (similar to VUSREXTID logic)


495911 – Logon problem trace analysis

539404 – FAQ: Answers to questions about the Security Audit Log

2181120 – Tracing and troubleshooting security events in http communication with the AS ABAP

2191612 – FAQ | Use of Security Audit Log as of SAP NetWeaver 7.50

Blog: Analysis and Recommended Settings of the Security Audit Log

With this we come to conclusion of this blog. Happy Learning!!!