1 2 3 6 Previous Next

SAP NetWeaver Application Server

90 Posts

Dear SCN Community,

 

The support experts in the ABAP Gateway area (BC-CST-GW) at SAP have decided to create a training for customers and SAP users. In this training session, they explain the concept fundamentals and provide configuration examples of the following Gateway security features:

 

• The “reginfo” rules (related to the registration of external programs/systems at SAP);

• The “secinfo” rules (related to programs started on demand);

• Parameter “gw/acl_mode” (system behavior depending on the value of this parameter).

 

Are you interested? If so, find more details and enroll yourself in the below link.

 

https://www.eventbrite.com/e/gateway-security-features-fundamentals-training-tickets-27728829676

 

Best Regards,
Daniel Grings

Purpose

 

The purpose of this document is help in cases where the JAVA Dispatcher/ ICM (Internet Communication Manager) leads to erroneous situations and more detailed investigation is needed.

 

  • The SAP Application Server JAVA dispatcher distributes the client requests to the free server processes using a “round robin” algorithm. If there is already a connection to the client, the request is forwarded to the server process that is already processing requests for this client.
  • The Internet Communication Manager ensures that communication between the SAP System (SAP Web Application Server) and the outside world via HTTP, HTTPS and SMTP protocols works properly. In its role as a server the ICM can process requests from the Internet that arrive as URLs with the server/port combination that the ICM can listen to. The ICM then calls the relevant local handler for the URL in question.

 

Example Scenario

 

Lets say that you suspect there is uneven load balancing between the server nodes. In this case, detailed JAVA dispatcher traces will help. Another example will be that requests are triggered from a 3rd party load balancer to the ICM and this fails. Analyzing the ICM traces will shed more light. This analysis will also help in standard performance tuning and optimization of ICM if needed.

Example Screenshot:
ICM error.png



DISPATCHER (SAP Release 6.40 and 7.00/7.01/7.02)


To trace the Dispatcher, enable the property HttpTrace (set it to enable) and HttpTraceTime to true as per  as per SAP note 724719.. Also open Visual Admin -> goto Dispatcher node -> services -> LogConfigurator -> Locations tab -> com.sap.engine.services.httpserver and set the severity (of the subtree as well) to DEBUG. Once the issue is reproduced, more detailed trace will be available in req_resp.trc files under Dispatcher folder of each instance.  The latest modified DefaultTrace files under dispatcher and server log folders will also have more info.


ICM (SAP Release 7.1/7.2/7.3/7.31/7.4/7.5


To enable the ICM trace, see SAP Note:1095475. Also enable the HTTP Provider service (location com.sap.engine.services.httpserver.server.RequestImpl) as mentioned in the note for more detailed tracing on the server nodes as well.Check the latest logs in the below folder to investigate further:
        -  usr\sap\<SID>\<instance_number>\work\dev_icm

        -  usr\sap\<SID>\<instance_number>\j2ee\cluster\serverX\defaultTrace<xx>.trc

This blog shows how to integrate the SAP OData service and perform the data operations via a UI5 Application. 


Example scenarios: Registration/Login form for employee. In below screen shots I have used Eclipse editor to build the app.

 

User will enter his details and click on Register, now these details need to be saved in SAP backend using ODATA service.

 

  1. Code in .XML file (can be any other like .JSON,.HTML)

 

In the UI5 application, we would have a view consisting of required fields and button. The button tag is written as shown below,

 

1.png

 

As we need to perform some activity on pressing the button, we have given the event ‘press’ for that button and the value for that event is ‘onReg’.

We shall use this ID onReg as a function, inside this we can perform the required activity.

 

     2. Now in the controller (.js file), we will implement this event as a function. Inside this function, we are going to render the required Odata service and perform READ/WRITE operations.

 

2.png

 

Below are the steps:


  1. READ

 

       First, you need to render you Odata service.Give the URI of your ODATA service as shown in below picture.

 

        3.png

      Perform the READ operation.

      4.png

 

         Variable OData – Will hold the read values from the backend. This is how we perform READ operation from front-end app.

         We can access all the fields from OATA like this - odata.NAME_FIRST (here fields NAME_FIRST need to be exactly as they were defined in Odata service.

 

5.png\

 

b. CREATE

 

        Pass the required data to be saved in back-end. We took a variable called oEntry and here we are passing all the required fields that are to be saved.

 

        Note: The field names must be same as they were declared in Odata service.

 

     6.png

 

     Render the service (you don’t need to render if this is already done in same function, if different function then we need to render again).

 

    7.png

 

        Performing the CREATE operation.


      8.png

 



  c. UPDATE

 

       Pass the required data to be saved as shown below.

 

      9.png

 

 

      Render the service if not rendered in same function.


     10.png


     Perform UPDATE.


     11.png


This is how we integrate the Odata service and perform required operations.

Thanks for reading !

Over the years I've had to install and upgrade a number of SAP Web Dispatchers, the following is my go-to configuration for version 7.45 as per and starting with SAP Note 908097 SAP Web Dispatcher: Release, apply patches #/notes/908097/E

 

Note the following statements, "Version 7.45 is the recommended SAP Web Dispatcher version for all backend systems" and "SAP Web Dispatcher version 7.45 is installed and delivered in the Unicode variant, older versions were non-Unicode. The non-Unicode variant is installed in the ../nuc/.. directory instead of ../uc/". Hence best to switch to ../uc/ when upgrading from a release prior to 7.45.

 

The configuration below is for a S/4 HANA (HANA system_0) & ABAP (system_1), default ports, supporting end-to-end HTTPS, running on a virtual IP (alias). I've also included references to SAP notes around some of the features and security parameters that I tend to enable for an internal install. Logging, HTTPS, http_mod configured as required.

 

The following  directories need to be created to support the config:


$(DIR_INSTANCE)/data/error_templ

$(DIR_INSTANCE)/log/httpaccess

$(DIR_INSTANCE)/data/cache/0

 

The following  files need to be created to support the config:


$(DIR_PROFILE)/$(SAPSYSTEMNAME)_$(INSTANCE_NAME)_http_mod

$(DIR_PROFILE)/$(SAPSYSTEMNAME)_$(INSTANCE_NAME)_permission_table

 

Parameters

 

# DEFAULT.PFL

 

SAPSYSTEMNAME = <SAPSID>

OS_UNICODE = uc

SAPGLOBALHOST = <hostname>

system/type =

#-----------------------------------------------------------------------

# Security

#-----------------------------------------------------------------------

# 2287039 - ICMAN - Redirect page shows server information

is/server_name = SAP

is/server_version = 1.0

# 2260323 - Internet Communication Manager (ICM) 7.20 security settings

is/HTTP/show_server_header = FALSE

is/HTTP/show_detailed_errors = FALSE

icm/HTTP/error_templ_path = $(DIR_INSTANCE)/data/error_templ

 

# INSTANCE_PROFILE.PFL

 

SAPSYSTEMNAME = <SAPSID>

SAPSYSTEM = <NR>

INSTANCE_NAME = W<NR>

DIR_CT_RUN = $(DIR_EXE_ROOT)$(DIR_SEP)$(OS_UNICODE)$(DIR_SEP)linuxx86_64

DIR_EXECUTABLE = $(DIR_CT_RUN)

SAPLOCALHOST = <HOSTNAME>

SAPFQDN = <FQDN>

SAPLOCALHOSTFULL = $(SAPLOCALHOST).$(SAPFQDN)

DIR_PROFILE = $(DIR_INSTALL)/profile

_PF = $(DIR_PROFILE)/$(SAPSYSTEMNAME)_$(INSTANCE_NAME)_$(SAPLOCALHOST)

SETENV_00 = DIR_LIBRARY=$(DIR_LIBRARY)

SETENV_01 = LD_LIBRARY_PATH=$(DIR_LIBRARY):%(LD_LIBRARY_PATH)

SETENV_02 = SHLIB_PATH=$(DIR_LIBRARY):%(SHLIB_PATH)

SETENV_03 = LIBPATH=$(DIR_LIBRARY):%(LIBPATH)

SETENV_04 = PATH=$(DIR_EXECUTABLE):%(PATH)

#-----------------------------------------------------------------------

# Accessibility of Message Server

#-----------------------------------------------------------------------

# 2193190 - Web Dispatcher - wdisp/system_conflict_resolution - BEST_MATCH

wdisp/system_conflict_resolution = BEST_MATCH

# 1937653 - System specific SSL parameter for SAP Web Dispatcher

wdisp/system_0 = SID=HDB, EXTSRV=https://saphdb1.$(SAPFQDN):4300, SRCSRV=$(SAPLOCALHOST).$(SAPFQDN):443, SRCVHOST=<ALIAS0>.$(SAPFQDN):443, SRCURL=/sap/hba/;/sap/hana/;/sap/ui5/, SSL_ENCRYPT=2

wdisp/system_1 = SID=ERP, MSHOST=saperp1.$(SAPFQDN), MSSPORT=8100, SRCSRV=$(SAPLOCALHOST).$(SAPFQDN):443, SRCVHOST=<ALIAS1>.$(SAPFQDN):443, SCSHOST=saperpscs.$(SAPFQDN), NR=01, SSL_ENCRYPT=2, CONFIG_PROTOCOL=https

#-----------------------------------------------------------------------

# Configuration for default scenario

#-----------------------------------------------------------------------

# 2007212 - Tuning SAP Web Dispatcher and ICM for high load

icm/max_conn = 2000

#-----------------------------------------------------------------------

# SAP Web Dispatcher Ports

#-----------------------------------------------------------------------

# 421359 - ICM: Binding ports < 1024 on UNIX

icm/server_port_0 = PROT=HTTP, HOST=$(SAPLOCALHOST), PORT=80, TIMEOUT=360, PROCTIMEOUT=720, EXTBIND=1

icm/server_port_1 = PROT=HTTPS, HOST=$(SAPLOCALHOST), PORT=443, TIMEOUT=360, PROCTIMEOUT=720, EXTBIND=1, SSLCONFIG=ssl_config_0

# 2258786 - Potential information disclosure relating to SAP Web Administration Interface

icm/HTTP/admin_0 = PREFIX=/sap/admin/, DOCROOT=$(DIR_DATA)$(DIR_SEP)icmandir, HOST=$(SAPLOCALHOST).$(SAPFQDN), AUTHFILE=$(icm/authfile), PORT=443, ALLOWPUB=FALSE

icm/host_name_full = $(SAPGLOBALHOST).$(SAPFQDN)

#-----------------------------------------------------------------------

# Security

#-----------------------------------------------------------------------

# 2014996 - SSL Setup SAP Web Dispatcher

# 510007 - Setting up SSL on Application Server ABAP

icm/ssl_config_0 = VCLIENT=1, CRED=$(DIR_INSTANCE)/sec/SAPSSLS.pse

icm/HTTPS/verify_client = 1

icm/HTTPS/forward_ccert_as_header = TRUE

# 2160678 - SSO stops working when the "icm/HTTPS/trust_client_with*" parameters are configured

icm/HTTPS/trust_client_with_issuer = CN=<as required>

icm/HTTPS/trust_client_with_subject = CN=<as required>

# 2092630 - Turning off SSLv3 on SAP NetWeaver

ssl/ciphersuites = <as required>

ssl/client_ciphersuites = <as required>

wdisp/add_client_protocol_header = TRUE

wdisp/ssl_encrypt = 2

wdisp/ssl_auth = 2

wdisp/ssl_cred = $(DIR_INSTANCE)/sec/SAPSSLC.pse

wdisp/HTTP/use_pool_for_new_conn = 1

# 2180024 - HANA & ABAP: New Option to Enable/Disable FIPS 140-2 Certified Crypto Kernel

ccl/fips/enable = 1

#-----------------------------------------------------------------------

# Logging (System Specific)

#-----------------------------------------------------------------------

# 2155855 - Web Dispatcher - System specific logging, caching and file access

icm/HTTP/logging_0 = PREFIX=/, LOGFILE=$(DIR_INSTANCE)/log/httpaccess/dev_httpaccess.log.erp, LOGFORMAT=SAP, SWITCHTF=day, SYSTEM=ERP

icm/HTTP/logging_1 = PREFIX=/, LOGFILE=$(DIR_INSTANCE)/log/httpaccess/dev_httpaccess.log.hdb, LOGFORMAT=SAP, SWITCHTF=day, SYSTEM=HDB

icm/HTTP/logging_2 = PREFIX=/sap/admin/, LOGFILE=$(DIR_INSTANCE)/log/httpaccess/dev_httpaccess.log.adm, LOGFORMAT=SAP, SWITCHTF=day

#-----------------------------------------------------------------------

# URL Mod Handler

#-----------------------------------------------------------------------

icm/HTTP/mod_0 = PREFIX=/, FILE = $(DIR_PROFILE)/$(SAPSYSTEMNAME)_$(INSTANCE_NAME)_http_mod

#-----------------------------------------------------------------------

# Permission Table

#-----------------------------------------------------------------------

wdisp/permission_table = $(DIR_PROFILE)/$(SAPSYSTEMNAME)_$(INSTANCE_NAME)_permission_table

#-----------------------------------------------------------------------

# File Access (Global)

#-----------------------------------------------------------------------

icm/HTTP/file_access_0 = PREFIX=/robots.txt, DOCROOT=$(DIR_INSTANCE)/data/public/robots.txt

icm/HTTP/file_access_1 = PREFIX=/favicon.ico, DOCROOT=$(DIR_INSTANCE)/data/public/favicon.ico

#-----------------------------------------------------------------------

# Cache (Global)

#-----------------------------------------------------------------------

icm/HTTP/server_cache_0/http_cache_control = true

icm/HTTP/server_cache_0 = PREFIX=/, CACHEDIR = $(DIR_INSTANCE)/data/cache/0

icm/HTTP/server_cache_0/expiration = 86400

#-----------------------------------------------------------------------

# Start Web Dispatcher

#-----------------------------------------------------------------------

# 768727 - Automatic restart functions in sapstart for processes

Autostart = 1

SignalMask_00 = default, 9

logfile/rotate = true

_WD = wd.sap$(SAPSYSTEMNAME)_$(INSTANCE_NAME)

SETENV_05 = SECUDIR=$(DIR_INSTANCE)/sec

Execute_00 = local rm -f $(_WD)

Execute_01 = local ln -s -f $(DIR_EXECUTABLE)/sapwebdisp$(FT_EXE) $(_WD)

Restart_Program_00 = local $(_WD) pf=$(_PF)

 

# _permission_table


# Deny public information

D /sap/public/icf_info/*

D /sap/public/info

D /sap/public/icf_check

# Allowed

S /sap/*

# Deny all others

D *

 

Some other good features to be aware of:

 

1971571 - Web Dispatcher new features: Proxy connect and cookie filter #/notes/1971571/E

2220456 - How to configure SAP Web Dispatcher for Reverse Invoke #/notes/2220456/E

2192839 - Using Web Dispatcher protocol ROUTER for TCP load balancing #/notes/2192839/E

 

Hope it's of help

Craig

Today I am starting a new blog series, on sizing and load testing in a SAP Netweaver environment.

In this blog, I describe the reasons for the new series of posts, the landscape I will use as a scenario and the tools I will use.

 

Reasons

 

Since 2007, I work supporting ITS (Internet Transaction Server). I also worked with WDA (Web Dynpro ABAP) and, most recently, I started supporting SAP Screen Personas.

I had some opportunities to visit SAP customers that use ITS, WDA and Personas. In such visits, there was a concern about the correct sizing of the system, to cope the expected demand.


For ITS, I use the following SAP notes:


742048 - Integrated ITS, memory requirement in application server

1888428 - Sizing for SAP GUI for HTML

2233645 - ITS Memory Trace tool


I also use SAP note 1343331 (Integrated ITS: Scaling, optimization and load test).


For Web Dynpro ABAP, the following SAP notes are valid:


1612245 - Frontend Hardware Requirements for Browser-Based SAP UI

1933805 - Stable ID for automated test


For SAP Screen Personas, this Wiki page can be used.

 

Therefore, for sizing, the ground is pretty well covered. Put things in practice require several coffee cups.

However, what about load tests?

For ITS, I found one note: 651581 (Load testing ITS servers), which gives some tips if you face issues while doing the load testing. Nothing on how to test itself and the same applies to Web Dynpro ABAP and to Personas.

Thus, I decided to write about load testing, starting with ITS scenarios, moving to Personas and include some WDA applications at the end (counting on the help of a few WDA co-workers).

 

Landscape

 

I will start with a simple scenario: a supported web browser reaching a SAP system:

 

Web Browser - SAP.jpg

 

I will gather basic information about what to test (transaction, steps involved, elapsed time, etc.). Then I will add more complexity, bit by bit: first adding another application server, load balancing using the message server; then adding a SAP Web Dispatcher (WDP) to do the load balancing; and finally adding a Portal in front of the WDP.

 

Tools

 

It seems that load testing appeared a few times in our neighborhood. I found this blog interesting. For a more hands-on approach, this blog is perfect - it shows the load testing with Web Dynpro ABAP applications.

I decided to go with the same flow and use Apache JMeter as the tool to perform my load tests.

I will use other tools to analyze the information from the tests.

 

More Information

 

Even though you can find plenty on Apache JMeter, I think a good book is also a good companion. To cover the basics, you might want to have Apache JMeter, from Emily H. Halili.

 

Stay tuned for my next blog on sizing & load tests.

Imagine the scenario where your system was migrated from one server to another. The OS used was changed. In order to keep SAL data, you have moved SAL files from the original system to the new system. However, you have no results in your SM20 reports. What happened? How to resolve this issue?

 

Big versus Little?

 

Usually the code page from the server changed. You may also have changed from a big endian system to a little endian one, from your favorite Unix flavor to your favorite Linux flavor (or vice-versa). You can read more about what “endian” means in SAP note 552464.

 

You can use transaction code I18N to view the current internationalization system configuration:

I18N.jpg

 

Then you can find the code page of your system. In my test system, it is 4103 (Windows Server).

My source system have code page 4102 (AIX). Yes, you need to check the I18N system configuration in both systems, so you have the correct code pages.

 

The issue: moving one SAL file from the source system to the new system, and reading the file via report RSAU_SELECT_EVENTS shows:

RSAU_SELECT_EVENTS-1.jpg

 

The file size is more than 20 Megabytes and no entry found? Who would think that a simple code page change would cause such effect!

 

How to resolve the issue?

 

The short version: file conversion.


The long version: use report RSCP_CONVERT_FILE. It allows you to specify source and target code pages, specify the location of the files.


Note that you need to specify one file that contains the list of files that should be converted.

My file “list.txt” holds the list of files that I want to convert. For test purposes, I just put a single row in the list.


The input screen is this one:


RSCP_CONVERT_FILE-1.jpg

 

The result of the file conversion:


RSCP_CONVERT_FILE-2.jpg

 

Now, the result of RSAU_SELECT_EVENTS:


RSAU_SELECT_EVENTS-2.jpg

 

Additional Information

 

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

747615 - Tool for converting files from one code page to another

752859 - sapiconv - a tool for converting the encoding of files

 

Do not miss the most comprehensive document on SAL that I ever found, available here: “Analysis and Recommended Settings of the Security Audit Log (SM19 / SM20)”.

 

If you have missed my previous blogs on SAL:

 

Stay tuned for my next blog series on… surprise, surprise!

Another scenario involving SAL: do you want to have a single SAL file created per day? Alternatively, do you want to have more than one file, limiting the file size and the total amount of space occupied per day?


Making myself tireless on spreading a good advice, the most comprehensive document on SAL that I ever found, is available here: “Analysis and Recommended Settings of the Security Audit Log (SM19 / SM20)”.

 

a) SAL configuration: a single file per day

 

The configuration is simple: just set:


FN_AUDIT = ++++++++.AUD


and:


rsau/max_diskspace/local = xxxxx


The unit used for the disk space is Bytes (if the number does not present a suffix), or k (or K) for Kilobytes, or m (or M) for Megabytes.

 

b) SAL configuration: multiple files per day

 

Similar to the configuration to have a single file per day, you have to set:


FN_AUDIT = audit_++++++++_######.AUD


and two additional parameters:


rsau/max_diskspace/per_file = xxxxx

rsau/max_diskspace/per_day = yyyyy


Where xxxxx < yyyyy. The unit used for the disk space is the same as above.

Note that the mask in FN_AUDIT now contains ######, which will be replaced by a sequential number, i.e. a new number as soon as the file have reached the permitted file size. The new number is used to create the new SAL file.

 

c) SAL configuration: mixing things with odd results

 

I already saw cases where a configuration like this was used:


FN_AUDIT = audit_++++++++_######.AUD

rsau/max_diskspace/local = zzzzz

rsau/max_diskspace/per_file = xxxxx

rsau/max_diskspace/per_day = yyyyy


In such case, the configuration is not correct. It is not possible have a single file and multiple files, using a specific FN_AUDIT value.

Using SM20 in such case can bring a result like:

SM20.jpg

 

Even though there are SAL entries recorded in the files.

 

The solution is simple: use a) or b). Option c) is not valid - and can give you headaches.

 

Additional Information

 

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

875835 - SecAudit: Analysis finds no audit events

909738 - SecAudit: Files are created with other names

 

Stay tuned for my last blog on SAL.

Today I will present a scenario about SAL: use one directory to store all SAL files from all application servers in a SAP system.

 

As I mentioned in my previous blog, the most comprehensive document on SAL that I ever found, is available here: “Analysis and Recommended Settings of the Security Audit Log (SM19 / SM20)”.

 

My system landscape

 

For testing purposes, I will use a SAP Netweaver 7.31 system. It have the following hosts and instances:


Host A: ASCS01 and DVEBMGS00

Host B: D00 and D01

 

SID.jpg

 

SAL configuration

 

I will set DIR_AUDIT to \\Host B\usr\sap\SID\Audit\ in all dialog instances from the system.


Additional parameters:


FN_AUDIT = audit_++++++++_######.AUD

rsau/max_diskspace/per_day = 1000M

rsau/max_diskspace/per_file = 100M

 

Thus, all SAL files will be recorded in a single directory, using the pattern above (given by FN_AUDIT). I expect multiple files per day, having each file 100 MB. The maximum disk space that can be used every day is 1000 MB.

 

In SM19 I decided to record all Audit classes in all clients for all user IDs.

 

Where are the entries?

 

Well, all the entries are recorded in the same file, for all application servers. You will find incorrect information in SM20:

SM20.jpg

 

As you can see, 1, 2 and 3 show the exact same entries, for the same User and same Terminal name (even though I omitted this information from the screenshot). The entries from 1 and 2 are from Host B, instances D00 and D01. The entries from 3 are from Host A, instance DVEBMGS00.

 

Solution

 

Set individual directories for SAL files. Each application server should write its own files in an exclusive directory.

So, in my landscape, fixing things means setting DIR_AUDIT in the instance profile, using:

SID_DVEBMGS00_HOSTA:

DIR_AUDIT = X:\usr\sap\SID\DVEBMGS00\log

SID_D00_HOSTB:

DIR_AUDIT = X:\usr\sap\SID\D00\log

SID_D01_HOSTB:

DIR_AUDIT = X:\usr\sap\SID\D01\log

Then I executed one transaction code in each app server, resulting in the following SM20 report:


SM20 v2.jpg

 

Additional Information

 

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

 

Stay tuned for my next blog on SAL.

Today I am starting a new blog series, about some issues when incorrect configuration is made on the Security Audit Log (SAL).

 

If you are interested on reading the most comprehensive document on SAL that I ever found, then please read “Analysis and Recommended Settings of the Security Audit Log (SM19 / SM20)”.

 

Why no UNC and NFS mounts?

 

The story short: performance.

 

SAL needs a stable file system to write. UNC (Universal Naming Convention) and NFS (Network File System) mounts are not appropriate. There is a variety of known issues using any of both.

Note that the file handler for SAL file needs to keep opened, due to performance reasons. The file handler would point to an arbitrary location when the file system disappears.

 

What should I do then?

 

The SAL files I have are huge, and I do not have enough file system space to store them. What should I do, if I cannot use UNC and NFS mounts?

 

You should use the local file system. Of course, since you have limited file system space, then you should use OS-level tools to archive audit files. Archived files can be moved to NFS mount location or to a UNC path. If you want to read individual files, then you can use report RSAU_SELECT_EVENTS (a single file can be read at time).

 

Additional Information

 

  • 539404 - FAQ: Answers to questions about the Security Audit Log
  • 1810913 - Performance improvement when reading the Security Audit Log
  • 2191612 - FAQ | Use of Security Audit Log as of NetWeaver 7.50

 

Stay tuned for my next blog on SAL.

By now, you already know how to setup the SM50 logon trace and how to configure the system to use X.509 client certificates.

Now it is time to go a bit deeper in the logon trace (and some other resources) and see what happens to have the SSO working.

 

Test: web browser side

 

Using IE or any other web browser, access a service in the ECC, e.g. the WEBGUI service (SAPGUI for HTML). The URL is:

https://<FQDN>/sap/bc/gui/sap/its/webgui

The port number is hidden (443 is the default HTTPS port).

The expected result is the WEBGUI loaded:

X.509.jpg

 

The question is: what happened behind the scenes? Using Fiddler I can see the SSL connection being established:

"...

HTTP/1.0 200 Connection Established

...

Secure Protocol: Tls12

Cipher: Aes128 128bits

Hash Algorithm: Sha256 ?bits

Key Exchange: RsaKeyX 4096bits

== Client Certificate ==========

[Subject]

  CN=...

...

[Issuer]

  CN=...

[Serial Number]

  6...

[Not Before]

  ...

[Not After]

  ...

[Thumbprint]

  ...

 

== Server Certificate ==========

[Subject]

  CN=...

[Issuer]

  CN=...

[Serial Number]

  0...

[Not Before]

  ...

[Not After]

  ...

[Thumbprint]

  2...

..."

So, the client certificate was sent to the ECC system. Where can I see the certificate? What happened then?

 

Test: ECC side, part 1: ICM trace


The ICM is the actual web server of the SAP system. It will receive the HTTP/HTTPS requests and, according to the configuration, pass the information to the appropriate handler.

 

In the ICM trace file, I can find the certificate information. Note that I set, prior of calling the WEBGUI service, the ICM trace level to 3, so I have a lot of information! I also set icm/trace_secured_data=1, so the HTML code is recorded in the trace file.

In the ICM trace file, I could find the following information:

 

"...

[Thr 3852] IcmWorkerThread: worker 8 got the semaphore

[Thr 3852] DoW moY dd hh:mm:ss yyyy

[Thr 3852] REQ TRACE BEGIN: 4/2944/1

[Thr 3852] REQUEST:

    Type: ACCEPT_CONNECTION    Index = 3891

[Thr 3852] CONNECTION (id=4/2944):

    used: 1, type: default, role: Server(1), stateful: 0

    NI_HDL: 115, protocol: HTTPS(2)

    local host:  xx.yyy.zzz.aa:443 ()

    remote host: xx.bbb.ccc.ddd:53128 ()

    status: NOP

    connect time: dd.mm.yyyy hh:mm:ss

    MPI request:        <0>      MPI response:        <0>     MPI next: <0>

    request_buf_size:   0 response_buf_size:   0

    request_buf_used:   0 response_buf_used:   0

    request_buf_offset: 0        response_buf_offset: 0

..."

This is the moment that the ICM received the request, so thread 3852 will process my connection.

 

The ICM is acting as a server and, having auth_type=1 (ICM parameter: icm/HTTPS/verify_client=1), the client certificate is requested.

"...

[Thr 3852] ->> SapSSLSessionInit(&sssl_hdl=0000000020162400, role=2 (SERVER), auth_type=1 (ASK_CLIENT_CERT))

[Thr 3852] <<- SapSSLSessionInit()==SAP_O_K

[Thr 3852]      in: args = "role=2 (SERVER), auth_type=1 (ASK_CLIENT_CERT)"

[Thr 3852]     out: sssl_hdl = 000000000554DC50

[Thr 3852] ->> SapSSLSetNiHdl(sssl_hdl=000000000554DC50, ni_hdl=115)

[Thr 3852]   SSL NI-hdl 115: local=xx.yyy.zzz.aa:443  peer=xx.bbb.ccc.ddd:53128

[Thr 3852] <<- SapSSLSetNiHdl(sssl_hdl=000000000554DC50, ni_hdl=115)==SAP_O_K

[Thr 3852] ->> SapSSLSessionStart(sssl_hdl=000000000554DC50)

..."

 

The SSL handshake happens, where server and client check their respective cipher suites, and decided for one:

"...

[Thr 3852]   Server-configured Ciphersuites: "TLS_RSA_WITH_AES128_GCM_SHA256:TLS_RSA_WITH_AES256_GCM_SHA384:TLS_RSA_WITH_AES128_CBC_

[Thr 3852]   Client-offered Ciphersuites: "TLS_ECDHE_RSA_WITH_AES256_CBC_SHA384:TLS_RSA_WITH_AES256_GCM_SHA384:TLS_RSA_WITH_AES128_G

[Thr 3852]   Client Certificate available (FCPath-Len= 0)

[Thr 3852]   New session (TLSv1.2, TLS_RSA_WITH_AES128_GCM_SHA256)

[Thr 3852]   HexDump of new SSL session ID { &buf= 000000002040B73C, buf_len= 32 }

..."

 

The client certificate is received:

"...

[Thr 3852] Base64-Dump of peer certificate (len=1052 bytes)

[Thr 3852]

[Thr 3852] -----BEGIN CERTIFICATE-----

[Thr 3852] MIIEGDCC 4 g w B g K T c gG   B   FA v  s  Q D

...

[Thr 3852] l  7/   i n   R   q g    Qu   Y o   8=

[Thr 3852] -----END CERTIFICATE-----

[Thr 3852] <<- SapSSLSessionStart(sssl_hdl=000000000554DC50)==SAP_O_K

[Thr 3852]  in/out: status = "new SSL session,TLSv1.2,TLS_RSA_WITH_AES128_GCM_SHA256, received client cert"

[Thr 3852]   Subject DN = "CN=..."

[Thr 3852]   Issuer  DN = "CN=CA Cert..."

..."

 

The URL requested was:

"...

[Thr 3852] Address   Offset IcmReadFromConn received

[Thr 3852] ------------------------------------------------------------------------

[Thr 3852] 0000000020714358  000000  47455420 2f736170 2f62632f 6775692f |GET /sap/bc/gui/|

[Thr 3852] 0000000020714368  000016  7361702f 6974732f 77656267 75692048 |sap/its/webgui H|

[Thr 3852] 0000000020714398  000064  5454502f 312e310d 0a416363 6570743a |TTP/1.1..Accept:|

[Thr 3852] 00000000207143A8  000080  20746578 742f6874 6d6c2c20 6170706c | text/html, appl|

...

[Thr 3852] 0000000020714568  000528  0a0d0a                              |...             |

[Thr 3852] ------------------------------------------------------------------------

[Thr 3852] HttpPlugInHandleNetData(rqid=4/2944/1): role: Server(1), status: 1

[Thr 3852]    content-length: 0/0, buf_len: 531, buf_offset: 0, buf_status: 0

...

[Thr 3852]   GET /sap/bc/gui/sap/its/webgui HTTP/1.1

[Thr 3852]   accept: text/html, application/xhtml+xml, */*

[Thr 3852]   user-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; Touch; rv:11.0) like Gecko

[Thr 3852]   accept-encoding: gzip, deflate, peerdist

..."

 

Additional information from the peer:

"...

[Thr 3852] Connection Info: role=Server, local=FQDN:443, peer=xx.bbb.ccc.ddd, protocol=HTTPS

[Thr 3852] ->> SapSSLGetPeerInfo(sssl_hdl=000000000554DC50, &cert=000000003F55E6B8, &cert_len=000000003F55E6B0,

[Thr 3852]     &subject_dn=000000003F55E6C8, &issuer_dn=000000003F55E6C0, &cipher=000000003F55E6D0)

[Thr 3852] <<- SapSSLGetPeerInfo(sssl_hdl=000000000554DC50)==SAP_O_K

[Thr 3852]     out: subject  = "CN=..."

[Thr 3852]     out: issuer   = "CN=CA Cert..."

[Thr 3852]     out: cert_len = 1052

[Thr 3852]     out: cipher   = "TLS_RSA_WITH_AES128_GCM_SHA256"

[Thr 3852] Client certificate info: subject="CN=...", issuer="CN=CA Cert..."

...

[Thr 3852] HttpModGetDefRules: Client certificate received: with len=1052, subj="CN=...", issuer="CN=CA Cert..."

[Thr 3852] HttpModGetDefRules: determined the defactions: COPY_CERT_TO_MPI ADD_CERT_TO_HEADER COMPAT_HANDLING  (21)

[Thr 3852] ->> SapSSLGetPeerInfo(sssl_hdl=000000000554DC50, &cert=000000003F545610, &cert_len=000000003F5455D8,

[Thr 3852]     &subject_dn=000000003F5456A8, &issuer_dn=000000003F5456B0, &cipher=000000003F5456A0)

[Thr 3852] <<- SapSSLGetPeerInfo(sssl_hdl=000000000554DC50)==SAP_O_K

[Thr 3852]     out: subject  = "CN=..."

[Thr 3852]     out: issuer   = "CN=CA Cert..."

[Thr 3852]     out: cert_len = 1052

[Thr 3852]     out: cipher   = "TLS_RSA_WITH_AES128_GCM_SHA256"

..."

 

Now the certificate will be copied to the header:

"...

[Thr 3852] HttpModHandler: add cert to headers: cert_array_len=1, cipher_id_len=2, cipher_size=128

[Thr 3852] cipher_suite: 009c[

[Thr 3852] HttpModHandler: perform the actions: COPY_CERT_TO_MPI ADD_CERT_TO_HEADER COMPAT_HANDLING (21)

[Thr 3852] MPI<139>4#4 GetOutbuf -1 214260 65536 (0) -> 00000000207042D0 104857600 MPI_OK

[Thr 3852] HttpModHandler: serialize new http header

[Thr 3852] ICT: IctHttpCloseMessage( 0000000020408020 ) -> u=0 rc=0

[Thr 3852] HttpModHandler: copy cert to buffer (len=1052)

[Thr 3852] Address   Offset ssl client cert:

[Thr 3852] ------------------------------------------------------------------------

[Thr 3852] 00000000203F9EF0  000000  30820418 30820381 a0030201 02020a65 |0...0..........e|

...

[Thr 3852] 00000000203FA300  001040  f85d0ba0 7c5633a6 1a1399bf          |.]..|V3.....    |

[Thr 3852] ------------------------------------------------------------------------

[Thr 3852] ICT: IctIHttpOpenMessage: 000000000564CC20 typ=1

[Thr 3852] Address   Offset request header rewritten (1 block):

[Thr 3852] ------------------------------------------------------------------------

[Thr 3852] 0000000020714774  000000  47455420 2f736170 2f62632f 6775692f |GET /sap/bc/gui/|

...

[Thr 3852] 0000000020714984  000528  0a73736c 5f636c69 656e745f 63657274 |.ssl_client_cert|

[Thr 3852] 0000000020714994  000544  3a204d49 49454744 43434134 47674177 |: MIIEGDCCA4GgAw|

...

[Thr 3852] 0000000020714F04  001936  75676646 597a7068 6f546d62 383d0d0a |ugfFYzphoTmb8=..|

[Thr 3852] 0000000020714F14  001952  73736c5f 63697068 65725f75 73656b65 |ssl_cipher_useke|

[Thr 3852] 0000000020714F24  001968  7973697a 653a2031 32380d0a 73736c5f |ysize: 128..ssl_|

[Thr 3852] 0000000020714F34  001984  63697068 65725f73 75697465 3a203030 |cipher_suite: 00|

[Thr 3852] 0000000020714F44  002000 39630d0a 0d0a |9c....          |

[Thr 3852] ------------------------------------------------------------------------

[Thr 3852] MPI<139>4#5 DiscardOutbuf 2 0 0 214260 0 0 -> 00000000207042B0 MPI_OK

[Thr 3852] HTTP request (rewritten) [4/2944/1]:

[Thr 3852]   GET /sap/bc/gui/sap/its/webgui HTTP/1.1

[Thr 3852]   accept: text/html, application/xhtml+xml, */*

[Thr 3852]   user-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; Touch; rv:11.0) like Gecko

[Thr 3852]   accept-encoding: gzip, deflate, peerdist

...

[Thr 3852]   ssl_client_cert: MIIEGDCCA4GgAw...

[Thr 3852]   ssl_cipher_usekeysize: 128

[Thr 3852]   ssl_cipher_suite: 009c

..."

 

Finally, the application server will be called to handle the URI:

"...

[Thr 3852] HttpSAPR3Handler: Call SAP AppServer for URI: /

..."

 

So now a work process will start handling the request, calling the ITS handler that will process the WEBGUI service request... but this is a matter for another blog in another community.

 

Test: ECC side, part 2: SM50 logon trace

 

The entries for my logon were recorded in dev_w2:

"...

---------------------------------------------------

trc file: "dev_w2", trc level: 2, release: "742"

---------------------------------------------------

*

*  ACTIVE TRACE LEVEL           2

ACTIVE TRACE COMPONENTS      all, N

*

..."

 

The logon trace shows that my logon was based on X.509 client certificate, asking to create a logon ticket:

"...

N DoY MoY dd hh:mm:ss yyyy

N  dy_signi_ext: X.509 client certificate logon with ticket request

N  dy_signi_ext: logon ticket creation disabled (system setting)

..."

The logon ticket creation is disabled (as I have login/create_sso2_ticket=3, i.e. only assertion tickets are created).

 

The certificate details are then displayed:

"...

N  CertGetInfo: Subject-Name >CN=...<

N  CertGetInfo: Issuer-Name >CN=CA Cert...<

N  CertGetInfo: Validity >Validity  -  NotBefore: DoY moY dd hh:mm:ss yyy (...Z)

N                NotAfter:   DoY MoY dd hh:mm:ss yyyy (...Z)

N  <

..."

 

The system looks for the mapping information (One certificate to one SAP user ID):

"...

lookup USREXTID for certificate mapping information

N  GetUsrExtId: search for <DN, "CN=..."> in client ccc for user ""

N  GetUsrExtId: found matching user >UserID< in client ccc

N  CheckX509CertIssuer: check skipped

N  GetUsrExtId: 1 matching USREXTID entries found

..."

 

Since there is a valid entry, then the authentication takes place:

"...

N  DyISigni: client=ccc, user=UserID     , lang=E, access=H, auth=X

N  usrexist: effective authentification method: X.509 client certificate

N  Get_RefUser(ccc,UserID) =>

N  password logon is generally enabled (default)

N  productive password is still valid (expiration period=0 / days gone=1)

N  password change not required (expiration period=0 / days gone=717)

N  usrexist: update logon timestamp (M)

N  save user time zone = >BRAZIL< for user >ccc> / >UserID     > into spa

N  dy_UserLocalTimeInit ()

N  DyISignR: return code=0 (see note 320991)

..."

 

The return code equal 0 was expected - as the WEBGUI screen was displayed!

 

Additional information

 

 

If you have a particular scenario that you would like to discuss, then use the comments and I will improve the blog to address your case.

Typical scenario: you have a Portal system (Java-based) and an ECC system (ABAP-based). You want your end users to access ECC content via Portal, without having a new authentication being required.


By reading SAP note 1257108 [Collective Note: Analyzing issues with Single Sign On (SSO)] you realize that there are several SSO possibilities. This blog will talk about the use of the SM50 logon trace to verify logon tickets (MYSAPSSO2 cookie) for SSO purposes.

 

Configuration made easy

 

In order to establish a trusted relationship between the Portal and the ECC system is quite easy.

In the ECC, all you need is execute transaction code STRUSTSSO2, import the certificate from the Portal into the Certificate List of the System PSE (usually used for SSO based on logon tickets) and adjust the ACL:

STRUSTSSO2.jpg

In the Portal, use the Netweaver Administrator tool to access the “Trusted Systems” application, in the “Configuration” tab. This will allow you to a) import the certificate from the ECC system or b) logon to the ECC system, so the Portal reads the certificate from the ECC:

Trusted Systems.jpg

 

Test made easy

 

How to test if the SSO is working? I used the Portal URL (http://<FQDN>:<port>/irj/portal) to create a new System (“System Administration” -> “System Landscape” path). There is a wizard to walk you through the steps.

Once I have the new system created, I just went to the “Content Administration” area and created a transaction iView, using the recently created system as the target. I called transaction SU01, just for testing purposes. The goal here is having a preview of the transaction, without the ECC asking for credentials.

 

Test: web browser side

 

I logged on to the Portal, using my Portal ID and password. I accessed, inside the “Portal Content” folder, the iView I have created. By right clicking on the node and clicking on “Preview”:

Portal - SU01 test.jpg

 

The transaction code SU01 was displayed:

Portal - SU01 test 02.jpg

 

While playing with the browser, I recorded the HTTP traffic using Fiddler tool. Inside the trace file, you should be able to find one cookie called MYSAPSSO2. It contains the actual logon ticket that will grant you access to the transaction code:

Fiddler test.jpg

 

You can also see that cookie SAPWP_active=1 was sent, telling the ECC that the Portal is active.

As you were able to see SU01 running, the SSO worked as expected. If, however, you were not able to see SU01 and you saw another cookie in the list: sap-ssolist, then you found a reason for the SSO failed. sap-ssolist is a cookie that can be decoded by a Base 64 parser: it will show you the system ID, the client number and the server name that does not accept logon tickets from the Portal you have used.

 

Test: ECC side, a.k.a. SM50 logon trace

 

While the web browser test was being executed, the SM50 logon trace was also recorded, by following the steps from my first blog on logon trace.

These are the entries recorded in dev_w2, related to this test:


"...

N DoW MoY dd hh:mm:ss yyyy

N  dy_signi_ext: LOGON TICKET logon (client ccc)

N  mySAPUnwrapTicket: was called.

N  HmskiFindTicketInCache: Trying to find logon ticket in ticket cache.

N  HmskiFindTicketInCache: Try to find ticket with cache key: ccc:ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ .

N  HmskiFindTicketInCache: Couldn't find ticket in ticket cache.

N  mySAP: Got the following SSF Params:

N         DN      =CN=XXX

N         EncrAlg =DES-CBC

N         Format  =PKCS7

N         Toolkit =SAPSECULIB

N         HashAlg =SHA1

N         Profile =C:\usr\sap\XXX\DVEBMGS00\sec\SAPSYS.pse

N         PAB     =C:\usr\sap\XXX\DVEBMGS00\sec\SAPSYS.pse

..."


Here we can see that the entries are related to a logon ticket logon, on client “ccc”. We can also find the PSE used to store the certificates, SAPSYS.pse (System PSE).


"...

N  Got the codepage 4103.

Got ticket (head) AjExMDAgA         Ww  S gx  T    M4g  E   hc  lj. Length = 484.

N  Convert ticket content from SAP_CODEPAGE >1100< to >4103<

N  MskiValidateTicket returns 0.

N  Got content client = 000.

Got content sysid = ZZZ     .

N  Got date yyyymmddhhmm from ticket.

N  Cur time = yyyymmddhh18.

N  Computing validity in hours.

N  Computing validity in minutes.

N  CurTime_t = 1460495880, CreTime_t = 1460494860

N  validity: 28800, difference:   1020.000.

..."


The entries above show a small part of the logon ticket (head only), as the logon trace was recorded using level 2 (with level 3 trace, the entire logon ticket would be dumped into the dev_w2 trace file). We also found the system that originated the cookie (ZZZ). As the logon tickets have a validity (usually 8 hours), the system will calculate the difference between the time the logon ticket was created with the current time. If the difference exceeds the limit, the ticket cannot be used for authentication.


"...

N  Ticket is without recipient information.

N  Ticket contains no RFC Payload info.

N  Ticket contains no language info.

N  HmskiInsertTicketInCache: Trying to insert logon ticket in ticket cache.

N  HmskiInsertTicketInCache: Inserted new ticket into logon ticket cache with cache key: ccc: ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ .

N  HmskiInsertTicketInCache: Inserted new ticket into logon ticket cache with cache info: <USER>=userID     ,<CLIENT>=ccc,<LANGUAGE

N  mySAPUnwrapTicket returns 0.

..."


The ticket is then inserted into the ticket cache for future reference.


"...

N  DyISigni: client=ccc, user=userID     , lang=E, access=H, auth=T

N  usrexist: effective authentification method: SAP logon ticket

N  Get_RefUser(ccc,userID) =>

N  password logon is generally enabled (default)

N  productive password is still valid (expiration period=0 / days gone=0)

N  password change not required (expiration period=0 / days gone=705)

N  usrexist: update logon timestamp (M)

N  save user time zone = >BRAZIL< into spa

N  DyISignR: return code=0 (see note 320991)

..."


Finally, the system checks the user ID from the logon ticket with the existent in the system. The return code equal 0 indicates that the SSO based on the logon ticket worked as expected.

If another access is made, then the logon trace will show:


"...

N  HmskiFindTicketInCache: Logon ticket found in ticket cache.

N  HmskiFindTicketInCache: Ticket information in ticket cache is: <USER>=userID ,<CLIENT>=ccc,<LANGUAGE>=

N  HmskiFindTicketInCache: Ticket information in ticket cache read successfully.

N  DyISigni: client=ccc, user=userID     , lang=E, access=H, auth=T

N  usrexist: effective authentification method: SAP logon ticket

..."


Here the logon ticket was found in the cache, so it is not necessary to the system to decode the logon ticket again.

 

Additional information

 

 

If you have a particular scenario that you would like to discuss, then use the comments and I will improve the blog to address your case.

 

Stay tuned for my next logon trace blog, involving SSO with X.509 client certificates.

In my first blog on the SM50 logon trace scenarios, I demonstrated how to correctly setup the logon trace.

In this blog I will show some common entries that can be found in the logon trace, when password-based logon is used.

 

A correct password-based logon

 

If you don't use any SSO form in your system, then your end users will have own passwords. When they access the system with the correct password, then you can find entries similar to these in the logon trace:

"...

N DoW MoY dd hh:mm:ss yyyy

N  DyISigni: client=ccc, user=userID     , lang=E, access=A, auth=P

N  DyDoSncChecks: client/user/access/auth :ccc/userID     /A/P

N  AcceptInsecure : Login without SNC accepted, reason: Profile parameter

N                   snc/accept_insecure_gui = Y

N  usrexist: effective authentification method: <client,username,password>

N  chckpass: client=ccc, user=userID     , accesstype=A

N  password logon is generally enabled (default)

N  productive password is still valid (expiration period=0 / days gone=41)

N  codvn=H => password is case-sensitive and up to 40 chars long

N  chckpass: correct password

N  Get_RefUser(ccc,userID) =>

N  password logon is generally enabled (default)

N  productive password is still valid (expiration period=0 / days gone=0)

N  password change not required (expiration period=0 / days gone=716)

N  save user time zone = >BRAZIL< for user >ccc> / >userID     > into spa

N  syssigni: checking for multiple dialog logons

M  ThEppGetConnectionCounter: read connectionCounter 0 from epp 0

N  dy_UserLocalTimeInit ()

N  DyISignR: return code=0 (see note 320991)

..."

 

The important message: "return code=0"! This means that no error happened while providing the user ID and password to access the system.

 

What happens if the incorrect password is used? Well, the return code is, obviously, different than 0:

"...

N DoW MoY dd hh:mm:ss yyyy

N  DyISigni: client=ccc, user=userID     , lang=E, access=A, auth=P

N  DyDoSncChecks: client/user/access/auth :ccc/userID     /A/P

N  AcceptInsecure : Login without SNC accepted, reason: Profile parameter

N                   snc/accept_insecure_gui = Y

N  usrexist: effective authentification method: <client,username,password>

N  chckpass: client=ccc, user=userID     , accesstype=A

N  password logon is generally enabled (default)

N  productive password is still valid (expiration period=0 / days gone=0)

N  codvn=H => password is case-sensitive and up to 40 chars long

N  chckpass: incorrect password ==> increase lock counter:1

N  send_usr02_refresh_req : send info

N  save user time zone = >BRAZIL< for user >ccc> / >userID     > into spa

N  DyISigni: return code=1 (see note 320991)

..."

 

You can read that an "incorrect password" was used, causing the lock counter to increase (a new feature, per SAP KBA 1894688).

 

There are more information about the possible return codes in SAP note 320991.

 

Preventing multiple GUI logons

 

You decided to follow SAP note 142724 and prevent multiple logons from users when they use SAPGUI.

The profile parameter login/disable_multi_gui_login was set to 1.

 

In this case, if someone tries to logon a second time (a concurrent session), the "License Information for Multiple Logon" screen appears, with the following options:

"...

User userID is already logged on in client ccc

(Terminal xxx.yyy.zzz.aaa-TerminalName , since dd.mm.yyyy, hh:mm:ss)

 

Note that multiple logons to the production system using the same user

ID are not part of the SAP licence agreement.

 

You can:

( ) Continue with this logon and end any other logons in system

    When ending any existing logons to system, unsaved data is lost.

(*) Terminate this logon

..."

 

The logon trace reflects the parameter being set:

"...

N DoW MoY dd hh:mm:ss yyyy

N  DyISigni: client=ccc, user=userID     , lang=E, access=A, auth=P

N  DyDoSncChecks: client/user/access/auth :ccc/userID     /A/P

N  AcceptInsecure : Login without SNC accepted, reason: Profile parameter

N                   snc/accept_insecure_gui = Y

N  usrexist: effective authentification method: <client,username,password>

N  chckpass: client=ccc, user=userID     , accesstype=A

N  password logon is generally enabled (default)

N  productive password is still valid (expiration period=0 / days gone=0)

N  codvn=H => password is case-sensitive and up to 40 chars long

N  chckpass: correct password

N  Get_RefUser(ccc,userID) =>

N  password logon is generally enabled (default)

N  productive password is still valid (expiration period=0 / days gone=0)

N  password change not required (expiration period=0 / days gone=716)

N  usrexist: update logon timestamp (M)

N  save user time zone = >BRAZIL< for user >ccc> / >userID     > into spa

N  syssigni: checking for multiple dialog logons

..."

 

The system forbids the second access: only one logon is possible, except if you use login/multi_login_users (this parameter should be used for an exception list).

 

New password checks

 

What happens when you create a new user in the system and an initial password is provided? What happens in the first logon?

 

These are the logon trace entries:

"...

N DoW MoY dd hh:mm:ss yyyy

N  DyISigni: client=ccc, user=userID      , lang=E, access=A, auth=P

N  DyDoSncChecks: client/user/access/auth :ccc/userID      /A/P

N  AcceptInsecure : Login without SNC accepted, reason: Profile parameter

N                   snc/accept_insecure_gui = Y

N  usrexist: effective authentification method: <client,username,password>

N  chckpass: client=ccc, user=userID      , accesstype=A

N  password logon is generally enabled (default)

N  initial password is still valid (expiration period=0 / days gone=0)

N  codvn=I => password is case-sensitive and up to 40 chars long

N  chckpass: correct password

N  Get_RefUser(ccc,userID) =>

N  password logon is generally enabled (default)

initial password is still valid (expiration period=0 / days gone=0)

password change required (initial password)

N  usrexist: partially update logon timestamp (M) - see note 441453

N  save user time zone = >BRAZIL< for user >ccc> / >userID      > into spa

N  syssigni: checking for multiple dialog logons

N  dy_UserLocalTimeInit ()

N  DyISignR: return code=0 (see note 320991)

ext_pwdrules_new: 2(0) digits, 6(0) letters, 5(0) lower-case, 1(0) upper-case, 0(0) special chars determined (required) in new pa

N  password_distance_ok: determined 8 different chars (required: 1) in old/new password

No outdated USRPWDHISTORY records found for <ccc,userID      >

N  syssignc: update logon timestamp (M)

N  send_usr02_refresh_req : send info

..."

 

The 5 last rows show what happened: the new password should abide to the password rules set in the system. There is no specific configuration defined.

It is possible to see that 2 digits and 6 letters were used, and no special character.

As there is no password history, the password set was accepted and the logon data and history data were updated in the database.

 

And what about when the password was reset by the administrator, so a new password must be informed?

If the user tries to use the same password causes a popup:

"...

Choose a password that is different from your last

5 passwords

..."

 

In the logon trace:

"...

N DoW MoY dd hh:mm:ss yyyy

N  DyISigni: client=ccc, user=userID      , lang=E, access=A, auth=P

N  DyDoSncChecks: client/user/access/auth :ccc/userID      /A/P

N  AcceptInsecure : Login without SNC accepted, reason: Profile parameter

N                   snc/accept_insecure_gui = Y

N  usrexist: effective authentification method: <client,username,password>

N  chckpass: client=ccc, user=userID      , accesstype=A

N  password logon is generally enabled (default)

N  initial password is still valid (expiration period=0 / days gone=0)

N  codvn=I => password is case-sensitive and up to 40 chars long

N  chckpass: correct password

N  Get_RefUser(ccc,userID) =>

N  password logon is generally enabled (default)

N  initial password is still valid (expiration period=0 / days gone=0)

N  password change required (initial password)

N  save user time zone = >BRAZIL< for user >ccc> / >userID      > into spa

N  syssigni: checking for multiple dialog logons

N  dy_UserLocalTimeInit ()

N  DyISignR: return code=0 (see note 320991)

N  ext_pwdrules_new: 2(0) digits, 6(0) letters, 5(0) lower-case, 1(0) upper-case, 0(0) special chars determined (required) in new pa

N  password_distance_ok: determined 8 different chars (required: 1) in old/new password

..."

Here the action was interrupted by the popup above.

 

After entering a new valid password:

"...

ext_pwdrules_new: 1(0) digits, 7(0) letters, 6(0) lower-case, 1(0) upper-case, 0(0) special chars determined (required) in new pa

N  password_distance_ok: determined 7 different chars (required: 1) in old/new password

No outdated USRPWDHISTORY records found for <ccc,userID      >

N  syssignc: update logon timestamp (M)

send_usr02_refresh_req : send info

..."

 

Here the password and the history were updated.

 

In another example, the password was reset again by the administrator. A third different password should be informed, as login/password_history_size = 5.


Four other parameters were also set:


login/min_password_lng = 12

login/min_password_digits = 2

login/min_password_letters = 4

login/min_password_specials = 2

 

The resulting logon trace shows:

"...

N DoW MoY dd hh:mm:ss yyyy

N  DyISigni: client=ccc, user=userID      , lang=E, access=A, auth=P

N  DyDoSncChecks: client/user/access/auth :ccc/userID      /A/P

N  AcceptInsecure : Login without SNC accepted, reason: Profile parameter

N                   snc/accept_insecure_gui = Y

N  usrexist: effective authentification method: <client,username,password>

N  chckpass: client=ccc, user=userID      , accesstype=A

N  password logon is generally enabled (default)

N  initial password is still valid (expiration period=0 / days gone=0)

N  codvn=I => password is case-sensitive and up to 40 chars long

N  chckpass: correct password

N  Get_RefUser(ccc,userID) =>

N  password logon is generally enabled (default)

N  initial password is still valid (expiration period=0 / days gone=0)

N  password change required (initial password)

N  save user time zone = >BRAZIL< for user >ccc> / >userID      > into spa

N  syssigni: checking for multiple dialog logons

N  dy_UserLocalTimeInit ()

N  DyISignR: return code=0 (see note 320991)

ext_pwdrules_new: 1(2) digits, 5(4) letters, 4(0) lower-case, 1(0) upper-case, 2(2) special chars determined (required) in new p

..."

 

As the minimum length was not observed, then the popup below is displayed:

"...

Password is not long enough (minimum length: 12

characters)

..."

 

A new (and valid) attempt:

"...

ext_pwdrules_new: 2(2) digits, 10(4) letters, 7(0) lower-case, 3(0) upper-case, 2(2) special chars determined (required) in new p

N  password_distance_ok: determined 14 different chars (required: 1) in old/new password

N  No outdated USRPWDHISTORY records found for <ccc,userID      >

N  syssignc: update logon timestamp (M)

N  send_usr02_refresh_req : send info

..."

 

More information

 

You can find more information about logon-related profile parameters in the following SAP notes:

 

2467 - Password rules and preventing incorrect logons

622464 - Change: Password change requirement for user type "SYSTEM"

862989 - New password rules as of SAP NetWeaver 2004s (NW ABAP 7.0)

1023437 - ABAP syst: Downwardly incompatible passwords (since NW2004s)

 

 

If you have a particular password-based example that you would like to discuss, then please use the comments and I will be glad to improve this blog.

 

Stay tuned for my next logon trace blog, involving SSO with logon tickets.

I am starting today a new blog series about how to use the logon trace created via SM50 to resolve logon-based issues. I will use the logon trace to analyze password issues, issues with SSO based on logon tickets and issues with SSO based on X.509 client certificates.


The basics is how to configure the SM50 logon trace. Probably you might know SAP note 495911, which tells about SM20 and SM50 logon traces, but sometimes the SM50 settings are not correctly used, making the trace unfriendly (more than the usual!) – looking for a needle in the haystack.

 

Enabling the trace

 

It is quite simple enabling the trace: the first step is execute transaction code SM50.

It might be worthy if you can truncate the trace files - so you can have only Security-related events recorded: access menu Administration -> Trace -> Reset -> Work Process Files:

SM50.jpg

 

Confirm the popup.


Now, to activate the logon trace, access menu Administration -> Trace -> Active Components:

SM50a.jpg

 

For those that like a good keyboard shortcut: Ctrl+Shift+F7 do the trick!

Now write “2” as Trace level value, write “DIA” for the WpType and select only “Security” in the Components section. You probably will find “Taskhandler” and “VM Container” checked: uncheck both. As a result, you should see a screen like:

SM50b.jpg

 

Finally, save the settings.


You will note that the SM50 screen changed, i.e. the color of the rows for DIA work processes is now yellow:

SM50c.jpg

 

Important… As the system might have more than one application server, the setting must be performed in all of them. You can switch among the app servers via SM51, just double clicking on a specific instance name:

SM50d.jpg


If you can isolate the issue to a specific app server, then you are already good to go.

 

Finally, you can reproduce the issue. All the information are recorded in dev_wXX trace files. These files can be viewed via transaction code ST11.

 

Disabling the trace

 

Assuming that you have reproduced the logon issue, collected the necessary trace files, now it is time to reset the settings in SM50.

 

Access menu Administration -> Trace -> Active Components and have the settings like this:

SM50e.jpg

 

After you saved the settings, the SM50 screen is back to normal (no more yellow rows):

SM50f.jpg

 

If you changed the settings in more than one application server, you need to perform the same steps in the affected app servers.

 

Next steps?

 

You have the trace you need in your hands. If you still see entries not related to security in the trace file, then you might want to split the information using a tool like this. Now it is time to analyze the traces and find the reason for the issue and the solution for it. I will present, in my next blogs, at least three examples where the SM50 logon trace is invaluable.

 

Remarks


If your logon issue happens in background processing, then you need to select all the WpType. In this case, use F5 to select all the work processes before call the Active Components window – then leave the WpType input field blank.


Important SAP notes:

  • 495911 - Logon problem trace analysis
  • 320991 - Error codes during logon (list)

Each work process writes trace entries into dev_wXX files.

 

Each line comes from one of the different components, as listed in SAP note 112:

"...

A  ABAP Processor

B  Database (general database interface)

C  Database (DBSL)

D  Diag Processor

E  Lock Management (Enqueue)

F  Startup Framework (in AS Java)

G  Language Support/Internationalization (Unicode Conversion)

H  Internet Communication Framework (ICF)

I  Semaphore, Shared Memory (IPC)

J  VM Container (Java in AS ABAP)

L  Background (Batch)

M  Dispatcher/Taskhandler

N  Security

P  Paging

R  Rolling

S  Printing

T  Debug System

W  WebGui

X  Extended Memory

Y  Dynp Processor

..."

 

In some cases, e.g. a security issue involving logon (in other words: SSO failed), a SM50 logon trace (per SAP note 495911) might be required.

The information will be recorded in the trace files, but not only "N" messages ("N" represents Security entries in the trace).

How to separate the entries, so you don't need to go through all unnecessary components?

 

In the past I wrote one application that separated all the entries by the respective components, creating new files (one file per component plus one file for remaining entries).

In order to avoid using a graphic interface, I decided to pursuit a Powershell approach, with the same outcome.

 

The resulting PS script I am sharing here:

"...

$filename = $args[0];

 

$fileA = [io.path]::GetFileNameWithoutExtension($filename) + ".A-ABAP-Processor.txt";

$fileB = [io.path]::GetFileNameWithoutExtension($filename) + ".B-Database-(general-database-interface).txt";

$fileC = [io.path]::GetFileNameWithoutExtension($filename) + ".C-Database-(DBSL).txt";

$fileD = [io.path]::GetFileNameWithoutExtension($filename) + ".D-Diag-Processor.txt";

$fileE = [io.path]::GetFileNameWithoutExtension($filename) + ".E-Lock-Management-(Enqueue).txt";

$fileF = [io.path]::GetFileNameWithoutExtension($filename) + ".F-Startup-Framework-(in-AS-Java).txt";

$fileG = [io.path]::GetFileNameWithoutExtension($filename) + ".G-Language-Support-Internationalization-(Unicode-Conversion).txt";

$fileH = [io.path]::GetFileNameWithoutExtension($filename) + ".H-Internet-Communication-Framework-(ICF).txt";

$fileI = [io.path]::GetFileNameWithoutExtension($filename) + ".I-Semaphore,-Shared-Memory-(IPC).txt";

$fileJ = [io.path]::GetFileNameWithoutExtension($filename) + ".J-VM-Container-(Java-in-AS-ABAP).txt";

$fileL = [io.path]::GetFileNameWithoutExtension($filename) + ".L-Background-(Batch).txt";

$fileM = [io.path]::GetFileNameWithoutExtension($filename) + ".M-Dispatcher-Taskhandler.txt";

$fileN = [io.path]::GetFileNameWithoutExtension($filename) + ".N-Security.txt";

$fileP = [io.path]::GetFileNameWithoutExtension($filename) + ".P-Paging.txt";

$fileR = [io.path]::GetFileNameWithoutExtension($filename) + ".R-Rolling.txt";

$fileS = [io.path]::GetFileNameWithoutExtension($filename) + ".S-Printing.txt";

$fileT = [io.path]::GetFileNameWithoutExtension($filename) + ".T-Debug-System.txt";

$fileW = [io.path]::GetFileNameWithoutExtension($filename) + ".W-WebGui.txt";

$fileX = [io.path]::GetFileNameWithoutExtension($filename) + ".X-Extended-Memory.txt";

$fileY = [io.path]::GetFileNameWithoutExtension($filename) + ".Y-Dynp-Processor.txt";

$fileZ = [io.path]::GetFileNameWithoutExtension($filename) + ".remaining-entries.txt";

 

foreach ($line in [System.IO.File]::ReadLines($filename)) {

  if ($line.length -gt 2) {

    $a = $line.Substring(0,1);

    switch ($a) {

       "A" { Add-Content $fileA $line }

       "B" { Add-Content $fileB $line }

       "C" { Add-Content $fileC $line }

       "D" { Add-Content $fileD $line }

       "E" { Add-Content $fileE $line }

       "F" { Add-Content $fileF $line }

       "G" { Add-Content $fileG $line }

       "H" { Add-Content $fileH $line }

       "I" { Add-Content $fileI $line }

       "J" { Add-Content $fileJ $line }

       "L" { Add-Content $fileL $line }

       "M" { Add-Content $fileM $line }

       "N" { Add-Content $fileN $line }

       "P" { Add-Content $fileP $line }

       "R" { Add-Content $fileR $line }

       "S" { Add-Content $fileS $line }

       "T" { Add-Content $fileT $line }

       "W" { Add-Content $fileW $line }

       "X" { Add-Content $fileX $line }

       "Y" { Add-Content $fileY $line }

       default { Add-Content $fileZ $line }

    }

  }

}

..."

 

Just open a PowerShell box and run:

 

powershell -executionPolicy bypass -noexit -file "devwxx.ps1" "dev_w0.txt"

 

You can replace "dev_w0.txt" by the developer trace you want to parse. "devwxx.ps1" is the name of the file that contains the script.

 

If you have another PowerShell alternative to do the same task and are willing to share, please comment below.

There are three different scenarios involving the SAP Web Dispatcher (WDP) and HTTPS access: SSL Termination (in the WDP), SSL Re-encryption and End-to-End SSL. This blog will present the third and last scenario.

 

Prerequisites

 

  • SAP Web Dispatcher 7.20 or higher
  • SAPCRYPTOLIB 5.5.5 patch level 24 or higher (in this blog pl 32 is used)

 

Profile parameters

 

The standard SSL configuration demands the following two parameters:


ssl/ssl_lib     = <path>\sapcrypto.dll

ssl/server_pse  = <path>\SAPSSLS.pse

 

As the WDP 7.20 or higher can connect to different systems, the following parameter was set:

 

wdisp/system_0 = SID=AAA, MSHOST=<FQDN1>, MSSPORT=44400, SRCSRV=webdispatcher.foo.bar:10000

 

The WDP will reach the message server from the backend through the HTTPS port 44400.


The server ports also must be defined:

 

icm/server_port_0 = PROT=ROUTER,PORT=10000

icm/server_port_1 = PROT=HTTPS,PORT=0

 

As the metadata exchange should be done via HTTPS, then the parameter below is set:

 

wdisp/server_info_protocol = https

 

At last, but not least, for testing purposes, the HTML dump into the trace will be enabled, along with a trace level 3. Important: the trace files will be HUGE! The parameters below should be set only for a quick test or for error analysis. The default trace level (i.e. 1) must be used in productive systems (and for security matters, the HTML dump should not be active).

 

icm/trace_secured_data = 1

rdisp/TRACE = 3

 

Checking the configuration

 

As soon as the profile file is saved, one can test the configuration by running:


sapwebdisp pf=sapwebdisp.pfl -checkconfig

 

No error message is expected (the result of the -checkconfig is the same as shown here)

 

The WDP is now ready to work!

 

Analyzing the scenario and the dev_webdisp trace file


One issue with this scenario is that the Web Application Server (WAS) will do the SSL handshake. The certificate sent to the web browser will have the CN from the WAS and not from the WDP! The web browser will see this and issue a warning:

End-to-End1.png


In this scenario, the WDP serves as a router to the request. The entry found in the dev_webdisp shows:

"...

[Thr 6424] IcmWorkerThread: worker 3 got the semaphore

[Thr 6424] REQ TRACE BEGIN: 2/15/2

[Thr 6424] REQUEST:

    Type: READ_REQUEST    Index = 10995

[Thr 6424] CONNECTION (id=2/15):

    used: 1, type: default, role: Server(1), stateful: 0

    NI_HDL: 169, protocol: ROUTER(16)

    local host:  <WDP IP>:10000 ()

    remote host: <Client IP>:54828 ()

    status: READ_REQUEST

    connect time: xx.zz.yyyy aa:bb:cc

    backend host: <FQDN WAS>:443, nihdl: 177, ssl: 0, desc: 0000000002BB0790

    MPI request:        <6>      MPI response:        <7>  

request_buf_size:   0        response_buf_size:   0    

    request_buf_used:   0 response_buf_used:   0    

request_buf_offset: 0 response_buf_offset: 0    

..."

 

The actual communication can be found in the dev_icm trace file from the WAS (in this case, the trace level was already set to 3).


The connection from WDP to WAS:

"...

[Thr 3428] IcmWorkerThread: worker 20 got the semaphore

[Thr 3428] REQ TRACE BEGIN: 0/1552/1

[Thr 3428] REQUEST:

    Type: ACCEPT_CONNECTION    Index = 3156

[Thr 3428] CONNECTION (id=0/1552):

    used: 1, type: default, role: Server(1), stateful: 0

    NI_HDL: 250, protocol: HTTPS(2)

    local host:  <WAS IP>:443 ()

    remote host: <WDP IP>:56517 ()

    status: NOP

    connect time: xx.zz.yyyy aa:bb:cc

    MPI request:        <0>      MPI response:        <0>

    request_buf_size:   0 response_buf_size:   0

request_buf_used:   0        response_buf_used:   0

request_buf_offset: 0 response_buf_offset: 0

..."

 

The SSL handshake between the client and the server (WAS):

"...

[Thr 3428] ->> SapSSLSessionInit(&sssl_hdl=0000000002A0BE60, role=2 (SERVER), auth_type=1 (ASK_CLIENT_CERT))

[Thr 3428] <<- SapSSLSessionInit()==SAP_O_K

[Thr 3428]      in: args = "role=2 (SERVER), auth_type=1 (ASK_CLIENT_CERT)"

[Thr 3428]     out: sssl_hdl = 0000000002D1D130

[Thr 3428] ->> SapSSLSetNiHdl(sssl_hdl=0000000002D1D130, ni_hdl=250)

[Thr 3428] NiIBlockMode: set blockmode for hdl 250 TRUE

[Thr 3428]   SSL NI-sock: local=<WAS IP>:443  peer=<WDP IP>:56517

[Thr 3428] <<- SapSSLSetNiHdl(sssl_hdl=0000000002D1D130, ni_hdl=250)==SAP_O_K

[Thr 3428] ->> SapSSLSessionStart(sssl_hdl=0000000002D1D130)

[Thr 3428] Server-configured Ciphersuites: "TLS_RSA_WITH_AES128_CBC_SHA:TLS_RSA_WITH_AES256_CBC_SHA:SSL_RSA_WITH_RC4_128_SHA:SSL_R

[Thr 3428] Client-offered Ciphersuites: "TLS_RSA_WITH_AES128_CBC_SHA:TLS_RSA_WITH_AES256_CBC_SHA:SSL_RSA_WITH_RC4_128_SHA:SSL_RSA_

[Thr 3428]   No Client Certificate

[Thr 3428]   Cached session resumed (TLSv1.0)

[Thr 3428]   HexDump of native SSL session ID { &buf= 0000000002C9D224, buf_len= 32 }

[Thr 3428] 00000: c6 7e ec f1 55 cb 9e 4c  d4 3d 34 08 78 ba 67 c3   .~..U..L .=4.x.g.

[Thr 3428]    00010: 01 36 ee 05 23 ea 98 5f  d8 fc 10 ac f2 29 49 4f   .6..#.._ .....)IO

[Thr 3428] <<- SapSSLSessionStart(sssl_hdl=0000000002D1D130)==SAP_O_K

[Thr 3428]          status = "resumed SSL session, NO client cert"

..."


The request is then read from the connection:

"...

[Thr 3428] IcmReadFromConn(id=0/1552): read 318 bytes, 1 readops (timeout 0)

[Thr 3428] Address Offset  IcmReadFromConn received

[Thr 3428]

[Thr 3428] 0000000007FF56D8 000000  47455420 2f736170 2f62632f 6775692f  GET /sap/bc/gui/

[Thr 3428] 0000000007FF56E8 000016  7361702f 6974732f 77656267 75692048  sap/its/webgui H

[Thr 3428] 0000000007FF56F8 000032  5454502f 312e310d 0a416363 6570743a  TTP/1.1..Accept:

...

[Thr 3428] 0000000007FF57D8 000256  0a486f73 743a2077 65626469 73706174  .Host: webdispat

[Thr 3428] 0000000007FF57E8  000272 63686572 2e666f6f 2e626172 3a313030 cher.foo.bar:100

[Thr 3428] 0000000007FF57F8 000288  30300d0a 436f6e6e 65637469 6f6e3a20  00..Connection:

[Thr 3428] 0000000007FF5808 000304  4b656570 2d416c69 76650d0a 0d0a      Keep-Alive....

..."


A few seconds later the WAS sends the response to the client:

"...

[Thr 3428] Address Offset  IcmWriteToConn:

[Thr 3428]

[Thr 3428] 0000000007FF56D8 000000  48545450 2f312e31 20323030 204f4b0d  HTTP/1.1 200 OK.

[Thr 3428] 0000000007FF56E8  000016 0a636f6e 74656e74 2d747970 653a2074 .content-type: t

[Thr 3428] 0000000007FF56F8 000032  6578742f 68746d6c 3b206368 61727365  ext/html; charse

..."

 

Finally, the thread is free to wait a new request:

"...

[Thr 3428] CONNECTION (id=1/1553):

    used: 1, type: default, role: Server(1), stateful: 0

    NI_HDL: 308, protocol: HTTPS(2)

    local host:  <WAS IP>:443 ()

    remote host: <WDP IP>:56518 ()

    status: READ_REQUEST

    connect time: xx.zz.yyyy aa:bb:cc

    MPI request:        <107a>   MPI response:        <107b>

request_buf_size:   0        response_buf_size:   0

request_buf_used:   0        response_buf_used:   0

request_buf_offset: 0 response_buf_offset: 0

[Thr 3428] REQ TRACE END: 1/1553/5

[Thr 3428] IcmWorkerThread: Thread 20: Waiting for event

..."


If the parameter "icm/trace_secured_data = 1" is not set, it is not possible to see the HTML content. The following log entry appears:

"…

BINDUMP of content denied

…"


So, the three usual SSL scenarios involving the web dispatcher are now available.


For more on the SAP Web Dispatcher, please access this Wiki page.

Actions

Filter Blog

By author:
By date:
By tag: