Analyzing HTTP 401 errors can be challenging many of the times. HTTP 401 (Unauthorized) 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 number of infrastructure and application components involved. For this blog, we will restrict ourselves to the AS ABAP server.
Some of the typical cases, but not limited to, that can be result in HTTP 401 error on AS ABAP, are:
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 of this blog is to talk about how to analyze HTTP 401 error, using Security Audit log, which I find quite useful and almost in all cases helps in identifying the root cause including 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.
The steps are as follows:
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.
This step needs to be performed on all application servers (unless you can use a specific server for reproducing the error, for example, by excluding the load distribution). Use transaction SM51 to switch to other 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 all application servers to their Default Values and deactivate SM19 filter settings.
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 (this selection screen is dependent on NetWeaver release)
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
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, method=X) we can clearly see that a client certificate has been received and accepted from ICM. So we can be sure that the client certificate was trusted, so STRUST entires are all properly configured. 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 (positive test)
The classic transaction for mapping a client certificate to user is EXTID_DN (SM30 View 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 entries)
320991 - Error codes during logon (list)
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!!!
Some of the typical cases, but not limited to, that can be result in HTTP 401 error on AS ABAP, are:
- User is locked
- Password is incorrect
- User Certificate mapping missing
- The client certificate has expired.
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 of this blog is to talk about how to analyze HTTP 401 error, using Security Audit log, which I find quite useful and almost in all cases helps in identifying the root cause including 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, the screenshots provided in this blog are based on 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 all application servers (unless you can use a specific server for reproducing the error, for example, by excluding the load distribution). Use transaction SM51 to switch to other 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 all application servers to their Default Values and deactivate SM19 filter settings.
Step 3 : Analyze the Security Audit log via transaction SM20
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 (this selection screen is dependent on NetWeaver release)
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
- The 2nd row says, it is an HTTP call (type H) with Client certificate authentication (Method X) and the logon was successful
- 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, method=X) we can clearly see that a client certificate has been received and accepted from ICM. So we can be sure that the client certificate was trusted, so STRUST entires are all properly configured. 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 (positive test)
Appendix
The classic transaction for mapping a client certificate to user is EXTID_DN (SM30 View 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 entries)
References:
320991 - Error codes during logon (list)
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!!!
- SAP Managed Tags:
3 Comments
| User | Count |
|---|---|
| 4 | |
| 4 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
