SAP Single Sign-On Insider Tips – Volume #2

“Insider Tips” talks about some of the lesser known configuration options of SAP Single Sign-On.

In volume #2 and upcoming blog articles, we will look at best practices for hardening your SAP Single Sign-On implementation. We will discuss challenges companies face when trying to enforce encryption for SAP GUI and RFC. We will also take a closer look at new profile parameters and configuration options available with the new CommonCryptoLib 8.5x, part of SAP Single Sign-On 3.0.

Challenges when trying to enforce SNC encryption

For most web applications, TLS already has become a standard. It offers an encrypted communication channel between the client and the server and enables secure authenticating, even when using basic authentication (username and password). This isn’t true for most SAP applications. The SAP proprietary protocols SAP Dynamic Information and Action Gateway (SAP DIAG) and SAP Remote Function Call (SAP RFC) do not cryptographically authenticate client and server or encrypt network communication.

Secure Network Communications (SNC) closes this gap and supports various authentication mechanisms as well as Single Sign-On standards. Ensuring the right QoP-level for Secure Network Communications is essential. If you connect to an SAP system using SNC you can see a lock icon on the right bottom corner of the GUI screen. Many users assume, that this is proof for an encrypted connection. Well, not necessarily!

After implementing SAP Single Sign-On and SNC, most companies do not enforce its use, and thus it is still possible to bypass the SNC layer. That can be accomplished by manually changing the SAP GUI connection settings. Often this is done to allow access to special system accounts or external users – even if there are be better solutions available.

Enforce SNC on backend

You can enforce encryption by setting the profile parameter snc/accept_insecure_gui = U to allow insecure logins on a user-specific basis, depending on a flag in the user master record. This is the first step in hardening an SSO deployment, but in my experience, many companies do not do it. As a result, it’s easy for end-users to bypass encryption by simply changing a check box in SAP GUI.

Enforce Quality of Protocol

It should be mentioned that snc/accept_insecure_gui all alone does not guarantee encrypted SNC communication, as it does not consider the so-called QoP (Quality of Protocol) in the SNC-layer. QoP specifies the level of protection for an SNC connection. In the worst case, this could be authentication only (aka level 1). From an end-user perspective, this is Single Sign-On. However, this would not take integrity protection (2) or privacy protection (3) into account. QoP has to be configured for both SNC communication partners involved in the end-to-end security mechanism.

For SAP GUI, the value is either fixed or could be negotiated with the SNC peer. Setting the profile parameter snc/data_protection/min = 3 ensures every SNC connection established with the server has to be encrypted. Our recommendation is to set the QoP to level 3 in SAP GUI to enforce the best possible security:

Also, you may also want to make use of some newer profile parameters such as snc/only_encrypted_gui and snc/only_encrypted_rfc to control whether GUI/RFC connections need to be encrypted (using SNC with a proper QoP) or not, so bypassing SNC is no longer possible. For more useful information see SAP Note 1690662: Blocking unencrypted SAP GUI/RFC connections.

Security Audit Log

Enforcing SNC encryption for GUI/RFC also means some work before, to make sure you do not experience any unexpected side effects. You should enable SNC for your RFCs, at least the external ones. Additionally, you should QoP level 3 as part of your client deployment. You should use the Security Audit Log (SAL) SM19/SM20 to filter successful logins by login type and method to get a clear picture about the current stage of SNC usage or SM04 (technical info -> snc_count).

You may also want to implement some custom reports to simplify reporting. Once you have enforced SNC, you can continuously monitor the encryption status. The system can also trigger a SAL event when it detects unencrypted SAP GUI or RFC communications. That way, you can inform affected users or system owners. For more information check out SAP Note 2122578: New: Security Audit Log event for unencrypted GUI / RFC connections

By the way, even without Single Sign-On, you can use the new SNC Client Encryption 2.0 solution from SAP, available since April 2017 to protect your SAP GUI connections using SNC encryption. It integrates directly into SAP GUI 7.50 without the need to deploy any additional software on the clients. This requires the new CommonCryptoLib 8.5 on each backend and you
Can influence or enforce DIAG-encryption by using the new CCL profile parameter ccl/snc/server_partner_auth_mode which brings us directly to the next topic.

CommonCryptoLib (CCL) special configuration parameters

Since CommonCryptoLib 8.5.2 and newer, there are new configuration settings available. You can configure them via profile parameters. CCL gets the name of its configuration file from the environment variable SETENV_xx = CCL_PROFILE=$(DIR_PROFILE)/DEFAULT.PFL which you have to set globally for <sid>adm. By using ccl/snc/* parameters, you can harden security by restricting CCL to use only high-security cipher suites and much more.

In a recent SSO project at one of our customers, we had to configure some SAP systems to accept authentication using X.509 certificates issued by ADCS (Active Directory Certificate Services). One drawback of ADCS is that you cannot easily make changes to the makeup of the certificate subject name. There are only two options available 1) CN=<displayName> or 2) fully distinguished name such as CN=John Doe, OU=North America, OU=Sales Dept., DC=customer, DC=domain. Way too complicated to make use of easy user mapping rules for SNC (SNC1) or HTTP based SSO via ICM (CERTRULE).

Example

We had the requirement to use the subject alternative name (SAN) extension instead of the default certificate subject name for user authentication. The SAN contains the UPN or the RFC 822 email address of a user in the Active Directory. In this case the UPN <sAMAccountName@DOMAIN> was included in each user certificate. And luckily the sAMAccountName was matching the User ID in SAP.

The solution was to set the parameter ccl/snc/server_partner_name_x509 to the value UserPrincipalNameOrSubject. In this way, we configured the SAP system to use the SAN-extension and to convert the SNC name accordingly. You can then use the *OrSubject value as a fallback if the system cannot find the requested alternative name in the certificate. That could happen for server certificates, as this setting impacts RFC connections as well.

You don’t need that for HTTP-based access. Instead, you can use rule-based certificate mapping (CERTRULE) to map users to parts of the certificate’s subject or the subject alternative name. For example, using the following rule, we enabled  login with X.509 certificates for all users at one customer:

There are lots of more options available to control SNC name conversion, encoding or upper/lower case transformations by the library. This also applies to Kerberos names which you can use with or without the REALM part. One of my favorites is ccl/snc/server_cipher_suites = HIGH. Similar to TLS, you can limit what cipher suites you want to use during the SNC client/server handshake. That way, you can eliminate insecure cipher suites, such as 3DES or SHA1. I already blogged about Perfect Forward Secrecy (PFS) which you can also enabled using this parameter.

By using ccl/pkix/* parameters, you can manage the certificate verification such as checking for special X.509 certificate constraints or certificate policies as well as certificate revocation checking (CRL) behavior. Sounds interesting? Take a look at SAP Note 338952: CommonCryptoLib 8.5: Configuration Profile Parameters

Stay tuned for volume #3 of Xiting’s Insider Tips for SAP Single Sign-On!