Security & GRCadvanced

SNC and SSO for SAP GUI and RFC: Trust, Kerberos and Certificates

Key takeaway

Use Secure Network Communications to protect SAP GUI and RFC traffic and enable strong single sign-on using supported Kerberos or certificate-based trust instead of transmitting reusable passwords.

Explanation

📌 KEY POINTS
✅ SNC secures classic GUI/RFC traffic via an external security product/library — Kerberos or X.509 certificates, depending on architecture.
⚠️ Client/server names must map correctly to the authenticated SAP user, or trust breaks silently.
💡 SNC protects the network; it does not grant application permissions — target-system authorization still applies.

━━━━━━━━━━━━━━━━━━━━
▶ 1. THE MECHANISM

App server has an SNC identity
Client/server names must map correctly to the authenticated SAP user
Enterprise SSO commonly uses Kerberos-based Windows identity or X.509 certificates, depending on the security product

━━━━━━━━━━━━━━━━━━━━
▶ 2. ENCRYPTION vs. SSO, AGAIN

Related but not identical — SNC can protect the network even when users still enter credentials, and SSO can fail while encrypted communication still succeeds

━━━━━━━━━━━━━━━━━━━━
⚠️ 3. WHAT DOESN'T CHANGE

RFC destinations using SNC still enforce target-system technical-user authorization
SNC does not grant application permissions

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP (TROUBLESHOOTING)

SNC library/configuration
Name/trust mapping
Ticket/certificate validity
SAP user mapping
PFCG authorization (separate from all of the above)

✅ CHECKPOINT: explain why a valid Kerberos ticket doesn't guarantee the user has the right SAP authorizations.

Real project scenario

Users could establish an SNC-encrypted SAP GUI connection but still received a password prompt. Encryption was working; user-name mapping for SSO was incomplete. Fixing identity mapping solved login without changing SAP roles.

Common mistakes

Treating SNC encryption and SSO as the same thing.
Using SNC to bypass SAP authorization.
Sharing one powerful RFC user because the channel is encrypted.
Ignoring certificate/Kerberos expiry.
Troubleshooting PFCG before authentication mapping.

Best practices

Define SNC identities/naming carefully.
Protect RFC as well as GUI where required.
Monitor trust/certificate lifecycle.
Keep SAP authorization least-privileged.
Diagnose authn before authz.

Interview angle

Explain what SNC secures, how Kerberos/certificates enable SSO and why backend authorization remains separate.

Practice this lesson

Quick check

1. Production follow-up for SNC and SSO — Use Secure Network Communications to protect SAP GUI and RFC traffic and enable strong single sign-on using supported Kerberos or certificate-based trust instead of transmitting reusable passwords. Which response best turns this into a preventive, supportable design choice?

2. A team proposes this shortcut while working on SNC and SSO for SAP GUI and RFC: Trust, Kerberos and Certificates: "Sharing one powerful RFC user because the channel is encrypted." Which alternative should you recommend?

3. A review of SNC and SSO for SAP GUI and RFC: Trust, Kerberos and Certificates finds this risky pattern: "Treating SNC encryption and SSO as the same thing.". Which corrective action is strongest?

Interview questions

1. You are the senior consultant/architect responsible for SNC and SSO for SAP GUI and RFC: Trust, Kerberos and Certificates. The project situation is: Users could establish an SNC-encrypted SAP GUI connection but still received a password prompt. How would you assess the design, identify the highest-risk failure modes, and define the evidence required before approving it for production?

Answer it in your own words first, then compare.

2. Using this SAP project situation — A user's SAP GUI session is encrypted but still prompts for a password — explain SNC and SSO Fundamentals for SAP GUI and RFC. What should happen, which concepts or process steps matter, and what common mistake would you avoid?