Enabling SNC and SSL

Enabling SNC (Secure Network Communications) in SAP Basis

I. Introduction to SNC

SNC (Secure Network Communications) is an application-level security layer in SAP systems. It provides end-to-end security for connections between SAP components, and between SAP systems and external clients (e.g., SAP GUI, RFC clients). SNC provides:

Authentication: Verifies the identity of communication partners.
Data Integrity: Detects any alteration of data during transmission.
Data Confidentiality (Encryption): Protects data from eavesdropping.

Primary Use Cases:

SAP GUI to Application Server.
RFC (Remote Function Call) connections (SAP to SAP, or SAP to non-SAP).
Application Server to Database connections (e.g., Oracle, IBM Db2, SAP HANA DB).
Message Server to Application Server.

II. Prerequisites for Enabling SNC

SNC Product: An external security product (GSS-API V2 compliant) must be available and installed.
- SAP NetWeaver SSO (CommonCryptoLib): SAP's recommended and most common solution. libsapcrypto.so (Linux) or sapcrypto.dll (Windows).
- Other Vendors: Third-party products like Kerberos, Microsoft Windows SSPI, various PKI solutions (e.g., from Entrust, RSA, etc.).
License: CommonCryptoLib usually does not require a separate license unless using advanced features of SAP NetWeaver SSO.
OS-Level Installation: The SNC library (e.g., libsapcrypto.so) must be placed in a directory accessible to the SAP kernel (typically $(DIR_EXE_ROOT)/sapjvm/jre/bin/sapjvm/<version>/lib/ or $(DIR_EXECUTABLE)).
PSE/Keytab Generation: Credentials (PSE files for X.509 certificates or Kerberos keytab files) must be generated for the SAP system's SNC identity.

III. Detailed Configuration Steps for SNC (ABAP Stack)

The configuration involves setting profile parameters, generating credentials, and configuring user/RFC settings.

A. Profile Parameter Configuration (RZ10 / RZ11):

These parameters need to be set in the instance profiles of all application servers that will use SNC.

Enable SNC:
- snc/enable = 1 (Activates SNC functionality).
SNC Library Path:
- snc/gssapi_lib = <path_to_snc_library> (e.g., $(DIR_EXECUTABLE)/libsapcrypto.so or C:\usr\sap\<SID>\SYS\exe\uc\NTAMD64\sapcrypto.dll).
SNC Identity of Application Server:
- snc/identity/as = p:<SNC_Name_of_AS>
  - For X.509: p:CN=SAPNetWeaver, OU=SAPService, O=MyCompany, C=US (or similar distinguished name from the PSE).
  - For Kerberos/SPNego: p:SAPService<SID>@YOUR.AD.REALM (Service Principal Name of the SAP service user in AD).
  - This name must match the identity in the generated PSE/Keytab file.
Quality of Protection (QOP):
- snc/qop = 8 (Default, allows initiator to choose)
- snc/data_protection/max = 3 (Integrity) or 9 (Privacy, highest protection). Set to enforce minimum protection for all SNC connections.
- snc/data_protection/min = 2 (Authentication) or 3 (Integrity).
Permit Insecure Logons (for transition):
- snc/accept_insecure_gui = 1 (Allows GUI logons without SNC during transition phase). Set to 0 when all users are on SNC.
- snc/permit_insecure_gui = 1 (Allows GUI logon if SNC fails). Set to 0 when full SNC is enforced.
- snc/accept_insecure_rfc = 1 (Allows RFC connections without SNC). Set to 0 when full SNC is enforced.
- Recommendation: Start with 1 to allow non-SNC connections during setup, then set to 0 to enforce SNC after successful testing.
Restart SAP System: After changing profile parameters in RZ10, a full SAP system restart (all instances) is required for changes to take effect.

B. Credential Generation (PSE for X.509 / Keytab for Kerberos):

For X.509 (CommonCryptoLib):
1. Create SNC PSE (STRUST):
  - In STRUST, create a new PSE (e.g., SNC ABAP).
  - Generate a Certificate Request (CSR) from this PSE.
  - Get the CSR signed by a Certificate Authority (CA) (internal or external).
  - Import the certificate response into the PSE.
  - Import the Root and Intermediate CA certificates into the PSE's certificate list.
  - Distribute PSE: After saving, select the PSE and choose PSE -> Distribute to propagate it to all application servers.
2. Mapping to snc/identity/as: The snc/identity/as profile parameter must match the Distinguished Name (DN) of the certificate in this PSE.
For Kerberos/SPNego:
1. Active Directory Configuration: Create a service user in Active Directory. Register Service Principal Names (SPNs) for the SAP system's virtual and physical hostnames (setspn command).
2. Keytab Generation: Generate a Kerberos keytab file (krb5.keytab) for the service user.
3. Place Keytab: Place the keytab file in a secure, accessible location on all SAP application servers (e.g., $(DIR_GLOBAL)/security/). Ensure <sidadm> has read/execute permissions.
4. Mapping to snc/identity/as: The snc/identity/as parameter must match the principal used in the keytab file.

C. SAP User Configuration (SU01):

For users who will log on via SNC (e.g., SAP GUI):
1. Go to SU01, enter the User ID.
2. Navigate to the "SNC" tab.
3. Enter the user's SNC name (e.g., p:CN=User Name, O=MyCompany, C=US for X.509, or p:user@YOUR.AD.REALM for Kerberos/SPNego).
4. Important: The format p:<SNC_Name> implies a distinguished name. The format s:<SNC_Name> implies a service name (less common for users).
5. Save changes.

D. RFC Destination Configuration (SM59):

For RFC connections that will use SNC:
1. Go to SM59, select the RFC Destination (Type 3 for ABAP, Type T for TCP/IP).
2. Go to the "Logon & Security" tab.
3. Check "SNC active".
4. Enter the "SNC partner name" of the target system/program. This is the snc/identity/as of the target SAP system, or the SNC identity of the external program.
5. Select the desired "SNC Protection (QoP)".
6. Recommendation: Use dedicated RFC users with limited S_RFC authorizations.

E. Database Connection (Specific to DB Type):

SAP HANA DB: Configure hdbuserstore and hdbnsutil for SNC secure store. Set [communication] ssl = systempki and [authentication] kerberos = true (or [authentication] pkicertificate = true).
Oracle/DB2/MS SQL: Follow the database vendor's specific documentation for enabling Kerberos/GSS-API authentication for the database client used by SAP.

IV. Enabling SSL/TLS (HTTPS) in SAP Basis

I. Introduction to SSL/TLS (HTTPS)

SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) are cryptographic protocols for securing communication over computer networks, primarily for web-based traffic (HTTPS). They provide:

Encryption: Protecting data in transit from eavesdropping.
Authentication: Verifying the identity of the server (and optionally the client).
Integrity: Ensuring data has not been tampered with.

Primary Use Cases:

Web browser to SAP Web Application (e.g., Fiori, Web Dynpro, SAP GUI for HTML).
Web Dispatcher to Backend.
SOAP/REST Web Service communication.

II. Prerequisites for Enabling SSL/TLS

CommonCryptoLib: Same as for SNC, libsapcrypto.so or sapcrypto.dll must be available in the kernel directory.
Certificates:
- Server Certificate: Issued by a trusted Certificate Authority (CA) for the SAP system's FQDN.
- CA Certificates: Root and Intermediate CA certificates that form the trust chain for the server certificate.
Ports: The HTTPS port (default 443, or 5xx01 for ABAP, 5xx02 for Java) must be open in firewalls.
FQDN: The Fully Qualified Domain Name of the SAP system must be resolvable and consistent with the CN in the server certificate.

III. Detailed Configuration Steps for SSL/TLS (HTTPS)

A. SAP ABAP Stack Configuration (STRUST and RZ10):

Configure ICM HTTPS Port (RZ10 / DEFAULT.PFL or instance profile):
- icm/server_port_0 = PROT=HTTPS, PORT=5xx01, TIMEOUT=600, PROCTIMEOUT=600 (Replace 5xx01 with your desired HTTPS port).
- ssl/ssl_lib = <path_to_commoncryptolib> (e.g., $(DIR_EXECUTABLE)/libsapcrypto.so).
- Restart SAP System after changing parameters in RZ10. (A soft ICM restart via SMICM is sufficient if only port/SSL parameters are added/changed, but a full system restart is safest).
Manage Server PSE (STRUST):
- Access STRUST: Go to STRUST.
- Select/Create PSE: Select "SSL Server Standard" (or create it if it doesn't exist).
- Generate Certificate Request (CSR): Click "Create Certificate Request". Fill in DN details, ensuring CN = Full FQDN of your SAP system. Save the CSR.
- Submit to CA & Obtain Certificate: Send the CSR to your CA. Receive the signed server certificate and potentially the CA chain.
- Import Certificate Response: In STRUST, with "SSL Server Standard" selected, click "Import Certificate Response" and select your signed server certificate.
- Import CA Certificates: For each Root and Intermediate CA certificate in your chain, click "Import Certificate" and then "Add to Certificate List".
- Save: Save the PSE.
- Distribute (if multi-app server): Select the "SSL Server Standard" PSE, go to PSE -> Distribute to propagate to all app servers.
Client Certificate Authentication (Optional):
- icm/HTTPS/verify_client = 1 (optional) or 2 (required): Set in RZ10.
- Import Client CA into Server PSE: In STRUST, import the Root/Intermediate CAs that issued the client certificates into the SSL Server Standard PSE's certificate list.
- User Mapping (SU01): In SU01, for each user, go to "SNC" tab, click "Certificate" and import the user's specific client certificate, mapping it to the SAP user.
Restart ICM (Soft Restart):
- After STRUST changes, perform SMICM -> Administration -> ICM -> Exit Soft -> Global.
Test: Access an SAP web service via https://<FQDN>:<port>/sap/bc/gui/sap/its/webgui.

B. SAP Java Stack Configuration (NetWeaver Administrator - NWA):

Access NWA: http://<host>:<port>/nwa.
Navigate to Key Storage: Configuration -> Security -> Certificates and Keys -> Key Storage.
Select Default View: This view contains the ICM_SSL_<SID> entry (Java's equivalent of ABAP's server PSE).
Generate Key Pair and CSR: Select ICM_SSL_<SID>, click "Generate Key Pair and CSR Request". Ensure CN is the FQDN. Download CSR.
Submit to CA & Obtain Certificate: Send CSR to CA.
Import Certificate Response: Select ICM_SSL_<SID>, click "Import Certificate Response", select signed server certificate.
Import CA Certificates: Import Root and Intermediate CA certificates into the TrustedCAs view (this view stores all trusted CAs for Java).
Configure SSL Manager Service:
- Navigate to Configuration -> Infrastructure -> Java System Properties -> Services.
- Select com.sap.engine.services.ssl.manager.
- Verify Port (e.g., 5xx02) and UseHTTPS (true).
Restart SSL Manager Service: Restart com.sap.engine.services.ssl.manager service.
Test: Access Java application via https://<FQDN>:<port>/nwa.

C. SAP Web Dispatcher Configuration (Reverse Proxy):

Install CommonCryptoLib: Ensure libsapcrypto.so/sapcrypto.dll is installed on the WD server.
Generate WD PSE (sapgenpse): Use command-line tool sapgenpse to create a PSE, generate CSR, get signed certificate, and import it along with the CA chain into the Web Dispatcher's PSE file. The CN must match the public FQDN of the WD.
Profile Parameters (sapwebdisp.pfl):
- icm/server_port_0 = PROT=HTTPS, PORT=443, TIMEOUT=600, HOST=<Public_WD_FQDN> (incoming HTTPS from clients).
- wdisp/ssl_encrypt = 1: (Optional, but recommended for re-encryption) Forces Web Dispatcher to use HTTPS when talking to backend.
- wdisp/ssl_auth = 0 (no client auth from WD to backend), 1 (optional), 2 (required).
- ssl/client_pse = <path_to_WD_client_PSE>: (If re-encrypting, WD acts as client to backend). WD's client PSE must trust backend CAs.
- wdisp/ssl_url_0 = <pattern>, HOST=<backend_host>, PORT=<backend_https_port>, SSL_CLIENT_PSE="<WD_client_PSE>" (Specific routing with SSL).
Restart Web Dispatcher: Restart the sapwebdisp service.

Important Configuration to Keep in Mind (SNC & SSL)

CommonCryptoLib Consistency: Ensure the version of CommonCryptoLib is compatible with your SAP Kernel version. Update it regularly.
FQDN and CN Matching (SSL): The Common Name (CN) in the SSL server certificate must precisely match the Fully Qualified Domain Name (FQDN) used by clients to access the SAP system. Mismatches cause browser warnings. Use virtual hostnames where appropriate.
Certificate Chain Completeness (SSL): Always import the entire certificate chain (Root CA, Intermediate CAs) into the PSE (STRUST) or TrustedCAs (NWA). Clients need the full chain to establish trust.
Certificate Expiration Monitoring: Implement robust monitoring for certificate expiration dates for all PSEs and key stores. Renew certificates well in advance to avoid outages.
Strong Cipher Suites and TLS Versions (SSL):
- Configure ssl/ciphersuites to use only strong, modern algorithms (e.g., 135:PFS:HIGH::EDH:SHA2).
- Set ssl/minimum_protocol_version = TLS1.2 (or TLS1.3 if supported) to disable older, insecure protocols. This is crucial for compliance.
Principle of Least Privilege (SNC Users/RFCs):
- For SNC-enabled users, ensure their authorizations are strictly limited.
- For SNC RFCs, ensure the RFC user has only the necessary S_RFC authorizations and is a dedicated user, not a powerful dialog user.
Gateway Security (reginfo, secinfo for RFCs): Harden the reginfo and secinfo files to control which external programs can register with and connect to the SAP Gateway. This is vital for RFC security, whether SNC is enabled or not.
Time Synchronization: Strict time synchronization (NTP) across all SAP systems, application servers, database servers, and any connected authentication servers (e.g., Active Directory for Kerberos) is critical for certificate validity and Kerberos ticket validation.
Network Ports: Ensure all necessary ports (e.g., 443, 5xx01, 5xx02 for HTTPS; specific ports for SNC security product like Kerberos ports) are open in firewalls.
Client/Partner Compatibility Testing: Before enforcing strict SNC/SSL settings (e.g., by setting snc/accept_insecure_gui = 0 or ssl/minimum_protocol_version = TLS1.2), rigorously test all connected clients and partner systems to ensure they support the new security standards. Old clients might break.
Security Audit Log (SM19/SM20): Ensure you are logging security-relevant events related to SNC and SSL connections (e.g., successful/failed SNC logons, SSL errors).
Private Key Security: The private key within the PSE/Keytab must be protected with strong passwords and strict file system permissions.

30 Interview Questions and Answers (One-Liner) for Enabling SNC and SSL

Q: What is the primary difference between SNC and SSL/TLS in SAP?
- A: SNC secures application-level communication (GUI, RFC, DB), while SSL/TLS secures web-based communication (HTTPS).
Q: Which cryptographic library is common for both SNC and SSL in SAP?
- A: CommonCryptoLib.
Q: What does QOP stand for in SNC?
- A: Quality of Protection.
Q: Which transaction is used to manage SNC PSEs in ABAP?
- A: STRUST.
Q: Which profile parameter enables SNC functionality?
- A: snc/enable = 1.
Q: How do you enforce a minimum level of data protection for SNC?
- A: snc/data_protection/max or snc/data_protection/min profile parameters.
Q: What is the snc/identity/as parameter used for?
- A: To define the SNC name of the application server.
Q: Where do you configure a user's SNC name in SAP?
- A: SU01, SNC tab.
Q: What does snc/accept_insecure_gui = 0 imply?
- A: Only SNC-secured GUI logons are permitted.
Q: Which SM59 tab is used to enable SNC for RFC destinations?
- A: Logon & Security tab.
Q: What is a Kerberos keytab file used for in SAP SNC?
- A: To store cryptographic keys for Kerberos authentication (e.g., SPNego).
Q: What is an SPN in the context of Kerberos SNC?
- A: Service Principal Name, mapping a service to an Active Directory account.
Q: What is the default HTTPS port for SAP ABAP?
- A: 5xx01 (where xx is the instance number).
Q: What transaction is used to manage SSL certificates in ABAP?
- A: STRUST.
Q: What must the Common Name (CN) of an SSL certificate match?
- A: The FQDN used to access the web service.
Q: Which profile parameter specifies the HTTPS port for ICM?
- A: icm/server_port_x (with PROT=HTTPS).
Q: What is a CSR in SSL configuration?
- A: Certificate Signing Request, generated to obtain a signed certificate from a CA.
Q: Where do you import Root and Intermediate CA certificates for SSL in ABAP?
- A: Into the "Certificate List" of the SSL Server Standard PSE in STRUST.
Q: Which profile parameter is used to restrict allowed SSL cipher suites?
- A: ssl/ciphersuites.
Q: How do you enforce a minimum TLS protocol version?
- A: ssl/minimum_protocol_version profile parameter.
Q: What is the role of icm/HTTPS/verify_client?
- A: To control whether client certificate authentication is optional or required for HTTPS.
Q: Where are SSL certificates managed on the SAP Java stack?
- A: NetWeaver Administrator (NWA) -> Key Storage.
Q: What is the TrustedCAs view in NWA Key Storage for?
- A: To store trusted Root and Intermediate CA certificates for Java applications.
Q: What is the purpose of wdisp/ssl_encrypt = 1 in Web Dispatcher?
- A: To force the Web Dispatcher to use HTTPS for communication with backend systems.
Q: Why is time synchronization important for both SNC and SSL?
- A: For validating certificate validity periods and Kerberos tickets.
Q: What does "Distribute PSE" in STRUST do?
- A: Propagates the updated PSE to all active application servers in the system.
Q: What are reginfo and secinfo files related to?
- A: SAP Gateway security for external program registration and connections.
Q: If an SSL certificate expires, what happens to HTTPS connections?
- A: They will fail, and browsers will show security warnings.
Q: What is the impact of an incomplete certificate chain for SSL?
- A: Clients will not be able to validate the server's certificate, leading to trust errors.
Q: Can SNC and SSL be enabled simultaneously on an SAP system?
- A: Yes, they secure different communication layers and can co-exist.

5 Scenario-Based Hard Questions and Answers for Enabling SNC and SSL

Scenario: You have just implemented SNC for SAP GUI users (using Kerberos/SPNego) and for RFC connections between two ABAP systems. Suddenly, users report "SNC Logon Failed" errors, while some critical RFCs between the systems also stop working with SNC errors, specifically after a recent OS-level patching. Non-SNC RFCs and GUI logons (if snc/accept_insecure_gui=1) are still working.
- Q: What are the primary suspects for these simultaneous SNC failures, considering the Kerberos setup and OS patching? Detail your Basis-level troubleshooting steps for both GUI and RFC issues, and how you would prevent recurrence.
- A:
  - Primary Suspects:
    1. Kerberos Keytab Corruption/Permissions: OS patching might have altered file permissions or even corrupted the krb5.keytab file on the SAP application servers. This is the most common issue in Kerberos-based SNC after OS changes. The SAP service user (<sidadm>) needs read/execute permissions.
    2. SPN Registration Issues: Less likely from OS patching directly, but it's possible a Windows update or a misconfiguration by an admin could inadvertently affect Service Principal Names (SPNs) in Active Directory if the service account was modified.
    3. Time Synchronization: OS patching might have temporarily disrupted NTP services, leading to time discrepancies between SAP servers and Domain Controllers, which breaks Kerberos ticket validity.
    4. SNC Library (libsapcrypto.dll) Corruption/Replacement: The patching process might have overwritten or corrupted the libsapcrypto.dll or its dependency.
  - Basis-Level Troubleshooting Steps:
    1. Verify Keytab File (Most Critical):
      - Action: Go to all SAP application servers (including ASCS). Check the location of krb5.keytab (from spnego/keytab parameter).
      - Action: Verify file permissions and ownership: Ensure <sidadm> user has read/execute permissions.
      - Action: Use ktutil (Linux) or klist -kt (Windows) to list the contents of the keytab. Verify the principal name (SAPService<SID>@REALM) and key versions. If corrupted, request a new keytab from the AD team.
    2. Check Time Synchronization:
      - Action: Verify time sync on all SAP servers (Application Servers, ASCS, DB) and Active Directory Domain Controllers. Use w32tm /query /source and w32tm /query /status (Windows) or ntpstat / timedatectl (Linux). Correct any discrepancies.
    3. SNC Profile Parameters (RZ11 & Trace):
      - Action: In RZ11, check snc/enable, snc/gssapi_lib, snc/identity/as, spnego/keytab, spnego/user_principal. Ensure paths are correct and identities match.
      - Action: Temporarily set snc/data_protection/min = 2 (Authentication) or 3 (Integrity) and snc/data_protection/max = 9 (Privacy) in RZ11 to increase SNC tracing detail in dev_w* files. Restart ICM (SMICM -> Administration -> ICM -> Exit Soft -> Global).
      - Action: Reproduce the error and analyze dev_w* trace files for SNC-specific error messages (e.g., GSS-API error).
    4. Verify SPNs (Coordinate with AD Team):
      - Action: Have the AD team verify that the SPNs for your SAP service account are correct and not duplicated using setspn -L <Domain>\SAPService<SID>.
    5. Test User SNC Name (SU01) & RFC SNC Name (SM59):
      - Action: Double-check the SNC names are correctly configured and match the expected format for Kerberos (p:user@REALM or p:service@REALM).
  - Prevention of Recurrence:
    1. Strict Change Management: Include SNC configuration and keytab file integrity checks in post-patching checklists.
    2. Dedicated Keytab Management: Implement a robust process for managing keytabs, potentially storing backups securely.
    3. Monitoring: Monitor for keytab expiration (if applicable for Kerberos). Monitor time synchronization services.
    4. Automated Testing: Implement automated scripts to perform basic SNC connectivity tests after system changes.
Scenario: Your SAP Fiori Launchpad (ABAP-based) is configured with HTTPS, and users access it via an SAP Web Dispatcher. You decide to enforce TLS 1.2+ and specific strong cipher suites (ssl/minimum_protocol_version=TLS1.2 and ssl/ciphersuites=135:PFS:HIGH::EDH:SHA2). After applying these changes to both the Web Dispatcher and the backend ABAP system, some users (using older browsers or custom applications) can no longer access Fiori, receiving SSL_PROTOCOL_ERROR or SSL_HANDSHAKE_FAILURE. However, modern browsers work fine.
- Q: What is the root cause of the connection failures for older clients? How would you identify the problematic clients/applications, and what is your recommended long-term strategy for balancing security hardening with compatibility requirements in this scenario?
- A:
  - Root Cause of Connection Failures: The SSL_PROTOCOL_ERROR or SSL_HANDSHAKE_FAILURE for older clients/applications is due to a TLS version or cipher suite mismatch. The hardened configuration (TLS 1.2+ minimum, specific strong ciphers) means the SAP Web Dispatcher (and potentially the backend ABAP system if re-encryption is enabled) no longer supports the older TLS versions (e.g., TLS 1.0, 1.1) or weaker cipher suites that the older clients might exclusively rely on. The negotiation during the SSL/TLS handshake fails because no mutually supported protocol version or cipher suite can be agreed upon.
  - Identifying Problematic Clients/Applications:
    1. Client-Side Browser Version: Ask affected users about their browser version and operating system. Older versions (e.g., Internet Explorer on Windows 7 without updates, very old Chrome/Firefox) might be the culprits.
    2. Custom Application Information: For custom applications, contact the application owner/developer to inquire about the underlying libraries/frameworks used for HTTPS connections and their TLS/cipher suite compatibility.
    3. Web Dispatcher/ICM Trace Files:
      - Action: Increase trace level for ICM (e.g., icm/trace_level = 3 in RZ10 or temporarily via SMICM).
      - Action: Replicate the error from a problematic client.
      - Action: Analyze dev_w* files (for ICM) and dev_webdisp (for Web Dispatcher) for specific SSL handshake error messages, showing the exact protocol or cipher suite negotiation failure. Look for phrases like "SSL handshake failed," "no common protocol version," "no common cipher suite."
    4. External SSL Scan Tool: Use tools like SSLLabs SSL Server Test on your Fiori Launchpad's FQDN. This will provide a detailed report of supported protocols and cipher suites, helping confirm the server-side configuration.
  - Recommended Long-Term Strategy for Balancing Security and Compatibility:
    1. Prioritize Security Hardening: For public-facing or sensitive systems, maintaining high security standards (TLS 1.2+ minimum, strong ciphers) is paramount. This should be the default goal.
    2. Client Upgrade Initiative: The ideal long-term solution is to ensure all clients and applications consuming SAP services are updated to support modern TLS versions and cipher suites. This often involves:
      - Communicating the new security requirements well in advance.
      - Providing guidance and support for client-side upgrades (e.g., OS updates, browser updates, .NET/Java runtime updates).
      - Phasing out support for older, insecure clients.
    3. Temporary Mitigation (If Absolutely Necessary):
      - Dedicated Proxy/Web Dispatcher: In rare cases where immediate client upgrades are impossible, consider setting up a separate, isolated Web Dispatcher instance (or another reverse proxy) with a less stringent SSL configuration only for the problematic legacy clients. This creates a security island but isolates the risk. This is a temporary and undesirable workaround, as it still maintains insecure access.
      - Careful Parameter Adjustment (Short-Term Reversion): As a very last resort, and only temporarily and with management approval, you could slightly relax the ssl/minimum_protocol_version or ssl/ciphersuites to allow the problematic clients to connect, while simultaneously pushing for their upgrade. This should be immediately followed by re-hardening.
    4. Comprehensive Client Inventory and Communication: Maintain an updated inventory of all external and internal systems connecting to your SAP services. Establish clear communication channels for security policy changes.
    5. Phased Rollout: For critical changes, implement them in non-production environments first, followed by a phased rollout to production, carefully monitoring for client compatibility issues.
Scenario: Your SAP Basis team needs to implement secure communication between your SAP ABAP (ECC) system and an external Java application that consumes several RFC-enabled Function Modules. The requirement is to use client certificate authentication, meaning the Java application will present its certificate to the SAP system for authentication, in addition to standard data encryption.
- Q: Detail the precise configuration steps required on both the SAP ABAP system and, conceptually, on the external Java application side to achieve client certificate authentication for RFCs. Highlight any key challenges or common pitfalls in such a setup.
- A:
  
  Precise Configuration Steps for Client Certificate Authentication (ABAP RFC to Java):
  
  Phase 1: SAP ABAP System (Server for Incoming RFCs)
  1. SNC Activation: Ensure SNC is enabled on the ABAP system (profile parameters snc/enable=1, snc/gssapi_lib, snc/identity/as are configured and system restarted).
  2. Generate SNC PSE for ABAP System:
    - Action: In STRUST, create or select a dedicated SNC PSE (e.g., SNC ABAP).
    - Action: Generate a CSR from this PSE. Obtain a signed certificate for the ABAP system's SNC identity from a trusted CA. Import the certificate response.
    - Action: Import the Root and Intermediate CA certificates that will issue the Java application's client certificates into the SNC ABAP PSE's certificate list in STRUST. (This is crucial for ABAP to trust the Java client's certificate.)
    - Action: Distribute the SNC ABAP PSE to all relevant application servers.
  3. Configure snc/permit_insecure_rfc:
    - Action: For the production environment, ensure snc/permit_insecure_rfc = 0 in RZ10 to enforce SNC.
  4. User Mapping (Client Certificate to ABAP User):
    - Action: For the dedicated RFC user in ABAP (e.g., RFC_JAVA_USER), go to SU01 -> SNC tab -> Certificate.
    - Action: Import the Java application's specific client certificate (not its CA) into SU01 and map it to RFC_JAVA_USER. This establishes the one-to-one mapping.
    - Action: Ensure RFC_JAVA_USER has only the necessary S_RFC authorizations for the consumed FMs.
  5. Restart SAP ABAP System: A full system restart is required for all RZ10 profile parameter changes to take effect. STRUST PSE changes can often be activated by distributing and soft ICM restart, but for full SNC enforcement, a system restart is best.
  Phase 2: External Java Application (Client for Outgoing RFCs)
  1. SNC Library and Configuration:
    - Action: The Java application must have an SAP Java Connector (JCo) or SAP Java Resource Adapter (JRA) setup. This typically includes sapjco3.jar and libsapjcorfc.so (or .dll).
    - Action: It must also have CommonCryptoLib (or another GSS-API V2 compatible product) installed and configured on the Java application server.
  2. Generate Java Application's Client Certificate:
    - Action: Generate a private key and CSR for the Java application (e.g., using keytool for Java Keystore, or sapgenpse if using CCL for the client side). The CN/DN of this certificate will be used in the ABAP SU01 mapping.
    - Action: Obtain a signed client certificate from the same CA that ABAP trusts (or a CA trusted by ABAP).
    - Action: Import the signed client certificate and its full CA chain into the Java application's keystore/truststore.
  3. JCo/JRA Connection Properties:
    - Action: Configure the JCo/JRA connection string to enable SNC and specify the client's SNC identity and PSE/keytab.
    - Example JCo properties:
      - jco.client.snc_mode = 1 (Enable SNC)
      - jco.client.snc_lib = <path_to_CommonCryptoLib> (e.g., libsapcrypto.so)
      - jco.client.snc_myname = p:<Java_Client_SNC_Name> (Matches CN of Java client certificate)
      - jco.client.snc_qop = 9 (Desired Quality of Protection)
      - jco.client.snc_partnername = p:<ABAP_SNC_Identity> (Matches snc/identity/as of ABAP system)
      - jco.client.snc_pse = <path_to_Java_client_PSE> (If using CommonCryptoLib for Java client)
  4. Trust ABAP System's Server Certificate (Optional but Recommended for Mutual Trust):
    - Action: If the ABAP system also sends its certificate (e.g., for mutual authentication or if the Java client enforces it), import the ABAP system's server certificate's CA chain into the Java application's truststore.
  Key Challenges / Common Pitfalls:
  1. SNC Name Mismatch: The SNC names specified in ABAP (snc/identity/as, SU01, SM59) and Java (jco.client.snc_myname, jco.client.snc_partnername) must exactly match the identities in the respective certificates/keytabs. Case-sensitivity is crucial.
  2. Certificate Trust Chain: Ensuring both ends (ABAP's SNC PSE and Java's truststore) trust the issuing CAs of each other's certificates.
  3. Keytab/PSE Permissions/Availability: The SNC libraries and credential files must be present and have correct OS-level permissions for the service user running the SAP system or Java application.
  4. Firewall Rules: Ensure no firewalls are blocking SNC communication (usually TCP/IP port 32xx).
  5. JCo/JRA Version Compatibility: Ensure the JCo/JRA libraries are compatible with the SAP kernel version and the CommonCryptoLib.
  6. Troubleshooting Complexity: Debugging can be challenging, involving dev_rfc, dev_w* traces on ABAP, and Java application logs, potentially including JCo/JRA trace settings.
Scenario: You are performing a regular security audit of your production SAP landscape. You discover that while HTTPS is enabled for Fiori and Web Dispatcher, the underlying ABAP application servers still support TLS 1.0 and 1.1, and some weaker cipher suites are still active. Additionally, SNC is only partially implemented for GUI users, and many RFC connections still use insecure clear-text communication.
- Q: Propose a phased roadmap to achieve comprehensive TLS 1.2+ and strong cipher suite enforcement for all HTTPS traffic, and 100% SNC enforcement for all internal SAP-to-SAP RFCs, while minimizing disruption to production. Detail the key technical steps and communication strategies for each phase.
- A:
  
  Phased Roadmap for Comprehensive Security Hardening:
  
  Phase 1: Discovery, Assessment & Communication (2-4 Weeks)
  1. Inventory & Current State Assessment:
    - Action (SSL): Identify all HTTPS-enabled services (Fiori, Web Dynpro, external integrations). Use SMICM -> Goto -> Services to list ports. Use external scanners (SSLLabs) on Fiori/Web Dispatcher FQDN, and potentially internal network tools for backend IPs, to identify currently supported TLS versions and cipher suites.
    - Action (SNC): Identify all critical SAP-to-SAP RFCs (SM59). Check their "Logon & Security" tab for SNC status. Identify all SAP GUI users. Review snc/permit_insecure_gui and snc/accept_insecure_gui parameters.
    - Action: Document all current settings, including CommonCryptoLib versions.
  2. Impact Analysis (Crucial):
    - Action (SSL): Identify all clients (browsers, mobile, third-party apps) consuming HTTPS services. Communicate the planned TLS/cipher hardening. Gather their current compatibility (e.g., via questionnaires, pre-tests).
    - Action (SNC): Identify all connected SAP systems and external RFC programs. Communicate the SNC enforcement plan. Verify their SNC compatibility and configuration readiness.
  3. Define Target State: Agree on specific ssl/minimum_protocol_version, ssl/ciphersuites (e.g., TLS1.2 and 135:PFS:HIGH::EDH:SHA2). Agree on 100% SNC enforcement (e.g., snc/accept_insecure_rfc=0, snc/accept_insecure_gui=0).
  4. Communication Strategy: Plan clear, multi-channel communication to all stakeholders (users, business, technical teams, third-party vendors) about upcoming changes, timelines, and impact. Provide resources for client-side preparation.
  Phase 2: Pilot & Test (4-8 Weeks)
  1. Non-Production Environment Hardening:
    - Action: Apply all planned RZ10 profile parameter changes (ssl/minimum_protocol_version, ssl/ciphersuites, snc/accept_insecure_rfc=0, snc/accept_insecure_gui=0) to Development and Quality systems.
    - Action: Ensure SNC PSEs are correctly distributed and configured for all internal RFCs. Verify user SNC names (SU01).
    - Action: Perform full system restarts on Dev/QA to activate changes.
  2. Comprehensive Testing:
    - Action (SSL): Test all identified client types (browsers, mobile, custom apps) against Dev/QA Fiori. Verify successful access and certificate details (ensure TLS 1.2+ is used).
    - Action (SNC): Test all critical SAP-to-SAP RFCs. Test GUI logons with SNC from various client OS/patch levels.
    - Action: Use SMICM for SSL/TLS validation and dev_w* traces for SNC/RFC issues.
  3. Remediation & Adjustment: Address any issues found. Work with client owners for necessary upgrades or workarounds. Refine profile parameters if needed.
  Phase 3: Production Phased Rollout (4-12 Weeks, depending on complexity)
  
  A. Initial Soft Enforcement (Minimizing Disruption):
  1. Action (SSL):
    - Apply ssl/minimum_protocol_version and ssl/ciphersuites to production Web Dispatcher and backend ABAP ICM in RZ10.
    - Perform soft ICM restarts (SMICM -> Administration -> ICM -> Exit Soft -> Global). This applies the changes with minimal disruption.
  2. Action (SNC):
    - Ensure SNC PSEs are distributed.
    - Ensure snc/permit_insecure_rfc = 1 and snc/permit_insecure_gui = 1 (allow insecure fallback) are temporarily set in RZ10 in production. This allows existing insecure connections to continue while you transition.
    - Ensure snc/accept_insecure_rfc = 1 and snc/accept_insecure_gui = 1 are set (allow insecure incoming).
    - Perform full system restart for RZ10 parameters.
  3. Monitoring: Monitor SM21, ST22, dev_w*, dev_icm, dev_rfc logs extensively for any new SSL or SNC errors. Monitor CPU utilization.
  B. Gradual Hardening & Enforcement:
  1. Enable SNC for Critical RFCs:
    - Action: One by one, or group by group, enable SNC for critical RFC destinations in SM59 (setting SNC active and SNC partner name).
    - Action: Work with corresponding partner systems to enable SNC on their side.
    - Monitoring: Closely monitor each RFC after enabling SNC.
  2. Enable SNC for GUI Users:
    - Action: Start by updating SU01 for small groups of users, ensuring their client configuration (SAP GUI SNC settings) is correct.
    - Communication: Provide clear instructions for users to configure their SAP GUI for SNC.
  3. Final Enforcement (Zero Insecure):
    - Action: Once all critical RFCs and target GUI users are successfully using SNC, set snc/accept_insecure_rfc = 0 and snc/accept_insecure_gui = 0 in RZ10 in production. This strictly enforces SNC.
    - Action: Perform a full system restart to activate these strict SNC parameters.
    - Monitoring: Intense monitoring after this final step for any unexpected connection failures.
  C. Client Upgrades (Ongoing):
  - Action: Continuously work with clients/applications that rely on older TLS versions/ciphers to upgrade their software. If unavoidable, refer to the "Temporary Mitigation" strategy in scenario 2.
  This phased approach allows for identification of issues in controlled environments, minimizes risk during production rollout, and ensures comprehensive security hardening over time.
Scenario: Your SAP landscape includes an ABAP system acting as a central hub for various RFC integrations. You want to implement comprehensive security for these RFC connections. Some integrations are with other SAP systems (ABAP and Java), some with external non-SAP applications (custom Java, .NET), and some use specific named users for authentication.
- Q: Design a robust RFC security strategy that incorporates both SNC and Gateway security, considering the diverse types of integrations. Detail the configuration considerations for each integration type and how to ensure "least privilege" is applied across all RFC connections.
- A:
  
  Robust RFC Security Strategy (SNC & Gateway Security):
  
  Core Principles:
  1. Least Privilege: Every RFC user and every registered program must have only the minimum necessary authorizations and access.
  2. Authentication: Strong authentication for all RFCs.
  3. Encryption: Data in transit must be encrypted.
  4. Gateway Control: Explicitly control what can register and connect to the SAP Gateway.
  5. Monitoring & Auditing: Log and review all security-relevant RFC activities.
  Strategy Pillars & Configuration Considerations:
  
  Pillar 1: SNC for All Possible Integrations (Preferred for SAP-to-SAP and Compatible Non-SAP)
  - Purpose: Provides application-level authentication, integrity, and confidentiality.
  - Configuration:
    1. SNC Product: Use CommonCryptoLib (libsapcrypto.so/dll) on all SAP systems and, if possible, on non-SAP systems (via SAP JCo/NCo with SNC).
    2. Profile Parameters (RZ10 on all involved SAP systems):
      - snc/enable = 1
      - snc/gssapi_lib = <path_to_cryptolib>
      - snc/identity/as = p:<unique_SNC_name_for_each_system> (e.g., based on certificate DN or Kerberos principal).
      - snc/data_protection/max = 9 (Privacy/Encryption for production).
      - snc/accept_insecure_rfc = 0 (Crucial for enforcing SNC).
    3. RFC Destination (SM59):
      - For each RFC destination:
        
        "Logon & Security" tab: Check "SNC active".
        
        "SNC partner name": Enter the SNC name of the target system/application (e.g., p:CN=TargetApp,OU=Dev,O=Comp,C=US).
        
        "SNC Protection (QoP)": Set to 9 (Privacy) to enforce encryption.
    4. SNC Credential Management (STRUST / Keytabs):
      - Each SAP system needs its own SNC PSE/keytab.
      - The PSE for the RFC initiator must trust the CA that signed the certificate of the RFC target.
      - The PSE for the RFC target must trust the CA that signed the certificate of the RFC initiator (for mutual authentication).
    5. User Mapping (for Named Users):
      - For RFCs using named users, the SNC name (from certificate DN or Kerberos principal) of the calling system/user account must be mapped to the corresponding SAP RFC user in SU01.
  Pillar 2: Gateway Security (for All External Integrations)
  - Purpose: Controls which external programs can register with the SAP Gateway and which hosts/users can connect to it. Essential for security even if SNC is used.
  - Configuration (OS level on Gateway host):
    1. reginfo file: (Controls program registration)
      - Location: $(DIR_INSTANCE)/data/reginfo
      - Content: Define explicit ACL_ALLOWED_PROGRAMS entries for every external program that needs to register with the Gateway.
      - Example: P GWHOST <SID> PROGRAM /path/to/prog.exe
    2. secinfo file: (Controls client connections to Gateway)
      - Location: $(DIR_INSTANCE)/data/secinfo
      - Content: Define explicit P (program), H (host), U (user) rules for allowed connections.
      - Example: P * H <Trusted_IP_Range> U * (More restrictive rules are better, e.g., P <RFC_Server_Program> H <Specific_Host_IP> U <Specific_OS_User>).
    3. Profile Parameter (RZ10):
      - gw/acl_mode = 1 (Enforces the use of reginfo and secinfo).
      - gw/reg_no_reg_info = 0 (Prevents registration without reginfo).
      - gw/reg_info = <path_to_reginfo>
      - gw/sec_info = <path_to_secinfo>
    4. Restart Gateway: Restart the SAP instance or specifically the Gateway process.
  Pillar 3: "Least Privilege" Principle for RFC Users
  - Purpose: Limits the damage if an RFC user or connection is compromised.
  - Configuration:
    1. Dedicated RFC Users: Create a separate, dedicated RFC user for each integration scenario. Avoid using powerful dialog users.
    2. Restricted Authorizations (SU01 / PFCG):
      - Action: Do NOT assign SAP_ALL or SAP_NEW.
      - Action: Grant S_RFC authorization only for the specific Function Groups or Function Modules that the RFC integration needs to call.
      - Action: Restrict S_RFCACL for trusted system relationships to a bare minimum.
      - Action: Ensure the RFC user has no dialog logon capability (User Type: Communication).
    3. Avoid Dangerous FMs: Strictly prohibit RFC calls to FMs that execute OS commands (SXPG_COMMAND_EXECUTE), change system parameters (RS_CHANGE_PARAMETER), or provide direct table access (RFC_READ_TABLE) unless absolutely necessary and under extreme scrutiny. If such FMs are required, implement custom wrappers with strong internal authorization checks.
  Pillar 4: Monitoring and Auditing
  - Purpose: Detect and respond to suspicious RFC activity.
  - Configuration (SM19 / SM20):
    1. Security Audit Log: Enable SM19 to log:
      - RFC calls (B events).
      - Successful/failed RFC logons.
      - Transaction starts via RFC.
      - Gateway logging (profile parameters gw/logging, gw/log_level).
    2. Regular Review: Periodically review SM20N for unusual RFC activity, especially for sensitive FMs or from unexpected source systems/users.
    3. SIEM Integration: Forward SAP audit logs to a SIEM system for centralized analysis and correlation.
  Integration-Specific Considerations:
  - SAP ABAP to SAP ABAP:
    - Recommendation: 100% SNC.
    - Configuration: Configure SNC on both source and target ABAP systems, SM59 on source, SU01 mapping if named users.
  - SAP ABAP to SAP Java:
    - Recommendation: 100% SNC.
    - Configuration: SNC on ABAP side. Java side needs JCo/JRA with SNC enabled and its own SNC identity (keytab/PSE) and trust configuration.
  - SAP ABAP to External Non-SAP (Custom Java, .NET):
    - Recommendation: SNC if the external application can be configured with a GSS-API V2 library (e.g., SAP JCo for Java or SAP NCo for .NET, using CommonCryptoLib). This is the most secure.
    - Fallback (if SNC not possible): Use Secure Store & Forward (SSF) for secure credential storage, and enforce strong password policies for RFC users. If HTTP-based, use HTTPS.
    - Gateway Security: Absolutely critical for any external program that registers with the Gateway.
  - External Non-SAP to SAP ABAP (RFC Server Programs):
    - Recommendation: SNC. The external application acts as an RFC server (e.g., rfcexec), which registers with the SAP Gateway.
    - Configuration: The external program needs to support SNC and use an SNC identity that the SAP ABAP system trusts.
    - Gateway Security: Strictly define reginfo and secinfo entries for the external RFC server program to control its registration and network access.
    - SM59: Create a Type T (TCP/IP) RFC to trigger the external program.

This comprehensive strategy ensures multi-layered security for all RFC communications, drastically reducing the attack surface.

Rakshit Ranjan Singh

Search This Blog