Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
Martin-Pankraz
Active Contributor
1,864

Dear community,

Many of you still rely heavily on the legacy SAP interface RFC. In my world that often means customers connecting their third-party services to SAP backends (AS ABAP). Securing a protocol such as SAP Remote Function Call (RFC) requires network layer protection.

Often Kerberos is discussed on this topic, because it allows the mapping of Windows-Known identities to SAP backend users. However, this post is about apps and technical connections using X.509 certs – not people. They complain less – and boringly but reliably behave the same way once configured properly😉 Meet SAP Secure Network Communications (SNC).

By the way: In case you want user-based flows and focus on SAP Principal Propagation have a look at this series by my beloved colleague Martin Raepple.

 

SAP SNC integration architecture overviewSAP SNC integration architecture overview

 

Welcome to the world of SAP Secure Network Communications (SNC) for trustworthy technical connections!

In light of zero-trust efforts customers want to secure their technical connections to SAP RFCs too. In that space certificate-based authentication mechanisms are king. SNC is a prominent choice.

There are libraries for languages like Java, DotNet, C/C++, Python, and NodeJS that support SNC for RFC. Python and NodeJS were recently archived and will no longer be maintained. In case you get stuck, consider generating SOAP services for your SAP RFCs to uplevel the communication stack to layer 7 for use with TLS instead.

MartinPankraz_1-1736697403542.png

Source: SAP Help

Below I will show a simple setup with self-signed certificates. This way you can get started with a working setup and elevate towards more sophisticated as you go. Troubleshooting SNC errors can be cumbersome, so starting small with less variables and less room for error is a good idea.

 

Be aware of latest crypto library guidance (SAPCryptoLib vs, CommonCryptoLib) published by @JoeGoerlich in this post. My post still refers to SAPCryptoLib as it still widely applicable. Consider CommonCryptoLib if you can.

 

First things first: reach your private RFC interface

SAP products like the SAP Cloud Connector support apps (and people) on the SAP Business Technology Platform to connect to private instances of AS ABAP systems (behind firewall, in RISE, on-premises, or on a protected hyperscaler environment) and bring the required RFC execution environment.

Third-party apps must overcome the same challenges. Typically, that means you will be provided with a piece of software to act as reverse invoke proxy (same as the SAP Cloud Connector) besides the “line of sight” through connected private networks from that proxy. See step 0 in the overview drawing for reference.

It establishes connection to your third-party app inside out, so that no inbound firewall rules or the likes need to be touched.

For instance, Microsoft apps like Azure Data Factory, Azure Synapse, Microsoft Purview, Microsoft Fabric, and Microsoft Power BI have dedicated means to connect. These components are called Self-hosted Integration Runtime (SHIR) or On-Premises Data Gateway. Find the downloads on the individual product pages.

Be aware that services like Azure Functions or Azure LogicApps have a second approach beyond the Microsoft On-premises Data Gateway. They can bring the means to execute RFC calls, provide SNC configuration, and create line-of-sight to the private network through injection capability in a single deployment. This way you don't need the reverse invoke proxy.

Each of the described solutions have individual guides on the SAP RFC setup and how to expose the configuration for SAP SNC.

Can highly recommend my colleague Taylor Brazelton’s blog for SNC from Power Platform and On-premises Data Gateway.

Find below an SAP SNC config sequence with self-signed certificates generated by OpenSSL. Through this setup AS ABAP accepts requests protected by SNC via the SHIR.

I assume you have already installed the SHIR on a suitable windows machine and taken care of required installations like SAP Java Connector (JCo), SAP Connector for Microsoft .NET (NCo), and .NET Framework. My samples and script commands are Windows specific. However, Linux works the same way with slightly different commands.

 

Download SAP SNC Crypto Lib to your SNC client machine

  • Search the latest “SAPCRYPTOLIB” on SAP’s software center (S-User with download rights required)
  • And extract the SAR file using SAPCAR. Command looks something like this:

 

.\SAPCAR_1200-70007719.EXE -xvf .\SAPCRYPTOLIBP_8553-20011729.SAR -R .\..\libs\sapcryptolib

 

  • Find the executable sapgenpse

 

Prepare your SNC client machine

  • Create a folder to hold your SAP PSE artifacts:

 

mkdir sapsecudir
cd .\sapsecudir

 

  • Permanently add environment variable to point at this folder

 

[Environment]::SetEnvironmentVariable("SECUDIR", "C:\sapsecudir", "Machine") # Sets the variable permentaly on the system.
$env:SECUDIR = "C:\sapsecudir" # Updates the current powershell session as there currently does not exist a function to reload.

 

 

Generate a certificate for your SNC client app

  • Create folders to hold your certificates: mkdir rootCA sncCert
  • Generate root CA certificate: Adjust the subject as needed

 

openssl genpkey -algorithm RSA -out rootCA/ca.key.pem -pkeyopt rsa_keygen_bits:2048 

openssl req -x509 -new -key rootCA/ca.key.pem -days 7305 -sha256 -extensions v3_ca -out rootCA/ca.cert.pem -subj "/O=Contoso/CN=Root CA"

 

  • Generate SNC client certificate and adjust subject as needed:

 

openssl genrsa -out sncCert/snc.key.pem 2048

openssl req -key sncCert/snc.key.pem -new -sha256 -out sncCert/snc.csr.pem -subj "/O=Contoso/CN=SNC"

 

  • Sign the SNC certificate with the root CA certificate:

 

openssl x509 -req -in sncCert/snc.csr.pem -days 3650 -CA rootCA/ca.cert.pem -CAkey rootCA/ca.key.pem -CAcreateserial -out sncCert/snc.cert.pem

 

 

Establish trust between SNC client and SAP

  • Add the SNC cert to a PKCS #12 archive file (.p12)

 

openssl pkcs12 -export -out snc.p12 -inkey sncCert\snc.key.pem -in sncCert\snc.cert.pem -certfile rootCA\ca.cert.pem

 

  • Create the SAP Personal Security Environment (PSE) using the container

 

.\sapgenpse.exe import_p12 -p SAPSNCSKERB.pse C:\Users\shir-admin\Documents\snc.p12

 

 

Verify SAP is configured for SNC yet

One way of doing that is using transaction RZ10 and browsing the parameters prefixed with SNC. See this SAP document on the required “SNC Parameters for X.509 Configuration” settings and their implications.

If there is no configuration yet execute the transaction SNCWIZARD and maintain settings for X.509 credentials. Take note of the SNC private key subject. The CN will be required later.

Add your SNC client (I named mine PRV for Microsoft Purview) to the SAP Access Control List (ACL) using transaction SNC0 and allow RFC and CPIC connections.

MartinPankraz_2-1736697403544.png

 

Import SNC client cert into SAP

  • Use transaction STRUST
  • Navigate to the instance below SNC SAPCryptolib (if crossed out with a red X, create one from right-click)
  • Scroll down below the certificate list pane, choose import certificate and supply your snc.cert.pem file.
  • Click “Add to Certificate List” button
  • Click “Save”.

MartinPankraz_3-1736697403552.png

 

Download SAP cert and import into SNC client PSE

  • From the same STRUST screen, double click the Subject line of “Own Certificate” and
  • Scroll down again to find the “Export Certificate” button at the bottom.
  • Move to your SNC client machine (where your SHIR runs), put the certificate in a secure place (in my sample it landed in a folder called sap) and run below command to import it into your PSE.

 

sapgenpse.exe maintain_pk -p SAPSNCSKERB.pse -v -a  C:\sap\contoso-public-key.crt

 

Now your SAP trusts connections coming from your SHIR.

 

Allow your SHIR process to use your SAP PSE

  • Verify which user or service is being used by your SNC client to obtain certificate to communicate with SAP. The Purview SHIR uses the service user “NT SERVICE\DIAHostService”.
  • Add a credential to allow the certificate retrieval request from the PSE.

 

.\sapgenpse.exe seclogin -p C:\sapsecudir\SAPSNCSKERB.pse -x your-pse-pin -O "NT SERVICE\DIAHostService"

 

Verify credentials like so

 

.\sapgenpse.exe seclogin -l -O "NT SERVICE\DIAHostService"

 

You can delete them like this:

 

.\sapgenpse.exe seclogin -d -O " NT SERVICE\DIAHostService "

 

Use the -h parameter to get help with the sapgenpse command line tool or check the command reference here.

 

Test communication using SAP SNC

Navigate to your client application and supply the SNC configuration you have prepared. Some apps require an SAP user and password in addition even though providing a client certificate would be enough for a technical connection (remember: no user mapping or SSO).

This gives you the option to further trim down access. Use transaction SU01 and the SNC tab or the maintenance view “VUSREXTID” from transaction SM30 to configure the SNC external ID (CN) to your SAP user name.

See below sample taken from the connection configuration fly-out pane on the Azure portal UI. It can be applied, however, to any SNC client configuration. See further samples here and here.

MartinPankraz_4-1736697403557.png

 

Trigger “Test connection” and marvel at the SNC secured communication test from Microsoft Purview to AS ABAP😊

Or go even a step further and call your first RFC. RFC_PING or STFC_CONNECTION might be a suitable one in case your target is not yet operational or not identified yet.

 

Hints on Troubleshooting

  • First, try to connect from your client to AS ABAP without SNC to ensure that networking is properly configured already. Be aware of SAP RFC ports (ZZ placeholder represents your SAP instance number, e.g. 00 or 01 often) and check firewall accordingly if needed.
    • 32ZZ and 33ZZ for direct RFC connections
    • 48ZZ for SNC secured RFC connections
  • Verify SNC status from transaction SM51 -> click “SNC Status” button to ensure it is fully configured
  • Consult the blog series from @Frank_Buchholz on more sophisticated approaches to verify individual SNC connections. For instance, report “ZSM04000_SNC” shows more details.
  • For those of you using SAP UCON may consult the SNC connectivity status there.
  • Closing above mentioned RFC ports (32ZZ, 33ZZ) on the proxy VM firewall does the trick to verify if SNC connection is opened. Intentionally “breaking” your SNC config by mistyping the SNC partner name for instance could give you another indication on a functional setup.

 

Final Words

That’s a wrap 🌯. You learned today how to secure your technical RFC connections from third party apps to AS ABAP systems using SNC. The guide keeps it simple so you can establish a stable setup base from which to iterate on more complex setups confidently 😊Generate SOAP services for your RFCs and use TLS in case SNC is not an option.

By the way: When introducing an API Management solution between your 3rd party app and the SOAP service on AS ABAP you may use OAuth2, or OpenID Connect on the client. You still need to translate on the API Management layer to an auth mechanism that AS ABAP supports. Either way a step forward in securing your SAP connections.

Happy integrating with SAP!

#Kudos again to Savas Akgol@MartinRaepple, and @Frank_Buchholz for helping with some  of the hard parts 🙏

 

Cheers

Martin

2 Comments
Labels in this area