Make Me The Boss

13. June 201920. July 2022 SAP Single Sign-On Carsten Olt

In a default SAP setup, users enter their SAP user name and password on the SAP GUI login screen. SAP user names and passwords are transferred through the network without encryption. To secure networks, SAP provides a “Secure Network Communications” interface (SNC) that enables users to log on to SAP systems without entering a user name or password. For the user authentication using security tokens (X.509 certificate or Kerberos token), a mapping is required to define which security token belongs to which SAP user.

This blog deals with the risk of SNC name mapping, which could be abused primarily by Insiders. Not for the first time, in one of our projects recently we got the question: Why can your own SNC name be assigned to any SAP user. Isn’t that a potential security issue?

We believe this is a risk as anyone who has access to update SU01 can update their SNC user master data field to any user they wish to log in and their access could be compromised.
Risk Summary – Statement of our customer

Table of Contents

Technical background

There is no relationship between the SAP username and the Windows AD username. In many companies, they are completely different. If a corresponding SSO product is used such as SAP Single Sign-On 3.0, the Distinguished Name (DN) of the user certificate or the Kerberos Principal Name (KPN) must be linked to the SAP user name. This is necessary so that the user receives a session under his SAP user after successful token-based authentication.

This SNC name mapping can be carried out either manually via transaction SU01 (USRACL-PNAME) or automatically by using SAP reports such as RSUSR300 (SNC1). To automate the SNC name mapping the CUA or an Identity Management solution can be used as well.

Within the SAP system, SNC-Names are canonicalized using the configured SNC library, thus the printable (human readable) name shown in SU01 tab SNC-Name gets converted to a binary canonical name used by the system (USRACL-HNAME).

SU01

So, if the “evil admin” would add his SNC name to his Boss’ SAP account in addition, he would be allowed to (surreptitiously) log in with his Boss’ SAP account and have some fun. After that, he just switches back the old entry and that’s it. During this attempt, his boss did not notice, and his password was not changed at all.

For this insider threat, you wouldn’t even need to have a lot of criminal energy, cracking tools to calculate password hashes or to write ABAP code. A badly implemented SAP authorization concept it sufficient. You just need permission to use SU01. Unfortunately, many companies often have (too) many SAP users who are allowed to use SU01.

Consequently, more attention must be paid to the SAP user management – in particular, the maintenance of SNC names in the context of SNC – when using Single Sign-On. However, the potential abuse is limited to users with SU01 care privileges and of course you can log such changes. On the other hand, who really checks the logs regularly? Wouldn’t it be better to have a technical and automated solution to monitor and mitigate this specific risk?

Above all, a reasonable SAP authorization concept is absolutely mandatory. There are ways to control changes to SNC names and restrict SU01. Furthermore, you can make use of table logging, change documents or automated monitoring, detection and alerting.

Solutions

Finally, we would like to show you some (certainly not all) possible solutions to reduce this risk.

ZSU01

You could create a screen variant for SU01 via transaction SHD0 and the SNC-Name or individual fields in this register could be hidden there. The screen variant could then be provided as a Z-transaction, for example, as ZSU01 or, alternatively, you could modify the SU01 so that it always uses this variant in the standard and hides the SNC area.

You could also make it legible, so you can at least see what value is maintained, but without being able to change it.

Restrict SNC maintenance | S_USER_GRP (36)

Make use of the customizing switch CHECK_NONPW_LGNDATA. Instead of just checking activity “Change” (02) you can check for the activity “Extended Maintenance” (36) in the authorization object S_USER_GRP.

Therefore, it is possible to separate the tasks/authorizations for individual user administrators in a better way. For example, SNC name maintenance could be restricted to a few admins only. For more details check SAP Note 1882254

Notes on logging SNC name maintenance (change documents)

The SNC name of the users in table USRACL has also been in the change documents for some time (Transaction SUIM / Report RSUSR100N or Report RSSCD100 for object class = IDENTITY). For the other relevant tables in the SECN package (in particular RFCDESSECU, SNCSYSACL, USRACLEXT, and USREXTID), report RDDPRCHK indicates if table logging is active. Report RDDPRCHK also displays in column “SCDO Object” whether a change document object exists for a table (in this case, for table USRACL)

Note 419933 - FAQ: Maintenance of change documents in user administration

[...]

As of Note 1079207, additional change documents for the user are stored in the central change documents in the object class IDENTITY. This includes (among other things) documents for the attributes reference user, alias, SNC name and CUA-specific attributes such as child systems, role assignment and the assignment of manual profiles.

[...]

You can activate the general table logging in accordance with Notes 1916 and 163694. ... LDAP, PSE, SNC administration

[...]

Note 1079207 - Downports: CUA change docs, archiving, 12 hour time format

[...]

SNC name - Change documents are evaluated using the new report RSUSR100N.

[...]

The system uses the selection option 'SNC Name' to evaluate changes to the switch 'Insecure communication allowed (user- specific)' as well as to the field 'SNC Name' of the user (Both can be maintained on the tab page SNC of transaction SU01.).

[...]

Keep an eye on your compliance status with Security Architect

You can use our Security Architect for this as well. With the Security Architect, you can generate, publish, and monitor your SAP Security Concept best practice at the push of a button. Since SP14 it provides an automated check SNC_DUPLICATE which shows if at least two users with the same SNC name has been found.

Automated detection and alerting using ETD

SAP Enterprise Threat Detection (SAP ETD) is a security solution that at its core, provides real-time detection of suspicious events. One of the many features SAP ETD provides besides log collection or forensic research is attack detection and alerting: When Enterprise Threat Detection detects unusual activity based on log data, it triggers an alarm in the event of an attack. For this you can customize ETD in a way to use it as your alerting system for such „SNC name mapping” related events, just to name one of the many use cases.

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]