SAP Single Sign-On Insider-Tipp: SSO in Multidomains

Anmerkung: Dieser Blog wurde aus dem Englischen übersetzt, hier geht’s zum Original.

In unserer Blog-Reihe „SAP Single Sign-On Insider Tips“ teilen wir gerne Best Practices mit Ihnen, um Sie bei Ihren SSO-Projekten besser zu unterstützen und Ihnen unnötiges Kopfzerbrechen zu ersparen. In diesem Blog geht es um die Implementierung von SAP Single Sign-On 3.0 mit Kerberos/SPNEGO-Authentifizierung in Active Directory Umgebungen, die aus mehreren Domänen oder Gesamtstrukturen bestehen.

Wir haben bereits viele Projekte in diesem Umfeld durchgeführt, von kleinen bis hin zu mittleren und sehr großen AD-Strukturen, die aus mehreren autonomen Gesamtstrukturen mit Dutzenden von Domänen bestehen. Manchmal ist alleine die Informationsbeschaffung in größeren Landschaften, in denen viele  AD-Domänen oder Forests beteiligt sind, umständlich. Auch gibt es so manche Missverständnisse was korrekte Ansätze und die Vorgehensweise betrifft, um eine Kerberos-Authentifizierung in solchen Umgebungen zu implementieren. Dieser Blog soll Sie dabei unterstützen, die richtigen Entscheidungen für die Architektur der Lösung zu treffen.

Diese Blog-Reihe ist nicht für Neueinsteiger in das Thema gedacht, stellen Sie bitte sicher, dass Sie die Grundprinzipien der Kerberos-Authentifizierung (TGS, KDC, TGT, ST) verstehen und bereits wissen, was Keytabs, Service Accounts und Service Principals sind.

Active Directory Gesamtstrukturen- und Domänen

Ein Active Directory Forest (im Deutschen die Gesamtstruktur) ist der oberste logische Container in einer Active Directory-Konfiguration, der Domänen, Benutzer, Computer und Gruppenrichtlinien enthält. Eine einzelne Domäne bildet auch einen Forest, der später durch zusätzliche Domänen ergänzt werden kann. Unterhalb der so genannten Forest-Root-Domäne (der ersten Domäne in einem neuen AD-Forest) können Sie mehrere untergeordnete Domänen haben, die wiederum ihre eigenen untergeordneten Domänen haben können. Das kann im gleichen durchgängigen Namensraum sein, z. B. COMPANY.INTRA und UK.COMPANY.INTRA, oder in einem eigenen bzw. nicht durchgängigen Namensraum. Somit kann eine größere Struktur aus mehreren Forests etabliert werden, jeder mit seinen Domänen, die mehrere Bäume und Zweige haben, daher wird es auch Forest genannt.

Heute wird in den meisten Fällen eine einzelne AD-Gesamtstruktur bzw. Domänenumgebung als Best Practice betrachtet, also ein Forest, eine Domain, alles Flach. Objekte können mittels OUs (Organisationseinheiten) strukturiert und somit nach dem „Least Privilege-Prinzip“ verschiedenen Verwaltungseinheiten- und Admins zugeordnet werden. In den letzten Jahren wurden viele komplexe AD-Strukturen nach diesem Ansatz vereinfacht und oft erleben wir bei Durchführung von SSO-Projekten, dass gerade ein paralleles Projekt zur Neustrukturierung der Active Directory stattfindet, welches ebenfalls Berücksichtigung finden muss.

Solange alle Domänen zur gleichen Gesamtstruktur gehören, ist gegenseitiges Vertrauen zwischen den Domänen inhärent. Benutzer können daher Ressourcen aus allen Domänen in der Gesamtstruktur verwenden, sofern sie dazu berechtigt sind. Dies wird auch als transitive Vertrauensstellung bezeichnet.

Manchmal kommt es vor, dass eine Organisation entweder aus historischen Gründen, zum Beispiel aufgrund von Firmenübernahmen oder Fusionen, mehrere AD-Forests betreibt. Standardmäßig besteht keine Vertrauensstellung zwischen zwei Gesamtstrukturen. Vertrauensstellungen zwischen Gesamtstrukturen sind dann erforderlich, um Zugriff auf einige Ressourcen der anderen Gesamtstruktur zu erhalten. Es gibt bidirektionale oder unidirektionale Gesamtstruktur- bzw. Domänenvertrauensstellungen. Somit kann man unter Umständen in Projekten, die das Thema Kerberos Authentifizierung adressieren, auch eine Multi-Forest-Umgebung vorfinden und muss nun wissen, wie hier in Bezug auf die Integration von SAP SSO vorzugehen ist. Der technisch beste und einfachste Weg sollte gewählt und dabei auch wichtige Sicherheitsstandards – wie zum Beispiel erzwungene AES256-Verschlüsselung vom KDC – eingehalten werden.

Erster Schritt – Informationsbeschaffung

Wenn Sie im Umfeld IAM und SAP tätig sind, müssen Sie sich normalerweise nicht mit allen Details des Active Directory auskennen. Eines der wichtigsten Dinge ist es, zuerst die Active Directory-Landschaft, dessen Domänen und Gesamtstrukturen sowie deren Vertrauensbeziehungen untereinander zu verstehen.

Anmerkung: Die Domänen- oder Gesamtstrukturfunktionsebene spielt in diesen Projekten meist keine Rolle

Tipp: Beziehen Sie die Experten aus dem Active Directory-Team in Ihr Projekt ein und gewinnen Sie ein genaues Verständnis, bevor Sie mit dem Projekt beginnen. Starten Sie mit einem Workshop, um die erforderlichen Details zu sammeln und architektonische Fehler (z. B. wie die Anlage von Service Accounts in jeder Domäne) zu vermeiden.

Hintergrundinformationen – Beispiel SAP Logon

Jeder Active Directory Domain Controller betreibt den KDC-Dienst (Key Distribution Center) und dient damit als Kerberos-Server. Nach erfolgreicher Anmeldung eines Benutzers an seinem PC erhält dieser vom DC seiner Domäne ein TGT (Ticket Granting Ticket) ausgestellt. Für das SAP-System (z. B. AS ABAP) wird ein Service Konto angelegt. Für dieses Service Konto werden im Active Directory zudem SPNs (Service Principal Names) registriert, auf dessen Basis Kerberos fähige Systeme bzw. Anwendungen ein entsprechendes Service Tickets (ST) anfordern können.

Dieses Service Konto wird auf dem SAP-Backend hinterlegt, das Resultat ist eine Keytab-Datei, die das System zur „Entschlüsselung“ von Service Tickets benötigt. Diese Keytab wird je nach eingesetzter CommonCryptoLib-Version und NetWeaver Release entweder global in der Datenbank oder auf Dateiebene in einer PSE gespeichert. Ein Kerberos Ticket enthält den iUPN (Impliziter UserPrincipalName) der in der Windows-Welt einen Benutzer eindeutig in einem AD-Forest identifiziert und sich aus sAMAccountName@<FQ-Domain-Name> zusammensetzt.

Wenn der Anwender nach erfolgreicher Anmeldung am Windows System nun vom KDC ein TGT erhalten hat, dann versucht der Secure Login Client automatisch – beim Start einer SNC gesicherten SAP Logon Verbindung – mit diesem TGT ein ST für den SPN anzufordern. Darüber weiß der TGS, mit welchem Service Konto er das Ticket verschlüsseln muss und sendet das ST verschlüsselt an den Windows Ticket Cache zurück.

Der Secure Login Client verfügt nun über das Ticket welches er als Credential-Provider der SNC-Bibliothek am Client (CommonCryptoLib) zur Verfügung stellt. Über das DIAG-Protokoll sendet das SAP Logon das ST nun an das SAP-Serversystem. Dieses kann das ST durch die SNC-Konfiguration sowie das vorhandene Keytab entschlüsseln, vertraut somit dem REALM (der Domäne) und kann den Anwender damit eindeutig identifizieren.

SPNEGO-Authentifizierungsablauf in mehreren Domänen einer Gesamtstruktur

Um den Kerberos-Authentifizierungsablauf besser zu veranschaulichen, hier nun ein Beispiel, welches den Vorgang der SPNEGO-Authentifizierung über den Browser verdeutlichen soll. Der Benutzer Max Mustermann in der Domäne SALES.INTRA (eine Child Domäne im Forest COMPANY.INTRA) greift auf das SAP Fiori Launchpad eines Unternehmens zu.

Künftig sollen auch noch Anwender aus verschiedenen anderen Domänen in der gleichen Gesamtstruktur mit SAP Fiori arbeiten. Das Fiori Launchpad wird auf einem SAP NetWeaver AS ABAP betrieben, der für die SPNEGO-Authentifizierung konfiguriert wurde. Für den AS ABAP wurde nur ein Service Account und eine Keytab erstellt, in diesem Fall wurde der Service Account und SPN in der Forest Root-Domäne COMPANY.INTRA erstellt. Das SAP-System vertraut somit durch die Keytab automatisch allen weiteren Domänen in der Gesamtstruktur.

1. Max meldet sich in der Domäne INTRA an seinem Computer an. SALES.INTRA ist eine Child Domäne im Forest COMPANY.INTRA. Ergebnis dieser Authentifizierungsdienst-Anforderung (AS) ist ein TGT: krbtgt/[email protected]
2. Anschließend versucht Max, auf die SSO-fähige SAP-Webanwendung zuzugreifen. Durch die SPNEGO Konfiguration liefert der SAP ICM dem Client Browser ein 401 Unauthorized zurück inkl. dem Header WWW-Authenticate: Negotiate.
3. Max‘ Browser weiß nun, dass der Webserver die Kerberos Authentifizierung unterstützt (SPNEGO) und erstellt einen Ticket Granting Server (TGS)-Request für die aufgerufene URL (SPN) an den KDC in der Domäne INTRA. Da dieser SPN für keine Principals in der Domäne SALES.INTRA registriert ist, sendet der Domänencontroller eine Verweisung an einen globalen Katalog (GC) in der Gesamtstruktur COMPANY.INTRA. Der GC weiß, dass diese TGS-Anforderung für einen Principal in einer anderen vertrauenswürdigen Domäne bestimmt ist, und sendet dem Client eine Verweisung an die übergeordnete Domäne COMPANY.INTRA.
4. Der Client erhält ein TGT für die Parent-Child-Vertrauensstellung zwischen INTRA und SALES.INTRA: krbtgt/[email protected]
5. Sobald Max nun ein TGT für die Domain INTRA hat, sendet er eine TGS-Anfrage an einen KDC in dieser Domain. Der KDC liefert ein ST für den SPN zurück, z. B. HTTP/<URL>
6. Das ST wird vom Browser codiert und über den Authorization-Header an den Webserver übergeben. Durch die SPNEGO-Konfiguration und das Keytab, kann das SAP-System das Service Ticket entschlüsseln und den Anwender automatisch authentifizieren.

Tipp: Befindet sich der Benutzer, der auf die SSO-fähige Ressource zugreift, in einer anderen AD-Gesamtstruktur, wird von der so genannten „Cross-Realm-Authentication“ gesprochen. Damit Clients in einer Gesamtstruktur bei einem Dienst in einer anderen vertrauenswürdigen Gesamtstruktur authentifiziert werden können, müssen sie diese Authentifizierung durchlaufen, bevor sie ein Kerberos Service Ticket in der Remotedomäne anfordern können. Hier würde Schritt 4 anders aussehen, da der Client zuerst ein Ticket Granting Ticket (TGT) in seiner eigenen Domäne erhält (falls nicht bereits vorhanden) und dann bereichsübergreifende TGTs für jede Ziel-Domäne in der Gesamtstruktur. Dies gilt natürlich nur für vertrauenswürdige Gesamtstrukturen. Wenn es keinen Trust zwischen den Forests gibt, müssten Sie einen Service  Account pro Gesamtstruktur erstellen.

Empfehlungen für die Verwendung von SNC in Umgebungen mit mehreren Domänen oder Gesamtstrukturen

• Wenn es mehrere Gesamtstrukturen ohne Vertrauensstellungen gibt, müssen Sie einen Service Account (der Ihren SAP-Anwendungsserver darstellt) und einen oder mehrere SPNs in jeder Gesamtstruktur-Stammdomäne erstellen. Auf diese Weise verfügen Ihre SAP-Systeme möglicherweise über mehrere Keytabs für die verschiedenen Gesamtstrukturen, aber das ist in Ordnung.
• In Szenarien, in denen Sie über eine Gesamtstrukturvertrauensstellung oder eine Gesamtstruktur mit mehreren Domänen (transitive Vertrauensstellungen) verfügen, müssen Sie die Service Accounts und SPNs nur in der Gesamtstruktur-Stammdomäne (oder in einer der Domänen) erzeugen.
• Es empfiehlt sich, den SNC-Namen des SAP Server snc/identity/as wie ein X.509 DN zu definieren, z.B. p:CN=<SID>, O=Firma, C=DE. Die SAP CommonCryptoLib kann die zertifikatbasierte Authentifizierung (z. B. für Server-zu-Server-Kommunikation) und Kerberos parallel verwenden. Je nach Authentifizierungsmethode verwendet der Secure Login Client entweder den vorhandenen X.509 (DN) für die zertifikatbasierte Authentifizierung oder versucht, den CN-Teil einem Service Principal Name zuzuordnen z. B. SAP/<SID> wobei SID dem CN entspricht. Mit anderen Worten, der SAP Secure Login Client 3.0 erstellt den richtigen SPN, fügt die jeweilige Domäne des Benutzers hinzu und fordert beim lokalen KDC ein Ticket für SAP/<SID>@<USERDNSDOMAIN> an. Die Elemente O,  OU, C, usw. werden in diesem Fall vom Secure Login Client nicht weiter berücksichtigt. Weitere Informationen finden Sie im SAP-Hinweis 1696905.
• Wenn mehrere vertrauenswürdige Gesamtstrukturen vorhanden sind, können Sie den Service Account für Ihr SAP-System in der Gesamtstruktur-Stammdomäne Damit Benutzer aus verschiedenen vertrauenswürdigen Gesamtstrukturen ein Service Ticket für Ihr SAP-System in der vertrauenswürdigen Stammdomäne der Gesamtstruktur anfordern können, müssen Sie sicherstellen, dass Sie den Domänennamen dem SNC-Namen im SAP Logon hinzufügen. Beispiel: p:CN=<SID>@<FORESTROOTDOMAIN>
• Wenn Sie Anmeldegruppen verwenden, wird der SNC-Name dynamisch vom Profilparameter snc/identity/as des jeweiligen Anwendungsservers ausgelesen und vom Message Server an das SAP Logon übertragen. Dies kann Auswirkungen auf Ihr Lösungsdesign haben, und Sie sollten sorgfältig prüfen, ob Sie den Domänenteil in diesem Profilparameter benötigen oder nicht.

Wie Sie sehen, ist die Implementierung von SAP Single Sign-On 3.0 basierend auf Kerberos auch in Umgebungen mit mehreren Gesamtstrukturen nicht so schwierig. Natürlich gibt es noch viele andere wichtige Punkte, die bei solchen Projekten berücksichtigt werden müssen. Sie benötigen ein sauberes Namenskonzept für Ihre Active Directory Service Accounts, sichere Kennwörter und Verschlüsselungsalgorithmen sowie die richtigen SPNs. Sie müssen DNS-Auflösung, Reverse-Proxys bzw. NLB sowie die korrekte Systemzeit berücksichtigen. Sie benötigen ein Konzept zur Erstellung und zum Passwortmanagement Ihrer Service Accounts- und Keytabs etc.

Gerne sind wir Ihnen bei Ihrem nächsten Kerberos-basierten SAP Single Sign-On-Projekt behilflich.

Die anderen Artikel dieser Blog-Reihe finden Sie in unserem englischsprachigen Blog:

• SAP Single Sign-On Insider Tips – Volume #5 – EN
• SAP Single Sign-On Insider Tips – Volume #3 – EN   
• SAP Single Sign-On Insider Tips – Volume #2 – EN
• SAP Single Sign-On Insider Tips – Volume #1 – EN

• Über
• Letzte Artikel

Carsten Olt

Managing SAP Security Consultant | SAP Trainer Secure Authentication | SSO | Cloud Security Services bei Xiting GmbH

Carsten Olt has been working as a Managing SAP Security Consultant since 2016, responsible for Secure Authentication & SSO and SAP Cloud Security Services at Xiting in Germany. As a member of the IAM team, he is also a team leader who conveys the company's goals and strategies to employees and has organizational responsibility.

With a security-minded approach, Carsten has international project and IT security experience in many industries. He has been working in IT-Security since 2001, specializing in SAP security since 2010. He is a subject matter expert for SAP Single Sign-On 3.0 and a trainer for the WDESSO course. His current focus is on supporting customers in solving authentication and security challenges within hybrid SAP landscapes, as well as designing and implementing holistic authentication concepts. Carsten is an ISACA CISA and a former MCP and RHCE with an ISP background, and he looks at security from different angles. He also translates between SAP and IT security vocabulary.

Carsten has in-depth experience in multi-vendor architectures and MSFT/Azure components, dealing with all the requirements concerning SAML 2.0, OAuth, OpenID Connect, SCIM, X.509 CBA & PKI, MFA, SAP SSO, and Secure Network Communications, Kerberos/SPNEGO, data security and encryption, as well as digital signatures.

Carsten is experienced in SAP on-premises components such as S/4HANA, ABAP, and Java, as well as security solutions like SSO 3.0. Since 2019, he has focused on SAP-Cloudified environments, specifically the SAP Cloud Identity Services and SAP BTP, as well as SaaS integrations concerning IAM. He deals with hybrid SAP security in conjunction with Azure Active Directory, ADDS, ADFS, ADCS, Reverse Proxies/WAF, SAP Web Dispatcher, SAP Cloud Connector, third-party products, and infrastructure components.

Letzte Artikel von Carsten Olt (Alle anzeigen)

• Cloud-Integration leicht gemacht: Xiting Central Workflows (XCW) trifft auf SAP Cloud - 30. Juli 2024
• Von Wehmut und Vorfreude: Das bevorstehende Ende von SAP IDM - 20. März 2024
• 2024 SAP Cloud Identity Services & IAM Portfolio: Was ist neu? - 26. Februar 2024