SAP Single Sign-On (SSO) – kostenlos

Einleitung

Bei einer SAP-Systemlandschaft kommt früher oder später der Wunsch nach einer Single Sign-On Anmeldung auf, da die Anzahl der Systeme durch eine Zwei- oder Drei-Systemlandschaft signifikant hoch ist.

Zudem erhöht der Einsatz von Single Sign-On die Sicherheit, da der Einsatz von Kennwörtern eingeschränkt werden kann.

Die SAP hat mit SAP Single Sign-On (SAP Produkt Überblick V3) ein kostenpflichtiges Produkt im Angebot. Damit sind in einem Unternehmen sehr komplexe Szenarien wie SSO mittels X.509 Zertifikaten oder Security Assertion Markup Languag (SAML) möglich.

Dies ist aber für viele Unternehmen nicht notwendig, zu aufwendig und zu kostenintensiv. SAP hat ursprünglich einen Secure Network Communication (SNC) Adapter für die ABAP Systeme zur Verfügung gestellt, über dem dann Single Sign-On realisiert werden konnte. Daraus entstand dann mit SAP Single Sign-On 2.0 das erste kostenpflichtige Produkt bei SAP.

Da die zugrundeliegende Technik auf dem Generic Security Service Application Program Interface (GSS-API) und Kerberos (Link) beruht, kann auch die ursprüngliche SAP SSO Lösung mit Einschränkungen, zumindest bei ABAP, eingesetzt werden.

Die Einschränkungen sind:

• keine Secure Network Communication für RFCs
• kein SSO für SAP ABAP WebGui
• kein Support von SAP

Wem diese Einschränkungen nicht hinderlich sind, kann die folgende Anleitung verwenden, um Single Sign-On zu konfigurieren. Wer für Web Anwendungen Single Sign-On einrichten möchte, kann sich meinen Artikel SAP Single Sign-On (SSO) kostenlos mit Zertifikaten anschauen.

Die Anleitung geht vom folgenden Szenario aus: Die Benutzer werden im Unternehmen von einem Windows Active Directory verwaltet. Die Clients der Benutzer sind Windows PC (getestet bis Windows 10) und der SAP Anwendungsserver läuft auf einem Linux Server.

SAP ABAP SSO

SAP Single Sign-On setzt auf das Secure Communication Network (SNC) auf. Damit ist eine verschlüsselte Verbindung von Clients wie derm SAP Logon und dem SAP ABAPServer möglich. SNC bietet die SAP für alle Kunden kostenfrei mittels der sapcryptolib an. Auch wenn man kein Single Sign-On einsetzen möchte, sollte auch innerhalb eines Unternehmensnetzwerks die Verbindungen aus Sicherheitsgründen verschlüsselt betrieben werden.

Als erstes wird aber ein spezieller Benutzer Account mit einem Service Principal Name (SPN) benötigt.

AD Service Account erstellen

Prinzipiell kann man einen Service Principal Name auf einen Benutzer- oder auf einen Hostaccount setzen. Ich empfehle den Benutzeraccount, da dieser mit einer Anwendung mitgehen kann. Das bedeutet, falls eine Anwendung von einem Host auf einen anderen verschoben wird, dann kann der Benutzeraccount einfacher weiterverwendet werden.

Um diesen Benutzer zu erstellen benötigt man Administrationsrechte für die Active Directory.

Der Benutzer sollte dabei gewisse Eigenschaften aktiviert haben:

• der UserPrincipalName muss genauso heißen wie der ServicePrincipalName
• das Kennwort sollte nie ablaufen
• AES sollte aktiviert sein

Für den ServicePrincipalName hat es sich als sinnvoll erwiesen, diesen nach dem Schema SAP/SAPService<SID> zu benennen. In einer Domain darf dabei ein SPN nur einem Benutzer zugewiesen werden.

Benutzeranlage:

Den SPN könnte man jetzt über den Attribut-Editor setzen. Dies funktioniert aber im direkten Zusammenspiel mit Linux nicht. Wenn die Kerberos Konfiguration aus der Anwendung heraus, wie bei SAP Java oder nativ mit der HANA Anwendung, kommt, dann kann der SPN direkt gesetzt werden. Dies erkläre ich weiter unten.

In diesem Fall wird der SPN über das Kommandozeilentool ktpass erstellt.

HINWEIS: Bei einem Computer-Account kann man die AES Unterstützung nicht so einfach sehen. Vor allem bei älteren Accounts besteht auch die „Gefahr“, dass diese kein AES aktiviert haben. Die AES Unterstützung kann über das Tool ADSIEdit und dem Attribut msDS-SupportedEncryptionTypes bearbeitet werden. Der Wert sollte hier auf 24 (dezimal) stehen, dann wird nur AES unterstützt. Weiterführende Informationen sind in den Links im Anhang zu finden.

Kerberos Keytab erstellen

Im folgenden wird dem Windows Benutzer sasap001 (Service Account SAP) der ServicePrincipalName SAP/SAPServiceSID zugewiesen (SID sollte natürlich durch die richtige SAP SID ersetzt werden 😉 ). Gleichzeitig wird eine Datei, die keytab, erstellt, die auf das Zielsystem übertragen werden muss. Diese Datei enthält für den Benutzer sasap001 alle unterstützten kryptografischen Schlüssel.

Für die Ausführung dieses Kommandos werden wieder AD Administrationsrechte benötigt.

SPN einem Benutzer zuweisen und eine keytab erzeugen:

ktpass -mapuser sasap001 -princ SAP/ 
-mapop add -crypto ALL -ptype KRB5_NT_SRV_INST +answer +setupn 
-pass rndpass -out %TEMP%\sasap001.keytab 

Bei dem Kommando ist vor allem der Parameter ptype wichtig. Standardmäßig wird KRB5_NT_PRINCIPAL verwendet. Der funktioniert in diesem Fall aber nicht und ist der Grund warum man den Service Benutzer (nur) für SAP ABAP mit ktpass erstellen sollte.

Als –crypto Parameter wird in diesem Beispiel ALL angegeben. Damit werden alle unterstützten kryptografischen Keys in der Ausgabedatei geschrieben. Auch die unsicheren. Wenn man nur einen dedizierten Eintrag erstellen möchte, kann man diesen auch direkt angeben: {DES-CBC-CRC|DES-CBC-MD5|RC4-HMAC-NT|AES256-SHA1|AES128-SHA1} z. B. -crypto AES256-SHA1. Wenn Sie auf Windows Ebene eine keytab mit dedizierten Einträgen erstellen möchten, können Sie mit dem -in Parameter auch eine keytab angegeben, aus der ein dedizierter Einträg gelesen und verarbeitet wird. Zusätzlich zu den oben aufgeführten Parametern.

Die Warnung, dass pType und account type nicht übereinstimmen, kann ignoriert werden.

Was man beachten sollte, die Key Version Number (kvno) spielt bei AES eine wichtige Rolle. Wurde dieser Parameter bei Windows viele Jahre nicht beachtet, so wird nun bei jeder Kennwortänderung die KVNO hochgezählt und damit ein Keytab Eintrag mit falscher KVNO ungültig.

SPN einem Computerkonto zuweisen und eine keytab erzeugen:

ktpass -mapuser <HOST>$@testlab.local -PRINC SAP/SAPService<SID>@TESTLAB.LOCAL 
-crypto ALL -mapop add -ptype KRB5_NT_SRV_HST +answer 
-out %TEMP%\<HOST>.keytab –pass rndpass

Zur Keytab möchte ich noch folgenden Hinweis vom MIT weitergeben:

The keytab file is an encrypted, local, on-disk copy of the host’s key. The keytab file, … is a potential point-of-entry for a break-in, and if compromised, would allow unrestricted access to its host. The keytab file should be readable only by root, and should exist only on the machine’s local disk. The file should not be part of any backup of the machine, unless access to the backup data is secured as tightly as access to the machine’s root password itself.

https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-install/The-Keytab-File.html

Daher sollte diese Datei, wenn sie auf dem Zielsystem implementiert wurde, auf allen anderen Systemen wo sie temporär gespeichert wurde, gelöscht werden.

Linux – Server Kerberos Konfiguration

Die weitere Konfiguration findet jetzt auf dem Linux SAP-Anwendungsserver statt. Sollten für ein SAP-System mehrere Anwendungsserver existieren, dann muss diese Konfiguration auf allen Anwendungsservern durchgeführt werden. Es wird in diesem Fall die gleiche keytab verwendet.

Damit Kerberos verwendet werden kann und die notwendigen Tools zur Verfügung stehen, müssen unter SLES folgende Pakete installiert werden:

$ sudo zypper in krb5 krb5-client

Die Grundkonfiguration findet dann in der /etc/krb5.conf statt. Die Konfiguration sollte, angepasst an der eigenen Domain, ungefähr wie folgt aussehen:

$ sudo vim /etc/krb.conf
[libdefaults]
    dns_canonicalize_hostname = false
    rdns = false
    dns_lookup = false
    dns_lookup_realm = false
    ignore_acceptor_hostname = true
    default_realm = TESTLAB.LOCAL
    # default_ccache_name = FILE:/tmp/krb5cc_%{uid}
    # Stärkere Verschlüsselung
    default_tkt_enctypes = aes
    default_tgs_enctypes = aes
    allow_weak_crypto = false
 
[domain_realm]
    .testlab.local = adsvr.testlab.local
    testlab.local = adsvr.testlab.local
 
[realms]
TESTLAB.LOCAL = {
    default_domain = testlab.local
    kdc = adsvr.testlab.local
    admin_server = adsvr.testlab.local
}
 
[logging]
    kdc = FILE:/var/log/krb5/krb5kdc.log
    admin_server = FILE:/var/log/krb5/kadmind.log
    default = SYSLOG:NOTICE:DAEMON

Mit dieser Konfiguration sollte bereits ein Ticket eines normalen AD-Benutzers angefordert werden können.

$ kinit <ad-benutzer>@TESTLAB.LOCAL
Password for <ad-benutzer>@TESTLAB.LOCAL:
$ 

Wenn dies funktioniert, dann ist es Ziel, Tickets automatisiert ohne Kennworteingabe zu bekommen. Dafür benötigen wir die zuvor erstellte keytab. Diese kann zum Beipiel mit WinSCP auf den Linux Server transferiert werden.

Der Standardpfad für die keytab ist /etc/krb5.keytab. Sie könnte aber auch unter einem benutzerdefinierten Pfad liegen.

keytab Einträge modifizieren

Wenn die keytab, wie oben beschrieben, mit ktpass … -crypto ALL, erstellt wurde, dann enthält die keytab auch nicht so sichere krypthografische Einträge. Prinzipiell werden die, mit der oben aufgeführten krb.conf, nicht zugelassen. Man kann diese Einträge aber auch entfernen. Damit man die Einträge mit den Eigenschaften sehen kann, klist aufrufen:

$ klist -k krb5.keytab -etK

$ ktutil
rkt krb5.keytab
list
delent 1
delent 1
delent 1
wkt krb5_mod.keytab
q
$

Zum Abschluss die keytab an den richtigen Platz verschieben und absichern.

$ sudo mv krb5_mod.keytab /etc/krb5.keytab
$ sudo chown root:sapsys /etc/krb5.keytab
$ sudo chmod 640 /etc/krb5.keytab

Mit dieser Konfiguration sollte jetzt ein automatisches Ticket erzeugt werden können. Die weitere Konfiguration findet jetzt als <sid>adm statt.

Ein Testticket erstellen und prüfen:

<sid>adm $ /usr/bin/kinit -V -k -t /etc/krb5.keytab SAP/SAPService<SID>@TESTLAB.LOCAL
Using existing cache: :/run/user/1042/krb5cc/tktUJfFjB
Using principal: SAP/
Using keytab: /etc/krb5.keytab
Authenticated to Kerberos v5
<sid>adm $ klist -e
Ticket cache: DIR::/run/user/1042/krb5cc/tktUJfFjB
Default principal: SAP/

Valid starting     Expires            Service principal
08/09/20 18:14:05  08/10/20 04:14:05  krbtgt/
	renew until 08/10/20 18:14:05, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
<sid>adm $

Wenn alles geklappt hat, steht SAP Single Sign-On nichts mehr im Wege. Damit die Tickets regelmäßig erneuert werden, wird ein crontab Eintrag erzeugt.

<sid>adm $ crontab -e
15 0-23/8 * * * /usr/bin/kinit -k -t /etc/krb5.keytab SAP/SAPService<SID>@TESTLAB.LOCAL

Troubleshooting

Wenn man die vorangeganenen Schritte so durchgegangen ist, dann kann man die Fehler relativ gut eingrenzen. Um bei der Ticketerzeugung zusätzliche Informationen zu erhalten, kann

$ KRB5_TRACE=/dev/stderr kinit -k -t /etc/krb5.keytab SAP/SAPService<SID>@TESTLAB.LOCAL

Wichtig ist zudem, dass die Zeitdifferenz zwischem dem AD-Server, dem Linux SAP-Anwendungsserver oder auch dem Client nicht mehr als 5 Minuten beträgt. Dies ist die Standard Zeit von Kerberos, die noch toleriert wird. Das sollte eigentlich kein Problem sein, hat aber immer wieder mal bei falsch konfigurierter Zeitservern zu Fehlern geführt.

SAP Anwendungsserver konfigurieren

Die Konfiguration für SAP Single Sign-On wird im Anwendungsserver über verschiedene Parameter gesteuert. Die Parameter können im DEFAULT.PFL hinterlegt werden. Eine Minimalkonfiguration könnte wie folgt aussehen:

snc/accept_insecure_gui             1
snc/accept_insecure_r3int           1
snc/accept_insecure_cpic            1
snc/accept_insecure_rfc             1
snc/extid_login_diag                1
snc/permit_insecure_start           1
snc/identity/as                     p:SAP/SAPService<SID>@TESTLAB.LOCAL
snc/gssapi_lib                      /usr/lib64/libgssapi_krb5.so
snc/enable                          1

Die Konfiguration wird nach einem Neustart des SAP-Systems aktiv. Sollte der dev_disp Prozess nicht starten, sollte ein dev_w<n> Workprozess auf SNC-Fehler geprüft werden. Im Zweifel den Parameter snc/enable wieder auf 0 stellen und das System neu starten.

Windows Client-PC konfigurieren

Zum Abschluss noch den Client konfigurieren. Dazu muss der Hinweis 2115486 freigeschaltet und dann die Dateien win32sso.zip bzw. win64sso.zip heruntergeladen werden. In denen ist die aktuellste Version enthalten. In der Regel reicht die 32bit Version.

Diese Dateien müssen anschließend nach C:\windows\SYSWOW64 kopiert und Systemvariablen gesetzt werden.

c:\setx SNC_LIB C:\windows\SYSWOW64\gsskrb5.dll

Als letzter Schritt muss noch der SAP Logon konfiguriert werden. Je nachdem wie man die Systeme anspricht, per Message Server oder die Dialoginstanz direkt, wird der SNC Name beim Message Server direkt vom System gezogen. Bei der Dialoginstanz muss er manuell eingetragen werden.

SAP Logon konfigurieren

Den SNC-Name hier so angeben wie im Parameter snc/identity/as angegeben. Hier kann, muss aber nicht, noch der Domainname in Großbuchstaben mitgegeben werden, SAP/.

Die verschlüsselte Kommunikation bekommt man auch mit SAP Standardmitteln kostenfrei hin. Der letzte Schritt ist die SAP Benutzerkonfiguration um SAP Single Sign-On abzuschließen.

Als SNC-Name wird der Windows Anmeldename mit dem Prefix p: angegeben. Es reicht den Anmeldenamen zu hinterlegen, es ist aber auch möglich die Domain mit anzugeben – p: – diese muss dann in Großbuchstaben angegeben werden.

Jetzt muss man noch entscheiden ob der Benutzer ein reiner Single Sign-On Benutzer wird und das Kennwort deaktiviert werden soll.

Ist das alles erledigt, steht dem Single Sign-On Zugriff nichts mehr im Wege. ist der Windows Benutzer in verschiedenen oder im gleichen Mandanten mehreren SAP Benutzern zugeordnet, erscheint beim Anmelden eine Auswahlliste für Mandant und SAP Benutzer. Anderenfalls wird die Anmeldung direkt durchgeführt.

Benutzer die sich weiterhin per Kennwort anmelden wollen, können dies weiterhin über das Kontextmenü des SAP Logon.

Wie bereits erwähnt, ein Wermutstropfen ist die fehlende RFC Verschlüsselung. Mit dem setzen des Parameters snc/gssapi_lib kann die SNC SAPCryptolib für RFC Verbindungen nicht mehr erzeugt werden.

Ein weiteres Manko dieser Lösung ist die fehlende Unterstützung für die Web-Services, z. B. die WebGui. Hier kann man aber gegebenenfalls eine Lösung über SAML und einem zentralen Identity Provider herstellen bzw. die Lösung in meinen Artikel SAP Single Sign-On (SSO) kostenlos mit Zertifikaten einrichten. Damit ist dann z. B. auch SAP Java Systeme mit SSO einzurichten.

-----------------------------------------------

Weiterführende Links

SAP Explanatory Notes on the Usage of GSS API Version 2 for SNC: https://ftp.gwdg.de/pub/misc/sapdb/icc/bc-snc40/SAP_Explanatory_Notes_on_the_Usage_of_GSS_API_Version_2_for_Secure_Network_Communications.pdf

SAP Note: 2115486 – GSSKRB5.DLL & GSSNTLM.DLL Download

SAP Note: 2025528 – (Limited Support for) more than one concurrent SNC_LIB

SAP Note: 1898778 – How to mass update the SNC Name/Canonical Name of a user

SAP Note: 2721210 – SAP SSO 3.0 through Active Directory and Kerberos when AD usernames differ from SAP user IDs

Microsoft Dokumentation ktpass: https://docs.microsoft.com/de-de/windows-server/administration/windows-commands/ktpass

Microsoft Dokumentation Service Principal Name: https://docs.microsoft.com/en-us/windows/win32/ad/service-principal-names

Decrypting the Selection of Supported Kerberos Encryption Types: https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/decrypting-the-selection-of-supported-kerberos-encryption-types/ba-p/1628797

msDS-SupportedEncryptionTypes – Computer accounts: https://docs.microsoft.com/de-de/archive/blogs/openspecification/msds-supportedencryptiontypes-episode-1-computer-accounts

Active Directory: Using Kerberos Keytabs to integrate non-Windows systems: https://social.technet.microsoft.com/wiki/contents/articles/36470.active-directory-using-kerberos-keytabs-to-integrate-non-windows-systems.aspx