Identitäts- und Verzeichnisintegration: wo Entra ID, LDAP und SSO anfangen und aufhören

Das leiseste Scheitern eines Intranets steckt in seiner Benutzerliste. Zum Start wird eine Tabelle aus der Personalabteilung importiert, einen Monat lang sind alle zufrieden; ein halbes Jahr später stehen drei längst ausgeschiedene Personen darin, fünf neue fehlen, und niemand traut dem Organigramm mehr. Das ist kein Inhaltsproblem, sondern ein Problem der Datenquelle: die Wahrheit über den Personalstand lebt in einem anderen System.

Die Anbindung an das Unternehmensverzeichnis löst das. Doch „Verzeichnisintegration" ist nicht eine Sache, sondern zwei regelmäßig verwechselte Aufgaben.

SSO authentifiziert, das Verzeichnis liefert

Diese Linie früh zu ziehen erleichtert jede spätere Entscheidung.

SSO (SAML oder OIDC) ist eine Aufgabe der Authentifizierung. Menschen melden sich mit dem Firmenkonto an, führen kein eigenes Intranet-Passwort und verlieren den Zugang in dem Moment, in dem dieses Firmenkonto geschlossen wird. Die Frage, die SSO beantwortet, lautet: „Ist diese Person wirklich die, die sie zu sein behauptet?"

Verzeichnisabgleich ist eine Aufgabe der Datenversorgung. Er liest, wer beschäftigt ist, in welcher Abteilung, mit welcher Funktionsbezeichnung, und schreibt das in die Intranetprofile. Seine Frage ist eine andere: „Wer gehört heute zum Personalstand?"

Keines ersetzt das andere. Führt man nur SSO ein, wird die Anmeldung besser, während das Verzeichnis weiter veraltet — denn wer sich nie angemeldet hat, erscheint überhaupt nicht. Führt man nur den Abgleich ein, bleibt das Verzeichnis aktuell, während alle weiterhin ein separates Passwort tragen. Reife Installationen betreiben beides.

Die Entra-ID-Seite

Auf der Seite von Microsoft Entra ID (früher Azure AD) beginnt die Einrichtung mit einer App-Registrierung. Das Intranet verbindet sich über diese Registrierung mit eigener Identität; niemandes persönliches Konto wird verwendet.

Drei Werte werden gebraucht: die Verzeichnis-(Mandanten-)ID, die Anwendungs-(Client-)ID und ein Clientgeheimnis. Dazu eine Berechtigung: um den Personalstand zu lesen, erhält die Anwendung User.Read.All, und diese Erteilung durchläuft die Administratorzustimmung. Wird dieser Schritt vergessen, holt der Verbindungstest zwar ein Token, die Benutzerliste kommt aber leer zurück — deshalb sollte ein tauglicher Test nicht beim Token stehen bleiben, sondern den Benutzerendpunkt tatsächlich abfragen.

Zu beachten ist außerdem, dass das Clientgeheimnis abläuft. Dann bricht die Integration stillschweigend ab; eine Kalendererinnerung ist billiger, als ein halbes Jahr später zu suchen, warum die Synchronisierung stehen blieb.

Die LDAP-/Active-Directory-Seite

Existiert ein klassisches Active Directory im Haus, läuft die Verbindung über LDAP. Hier wird anderes gebraucht: die Serveradresse, ein Konto mit Leserechten (Bind-DN) und der Punkt, an dem die Suche beginnt (Base-DN).

Zwei Details entscheiden die meisten Einführungen. Erstens die verschlüsselte Verbindung: ohne LDAPS oder StartTLS wandern Unternehmensanmeldedaten im Klartext durchs Netz. Zweitens das Aussortieren deaktivierter Konten: im Active Directory werden Datensätze ausgeschiedener Beschäftigter meist nicht gelöscht, sondern deaktiviert. Dieser Zustand steckt als Bit im Attribut userAccountControl; fehlt er im Filter, fließen alle Ausgeschiedenen als „aktive Beschäftigte" ins Intranet — womit genau das Problem reproduziert wird, das man lösen wollte, nur diesmal automatisch.

Erst anzeigen, dann übernehmen

Das am meisten gefürchtete Szenario bei Verzeichnisintegrationen ist eine Fehlkonfiguration, die den Personalstand im Ganzen beschädigt. Die Antwort darauf ist eine einfache Disziplin: die Abweichung wird zuerst gezeigt, die Übernahme braucht eine eigene Freigabe.

Praktisch sieht der Ablauf so aus: der Verbindungstest besteht, das System vergleicht die Verzeichnisdatensätze mit den Intranetprofilen und erzeugt eine Differenzliste — wie viele zugeordnet wurden, wessen Abteilung sich geändert hat, wer nicht mehr im Verzeichnis steht. Eine Administratorin liest diese Liste und übernimmt sie dann.

Auch die Grenzen gehören von Anfang an gekannt. In Wepilot legt der Verzeichnisabgleich weder Konten noch Abteilungen an; er aktualisiert vorhandene Profile. Der Grund ist Vorsicht: Hunderte wegen eines falschen Filters angelegte Konten sind weit schwerer rückgängig zu machen als Profilfelder, die derselbe Fehler geschrieben hat. Ein vollautomatischer Kontolebenszyklus — Joiner-Mover-Leaver über SCIM — ist ein eigenes Thema und liegt außerhalb dieser Integration.

Wo liegen die Geheimnisse?

Was diese Integration trägt, ist keine gewöhnliche Einstellung, sondern Zugriff auf Ihr Verzeichnis. Clientgeheimnis und LDAP-Passwort dürfen den Browser nie erreichen.

Das richtige Muster ist, diese Datensätze in einer Tabelle ganz ohne Leserichtlinie zu halten und an die Verwaltungsoberfläche nur zurückzugeben, ob ein Geheimnis hinterlegt ist oder nicht. Eine Administratorin kann das Feld füllen, aber nicht zurücklesen, was sie zuvor geschrieben hat. Das unterscheidet sich davon, ein Feld in der Oberfläche auszublenden: die Beschränkung sitzt auf Datenbankebene, und keine Anfrage aus einem Browser kommt daran vorbei. Weitere Stellen mit demselben Prinzip haben wir im Datenschutzartikel beschrieben.

Womit anfangen?

Unsere Reihenfolge ist eindeutig: zuerst den Verzeichnisabgleich einrichten, dann zu SSO übergehen. Der Grund ist praktisch — ein korrektes Verzeichnis erzeugt vom ersten Tag an einen sichtbaren Nutzen, während SSO Abstimmung mit dem Identitätsteam und ein Testfenster verlangt.

Messbar ist es ebenfalls leicht: die Zahl nicht zugeordneter Datensätze, die Zahl der Personen im Verzeichnis ohne Intranetprofil und die Zeit seit der letzten erfolgreichen Synchronisierung. Bewegen sich diese drei nicht gegen null, ist die Integration installiert, wird aber nicht betrieben. Diese Art von Prozessverantwortung behandeln wir im Betriebsartikel.