Vorher und nachher: Wie eine französische Kommunalverwaltung MFA und SSO für alle Zugriffspfade einführte, ohne ihr lokales Active Directory zu verlassen
Vorher und nachher: Wie eine französische Gebietskörperschaft MFA und SSO für jeden Zugriffspfad eingeführt hat, ohne ihr lokales Active Directory zu verlassen
Eine französische Kommunalverwaltung betreibt ihre Identitätsinfrastruktur so, wie es sehr viele öffentliche Einrichtungen tun: mit einem lokalen Active Directory als Kern und mehr als tausend Mitarbeitern, die sich darüber authentifizieren. Die darauf aufbauenden Systeme waren jedoch zunehmend fragmentiert. Ein MFA-Overlay eines Drittanbieters schützte weniger als hundert Konten. Die für den Fernzugriff verwendete SSL-VPN-Appliance wurde mit dem herstellereigenen mobilen token ausgeliefert, das ausschließlich für das VPN und für nichts anderes genutzt werden konnte. Ein SSO-Projekt stand kurz davor, einen weiteren Stack hinzuzufügen, wobei Keycloak als Identitätsanbieter in die engere Wahl gekommen war. Und alles andere – Windows-Sitzungen, macOS-Sitzungen, das Intranet, die IT-Service-Management-Plattform – wurde allein durch das AD-Passwort geschützt.
Der Umdenkprozess setzte ein, als das Unternehmen den Umbau seiner Infrastruktur analysierte. Anstatt jedes Silo einzeln zu erweitern, suchte es nach einer einzigen lokalen Plattform, die MFA und SSO gemeinsam auf jedem Zugriffspfad unterstützen konnte, wobei Active Directory genau dort verbleiben sollte, wo es war. Genau das haben wir gemeinsam mit den Teams des Unternehmens im Rahmen des Proof-of-Concept konfiguriert – auf Basis von OpenOTP, dem RCDevs-Authentifizierungsserver, und WebADM, der zentralen IAM-Konsole, die alle Dienste der Suite steuert und verwaltet. Der Artikel schließt mit einem Vorher-Nachher-Vergleich, der den Anstoß für diese Umstellung gab.
Warum MFA-Overlays pro Konto und token-Appliances nicht skalierbar sind
Eine MFA-Ergänzung, die pro geschütztem Konto berechnet wird, ist sinnvoll, wenn das Ziel eine Handvoll privilegierter Benutzer ist. Sie macht keinen Sinn mehr, sobald das Ziel MFA überall ist. Die Zahlen, die das Unternehmen mit uns teilte, machten den Punkt von allein deutlich: Eine fünfstellige jährliche Gebühr deckte weniger als hundert Konten ab, und bei diesen Kosten pro Konto war es nie eine realistische Option, die gleiche Abdeckung auf die gesamte Belegschaft auszuweiten. Die Wirtschaftlichkeit von pro-Konto-Ergänzungen bricht genau dann zusammen, wenn man sich entscheidet, dass jeder Benutzer, nicht nur die privilegierte Minderheit, einen zweiten Faktor verdient.
Das Gerät token wies dasselbe Problem in einer anderen Form auf. Ein in ein Netzwerkgerät integrierter zweiter Faktor löst genau einen Sicherheitsbereich: die Authentifizierung auf diesem Gerät. Jedes weitere System benötigt dann seinen eigenen Authentifikator, sein eigenes Registrierungsverfahren und seinen eigenen Support-Pfad, wenn ein Benutzer das Telefon wechselt. Richtlinien können nicht einheitlich angewendet werden, da es keinen zentralen Ort gibt, an dem sie gespeichert sind, und die Sperrung muss bei Ausscheiden eines Mitarbeiters Silo für Silo wiederholt werden. Das Unternehmen wünschte sich eine einzige Richtlinien-Engine für all diese Aufgaben.
Die Konsolidierung kehrte auch die Kostenkalkulation um. Verglichen mit dem pro Konto berechneten Satz, den das Unternehmen für seine vorherige MFA-Überlagerung bezahlt hatte, halbiert der pro Benutzer berechnete Satz von OpenOTP in diesem Projekt die Kosten eines geschützten Benutzers um den Faktor fünf bis zehn. Die Sicherung jedes Zugriffspfads war in diesem Fall nicht mit einem Aufpreis verbunden: Sie war ein Bruchteil dessen, was der Schutz einer kleinen Teilmenge von Konten pro Kopf gekostet hat.
SSO mit Keycloak, oder in dieselbe Plattform integriert wie die MFA?
Die SSO-Frage verdiente eine eigene Entscheidung. Keycloak, der Open-Source-Identitätsanbieter, den die Organisation in die engere Wahl gezogen hatte, ist eine legitime und weit verbreitete Wahl. Aber lizenzkostenfrei ist nicht kostenlos im Betrieb: Es ist ein weiterer Stack, der neben dem, was MFA handhabt, bereitgestellt, aktualisiert, gehärtet und betrieben werden muss, mit zwei zugehörigen Konfigurationen, die konsistent gehalten werden müssen.
Da WebADM bereits Föderationsdienste unterstützt, die SAML2, OpenID Connect und OAuth umfassen, entschied sich die Organisation, SSO in dieselbe Plattform wie MFA zu integrieren. Die Begründung, wie sie es formulierten, war schlichtweg weniger Verwaltungsaufwand: Eine einzige Richtlinien-Engine entscheidet nun sowohl, was ein Benutzer zur Authentifizierung vorlegen muss, als auch für welche Anwendungen diese Sitzung gültig ist.
Zwei-Faktor-Authentifizierung (MFA) für Windows- und macOS-Anmeldungen in einer Active Directory-Domäne hinzufügen
Arbeitsplatzanmeldungen waren die erste Peripherie des Proof of Concept. Auf dem Windows-Fleet fügt der OpenOTP Credential Provider den zweiten Faktor direkt in die Windows-Anmeldung ein: Der Benutzer gibt wie gewohnt die AD-Anmeldeinformationen ein und bestätigt dann eine Push-Benachrichtigung in der OpenOTP-Token-App. OpenOTP verarbeitet beide Faktoren: es validiert das Passwort und wendet den zweiten Faktor gemäß den definierten Richtlinien an. Active Directory bleibt die Single Source of Truth: Das Passwort wird beim Anmelden gegen das AD validiert.
Die Organisation verfügt auch über macOS-Maschinen in derselben Domäne, was im öffentlichen Sektor seltener vorkommt und jede Lösung ausschließt, die nur für Windows-Endpunkte konzipiert ist. Der OpenOTP Credential Provider für macOS bringt diese Sitzungen unter dieselbe Richtlinie: dieselbe Push-Bestätigung, derselbe Server, dieselbe Konsole. Für die Administratoren werden die Anmeldungen von macOS und Windows von demselben Ort aus konfiguriert und durchgesetzt, anstatt über zwei separate Werkzeuge.
SAML Single Sign-On für das Intranet: GLPI, WordPress und Anwendungen hinter einem Reverse Proxy
Der Web-Perimeter war als Nächstes dran. Die Intranet-Anwendungen der Organisation waren über SAML mit dem Identitätsanbieter der Plattform verbunden, sodass die Authentifizierung einmal am IdP erfolgt, wobei die MFA dort erzwungen wird, anstatt in jeder Anwendung repliziert zu werden.
Zwei dieser Anwendungen sind nennenswert, da so viele Organisationen sie nutzen. GLPI, die Open-Source-IT-Service-Management-Plattform, die zur Orchestrierung von Tickets und Anfragen über IT-Teams hinweg eingesetzt wird, wurde über SAML integriert; sowohl SAML als auch OpenID Connect wurden während der Sitzungen getestet, bevor der SAML-Weg beibehalten wurde. Die WordPress-Seiten des Intranets wurden auf die gleiche Weise angebunden. In beiden Fällen delegiert die Anwendung die Authentifizierung vollständig: Der Benutzer landet auf der IdP-Seite, authentifiziert sich mit dem AD-Passwort und der Push-Bestätigung und kehrt dann angemeldet zur Anwendung zurück.
Ein Teil der Webpräsenz der Organisation befindet sich hinter einem F5 Reverse Proxy, der von ihrem Infrastrukturpartner betrieben wird, und der Authentifizierungsfluss wurde ebenfalls so konfiguriert, dass er über diese Schicht läuft. Der Punkt für einen Leser mit einer ähnlichen Konfiguration ist, dass ein Reverse Proxy vor den Anwendungen kein Hindernis für die Zentralisierung der Authentifizierung dahinter darstellt.
MFA auf dem bestehenden SSL-VPN, ohne den Austausch des Geräts
Fernzugriff war der einzige Weg, der bereits über eine zweite Faktor verfügte, und er war auch die deutlichste Veranschaulichung des Silo-Problems. Die ordnungsgemäße Absicherung bedeutete nicht den Austausch des Geräts: OpenOTP verbindet sich über Standardprotokolle mit SSL-VPN-Gateways, sodass das bestehende VPN der Organisation auf denselben Authentifizierungsserver verwies, der jetzt die Workstations und das Intranet schützt.
Für die Nutzer bedeutet dies in der Praxis, dass sie nur noch eine statt zwei Apps benötigen. Der Anbieter token, der bisher ausschließlich für das VPN zuständig war, wird nicht mehr benötigt: Dieselbe OpenOTP-Token-App, die die Windows-Anmeldung bestätigt, bestätigt auch die VPN-Verbindung. Für das IT-Team werden VPN-Authentifizierungsereignisse in denselben Protokollen erfasst und unterliegen denselben Richtlinien wie alle anderen Vorgänge auch.
Präsenzbasierter logischer Zugriff: Konten, die sich sperren, wenn niemand da ist
Der Proof of Concept umfasste auch eine Ebene, die über das klassische MFA hinausgeht. Anwesenheitsbasierter logischer Zugriff hält das AD-Konto auf LDAP-Ebene jederzeit gesperrt, es sei denn, der autorisierte Mitarbeiter hat sich von einem genehmigten Standort mit der OpenOTP Token App angemeldet oder gebatched. Der Zugriff wird um Mitternacht automatisch wieder gesperrt, auch wenn der Benutzer vergessen hat, sich abzumelden. In der Praxis verhält sie sich wie ein dritter Faktor: nicht etwas, das der Benutzer weiß oder hat, sondern wo sich der Benutzer nachweislich befindet.
Für eine Behörde ist der Einspruch einfach. Ein auf Verzeichnisebene gesperrtes Konto außerhalb der Geschäftszeiten ist ein Konto, das um 3 Uhr morgens von einem anderen Kontinent aus nicht genutzt werden kann, ganz gleich, welche Anmeldedaten der Angreifer besitzt. Die bedingte Zugriffsgenehmigung, bei der ein ungewöhnlicher Verbindungsversuch eine menschliche Überprüfung erfordert, bevor der Zugriff gewährt wird, war Teil des gleichen Bewertungsbereichs.
Zugriffssicherheit davor und danach, pro Eintrittspunkt
Die Schicht lässt sich am besten nebeneinander lesen.
Vorher / Nachher
Konsolidierter Zugriffssicherheit im gesamten Unternehmen
MFA ist jetzt über jeden Zugriffsweg aktiv: eine Plattform für Mitarbeiterzugriff, Fernzugriff und Web-SSO.
| Zugriffspfad | Bevor | Nach MFA durchgehend aktiv |
|---|---|---|
| Windows-Sitzung | AD-Passwort | AD-Passwort + Push-Bestätigung |
| macOS-Sitzung | AD-Passwort | AD-Passwort + Push-Bestätigung |
| SSL-VPN (Remote-Zugriff) | AD-Passwort + Anbieter token, nur für das VPN verwendbar | AD-Passwort + zweiter Faktor vom zentralen Authentifizierungsserver |
| Intranet-Anwendungen (GLPI, WordPress, SAML-Apps) | AD-Passwort, pro Anwendung eingegeben | SAML SSO mit MFA, erzwungen beim Identitätsanbieter |
| Web-SSO | Geplant als separates Keycloak-Deployment | Integriert in dieselbe Plattform (SAML2, OpenID Connect, OAuth) |
| MFA-Abdeckung und -Verwaltung | Ein Overlay pro Konto bei weniger als hundert Konten, ein VPN token, keine zentrale Übersicht | Ein Server, eine Konsole, eine mobile App für die gesamte Belegschaft |
Organisationen gewinnen über den zweiten Faktor hinaus
Weniger zu bedienen, weniger zu bezahlen:
eine Konsole, eine mobile App, einheitliche Richtlinien für jeden Zugriffspfad.
| Leistungen | Bevor | Nach WebADM aktiv |
|---|---|---|
| Verwaltung | Eine Konsole pro Lösung, tokens und Richtlinien werden separat in jedem Silo verwaltet | Eine zentrale Konsole für Benutzer, Gruppen, Zugriffsrichtlinien, tokens und Integrationen in WebADM |
| Mobiler Authentifikator | Ein Anbieter token, der ausschließlich für das VPN genutzt werden kann | Eine App, der OpenOTP Token, für Windows, macOS, VPN- und Web-Anmeldungen |
| Widerruf | Das Deaktivieren des AD-Kontos hat den Verzeichnisszugriff unterbrochen, aber jeder einzelne zweite Faktor musste separat bereinigt werden. | Konten und Zweitfaktoren gemeinsam von einer Konsole aus über jeden Zugriffspfad widerrufen |
| Protokolle und Richtlinien | Authentifizierungsereignisse, die über Systeme verteilt sind | Jeder Zugriffspfad in denselben Protokollen, unter denselben Richtlinien |
| Ungewöhnliche Verbindungen | Wie jeder andere Login behandelt | Zugriffsberechtigungen für bedingten Zugriff können eine menschliche Validierung erfordern, bevor der Zugriff gewährt wird |
| Angriffsfläche | Konten, die rund um die Uhr mit gültigen Anmeldeinformationen nutzbar sind | Konten auf Verzeichnisebene gesperrt außerhalb der autorisierten Anwesenheit |
| Kosten pro geschütztem Benutzer | Eine Kontoführungsgebühr für weniger als hundert Konten | Fünf- bis zehnmal niedriger, die gesamte Belegschaft umfassend |
Was sich geändert hat, ist nicht nur, dass nun auf jedem Pfad ein zweiter Faktor vorhanden ist. Vielmehr sind Registrierung, Richtlinien und Sperrung nun an einem Ort zusammengefasst: Die Deaktivierung eines Benutzers oder eines token in WebADM wirkt sich sofort auf jeden Zugriffspfad aus, da jeder Pfad die Authentifizierung über denselben Server durchführt – während bei der bisherigen Konfiguration die einzelnen Silos jeweils separat bereinigt werden mussten. Die nächste Anwendung, die die Organisation anbindet – egal welches Protokoll sie verwendet –, erhält denselben Schutz, anstatt ein neues Silo zu schaffen. Das Gleiche gilt für die nächste Zielgruppe: Die von der Organisation betriebenen Schulen stellen eine mögliche spätere Erweiterung auf derselben Plattform dar. Active Directory wurde weder migriert, noch in eine Anbieter-Cloud dupliziert oder umstrukturiert: Es bleibt die „Quelle der Wahrheit“, die es schon immer war, und der gesamte Authentifizierungsstack läuft vor Ort, innerhalb des eigenen Perimeters der Organisation.
Weiterführende Literatur
- MFA bei Windows-Anmeldung & RDS
- Anmeldeinformationsanbieter für die macOS-Anmeldung
- SSO mit dem OpenID & SAML Identity Provider
- Presence-based Logical Access
- Vergleichen Sie OpenOTP mit Cloud-IAM- und MFA-Lösungen
Der OpenOTP Credential Provider fügt einen zweiten Faktor, wie z. B. eine Push-Benachrichtigung, direkt in den Windows- und macOS-Anmeldevorgang ein, während das Passwort selbst weiterhin gegen Active Directory validiert wird. In diesem Projekt wurden beide Flotten unter die gleiche Authentifizierungsrichtlinie gebracht, die von einer Konsole aus verwaltet wird.
Die bestehende VPN-Appliance bleibt weiterhin im Einsatz: OpenOTP stellt über Standardprotokolle eine Verbindung zu SSL-VPN-Gateways her. In diesem Projekt wurde das VPN der Organisation auf denselben zentralen Authentifizierungsserver ausgerichtet wie die Arbeitsstationen und Webanwendungen, wodurch das herstellereigene token außer Betrieb genommen wurde.
Eine bestehende Keycloak-Bereitstellung kann weiterhin die damit integrierten Anwendungen bedienen und die Authentifizierung selbst an OpenOTP delegieren, das das Passwort validiert und den zweiten Faktor hinter Keycloak erzwingt. Die andere Option ist die Migration zum integrierten Identitätsanbieter von WebADM: Dies hat die Organisation gewählt, da ihre Keycloak-Bereitstellung noch nicht begonnen hatte und ein Stack einfacher zu betreiben war als zwei.
Eine pro-Konto-Überlagerung, die für eine kleine Anzahl privilegierter Konten bepreist ist, wird schwer zu rechtfertigen, wenn das Ziel die MFA für jeden Benutzer auf jedem Zugriffspfad ist. In diesem Projekt machte die Gebühr, die die Organisation für weniger als hundert geschützte Konten meldete, die Ausweitung dieser Abdeckung auf mehr als tausend Mitarbeiter unrealistisch, was die Konsolidierung von MFA und SSO auf einer einzigen Plattform motivierte, zu einem pro-Benutzer-Satz, der fünf- bis zehnmal niedriger ist als der pro-Konto-Satz, der für die vorherige Überlagerung gemeldet wurde.
Anwesenheitsbasierter logischer Zugriff hält das AD-Konto auf LDAP-Ebene gesperrt, es sei denn, der autorisierte Mitarbeiter hat sich von einem zugelassenen Standort mit der OpenOTP Token App angemeldet, mit einer automatischen erneuten Sperrung um Mitternacht. Es fungiert als dritter Faktor basierend auf dem nachweislichen Standort des Benutzers.
Das Active Directory bleibt die einzige Quelle der Wahrheit: OpenOTP validiert das Passwort beim Login gegen das AD. Das Verzeichnis wurde in diesem Projekt nicht in eine Vendor Cloud migriert, umstrukturiert oder dupliziert, und der gesamte Authentifizierungs-Stack läuft On-Premise.
