Skip to Content
Technical Articles
Author's profile photo Frank Buchholz

Report ZSM04000_SNC / ZRSUSR000_620 – Show SNC status of current user sessions

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):

  • 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, 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 1tech 'internal_error:'.
    WHEN 2tech '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 solutionsare 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 the corresponding wiki page.

ABAP source code:

ZSM04000_SNC

https://wiki.scn.sap.com/wiki/download/attachments/491918649/ZSM04000_SNC.txt

ZRSUSR000_620

https://wiki.scn.sap.com/wiki/download/attachments/491918787/ZRSUSR000_620.txt

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:

ZSM04000_SNC_01.PNG

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…)

Assigned Tags

      14 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Hi  Frank Buchholz,

      The report is great and works perfectly!

      It is possible to make an improvement since the report does not collect the aggregate of all application servers?

      Best regards,

      Carlos Biscaia

      Author's profile photo Frank Buchholz
      Frank Buchholz
      Blog Post Author

      Great idea, however, at the current stage I do not know how to solve it as I need an RFC enabled function which I could call on other application servers which executes the statement

      call 'ThUsrInfo' id 'OPCODE' field opcode_usr_info
      (This statement shows the SNC status.)

      Kind regards
      Frank

      Update: 01.10.2021 It was quite easy to merge the code from SM04 (for one application server) and AL08 (for all application servers)

       

      Author's profile photo Former Member
      Former Member

      If it must remain a report which contains everything and you want to regularly collect snap shots, then it could submit itself in a background task on each server with list to memory and present the result with an app server column?

      Workaround: Schedule the report on each host and only output if a result is found, in which case send spool to a mail recipient list. Then just prove that you did not get any emails..  🙂

      Author's profile photo Former Member
      Former Member

      Hello Jullius,

      Thanks for the help, but that workaround I already have implemented.

      I would prefer to have one solution than an alternative 🙂

      Regards,

      Carlos Biscaia

      Author's profile photo Former Member
      Former Member

      FM TH_SHOW_USR_DETAILS uses that opcode and returns the values, so you (or Frank...) could get the server list and loop through it importing the BNAME = <user> in the job variant of the check. It is remote enabled, but in an internal function group which is rather exotic. Calling ThUsrInfo is however also rather exotic and not something you want to do voluntarily. Then keep a log of it for a while before you enforce SNC on the server side.

      As you want to catch the SAPGui based exceptions, you can catch those during the login from the SAPGui Login Pad using the exit in SAPMSYST, but it is not a 100% guarantee that all logins are covered.

      Trusted RFC calls / navigation with connection to SAPGui might slip through (SOLMAN!) as well as shortcut based navigation. An often encountered problem is also importing a transport request in the queue of system QAS or PROD but the user is logged onto system DEV (from a UI perspective). You will need to make some adjustments to your STMS setup to get that working for SNC authentication as well, but it does work with SAP SSO.

      Cheers,

      Julius

      Author's profile photo Frank Buchholz
      Frank Buchholz
      Blog Post Author

      Hi Julius,

      thank you for telling me about TH_SHOW_USR_DETAILS - strange that I had missed this function.... I've added this function to a copy of transaction AL08 = report RSUSR000. I've used the version from release 620 to cover older releases as well. You can find the new report ZRSUSR000_620 linked within this blog.

      Kind regards

      Frank

      Author's profile photo Former Member
      Former Member

      Super! Thanks for sharing the solution and code gallery for reuse when needed!

      How about a more user friendly SAP (SM19) message for this as well to collect the login events instead of time snapshots? Currently it is very tedious to get the session ID from SAL and then the authentication type from ST05 and make assumptions based on the authentication code. An Sm19 message (SNC on / off at logon types other than B) would be very useful as we could then simply turn it on a wait....  🙂

      Cheers,

      Julius

      Author's profile photo Former Member
      Former Member

      Hello Frank Buchholz,


      thanks for the feedback 😀


      Does you have interest to develop such RFC?


      Best regards,

      Carlos Biscaia

      Author's profile photo Former Member
      Former Member

      Hello to both,

      the program ZRSUSR000_620 works perfectly on ERP 6.0 EHP5 version.

      Excellent work!!

      Many thanks for your help :), Frank Buchholz & Julius von dem Bussche

      Regards,

      Carlos Biscaia

      Author's profile photo Wolfgang Janzen
      Wolfgang Janzen

      Actually, the profile parameter snc/accept_insecure_gui is the wrong one - since it only controls whether is user is forced to use SNC for authentication or whether he should be allowed to logon by password, as well.

      With note 1690662 two new profile parameters (snc/only_encrypted_gui, snc/only_encrypted_rfc) were introduced which allow to control whether SAPGUI / RFC connections need to be encrypted (using SNC with a proper QoP) or not. That's independent from the question whether the user logs on using SNC or password.

      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'm such a nerd.

      But I've to admit that setting profile parameter snc/data_protection/min = 3 (privacy) ensures that every SNC connection which is established will be encrypted. Thus, in that case it's valid to conclude "if SNC is used, then the connection is encrypted".

      Regards, Wolfgang

      Author's profile photo Former Member
      Former Member

      My understanding of the blog is that if you want to enforce SNC from the server side, then you need a migration path and tools (such as Frank's report).

      But snapshots are not reliable. Better option would be using SM19.

      Cheers,

      Julius

      Author's profile photo Frank Buchholz
      Frank Buchholz
      Blog Post Author

      Meanwhile there exist a better option to analyse the encryption status:

      Use the Security Audit Log (SAL), Transaction SM19 and SM20, to log when an unencrypted SAPGUI or RFC communication has been detected.

      See note 2122578 - New: Security Audit Log event for unencrypted GUI / RFC connections

      Author's profile photo Vanderlei Vitorio Gomes
      Vanderlei Vitorio Gomes

      Hi Frank,

       

      the wiki pages are not working anymore, is it because of SAL entries you mentioned from note 2122578?

       

      Best regards,

      Vanderlei Gomes.

      Author's profile photo Frank Buchholz
      Frank Buchholz
      Blog Post Author

      I've adjusted the broken wiki page and the links to the code.

      The report now scans all application servers.

      In addition I've added so tips about using teh Security Audit Log message BUJ and the SMOD-user exit to gather information about the SNC of all connections.