1 2 3 6 Previous Next

SAP NetWeaver Application Server

88 Posts

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.

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 second 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 three parameters:


ssl/ssl_lib     = <path>\sapcrypto.dll

ssl/server_pse  = <path>\SAPSSLS.pse

ssl/client_pse  = <path>\SAPSSLC.pse

 

As the WDP 7.20 or higher can connect to different systems, the following parameters were set:

 

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

wdisp/system_1 = SID=BBB, MSHOST=<FQDN2>, MSPORT=8171, SRCSRV=webdispatcher.foo.bar:10001

 

The server ports also must be defined:

 

icm/server_port_0 = PROT=HTTP,PORT=9999

icm/server_port_1 = PROT=HTTPS,PORT=10000

icm/server_port_2 = PROT=HTTPS,PORT=10001


As the WDP will perform a re-encryption of the data, the parameter below must be set:

 

wdisp/ssl_encrypt = 1

 

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

 

Similar to other scenarios, the trace level 3 recorded in the dev_webdisp has plenty information. From a test calling a giving internet service (WEBGUI, for example) it is possible to see the moment the request reached the WDP:


"...

[Thr 6876] IcmWorkerThread: worker 2 got the semaphore

[Thr 6876] REQ TRACE BEGIN: 0/18/1

[Thr 6876] REQUEST:

    Type: ACCEPT_CONNECTION    Index = 2

[Thr 6876] CONNECTION (id=0/18):

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

    NI_HDL: 147, protocol: HTTPS(2)

    local host:  <WDP IP>:10000 ()

    remote host: <Client IP>:53691 ()

    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    

..."


Next it is possible to check the SSL handshake between the client and the server (WDP):

"...

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

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

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

[Thr 6876]     out: sssl_hdl = 0000000002D7D810

[Thr 6876] ->> SapSSLSetNiHdl(sssl_hdl=0000000002D7D810, ni_hdl=147)

[Thr 6876] NiIBlockMode: set blockmode for hdl 147 TRUE

[Thr 6876]   SSL NI-sock: local=<WDP IP>:10000 peer=<Client IP>:53691

[Thr 6876] <<- SapSSLSetNiHdl(sssl_hdl=0000000002D7D810, ni_hdl=147)==SAP_O_K

[Thr 6876] ->> SapSSLSessionStart(sssl_hdl=0000000002D7D810)

[Thr 6876] Server-configured Ciphersuites: "TLS_RSA_WITH_AES128_CBC_SHA:TLS_RSA_WITH_AES256_CBC_SHA:SSL_RSA_WITH_RC4_128_SHA:SSL_RSA_WITH_RC4_128_MD5:SSL_RSA_WITH_3DES_EDE_CBC_SHA:SSL_RSA_WITH_DES_CBC_SHA:SSL_RSA_EXPORT_WITH_DES40_CBC_SHA:SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5:SSL_RSA_EXPORT_WITH_RC4_40_MD5"

[Thr 6876] Client-offered Ciphersuites: "TLS_RSA_WITH_AES128_CBC_SHA:TLS_RSA_WITH_AES256_CBC_SHA:SSL_RSA_WITH_RC4_128_SHA:SSL_RSA_WITH_3DES_EDE_CBC_SHA:SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA:SSL_RSA_WITH_RC4_128_MD5"

[Thr 6876]   No Client Certificate

[Thr 6876]   New session (TLSv1.0)

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

[Thr 6876]    00000: 5f d1 b3 37 34 1f 33 fc  84 a5 d8 c3 01 4f fe b1   _..74.3. .....O..

[Thr 6876] 00010: 33 99 af e4 20 0f 1a 88  77 24 e2 2f 4a d8 64 c6   3... ... w$./J.d.

[Thr 6876] <<- SapSSLSessionStart(sssl_hdl=0000000002D7D810)==SAP_O_K

[Thr 6876] status = "new SSL session, NO client cert"

..."


The request is then read from the connection:

"...

[Thr 6876] IcmReadFromConn(id=0/18): read 443 bytes, 1 readops (timeout 0)

[Thr 6876] Address Offset  IcmReadFromConn received

[Thr 6876] ------------------------------------------------------------------------

[Thr 6876] 0000000003F76058 000000  47455420 2f736170 2f62632f 6775692f |GET /sap/bc/gui/|

[Thr 6876] 0000000003F76068 000016  7361702f 6974732f 77656267 75692048 |sap/its/webgui H|

[Thr 6876] 0000000003F76078 000032  5454502f 312e310d 0a416363 6570743a |TTP/1.1..Accept:|

[Thr 6876] 0000000003F76088 000048  202a2f2a 0d0a4163 63657074 2d4c616e | */*..Accept-Lan|

..."

 

The WDP will reach the web application server ABAP via HTTPS:

"...

[Thr 6876] HttpPortTableMatchPort: Port 0, webdispatcher.foo.bar:10000 (<WDP IP>:10000) matches request

[Thr 6876] ICR: IcrFindTargetSystem(0000000002D614F0, '/sap/bc/gui/sap/its/webgui' -> 0

[Thr 6876] HttpGetRouteTargetSystem: SID='AAA'

[Thr 6876] ICT: IctLookupPathTable() -> 0

[Thr 6876] HTR: found stack ABAP for URL /sap/bc/gui/sap/its/webgui

[Thr 6876] HTR: routing destination type = ICF/ABAP .

[Thr 6876] HTR: No esid found in request

[Thr 6876] HTR: HtrIExtractSessionID -> '' 0

[Thr 6876] HTR: stateless request (no valid session ID found) or initial request for stored session id

[Thr 6876] ICR: IcrIGetMinLoadServer: server 'HOST_AAA_00'1 delta=400 load=0/0valid=1 resp=1 capacity=10

[Thr 6876] ICR: IcrIFindMatchingPort for prot=1 stack=1 vhost=-1

[Thr 6876] ICR: IcrIFindMatchingPort: compare with 0 0 8000 10

[Thr 6876] ICR: IcrIFindMatchingPort: compare with 1 0 443 10

[Thr 6876] ICR: IcrIFindMatchingPort: found matching port: prot=1 vhost=0 port=443 f=10

[Thr 6876] ICR: IcrIGetMinLoadServer: near-zero load #0: HOST_AAA_00

[Thr 6876] ICR: IcrAttachToServer: next destination server 'HOST_AAA_00'1 10 1 0 port:443/1/0

..."


Since the connection to the server uses HTTPS, a new SSL handshake is necessary:

"...

[Thr 6876] NiHLGetNodeAddr: found hostname '<FQDN WAS>' in cache

[Thr 6876] NiIGetNodeAddr: hostname '<FQDN WAS>' = addr <WAS IP>

[Thr 6876] NiIGetServNo: servicename '443' = port 443

[Thr 6876] NiICreateHandle: hdl 153 state NI_INITIAL_CON

[Thr 6876] NiIInitSocket: set default settings for new hdl 153/sock 32916 (I4; ST)

[Thr 6876] NiIBlockMode: set blockmode for hdl 153 FALSE

[Thr 6876] NiIConnectSocket: hdl 153 is connecting to <WAS IP>:443 (timeout=5000)

[Thr 6876] SiPeekPendConn: connection of sock 32916 established

[Thr 6876] NiICheckPendConnection: connection of hdl 153 to <WAS IP>:443 established

[Thr 6876] NiIConnect: hdl 153 took local address <WDP IP>:53692

[Thr 6876] NiIConnect: state of hdl 153 NI_CONNECTED

[Thr 6876] IcmConnPoolConnect: Connection to host: <FQDN WAS>, service: 443 established (nihdl=153)

[Thr 6876] ->> SapSSLSessionInit(&sssl_hdl=00000000026CC6E8, role=1 (CLIENT), auth_type=0 (NO_CLIENT_CERT))

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

[Thr 6876]      in: args = "role=3 (ANONYMOUS-CLIENT), auth_type=0 (NO_CLIENT_CERT)"

[Thr 6876]     out: sssl_hdl = 0000000002D7DA30

[Thr 6876] ->> SapSSLSetNiHdl(sssl_hdl=0000000002D7DA30, ni_hdl=153)

[Thr 6876] NiIBlockMode: set blockmode for hdl 153 TRUE

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

[Thr 6876] <<- SapSSLSetNiHdl(sssl_hdl=0000000002D7DA30, ni_hdl=153)==SAP_O_K

[Thr 6876] ->> SapSSLSetTargetHostname(sssl_hdl=0000000002D7DA30, &hostname=0000000002D4FE20)

[Thr 6876] <<- SapSSLSetTargetHostname(sssl_hdl=0000000002D7DA30)==SAP_O_K

[Thr 6876]      in: hostname = "<FQDN WAS>"

[Thr 6876] ->> SapSSLSessionStart(sssl_hdl=0000000002D7DA30)

[Thr 6876] SapISSLUseSessionCache(): Creating NEW session (0 cached)

[Thr 6876] SecudeSSL_SessionStart(): created new SSL session (TLSv1.0)

[Thr 6876]   Server Certificate available (FCPath-Len= 0)

[Thr 6876]   Server's List of trusted CA DNames (from cert-request message):

[Thr 6876]     #1  "CN=xxxxxxxxxxxx, OU=yyyyyyyyy, O=zzzzzzzzzzzzzzzzzz, C=??"

[Thr 6876]     #2  "CN=kkkkkkkkkkkk, O=wwwwwwwwww, C=??"

[Thr 6876] secudessl_AddSSL2Cache(): Creating new SSSL_CACHE entry

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

[Thr 6876] 00000: 5e 4a f0 f1 1d 0e 94 c8  c8 37 d0 c5 66 4b c1 e0   ^J...... .7..fK..

[Thr 6876] 00010: 80 26 ee b5 b1 0e 36 bb  92 45 10 c9 3a 8d ad e4   .&....6. .E..:...

...

[Thr 6876]   Subject DN: CN=<FQDN WAS>, OU=aaaaaaa, OU=bbbbbbbbbbbbbb, OU=ccccccc, O=ddddd, C=??

[Thr 6876] Issuer  DN: CN=xxxxxxxxxxxx, OU=yyyyyyyyy, O=zzzzzzzzzzzzzzzzzz, C=??

[Thr 6876]   Current Cipher: TLS_RSA_WITH_AES128_CBC_SHA

[Thr 6876] MatchTargetName("<FQDN WAS>", CN="<FQDN WAS>") == EXACT match

[Thr 6876] <<- SapSSLSessionStart(sssl_hdl=0000000002D7DA30)==SAP_O_K

[Thr 6876] status = "new SSL session"

[Thr 6876] Server DN = " CN=<FQDN WAS>, OU=aaaaaaa, OU=bbbbbbbbbbbbbb, OU=ccccccc, O=ddddd, C=??"

[Thr 6876] IcmConnPoolNewEntry: created new entry 000000000B8A0930[0] for pool 000000000B809610 (nihdl=153, ssl=0000000002D7DA30)

[Thr 6876] ICR: IcrAttachToServer('!DIAGS' 1 2 4100 1 port:443/1/0) 0-> 0

[Thr 6876] HTR: routing to destination 'HOST_AAA_00' (balanceable=0)

[Thr 6876] server triggered

[Thr 6876]    Pool Entry 000000000B8A0930:

[Thr 6876]    NI: 153, SSL: 0000000002D7DA30, allocated: 1, inuse: 1, desc: 000000000B8096B0

..."


A few seconds later the WDP sends the request to the application server:

"...

[Thr 6876] local host: <WDP IP>:53692

[Thr 6876] remote host: <WAS IP>:443

[Thr 6876] HTR: forwarding buffer to server (443)

[Thr 6876] Address Offset  Send to AppServer via net:

[Thr 6876] ------------------------------------------------------------------------

[Thr 6876] 0000000003F76058 000000  47455420 2f736170 2f62632f 6775692f |GET /sap/bc/gui/|

[Thr 6876] 0000000003F76068 000016  7361702f 6974732f 77656267 75692048 |sap/its/webgui H|

[Thr 6876] 0000000003F76078 000032  5454502f 312e310d 0a616363 6570743a |TTP/1.1..accept:|

[Thr 6876] 0000000003F76088 000048  202a2f2a 0d0a6163 63657074 2d6c616e | */*..accept-lan|

..."


A response is received from the application server:

"...

[Thr 6876] Address Offset  IcmReadFromPartner received

[Thr 6876] ------------------------------------------------------------------------

[Thr 6876] 0000000003F76058 000000  48545450 2f312e31 20323030 204f4b0d |HTTP/1.1 200 OK.|

[Thr 6876] 0000000003F76068 000016  0a636f6e 74656e74 2d747970 653a2074 |.content-type: t|

[Thr 6876] 0000000003F76078 000032  6578742f 68746d6c 3b206368 61727365 |ext/html; charse|

[Thr 6876] 0000000003F76088  000048 743d7574 662d380d 0a636f6e 74656e74 |t=utf-8..content|

[Thr 6876] 0000000003F76098  000064 2d656e63 6f64696e 673a2067 7a69700d |-encoding: gzip.|

[Thr 6876] 0000000003F760A8  000080 0a636f6e 74656e74 2d6c656e 6774683a |.content-length:|

..."

 

The response is then re-encrypted and sent to the web browser:

"...

[Thr 6876] IcmPlCheckRetVal: Next status: READ_REQUEST(1)

[Thr 6876] IcmHandleNetWrite(id=0/18): HandleServData returned: 1

[Thr 6876] Address    Offset  IcmWriteToConn:

[Thr 6876] ------------------------------------------------------------------------

[Thr 6876] 0000000003F76058 000000  48545450 2f312e31 20323030 204f4b0d |HTTP/1.1 200 OK.|

[Thr 6876] 0000000003F76068 000016  0a636f6e 74656e74 2d747970 653a2074 |.content-type: t|

[Thr 6876] 0000000003F76078 000032  6578742f 68746d6c 3b206368 61727365 |ext/html; charse|

[Thr 6876] 0000000003F76088  000048 743d7574 662d380d 0a636f6e 74656e74 |t=utf-8..content|

[Thr 6876] 0000000003F76098  000064 2d656e63 6f64696e 673a2067 7a69700d |-encoding: gzip.|

[Thr 6876] 0000000003F760A8  000080 0a636f6e 74656e74 2d6c656e 6774683a |.content-length:|

..."


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

"...

[Thr 6876] IcmWriteToConn(id=0/18): wrote data to partner (len = 5243)

[Thr 6876] IcmNetBufFree: free netbuf: 0000000000759C10 out of 1 used

[Thr 6876] MPI<5>0#4 DiscardOutbuf 0 0 0 1a5fa0 0 0 -> 0000000003F75FF0 MPI_OK

[Thr 6876] NiWakeupExec: send wakeup signal to 49627->64998 (sock 33032)

[Thr 6876] IcmConnRollOut: connection (id=0/18) rolled out: reason:1 role:1 timeout:60

[Thr 6876] CONNECTION (id=0/18):

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

    NI_HDL: 147, protocol: HTTPS(2)

    local host:  <WDP IP>:10000 ()

    remote host: <Client IP>:53691 ()

    status: READ_REQUEST

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

    MPI request:        <4>      MPI response:        <5>  

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 6876] IcmWorkerThread: SSL Session rolled out

[Thr 6876] REQ TRACE END: 0/18/1

[Thr 6876] IcmWorkerThread: Thread 2: 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

…"

 

Stay tuned for my next blog about End-to-End SSL in the SAP Web Dispatcher!

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 first scenario.

 

The SSL Termination causes that the communication between the WDP and the SAP application server happens via HTTP. If you have no concerns about unencrypted traffic passing in your network, then this is a valid approach for your landscape.

 

If you intend to use SSL Re-encryption, then be aware that the WDP will have more CPU work: you have encryption/decryption operations happening in both sides of the WDP: [browser <-> WDP] AND [WDP <-> app server].

 

The last scenario is End-to-End SSL: the web dispatcher simply forwards all the content to the application server. The WDP cannot look at the browser request, cannot look for session cookies. The load balancing, in this scenario, can only be accomplished based on the browser's network address (IP address).

 

Prerequisites

 

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

 

Profile parameters

 

The standard SSL configuration demands the following three parameters:

ssl/ssl_lib     = <path>\sapcrypto.dll

ssl/server_pse  = <path>\SAPSSLS.pse

ssl/client_pse  = <path>\SAPSSLC.pse

 

As the WDP 7.20 (and higher) can connect to different systems, the following parameters were set:

 

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

wdisp/system_1 = SID=BBB, MSHOST=<FQDN2>, MSPORT=8171, SRCSRV=webdispatcher.foo.bar:10001

 

The server ports also must be defined:

 

icm/server_port_0 = PROT=HTTP,PORT=9999

icm/server_port_1 = PROT=HTTPS,PORT=10000

icm/server_port_2 = PROT=HTTPS,PORT=10001

 

As the WDP will terminate the SSL communication, the parameter below must be set:

 

wdisp/ssl_encrypt = 0


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


A result similar to the following should be seen:

 

Checking SAP Web Dispatcher Configuration

=========================================

maximum number of sockets supported on this host: 8192

Server info will be retrieved from host: <FQDN1>:8100 with protocol: http

Checking connection to message server of system AAA...OK

Retrieving server info from message server...OK

Message Server instance list of system AAA

+---------------------+---------------------+---------+----------+

| instance name    |    hostname         |HTTP port|HTTPS port|

+---------------------+---------------------+---------+----------+

|         HOST_AAA_00 |<FQDN1>              |    8000 | 443  |

+---------------------+---------------------+---------+----------+

Checking ABAP servers with URL "/sap/public/icman/ping":

Checking ABAP server http://<FQDN1>:8000...OK

Checking J2EE servers with URL "/index.html":

No server group "!J2EE" defined

 

Server info will be retrieved from host: <FQDN2>:8171 with protocol: http

Checking connection to message server of system BBB...OK

Retrieving server info from message server...OK

Message Server instance list of system BBB

+---------------------+---------------------+---------+----------+

| instance name    |    hostname         |HTTP port|HTTPS port|

+---------------------+---------------------+---------+----------+

| HOST_BBB_71 |<FQDN2>              |    8071 | 443  |

+---------------------+---------------------+---------+----------+

Checking ABAP servers with URL "/sap/public/icman/ping":

Checking ABAP server http://<FQDN<:50071...OK

Checking J2EE servers with URL "/index.html":

No server group "!J2EE" defined

 

Retrieving group info with HTTP from server <FQDN1>:8000...OK

Defined server groups:

+---------------------+----------+

| group name      | #entries |

+---------------------+----------+

|               !DIAG |       3 |

|              !DIAGS |       3 |

|                !ALL |       3 |

+---------------------+----------+

Retrieving url info with HTTP from server <FQDN1>:8000...OK

Url map info file "/sap/public/icf_info/icr_urlprefix" is OK

Contents of url map file:

+---------------------+---------------------+--------------------+

|        URL          |        Group        | virtual host     |

+---------------------+---------------------+--------------------+

|              /nwbc/ |                     |                *:*;|

|               /sap/ |                     |                *:*;|

|               /srm/ |                     |                *:*;|

+---------------------+---------------------+--------------------+

 

Check ended with 0 errors, 0 warnings

 

The WDP is now ready to work!

 

Analyzing the scenario and the dev_webdisp trace file

 

The backend is emitting a warning in the logon screen, since the WDP is terminating the SSL:

SSLTermination1.png

In this case, the service in SICF can be set to avoid issuing warnings:

SSLTermination2.png

 

The dev_webdisp has plenty information available. From the test above it is possible to see the moment the request reached the WDP:

"...

[Thr 7540] IcmWorkerThread: worker 4 got the semaphore

[Thr 7540] REQ TRACE BEGIN: 0/207/1

[Thr 7540] REQUEST:

    Type: ACCEPT_CONNECTION    Index = 24

[Thr 7540] CONNECTION (id=0/207):

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

    NI_HDL: 103, protocol: HTTPS(2)

    local host:  <WDP IP>:10000 ()

    remote host: <Client IP>:50098 ()

    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    

..."


Next it is possible to check the SSL handshake between the client and the server (WDP):

"...

[Thr 7540] ->> SapSSLSessionInit(&sssl_hdl=000000000296C6E0, role=2 (SERVER), auth_type=1 (ASK_CLIENT_CERT))

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

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

[Thr 7540]     out: sssl_hdl = 0000000000566A80

[Thr 7540] ->> SapSSLSetNiHdl(sssl_hdl=0000000000566A80, ni_hdl=103)

[Thr 7540] NiIBlockMode: set blockmode for hdl 103 TRUE

[Thr 7540]   SSL NI-sock: local=<WDP IP>:10000 peer=<Client IP>:50098

[Thr 7540] <<- SapSSLSetNiHdl(sssl_hdl=0000000000566A80, ni_hdl=103)==SAP_O_K

[Thr 7540] ->> SapSSLSessionStart(sssl_hdl=0000000000566A80)

[Thr 7540] Server-configured Ciphersuites: "TLS_RSA_WITH_AES128_CBC_SHA:TLS_RSA_WITH_AES256_CBC_SHA:SSL_RSA_WITH_RC4_128_SHA:SSL_RSA_WITH_RC4_128_MD5:SSL_RSA_WITH_3DES_EDE_CBC_SHA:SSL_RSA_WITH_DES_CBC_SHA:SSL_RSA_EXPORT_WITH_DES40_CBC_SHA:SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5:SSL_RSA_EXPORT_WITH_RC4_40_MD5"

[Thr 7540] Client-offered Ciphersuites: "TLS_RSA_WITH_AES128_CBC_SHA:TLS_RSA_WITH_AES256_CBC_SHA:SSL_RSA_WITH_RC4_128_SHA:SSL_RSA_WITH_3DES_EDE_CBC_SHA:SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA:SSL_RSA_WITH_RC4_128_MD5"

[Thr 7540]   No Client Certificate

[Thr 7540]   New session (TLSv1.0)

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

[Thr 7540] 00000: 3e a1 0f 16 d4 da 2c d8  0e df 81 df f7 fd e1 8e   >.....,. ........

[Thr 7540]    00010: 1b d9 31 11 77 32 33 9b  23 66 90 fc 36 97 e3 ed   ..1.w23. #f..6...

[Thr 7540] <<- SapSSLSessionStart(sssl_hdl=0000000000566A80)==SAP_O_K

[Thr 7540] status = "new SSL session, NO client cert"

..."

 

The request is then read from the connection:

"...

[Thr 7540] IcmReadFromConn(id=0/207): read 631 bytes, 1 readops (timeout 0)

[Thr 7540] Address Offset  IcmReadFromConn received

[Thr 7540] ------------------------------------------------------------------------

[Thr 7540] 0000000003F16058 000000  47455420 2f736170 2f62632f 6775692f |GET /sap/bc/gui/|

[Thr 7540] 0000000003F16068 000016  7361702f 6974732f 77656267 75692048 |sap/its/webgui H|

[Thr 7540] 0000000003F16078 000032  5454502f 312e310d 0a416363 6570743a |TTP/1.1..Accept:|

[Thr 7540] 0000000003F16088 000048  20617070 6c696361 74696f6e 2f782d6d | application/x-m|

..."


The WDP will reach the web application server ABAP via HTTP:

"...

[Thr 7540] HttpPortTableMatchPort: Port 0, webdispatcher.foo.bar:10000 (<WDP IP>:10000) matches request

[Thr 7540] ICR: IcrFindTargetSystem(0000000002A78020, '/sap/bc/gui/sap/its/webgui' -> 0

[Thr 7540] HttpGetRouteTargetSystem: SID='AAA'

[Thr 7540] ICT: IctLookupPathTable() -> 0

[Thr 7540] HTR: found stack ABAP for URL /sap/bc/gui/sap/its/webgui

[Thr 7540] HTR: routing destination type = ICF/ABAP .

[Thr 7540] HTR: No esid found in request

[Thr 7540] HTR: HtrIExtractSessionID -> '' 0

[Thr 7540] HTR: stateless request (no valid session ID found) or initial request for stored session id

[Thr 7540] ICR: IcrIGetMinLoadServer: server 'HOST_AAA_00'1 delta=400 load=0/8800valid=1 resp=1 capacity=10

[Thr 7540] ICR: IcrIFindMatchingPort for prot=0 stack=1 vhost=-1

[Thr 7540] ICR: IcrIFindMatchingPort: compare with 0 0 8000 10

[Thr 7540] ICR: IcrIFindMatchingPort: found matching port: prot=0 vhost=0 port=8000 f=10

[Thr 7540] ICR: IcrIGetMinLoadServer: near-zero load #0: HOST_AAA_00

[Thr 7540] ICR: IcrAttachToServer: next destination server 'HOST_AAA_00'1 10 1 0 port:8000/0/0

..."


A few seconds later the WDP sends the request to the application server:

"...

[Thr 7540] local host: <WDP IP>:50099

[Thr 7540] remote host: <WAS IP>:8000

[Thr 7540] HTR: forwarding buffer to server (631)

[Thr 7540] Address Offset  Send to AppServer via net:

[Thr 7540] ------------------------------------------------------------------------

[Thr 7540] 0000000003F16058 000000  47455420 2f736170 2f62632f 6775692f |GET /sap/bc/gui/|

[Thr 7540] 0000000003F16068 000016  7361702f 6974732f 77656267 75692048 |sap/its/webgui H|

[Thr 7540] 0000000003F16078 000032  5454502f 312e310d 0a616363 6570743a |TTP/1.1..accept:|

[Thr 7540] 0000000003F16088 000048  20617070 6c696361 74696f6e 2f782d6d | application/x-m|

..."

 

A response is received from the application server:

"...

[Thr 7540] Address Offset  IcmReadFromPartner received

[Thr 7540] ------------------------------------------------------------------------

[Thr 7540] 0000000003F16058 000000  48545450 2f312e31 20323030 204f4b0d |HTTP/1.1 200 OK.|

[Thr 7540] 0000000003F16068 000016  0a636f6e 74656e74 2d747970 653a2074 |.content-type: t|

[Thr 7540] 0000000003F16078 000032  6578742f 68746d6c 3b206368 61727365 |ext/html; charse|

..."


The response is then encrypted and sent to the web browser:

"...

[Thr 7540] IcmPlCheckRetVal: Next status: READ_REQUEST(1)

[Thr 7540] IcmHandleNetWrite(id=0/207): HandleServData returned: 1

[Thr 7540] Address Offset  IcmWriteToConn:

[Thr 7540] ------------------------------------------------------------------------

[Thr 7540] 0000000003F16058 000000  48545450 2f312e31 20323030 204f4b0d |HTTP/1.1 200 OK.|

[Thr 7540] 0000000003F16068 000016  0a636f6e 74656e74 2d747970 653a2074 |.content-type: t|

[Thr 7540] 0000000003F16078 000032  6578742f 68746d6c 3b206368 61727365 |ext/html; charse|

[Thr 7540] 0000000003F16088  000048 743d7574 662d380d 0a636f6e 74656e74 |t=utf-8..content|

..."

 

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

"...

[Thr 7540] IcmWriteToConn(id=0/207): wrote data to partner (len = 5502)

[Thr 7540] IcmNetBufFree: free netbuf: 0000000000619C30 out of 1 used

[Thr 7540] MPI<5>0#4 DiscardOutbuf 0 0 0 1a5fa0 0 0 -> 0000000003F15FF0 MPI_OK

[Thr 7540] NiWakeupExec: send wakeup signal to 59458->64998 (sock 33016)

[Thr 7540] IcmConnRollOut: connection (id=0/207) rolled out: reason:1 role:1 timeout:60

[Thr 7540] CONNECTION (id=0/207):

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

    NI_HDL: 103, protocol: HTTPS(2)

    local host:  <WDP IP>:10000 ()

    remote host: <Client IP>:50098 ()

    status: READ_REQUEST

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

    MPI request:        <4>      MPI response:        <5>  

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 7540] IcmWorkerThread: SSL Session rolled out

[Thr 7540] REQ TRACE END: 0/207/1

[Thr 7540] IcmWorkerThread: Thread 4: 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

…"


Stay tuned for my next blog about SSL Re-encryption in the SAP Web Dispatcher!



Instead of using the user ID and password to access a service from the Web Application Server ABAP via HTTPS, it is possible to use a client certificate for authentication purposes.


Import the CA certificate into the SSL server Standard

 

As a given user ID holds a certificate from a trusted CA, the certificate from the CA must be imported into the SSL server Standard PSE via STRUST. Just click on the button highlighted by the red rectangle:

SSO-X509a.png


Once the certificate is loaded, just click in the "Add to Certificate List" button (see "1" in red); the certificate will be displayed in the "Certificate List" section (see "2" in red):

SSO-X509b.png


Maintain the client certificate

 

It is necessary to map the client certificate with the actual user ID in the ABAP system. It is time to use transaction code SM30, loading maintenance view "VUSREXTID":

SSO-X509c.png


The "External ID type" is "DN":

SSO-X509d.png


Click on the "New Entries" button to add the client certificate (DN) and map to the existent user ID in the ABAP side:

SSO-X509e.png


Inform the External ID (the DN field of the client certificate), the user ID (as created in transaction code SU01), then mark the "Activated" checkbox and save the entry. The information presented is:

SSO-X509f.png


There are cases where the DN length from the user ID exceeds the length of column EXTID in table USREXTID. This is not a problem: just use the button highlighted (red square) above to load the actual certificate. The system is able to store the entire subject name in the database table or calculates a hash value (and store the original subject name in a second database table).

 

At last, but not least, profile parameter icm/HTTPS/verify_client must be set to 1 (if the system should accept the client certificate) or 2 (the use of client certificates is mandatory).


Test if the SSO is working

 

For testing purposes, I used the WEBGUI internet service (via HTTPS) to test if the SSO works (assuming that the WEBGUI was correctly setup in the system): https://<FQDN>:<HTTPS port>/sap/bc/gui/sap/its/webgui

 

The SM50 logon trace (SAP note 495911) shows the following:

SSO-X509g.png


You can read more about the use of X.509 certificates in AS ABAP in the SAP Help page.


Actions

Filter Blog

By author:
By date:
By tag: