On-Premise MFA and SSO Without Writing to Active Directory
On-Premise MFA und SSO ohne Schreiben in Active Directory
Wenn Sie ein On-Premise Active Directory, ein paar hundert interne Anwendungen und ein Sicherheitsteam betreiben, das kein neues Tool in AD schreiben lässt oder das Verzeichnis in eine Anwendungsdatenbank umwandelt, werden die meisten modernen Identitätsplattformen Ihnen höflich erklären, dass sie nicht so funktionieren. Wir hatten diese Unterhaltung kürzlich mit einer europäischen Gruppe von mehreren tausend Benutzern, die ihren Identitätsstapel On-Premise betreibt. Hier ist, wie die Einschränkung tatsächlich gelöst wird und warum sie weitaus weniger exotisch ist, als Anbieter sie darstellen.
Die Anforderung, von der alle versuchen, Sie abzubringen
Die Gruppe hatte bereits ein Zugriffsprodukt. Es bot nur Einmalpasswörter und sonst nichts, war instabil und das Team konnte es nicht ohne externe Hilfe bedienen. Sie wollten raus und hatten eine klare Liste: Single Sign-on für eine große Anwendungslandschaft über SAML und OIDC, ein zweiter Faktor sowohl über TOTP als auch per Push-Nachricht, bedingter Zugriff, Nutzungsberichterstattung mit Export zu ihrem SIEM, ein Portal für Benutzer und die Möglichkeit, externe Auftragnehmer über denselben Identitätsanbieter und nicht über einen separaten Hintereingang einzubinden.
Bisher gewöhnlich. Dann kam der Teil, der entscheidet, welche Anbieter noch im Raum sind.
Die neue Ebene durfte keine Daten in das Active Directory schreiben oder dort eigene Betriebsdaten speichern. Das Active Directory musste für die RCDevs-Ebene weiterhin als maßgebliche Quelle dienen und schreibgeschützt bleiben. Benutzer und Gruppen konnten von AD in OpenLDAP synchronisiert werden, und Passwörter konnten anhand von AD validiert werden, aber das Produktionsverzeichnis selbst sollte nicht zum Speicher-Backend für MFA, SSO, Richtlinien oder Konfigurationen werden.
Dies ist keine eigenwillige Präferenz, und ein gutes Team sollte sich nicht dagegen verteidigen müssen. Jeder zusätzliche Ort, an dem Authentifizierungsdaten verarbeitet werden, muss explizit, kontrolliert und begründet sein. AD als maßgeblich zu erhalten und aus dem Schreibpfad herauszuhalten, ist eine bewusste Kontrollentscheidung. Das Problem ist, dass viele Cloud-First-Identitätsprodukte dieser Einschränkung nicht gerecht werden. Ihr normaler Betriebsmodus besteht darin, Ihr lokales Verzeichnis in einen Anbieter-Cloud-Tenant zu synchronisieren und von dort aus SSO, MFA, Richtlinien, Anmeldestatus, Berichte und manchmal auch die Lebenszyklusverwaltung auszuführen. Einige können AD maßgeblich belassen und das Zurückschreiben vermeiden, aber die Anbieter-Cloud wird dennoch zur operativen Identitätskontrollebene. Für einen Kunden, der AD als schreibgeschützt haben und die operativen MFA/SSO-Daten vor Ort belassen möchte, wird die Architektur, die er durchsetzen möchte, nicht eingehalten. Der Kunde bewertete eines dieser Produkte parallel, was teilweise der Grund dafür war, dass die Anforderung überhaupt auf dem Tisch lag.
Behalten Sie AD autoritativ bei und halten Sie es aus dem Schreibpfad heraus
Der Weg führt über die Trennung zweier Fragen, die Anbieter gerne zusammenführen: wo die Identität maßgeblich ist und was die MFA- und SSO-Schicht zum Funktionieren benötigt.
AD bleibt die maßgebliche Quelle für Benutzer und Gruppen. Die entsprechenden Konten und Gruppenmitgliedschaften werden mit RCDevs OpenLDAP synchronisiert, wo die Identitätsschicht darauf zugreifen kann, ohne dass AD zu einer Anwendungsdatenbank wird. In der Praxis bleibt AD die übergeordnete Quelle der Wahrheit, während OpenLDAP zum operativen Verzeichnis für die MFA- und SSO-Schicht wird.
Beim Anmelden wird das Domänenkennwort durch Abgleich mit dem entsprechenden Konto in AD überprüft. Wenn AD das Kennwort validiert, wird das zuletzt validierte Kennwort im replizierten OpenLDAP-Benutzerobjekt gespeichert. Dies ist eine beabsichtigte Ausfallsicherungsmaßnahme: Sie ermöglicht es der Authentifizierungsschicht, weiterhin zu funktionieren, falls AD später nicht verfügbar ist.
Das macht die Grenze klar. Die Passwortvalidierung kommt weiterhin aus AD, wenn AD verfügbar ist, und das zuletzt validierte Passwort wird zur Kontinuität in der On-Premise OpenLDAP-Schicht gehalten.
Alle weiteren Informationen, die die MFA- und SSO-Ebene benötigt – darunter token-Geheimnisse, Registrierungsstatus, Benutzerrichtlinien, Gruppenrichtlinien, Client-Richtlinien, IdP-Konfiguration und RCDevs-Konfigurationsdaten – befinden sich ebenfalls in OpenLDAP. AD bleibt aus dem Schreibpfad heraus: Es ist nach wie vor die maßgebliche Identitätsquelle, doch die Authentifizierungs- und SSO-Schicht befindet sich nun daneben und nicht mehr darin.
Das ist die ganze Idee, und es ist eine unterstützte Methode, die Suite auszuführen, kein Workaround, den wir improvisiert haben. Eine starke Identitätsschicht muss ihr Verzeichnis nicht besitzen, um es zu schützen.
Ein Identitätsanbieter vor dem Anwesen
Nachdem die Datenfrage geklärt ist, geht es nun um die Integration. Wir haben den Identitätsanbieter, der sowohl SAML als auch OIDC unterstützt, vor der Anwendungslandschaft eingerichtet, sodass sich ein Benutzer einmal authentifiziert und dann auf die Anwendungen zugreifen kann, für die er berechtigt ist. Die VDI- und Fernzugriffs-Gateways wurden als SAML-Dienstanbieter eingebunden. Die zweite Authentifizierungsstufe wurde über TOTP und Push bereitgestellt, unter Verwendung der kostenlosen OpenOTP-Token-App, sodass keine Hardware pro Benutzer gekauft werden musste.
Auch externe Auftragnehmer waren in Active Directory vertreten, sodass sie sich über denselben Identitätsanbieter und mit derselben MFA authentifizieren, anstatt über einen parallelen Mechanismus, der von niemandem überprüft wird. RCDevs schlug ursprünglich vor, die Konten externer Auftragnehmer in OpenLDAP statt in Active Directory zu speichern, um nur interne Konten in Active Directory zu führen. Der Kunde zog es jedoch vor, Auftragnehmerkonten direkt über Active Directory bereitzustellen und zu verwalten, was sowohl verständlich war als auch vollständig unterstützt wurde.
Conditional Access-Richtlinien halten routinemäßige Anmeldungen reibungslos, während ungewöhnliche Anmeldungen herausgefordert werden. Da das Ganze On-Premises läuft, bleiben der Audit-Trail und der SIEM-Export in ihrer eigenen Umgebung. Für eine europäische Gruppe, die ihre Authentifizierungsdaten unter eigenem Dach behalten möchte, ist das der Grund, es so zu machen.
Zudem galt es ein Problem hinsichtlich der Eigenständigkeit zu lösen, da das Team nicht in der Lage war, sein bisheriges Tool eigenständig zu betreiben. Dank der Self-Service-Registrierung für token und delegierten Helpdesk-Rollen laufen die täglichen MFA-Abläufe nicht mehr über einen Anbieter. Sie können Benutzer unterstützen und die Identitätsschicht selbst verwalten, während die AD-Passwortverwaltung außerhalb des Einsatzbereichs bleibt.
Ein Single-Sign-On-Portal für über 200 interne Anwendungen
Eine Anforderung passte zu keinem damaligen Produktblatt. Mit mehr als zweihundert Webanwendungen im Bestand wollte die Gruppe, dass die Benutzer nach der Anmeldung auf einer einzigen Seite landen, die für sie verfügbaren Anwendungen sehen und eine davon mit einem Klick öffnen können. Weniger ein Anmeldebildschirm als vielmehr ein internes Anwendungsverzeichnis, mit Berechtigungen, die von Team zu Team stark variieren.
Diese Anforderung bildete die Grundlage für das heutige „Application Shortcuts Portal“ in RCDevs Identity Provider 1.6.15. Das Portal zeigt dem authentifizierten Benutzer entsprechend seinen Berechtigungen Verknüpfungen zu Anwendungen an. Jede Verknüpfung ist ein Symbol, das den Benutzer zur Anmelde-URL der Anwendung weiterleitet. Die Anwendung leitet den Benutzer dann über SAML oder OpenID Connect zum IdP weiter. Da der Benutzer bereits über eine authentifizierte Sitzung auf dem Portal verfügt, schließt der IdP den SSO-Ablauf ab und leitet den Benutzer als authentifizierte Person zurück zur Anwendung.
Sichtbarkeit und Zugriff folgen der Verzeichnismitgliedschaft von Gruppen, sodass genau bestimmt wird, wer was sieht und öffnet, so wie die Gruppe bereits alles andere regelt.
Das ist die Art von Dingen, die eine anpassungsfähige Plattform von einer geschlossenen trennen. Die Anforderung war angemessen und lag nahe an dem, was die IdP bereits tat, daher war die Erweiterung die richtige Antwort, nicht “das wird nicht unterstützt”.”
Einrichtung von Self-Service-Passwortzurücksetzung gegen ein schreibgeschütztes AD
Früh während des POCs drehte sich die Hauptkomplexität um das Synchronisationsverhalten, die Gruppenzuordnung und die operative Ausfallsicherheit bei Änderungen der Verzeichnisverfügbarkeit. Da der Synchronisationsmechanismus auf Active Directory als autoritative Quelle angewiesen ist, werden Benutzer automatisch in OpenLDAP basierend auf ihrer Anwesenheit und ihrem Status in AD gepflegt. Fragen wie welche AD-Gruppen autoritativ waren, welche Mitarbeiter- und Auftragnehmerekonten synchronisiert werden mussten und wie sich die Plattform verhalten sollte, wenn AD nicht mehr verfügbar war, sind die Arten von operativen Überlegungen, die typischerweise erst in einer echten Produktionsumgebung und nicht in einem Demo-Tenant auftreten.
Operativ wurde die Verwaltung des Kontolebenszyklus letztendlich durch den nativen Synchronisierungsmechanismus selbst abgewickelt. Es war kein benutzerdefiniertes Skripting erforderlich, da der Synchronisierungsprozess automatisch jede Stunde läuft und OpenLDAP mit dem Zustand des Active Directory abgleicht.
Wenn Sie dieselbe Einschränkung haben
Die Fragen, die man jedem Identitätsanbieter stellen sollte, sind kurz, und die Antworten sortieren die on-premise-freundlichen Tools von denen, die zu Ihrem neuen System of Record werden müssen:
- Wo befinden sich meine Benutzerdaten physisch, sobald Ihr Produkt im Einsatz ist?
- Kann mein Active Directory autoritativ und schreibgeschützt bleiben, während Benutzer und Gruppen in ein lokales Verzeichnis synchronisiert werden?
- Schreiben Sie in AD oder speichern Sie die Produktkonfiguration in AD?
- Wie validieren Sie Passwörter, cachen Sie etwas und wo genau werden diese Daten gespeichert?
- Ist diese Lösung vollständig On-Premise?
Wir freuen uns, nach allen fünf gefragt zu werden.
Der Authentifizierungsstack läuft vor Ort: Identitätsdaten, Passwortüberprüfung, MFA-Richtlinien, SSO und Protokolle verbleiben vollständig in Ihrer Umgebung. Die einzige Ausnahme bilden Push-Benachrichtigungen. Wie jeder push-basierte Faktor stützt sich auch OpenOTP Push auf die Benachrichtigungsdienste von Apple und Google, die RCDevs über einen Relay-Server bei cloud.rcdevs.com erreicht. Dieser Relay-Server überträgt lediglich das Push-Signal, nicht jedoch Ihre Identitätsdaten oder Ihre Passwortvalidierung, die Ihre Räumlichkeiten niemals verlassen. Kunden mit strengen Isolationsanforderungen können stattdessen auf TOTP oder Hardware-tokens zurückgreifen, die vollständig offline funktionieren. Bei dieser Bereitstellung entschied sich der Kunde aus Gründen der Bequemlichkeit für Push.
Ja. AD kann weiterhin als zentrale Datenquelle dienen und schreibgeschützt bleiben. Die MFA-Ebene speichert ihre eigenen Daten, wie beispielsweise token-Geheimnisse und -Richtlinien, in einem separaten Verzeichnis, sodass Ihr AD-Schema und Ihre AD-Objekte nicht verändert werden.
In dieser Architektur wird das Domänen-Passwort mittels BIND gegen AD validiert. Nach erfolgreicher Validierung wird das zuletzt validierte Passwort im replizierten OpenLDAP-Benutzerobjekt gespeichert, was eine fortlaufende Authentifizierung ermöglicht, falls AD ausfällt.
Ja. Ein einzelner On-Premise IdP kann einen großen gemischten Bestand über SAML und OIDC darstellen. In diesem Fall waren sowohl interne Benutzer als auch externe Auftragnehmer in AD vertreten, mit OpenLDAP synchronisiert und durch dieselbe MFA- und Zugriffspolicyschicht geschützt.
Der Authentifizierungsstack läuft vor Ort: Identitätsdaten, Passwortüberprüfung, MFA-Richtlinien, SSO und Protokolle verbleiben vollständig in Ihrer Umgebung. Die einzige Ausnahme bilden Push-Benachrichtigungen. Wie jeder push-basierte Faktor stützt sich auch OpenOTP Push auf die Benachrichtigungsdienste von Apple und Google, die RCDevs über einen Relay-Server bei cloud.rcdevs.com erreicht. Dieser Relay-Server überträgt lediglich das Push-Signal, nicht jedoch Ihre Identitätsdaten oder Passwörter, die Ihre Räumlichkeiten niemals verlassen. Teams mit strengen Isolationsanforderungen können stattdessen TOTP oder Hardware-tokens verwenden, die vollständig offline funktionieren.
Ja. RCDevs OpenOTP und WebADM MFA und SSO zu einem lokalen Active Directory hinzufügen, während AD autoritativ und schreibgeschützt bleibt. Das AD-Schema wird nicht geändert, es werden keine Betriebsdaten in AD gespeichert, und die MFA-Schicht läuft auf der eigenen Infrastruktur des Kunden. Domänenkennwörter werden durch Bind gegen AD validiert.
RCDevs ist ein europäischer Anbieter, und OpenOTP kann vollständig vor Ort bereitgestellt werden, wobei alle Identitätsdaten, MFA-Richtlinien, SSO-Funktionen und Protokolle in der Umgebung des Kunden verbleiben. Im Gegensatz zu Cloud-First-IAM-Plattformen, die Identitäten in einen Cloud-Tenant des Anbieters synchronisieren, behält OpenOTP Active Directory als maßgebliche Quelle bei und dupliziert Identitäten niemals außerhalb der Infrastruktur des Kunden.
