Intro

SSO for SAPGUI logins from a Linux client machine can be set up using X.509 certificates – the idea is that the client machine presents a (public key) certificate identifying a SAP user by their SNC name to the target SAP system, and if that certificate is in the trusted certificate list of the SAP system’s SAP Cryptolib PSE, then the SAP system will allow the logon attempt. 

[Currently, SAP does not provide a Linux version of their SAP Secure Login Client (which is a software utility that uses Kerberos tokens – as of March 2023, available for Windows and macOS), so Kerberos is not in scope here as a login method].

We first consider getting encryption-via-SNC working (section “Using SNC encryption only”) so that even when doing manual (password-based) logins, at least the communication is encrypted, and thus not vulnerable to being deciphered by Wireshark or whatever. 

Then in a second iteration of the setup (section “Using SSO”) we set up the full SSO for SAPGUI over SNC, using an X.509 certificate to logon.

We don’t consider much about what SAP server-side config should look like for this client-side logon method to work (beyond some necessary activity in tcode STRUST) – instead, we just assume that the SAP system is setup for SNC in the right way already (so that, for example, Windows and MacBook users might already be using SAP Secure Login Client to present Kerberos tokens to SAP SNC for SSO purposes).

Note: this blog is the verbose-and-extended version of the excellent advice (which I followed) from Rob Liversage that he provided in a comment elsewhere on this SAP website – so if you prefer the concise original advice on how to get this stuff working, then it’s here:

https://blogs.sap.com/2022/03/04/notes-on-installing-sapgui-for-java-for-macos/comment-page-1/#comment-643057 

Other Note: The Linux client I used was Xubuntu 22.04, haven’t tested this on any other Linux distros – good luck now with whatever distro and release you are using!

Yet Another Note: this blog doesn’t operate a Helpdesk, so you might need to BYODS (Bring Your Own Debugging Skills). If there were some errors in my explanations though, feel free to point those out and I will try to improve the text. (Questions about server-side or AD-side configuration steps for SNC, are not considered in the blog, and of course I have no way of knowing if your or your organisation’s SNC configuration is suitable or enabling for the client-side config scenarios described below, so hopefully the comments section won’t be getting filled with chat about such server-side topics ).

Getting the media and basic preparation

On the Linux client machine, you need to download (or copy over to the machine) the SAPCRYPTOLIB archive… so for this, you need an S-user with Software Download rights (or you need to know someone in your organisation with such rights – ask them nicely for help, explain your use case and business case, etcetera etcetera).

https://launchpad.support.sap.com/#/softwarecenter 

Search on “sapcryptolib”, choose the non-versioned answer and go to Maintenance Software Component. Then choose the correct OS architecture from the box, and the latest version, then the I-Ching-like icon and “Content Info”:

Then download the .SAR file.

To unpack the SAP ARchive, you need a utility called SAPCAR… again we are in Software Downloads, and this time search on “sapcar”.  Again choose the non-versioned SAPCAR, Maintenance Software Component. And again choose the correct OS architecture, then download via Content Info…

Copy the SAR and the SAPCAR files over to your Linux machine in case you downloaded them using a different machine. Once you have both the SAR and the SAPCAR in some folder on the Linux machine, you can unpack the SAR archive. (If the SAPCAR isn’t executable yet, first make it so using chmod).

chmod +x SAPCAR_1115-70006178.EXE

./SAPCAR_1115-70006178.EXE -xvf SAPCRYPTOLIBP_8548-20011697.SAR

Now in your folder you will have the newly extracted sapgenpse utility (and a few other files), so this sapgenpse is what we need for the next steps.

Then it will be a good idea to define two environment variables – either in your bash profile at ~/.profile; or, in my case I just used the /etc/environment file – since this is a one-user machine, no problem… (if instead there would be multiple users, it would be better to use e.g. each user’s .profile). Anyway in this example, elevating ourselves with sudo, we edit /etc/environment, using nano or whatever you prefer:

sudo nano /etc/environment

Add then save these two lines to the file (obviously you adjust the example filepaths according to your own case):

SNC_LIB=/home/marmot/sapstuff/libsapcrypto.so

SECUDIR=/home/marmot/sec

The first environment variable says where libsapcrypto.so is located (same location as wherever sapgenpse is, since these were unpacked together). This is needed by SAPGUI for Java client software, when any SNC-related connections to SAP should be established. 

The second environment variable identifies the directory where the SAPSNCS.pse is going to be created via sapgenpse’s get_pse command. It’s a good idea to create this directory now (i.e. before you use get_pse):

mkdir ~/sec

Then logout and login, so the new environment variables of /etc/environment (or ~/.profile) get picked up.

Remember kids, the SNC tricks of this blog are only going to work, if your SAP system has been configured to accept X.509 certificates.

https://help.sap.com/docs/SAP_SINGLE_SIGN-ON/df185fd53bb645b1bd99284ee4e4a750/06298bf7ec7e4ae19fba6ab0c518dda1.html?locale=en-US 

The SNC parameters would be visible in RZ10 (typically in the Default profile of the SAP system), but we are not going to review those here, as this blog is not about configuring server-side SNC using SNCwizard etcetera.

Using SNC encryption only

In this section we are considering a scenario, where you are happy enough with password-based logins, but you would like (or need, or demand) all the SAPGUI traffic to be encrypted.

We deliberately generate a “dummy client certificate” that will not enable us to do SSO, so we specify a nonsense subject line, one which does not correspond to the SNC name of any SAP user in the target system.

When generating the certificate, be sure to call the new PSE created exactly as follows: “SAPSNCS.pse” … whereas for the actual CN= and O= details, you can make those up yourself:

./sapgenpse get_pse -s 2048 -p SAPSNCS.pse “CN=sapsnc O=murmelssonic”

You can hit <Enter> (twice), to avoid password-protecting your new PSE file, or you can supply a password (I didn’t as nobody else has access to my Linux VM).

So this creates a so-called “Personal Security Environment” (SAP terminology), but for our purposes it is enough to think of this as creating a public key certificate (and a private key), contained in the PSE file. And that PSE file is created in whatever filepath you defined as the SECUDIR above in “Getting the media and basic preparation”.

Next step is to go to the SAP system you want SNC logon to work with, and download (export) the relevant certificate. Obviously it helps if you can already logon to said system e.g. via password logon, or via SSO from a MacBook or Windows machine, and then you also need rights to tcode STRUST… if this is more access than you have, then hopefully you know someone who can get and send you the exported certificate.

So in our example we do a password login to an SAP system, then go to STRUST, double-click on left-hand menu under SNC Cryptolib (if this doesn’t exist, you are not going to be doing SNC login so you can stop reading), then double click on the subject field of the SNC SAPCryptolib “Own certificate” in the right-hand pane, so that its details appear lower down the page, then choose menu Certificate -> Export…

Choose Binary or Base64 format (doesn’t matter), choose a location on your local computer, give this certificate a filename and Save it. If you saved it to another computer, then copy it across to your Linux machine. So my copy of the exported SAP system certificate is stored in ~/sapstuff along with the sapgenpse utility files; called it sgdsnc.cert as it’s a (self-)signed SNC cert from the server, but obviously you can call your exported server certificate whatever you like.

Next step is to use this downloaded certificate and import it to the certificate list of the Linux VM’s PSE bundle, so we use sapgenpse utility for that also (in directory ~/sapstuff in my case):

./sapgenpse maintain_pk -v -a sgdsnc.cert -p SAPSNCS.pse

Then, we want to export our newly modified certificate of the PSE, as follows:

./sapgenpse export_own_cert -p SAPSNCS.pse

This command runs and then displays the output (exported) X.509 certificate in the terminal window you executed the command in. You need to now copy-paste the text beginning with line —–BEGIN CERTIFICATE—– and ending with line —–END CERTIFICATE—– (including those two lines in the block of text)… and save that text to a new file, using nano, or vi, or any text editor you like. My example is called exportedlocal.cert:

Back on the SAP server in STRUST, we go into Change mode, make sure the SNC Cryptolib certificate is still in focus (double-click on its subject line to make sure it appears in lower window), then scroll down to right-hand window near the bottom of the page, and click on Import certificate icon… then upload your exportedlocal.cert from local machine to server. Then click on Add to Certificate List, and Save the STRUST transaction from the upper menu.

So the list should now contain the relevant uploaded certificate:

Once this is done, you can attempt to logon to the SAP system using a Connection item with SNC enabled –  and e.g. Encryption only or Max. Available options, in the Security tab of the Connection Item. 

[Note that in this client side configuration, the (SAP system’s) “SNC name”-field should appear as Display-only (greyed-out) info provided from the SAP system’s Message Server – it should contain the SNC Cryptolib name of the SAP system as defined in STRUST, plus the prefix “p:” to match it with its relevant RZ10 parameter-value for parameter “/snc/identity/as”; so if the SAP system has, say, “CN=SAPServiceXYZ” as value of Subject in SAPCryptolib certificate, then in the SAPGUI client configuration, it would appear as “p:CN=SAPServiceXYZ”].

Although in this section’s scenario case there is (by design) no known SAP user with dummy SNC Name “p:CN=sapnc O=murmelssonic”, so SSO will not be working, however the sessions will be encrypted, so no Wireshark eavesdroppers or other bad actors will be able to see your username and password when you do login, nor will they see any transaction data when you work in the SAPGUI session. 

Your connection attempt should result in being presented with the standard manual login screen (with the warning message that (SSO is not possible as) no such user with that SNC name):

So on this standard SAP logon screen you enter your SAP username and password, login, and the whole session (including, importantly, your login attempts) is encrypted by SAP SNC – which is what this section’s scenario wanted to achieve.

Using SSO

Since from our previous activity for SNC encryption only, we currently have the file ~/sec/SAPSNCS.pse, which defined a nonsense subject, so as preparation for this section’s SSO enablement, what we need to do is get rid of that file (delete it); or in case we might want to switch back to using it later, then we could just rename that PSE to make it a backup file. So choose one of these two commands, according to your preference:

rm SAPSNCE.pse

mv SAPSNCS.pse SAPSNCS.pse_bac

So we have created space for a new SAPSNCS.pse (as that is what it must be named) which we are now going to generate, again using the sapgenpse utility… The only difference this time is that now we provide an appropriate subject line for SSO logon attempts… so if your SAP user (view using tcode SU01, Display, tab “SNC”):

…has the SNC name, say “p:[email protected]” (based typically on your organisation’s AD config having defined, in this example, your user as “[email protected]”, and then this information having been imported or maintained per SAP user/system/client – hence its visibility in SNC tab of SU01), then the build command you would need this time is:

./sapgenpse get_pse -s 2048 -p SAPSNCS.pse “[email protected]”

Then you modify the new Linux VM’s PSE by importing via maintain_pk the file you exported from the SAP server previously (see section above “Using SNC encryption only” for details): 

./sapgenpse maintain_pk -v -a sgdsnc.cert -p SAPSNCS.pse

…and then you export the updated X.509 certificate:

./sapgenpse export_own_cert -p SAPSNCS.pse

…and save the output certificate details from your terminal to a new file (again see previous section for details on copying and saving the relevant block of text); i called this file exportedlocaldd.cert but of course you can call yours whatever you like. 

Then import this exportedlocaldd.cert to the Certificate List of SNC Cryptolib PSE in STRUST of the target SAP system, just as we did for the other X.509 certificate in the previous section. So now there are two trusted client certificates in STRUST (the new one is the greyed-out CN line inside the Certificate List box:

Now that the client certificate for our subject [email protected] is in the trusted certificate list, so the logon from Linux VM to the relevant SAP system will work by SSO. Before testing the login, it’s a good idea to quit SAPGUI client then reopen it, so that SAPGUI caches the latest version of SAPSNCS.pse from your SECUDIR (and doesn’t e.g. keep any cached details from the previous file that was called SAPSNCS.pse, which we were using in the above section “Using SNC encryption only”).. So yeh, then you reopen the SAPGUI client, and logon to the target SAP system, this should successfully log you on to SAP via SSO (i.e. bypassing the manual logon), and a success message at bottom bar of SAPGUI screen will inform you of this event:

…so that completes our task of getting SSO for SAPGUI working on a Linux client. Time for an ice-cream!