- SAP Managed Tags:
Let's assume you run a project to encrypt all communication channels.
It's easy to enable servers to support encryption and to allow clients to choose about encryption even within a productive system landscape (despite the fact that it requires some profile parameter changes which require restarts of the servers):
However, as soon as you want to enforce encryption for a specific channel, e.g. by deactivating the profile parameter snc/accept_insecure_gui or by activating profile parameter snc/only_encrypted_gui to secure SAPGUI connections, you are in trouble: Most likely you are only allowed to change the profile parameter in a productive world if you can prove that all clients in fact are requesting encryption.
Here's one of the questions: How can you verify if all SAPGUI sessions use SNC?
Answer I (SAP standard):
Use the Security Audit Log (SAL), Transaction SM19 and SM20 (in old releases) respective RSAU_CONFIG and RSAU_READ_LOG (in newer releases) to activate message BUJ (for all users in all clients) to log when an unencrypted SAPGUI or RFC communication has been detected.
Prerequisite: Activate dynamic profile parameter snc/log_unencrypted_rfc
Yes, despite of the name of the profile parameter, this message BUJ logs unencrypted RFC as well as unencrypted SAPGUI connections.
The log is created during session creation before the user logon (that means is already created when the user sees the logon screen), therefore you get the dummy client 000 and no user but at least you get the terminal name of the caller.
Answer II (user exit):
You could use the SMOD-user exit SUSR0001 which is executed after dialog logon to develop your own solution to log the SNC status of SAPGUI sessions. This way you even could show a message popup explaining that and how the user could change the SAPlogon settings to switch to SNC mode.
Here is some sample code which gives you the idea about what you can do in the user exit:
Answer III (custom report):
If these solutions are not suitable for you or not available you can use transaction SM04 and check every line using the menu path Users -> Technical Info to inspect the field snc_count. (Thanks to Wolfgang Janzen who pointed me to that piece of information.)
Well, that's quite unpractical. Therefore I had developed the custom report ZSM04000_SNC (which is based on combined coding of SM04 and AL08) respective the very old fashioned report ZRSUSR000_620 (which is based on transaction AL08) to view this information directly on the main list.
Report ZSM04000_SNC shows a cross-client list about users, their terminals, the connection type and the SNC status. You can add the profile parameters about SNC to the header of the list. Here's an example without IP addresses and without terminal names:
Limitation: the report shows current sessions only.
Run this report regularly and as soon as it turns green completely for a specific connection type you can adjust the corresponding profile parameters to avoid insecure connections in the future.
(By the way: Extreme security nerds now would discuss if this is sufficient to prove if encryption is active, as the QOP, quality of protection, is not considered, too. Well, I know about this limitation, but let's begin the journey with the first step...)
It's easy to enable servers to support encryption and to allow clients to choose about encryption even within a productive system landscape (despite the fact that it requires some profile parameter changes which require restarts of the servers):
- You can activate SSL for web-based connections, LDAP connections and database connections
- You can activate SNC for SAPGUI, e.g. using SNC Client Encryption for Password Logon, and RFC
However, as soon as you want to enforce encryption for a specific channel, e.g. by deactivating the profile parameter snc/accept_insecure_gui or by activating profile parameter snc/only_encrypted_gui to secure SAPGUI connections, you are in trouble: Most likely you are only allowed to change the profile parameter in a productive world if you can prove that all clients in fact are requesting encryption.
Here's one of the questions: How can you verify if all SAPGUI sessions use SNC?
Answer I (SAP standard):
Use the Security Audit Log (SAL), Transaction SM19 and SM20 (in old releases) respective RSAU_CONFIG and RSAU_READ_LOG (in newer releases) to activate message BUJ (for all users in all clients) to log when an unencrypted SAPGUI or RFC communication has been detected.
Prerequisite: Activate dynamic profile parameter snc/log_unencrypted_rfc
Yes, despite of the name of the profile parameter, this message BUJ logs unencrypted RFC as well as unencrypted SAPGUI connections.
The log is created during session creation before the user logon (that means is already created when the user sees the logon screen), therefore you get the dummy client 000 and no user but at least you get the terminal name of the caller.
See note 2122578 - New: Security Audit Log event for unencrypted GUI / RFC connections
Answer II (user exit):
You could use the SMOD-user exit SUSR0001 which is executed after dialog logon to develop your own solution to log the SNC status of SAPGUI sessions. This way you even could show a message popup explaining that and how the user could change the SAPlogon settings to switch to SNC mode.
Here is some sample code which gives you the idea about what you can do in the user exit:
DATA:
pname_appl LIKE rfcdessecu-pname_appl,
snc_qop_min LIKE rfcdessecu-snc_qop,
snc_qop_max LIKE rfcdessecu-snc_qop,
snc_qop_use LIKE rfcdessecu-snc_qop, " this is the parameter value but not the current value!
pname_user LIKE usracl-pname,
pname_cpic LIKE usracl-pname,
gui_conn_type LIKE snc_fields-gui_conn, " Connection Type (D)irect/(R)FC
login_type LIKE snc_fields-login_type, " Logon method: SL, SD, SN, NN, ND
rc LIKE sy-subrc.
" 1. SNC not enabled:
" EXCEPTION snc_not_active
" 2. SNC enabled
" pname_appl = SNC name of system
" snc_qop_min, snc_qop_max, snc_qop_use are set
" 2a) SNC enabled but not used:
" pname_user =
" login_type = ND
" 2b) logon with SNC and SSO:
" pname_user = SNC name of user
" login_type = SL
" 2c) connection with SNC, logon with userid /password:
" pname_user = SNC name of user
" login_type = SD
CALL FUNCTION 'SNC_GET_MY_INFO'
IMPORTING
pname_appl = pname_appl
"snc_qop_min = snc_qop_min
"snc_qop_max = snc_qop_max
"snc_qop_use = snc_qop_use
pname_user = pname_user
"pname_cpic = pname_cpic
gui_conn_type = gui_conn_type
login_type = login_type
rc = rc
EXCEPTIONS
internal_error = 1
snc_not_active = 2
OTHERS = 3.
DATA status(80).
IF sy-subrc = 2.
status = 'SNC not enabled'.
ELSEIF pname_user IS INITIAL OR login_type = 'ND'.
status = 'SNC is enabled but not used'.
ELSEIF pname_user IS NOT INITIAL AND login_type = 'SL'.
status = 'SNC with Single Sign-On'.
ELSEIF pname_user IS NOT INITIAL AND login_type = 'SD'.
status = 'SNC with userid/password'.
ELSE.
status = 'unknown'.
ENDIF.
DATA tech(80).
CASE sy-subrc.
WHEN 1. tech = 'internal_error:'.
WHEN 2. tech = 'snc_not_active:'.
ENDCASE.
CONCATENATE
tech
'gui_conn_type=''' gui_conn_type ''' login_type=''' login_type ''''
INTO tech.
CALL FUNCTION 'POPUP_TO_INFORM'
EXPORTING
titel = 'SNC Status'
txt1 = status
txt2 = pname_appl
txt3 = pname_user
txt4 = tech.Answer III (custom report):
If these solutions are not suitable for you or not available you can use transaction SM04 and check every line using the menu path Users -> Technical Info to inspect the field snc_count. (Thanks to Wolfgang Janzen who pointed me to that piece of information.)
Well, that's quite unpractical. Therefore I had developed the custom report ZSM04000_SNC (which is based on combined coding of SM04 and AL08) respective the very old fashioned report ZRSUSR000_620 (which is based on transaction AL08) to view this information directly on the main list.
ABAP Source Code
You find the source code on GitHub.
Documentation
Report ZSM04000_SNC shows a cross-client list about users, their terminals, the connection type and the SNC status. You can add the profile parameters about SNC to the header of the list. Here's an example without IP addresses and without terminal names:
Limitation: the report shows current sessions only.
Run this report regularly and as soon as it turns green completely for a specific connection type you can adjust the corresponding profile parameters to avoid insecure connections in the future.
(By the way: Extreme security nerds now would discuss if this is sufficient to prove if encryption is active, as the QOP, quality of protection, is not considered, too. Well, I know about this limitation, but let's begin the journey with the first step...)
19 Comments
