Microsoft SSO einrichten: Schritt-für-Schritt-Anleitung für Entra ID

Freitag, 14:30 Uhr. Das Ticket lautet „SSO für die Analytics-Plattform aktivieren“, der Fachbereich wartet seit zwei Wochen, und Sie öffnen das Entra-Admin-Center mit der Erwartung, in einer Stunde fertig zu sein. Vierzig Minuten später steht der erste Testbenutzer vor einer weißen Seite mit dem Code AADSTS50011 – und niemand weiß, ob der Fehler auf Ihrer Seite oder beim Anbieter liegt. Wer Microsoft SSO einrichten will, scheitert selten an der Technik, sondern an fehlender Vorbereitung und an einem Testplan, der nur den Happy Path abdeckt. Diese Anleitung geht den Weg einmal vollständig durch: von den Werten, die Sie vor dem ersten Klick brauchen, über die Konfiguration in Microsoft Entra ID bis zu den Fehlern, die in der Praxis am häufigsten auftreten.

Die Grundsatzfragen – SAML oder OIDC, was in den Vertrag gehört, welche Rolle SCIM spielt – behandelt unsere Ausschreibungs-Checkliste für Office 365 SSO. Hier geht es ausschließlich um die Umsetzung.

Vorbereitung: fünf Werte, die vor dem ersten Klick feststehen müssen

Die meisten fehlgeschlagenen Ersteinrichtungen lassen sich auf einen Wert zurückführen, der während der Konfiguration erraten statt abgefragt wurde. Klären Sie deshalb vorab mit dem Anbieter – bei der Vemco-Plattform im Implementierungsgespräch mit dem Projektteam, da die Lösung als gehostete oder Private-Cloud-Variante betrieben wird und die konkreten Endpunkte von Ihrer Umgebung abhängen:

• Entity ID (Identifier) der Anwendung – exakt, inklusive Schema und eventuellem Schrägstrich am Ende.
• Reply URL (Assertion Consumer Service URL), an die Entra ID das Token sendet.
• Erwartetes NameID-Format: E-Mail-Adresse, UPN oder eine unveränderliche Object-ID. Diese Entscheidung bestimmt, ob Benutzer nach einer Domain-Umbenennung noch erkannt werden.
• Rollenmodell der Anwendung: Welche Rollen gibt es (etwa Store-Manager, Regionalleitung, Marketing, Vermieter-Reporting), und über welchen Claim werden sie zugewiesen?
• Zuständigkeiten: Wer darf im Mandanten Enterprise-Anwendungen anlegen, wer auf Anbieterseite die Federation-Metadaten hinterlegen? Ohne beide Personen im selben Termin dauert der Metadatenaustausch Tage statt Minuten.

Microsoft SSO einrichten in Entra ID: die Konfiguration Schritt für Schritt

Die folgenden Schritte gelten für eine SAML-2.0-Anbindung als Non-Gallery-Anwendung; bei einer vorkonfigurierten Galerie-App entfallen Teile von Schritt 3.

• 1. Enterprise-Anwendung anlegen: Im Entra-Admin-Center unter „Enterprise-Anwendungen“ eine neue Anwendung erstellen. Verwenden Sie einen sprechenden Namen mit Umgebungskennung, zum Beispiel „Vemco Analytics – Produktion“. Legen Sie für Test und Produktion getrennte Anwendungen an.
• 2. Single Sign-On-Methode wählen: SAML auswählen. Entra ID zeigt nun die Abschnitte für Basiskonfiguration, Attribute und Claims, Signaturzertifikat und Setup-URLs.
• 3. Basiskonfiguration füllen: Entity ID und Reply URL aus der Vorbereitung eintragen. Kopieren Sie beide Werte, tippen Sie sie nicht ab – ein fehlender Schrägstrich reicht für einen Fehlschlag.
• 4. Attribute und Claims setzen: Die NameID auf das vereinbarte Format umstellen. Einen Gruppen-Claim hinzufügen und dabei „Der Anwendung zugewiesene Gruppen“ wählen, nicht „Alle Sicherheitsgruppen“. Warum, steht im Abschnitt zu den häufigen Fehlern.
• 5. Federation-Metadaten übergeben: Die App-Federation-Metadaten-URL oder die XML-Datei an den Anbieter weitergeben. Notieren Sie das Ablaufdatum des automatisch erzeugten Signaturzertifikats sofort – es ist standardmäßig auf drei Jahre gesetzt.
• 6. Benutzer und Gruppen zuweisen: Zunächst nur eine Testgruppe zuweisen. Rollen in der Zielanwendung über Entra-ID-Gruppen steuern, damit das Offboarding automatisch greift.
• 7. Conditional Access anwenden: Mindestens MFA-Pflicht für die neue Anwendung, Blockierung von Legacy-Authentifizierung. Erst nach dem erfolgreichen Test der Pilotgruppe aktivieren, sonst vermischen sich Richtlinien- und Konfigurationsfehler.

Testen: drei Durchläufe statt eines Klicks

Die Schaltfläche „Testen“ in Entra ID prüft nur den IdP-initiierten Login mit dem angemeldeten Administrator – also genau den Fall, der im Alltag am seltensten vorkommt. Ein belastbarer Test für Single Sign On Microsoft-seitig umfasst drei Durchläufe:

• IdP-initiiert: Login über das Microsoft-Portal „Meine Apps“ mit einem Benutzer aus der Testgruppe, der keine Admin-Rechte hat.
• SP-initiiert: Aufruf der Anwendungs-URL im privaten Browserfenster, Weiterleitung zu Microsoft, Rückkehr in die Anwendung. Dieser Weg nutzt die Mehrheit der Anwender.
• Negativtest: Login mit einem Benutzer, der nicht zugewiesen ist. Erwartetes Ergebnis ist ein Fehler. Funktioniert der Login trotzdem, ist die Zuweisungspflicht in den Eigenschaften der Anwendung deaktiviert.

Prüfen Sie nach jedem Durchlauf im Anmeldeprotokoll von Entra ID, welche Claims tatsächlich gesendet wurden, und in der Zielanwendung, welche Rolle dem Benutzer zugewiesen wurde. Ein erfolgreicher Login mit falscher Rolle ist ein Fehler, der im Pilotbetrieb auffallen muss – nicht erst, wenn ein Store-Manager Konversionsraten anderer Regionen sieht.

Häufige Fehler und ihre Ursachen

• AADSTS50011 – Reply URL stimmt nicht überein: Die URL in der Anfrage der Anwendung weicht von der in Entra ID hinterlegten ab. Meist ein Tippfehler, ein http statt https oder ein fehlender Pfad. Vergleichen Sie beide Werte zeichenweise.
• AADSTS50105 – Benutzer nicht zugewiesen: Der Benutzer ist weder direkt noch über eine Gruppe der Anwendung zugewiesen. Bei verschachtelten Gruppen prüfen: Entra ID wertet für App-Zuweisungen nur direkte Mitgliedschaften aus.
• AADSTS700016 – Anwendung nicht gefunden: Die Entity ID der Anfrage passt zu keiner Anwendung im Mandanten. Häufig, wenn Test- und Produktionswerte vertauscht wurden.
• Login erfolgreich, Benutzer unbekannt: Die Anwendung erwartet eine E-Mail-Adresse als NameID, erhält aber die UPN – oder umgekehrt. Sichtbar im Anmeldeprotokoll unter den gesendeten Claims.
• Rollen fehlen bei einzelnen Benutzern: Ist ein Benutzer Mitglied in mehr als 150 Gruppen, schreibt Entra ID keine Gruppen mehr in das Token, sondern nur einen Verweis (Group Overage Claim). Betroffen sind typischerweise langjährige Mitarbeiter. Die Lösung ist der in Schritt 4 beschriebene Filter auf zugewiesene Gruppen.
• Login fällt Jahre später komplett aus: Das Signaturzertifikat ist abgelaufen. Tragen Sie das Datum am Tag der Einrichtung in Ihr Zertifikatsmonitoring ein und vereinbaren Sie mit dem Anbieter, wie die Rotation abläuft.

Abschluss: der Schritt, der am häufigsten ausgelassen wird

Nach einer Woche Parallelbetrieb mit SSO als Option folgt der Teil, der den eigentlichen Sicherheitsgewinn bringt: lokale Passwort-Logins in der Anwendung deaktivieren. Solange ein Benutzer sich an Microsoft vorbei anmelden kann, bleibt sein Zugang nach dem Austritt bestehen. Bei einer Plattform, in der Frequenzdaten, Konversionsraten und Standortvergleiche liegen, ist das kein kosmetisches Problem. Dokumentieren Sie zum Schluss auf einer Seite: Zertifikatsablaufdatum, Break-Glass-Prozess für den Fall eines IdP-Ausfalls und die Gruppen, die Rollen in der Anwendung steuern.

Häufig gestellte Fragen

Wie lange dauert es, Microsoft SSO für eine einzelne Anwendung einzurichten?
Die reine Konfiguration in Entra ID ist in unter einer Stunde erledigt, wenn alle Werte vorliegen. Realistisch sind zwei bis vier Wochen bis zur Passwort-Abschaltung, weil Pilotphase, Abstimmung mit dem Anbieter und Kommunikation an die Anwender Zeit brauchen.

Warum funktioniert der Login im Admin-Test, aber nicht für normale Benutzer?
Der Test im Admin-Center nutzt den angemeldeten Administrator und den IdP-initiierten Weg. Normale Benutzer scheitern meist an fehlender Zuweisung, an Conditional-Access-Richtlinien oder am SP-initiierten Pfad, der separat getestet werden muss.

Müssen die Gruppen-Claims wirklich gefiltert werden?
Ja, sobald Benutzer mit vielen Gruppenmitgliedschaften im Unternehmen existieren. Ab 150 Gruppen liefert Entra ID nur noch einen Verweis statt der Gruppenliste, den die meisten SaaS-Anwendungen nicht auflösen können, und das Rollen-Mapping schlägt still fehl.

Sie führen eine People-Counting- und Retail-Analytics-Plattform ein und möchten die Anbindung an Ihre Microsoft-Identitätsverwaltung, das Rollenkonzept und das Hosting-Modell von Beginn an sauber aufsetzen? Kontaktieren Sie Vemco Group – wir klären Entity ID, Claims und Zuständigkeiten gemeinsam mit Ihrer IT, bevor das erste Ticket entsteht.