SAP Single Sign-On Insider Tips – Volume #2

25. July 201714. May 2020 SAP Single Sign-On Carsten Olt

“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.

Table of Contents

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!

Author
Recent Posts

Carsten Olt

Managing SAP Security Consultant | SAP Trainer Secure Authentication | SSO | Cloud Security Services at Xiting GmbH

Carsten Olt has been working as a Managing SAP Security Consultant since 2016, responsible for Secure Authentication & SSO and SAP Cloud Security Services at Xiting in Germany. As a member of the IAM team, he is also a team leader who conveys the company's goals and strategies to employees and has organizational responsibility.

With a security-minded approach, Carsten has international project and IT security experience in many industries. He has been working in IT-Security since 2001, specializing in SAP security since 2010. He is a subject matter expert for SAP Single Sign-On 3.0 and a trainer for the WDESSO course. His current focus is on supporting customers in solving authentication and security challenges within hybrid SAP landscapes, as well as designing and implementing holistic authentication concepts. Carsten is an ISACA CISA and a former MCP and RHCE with an ISP background, and he looks at security from different angles. He also translates between SAP and IT security vocabulary.

Carsten has in-depth experience in multi-vendor architectures and MSFT/Azure components, dealing with all the requirements concerning SAML 2.0, OAuth, OpenID Connect, SCIM, X.509 CBA & PKI, MFA, SAP SSO, and Secure Network Communications, Kerberos/SPNEGO, data security and encryption, as well as digital signatures.

Carsten is experienced in SAP on-premises components such as S/4HANA, ABAP, and Java, as well as security solutions like SSO 3.0. Since 2019, he has focused on SAP-Cloudified environments, specifically the SAP Cloud Identity Services and SAP BTP, as well as SaaS integrations concerning IAM. He deals with hybrid SAP security in conjunction with Azure Active Directory, ADDS, ADFS, ADCS, Reverse Proxies/WAF, SAP Web Dispatcher, SAP Cloud Connector, third-party products, and infrastructure components.

	+41 43 422 8803 [email protected]
	+49 7656 8999 002 [email protected]
	+1 855 594 84 64 [email protected]
	+44 1454 838 785 [email protected]