Microsoft-365-Federation-Trust nach Zertifikatswechsel aktualisieren

WISSEN Grundlagen, Architektur und alle Praxisbeiträge rund um ADFS an einem Ort. › Active Directory Federation Services	BERATUNG Zertifikatswechsel und Trust-Abgleich mit Entra ID – geplant, begleitet, dokumentiert. › Consulting zu ADFS	SCHULUNG Den Trust im Labor absichtlich kaputt machen und wieder reparieren – ohne echte Anwender. › ADFS-Schulungen

 

Es ist Dienstagmorgen, 7:42 Uhr. Die Frühschicht meldet, dass sich niemand mehr an Outlook anmelden kann. Kennwort stimmt, die ADFS-Anmeldeseite erscheint brav, man tippt, man klickt – und landet auf einer Fehlerseite von Microsoft. Auf der ADFS-Farm ist alles grün. Im Admin-Log steht, dass Token ausgestellt wurden. Die Farm hat ihren Job gemacht. Und trotzdem kommt keiner rein.

Wer so einen Morgen einmal erlebt hat, kennt die Pointe: Irgendjemand hat am Vortag das Token-Signing-Zertifikat gewechselt – oder ADFS hat es ganz von selbst getan –, und Microsoft Entra ID hat davon nichts mitbekommen. ADFS unterschreibt jetzt mit einem neuen Schlüssel, Entra ID vergleicht die Unterschrift aber mit dem alten. Das ist ungefähr so, als würdest du deinen Personalausweis erneuern und der Türsteher hätte noch das Foto von vor zehn Jahren an der Liste. Du bist es zwar, aber er glaubt dir nicht.

In diesem Beitrag geht es um genau diesen Handgriff: den Microsoft-365-Federation-Trust nach einem Zertifikatswechsel zu prüfen und zu aktualisieren. Wir schauen uns an, warum Entra ID die Anmeldung verweigert, wie du mit Microsoft Graph PowerShell die Fingerabdrücke abgleichst und wie du mit Update-MgDomainFederationConfiguration sauber nachziehst – auch bei mehreren föderierten Domänen. Die Grundlagen zu Farm, Vertrauensstellungen und Claims setze ich voraus; die findest du gebündelt auf der Übersichtsseite Active Directory Federation Services.

FAKTEN — Der Federation Trust zu Microsoft 365 in drei Sätzen Für jede föderierte Domäne speichert Entra ID eine Federation-Konfiguration: Aussteller-URI, Anmelde- und Abmeldeadressen und vor allem den öffentlichen Teil deines Token-Signing-Zertifikats. Jedes Token, das ADFS für Microsoft 365 ausstellt, prüft Entra ID gegen genau dieses hinterlegte Zertifikat – oder gegen das optional hinterlegte Folgezertifikat. Gegen sonst nichts. Das SSL-Zertifikat spielt dabei keine Rolle. Ein Tausch des SSL-Zertifikats erfordert keine Änderung am Trust; ein Wechsel des Token-Signing-Zertifikats sehr wohl.

 

Wie das Token-Signing-Zertifikat selbst erneuert wird, mit und ohne Automatik, steht in ADFS Token-Signing-Zertifikat erneuern – mit und ohne AutoCertificateRollover. Dieser Beitrag setzt an der Stelle an, an der die Farm schon mit dem neuen Zertifikat arbeitet – oder gleich arbeiten wird – und die Cloud noch nicht Bescheid weiß.

Warum Entra ID nach dem Wechsel die Anmeldung verweigert

Bei einer föderierten Domäne authentifiziert Entra ID deine Anwender nicht selbst. Es schickt sie zu ADFS, lässt sich von dort ein signiertes Token mitbringen und entscheidet dann nur noch: Ist diese Unterschrift echt? Die Antwort liefert ein einfacher Vergleich. Entra ID nimmt den öffentlichen Schlüssel aus dem Zertifikat, das in der Domänenkonfiguration hinterlegt ist, und prüft damit die Signatur. Passt sie, ist der Anwender drin. Passt sie nicht, ist das Token aus Sicht von Entra ID eine Fälschung – und wird so behandelt.

Skizze 2: Der Anmeldefluss – ADFS arbeitet korrekt, die Ablehnung passiert erst in Entra ID.

Das Gemeine daran: Der Fehler entsteht nicht dort, wo du zuerst suchst. ADFS hat das Kennwort geprüft, die Claim Rules angewendet und ein korrektes Token ausgestellt. Aus Sicht der Farm war das eine erfolgreiche Anmeldung. Die Ablehnung passiert eine Station später, in der Cloud, und dort hast du keine Ereignisanzeige. Wer nur auf den ADFS-Servern sucht, sucht lange. Welche Protokolle du dort trotzdem lesen solltest, beschreibt ADFS-Ereignisprotokolle lesen – Admin-Log, Debug-Tracing und Auditing.

Der Trust ist im Kern ein gespeichertes Zertifikat

Man stellt sich unter einem „Federation Trust“ gern etwas Lebendiges vor, eine Verbindung, die sich selbst pflegt. In Wahrheit ist er ein Datensatz. In Microsoft Graph heißt dieser Datensatz internalDomainFederation, und er hängt an jeder föderierten Domäne deines Mandanten. Die wichtigsten Eigenschaften zeigt Tabelle 1.

Eigenschaft	Bedeutung	Beim Zertifikatswechsel
SigningCertificate	Öffentlicher Teil des aktuellen Token-Signing-Zertifikats, Base64-codiert	muss auf das neue primäre Zertifikat zeigen
NextSigningCertificate	Folgezertifikat, das ebenfalls zum Prüfen von Signaturen dient, etwa während eines Rollovers	idealerweise vor dem Umschalten mit dem neuen Zertifikat befüllen
IssuerUri	Aussteller-Kennung der Farm, bei mehreren Domänen je Domäne unterschiedlich	nicht anfassen
PassiveSignInUri, ActiveSignInUri, SignOutUri	Adressen der Farm für Browser, Rich Clients und Abmeldung	nicht anfassen
MetadataExchangeUri	Endpunkt für die Metadaten-Abfrage durch Rich Clients	nicht anfassen
SigningCertificateUpdateStatus	Ergebnis und Zeitpunkt der letzten automatischen Zertifikatsaktualisierung, schreibgeschützt	gut zum Nachsehen, ob die Automatik gelaufen ist
FederatedIdpMfaBehavior	Ob Entra ID die MFA von ADFS akzeptiert, erzwingt oder ignoriert	nicht anfassen – sonst hast du ein zweites Problem

Tabelle 1: Die Eigenschaften der Federation-Konfiguration einer Domäne in Entra ID.

Zwei Felder, SigningCertificate und NextSigningCertificate, entscheiden also darüber, ob deine Anmeldungen durchgehen. Skizze 1 zeigt die Lage nach einem Wechsel, bei dem niemand die Cloud informiert hat – und darunter denselben Zustand nach dem Abgleich.

Skizze 1: Links das Token-Signing-Zertifikat in ADFS, rechts die hinterlegte Konfiguration in Entra ID – vor und nach dem Abgleich.

WICHTIG — Zwei Felder, ein Sicherheitsnetz Entra ID akzeptiert Signaturen mit beiden hinterlegten Zertifikaten. Genau deshalb gibt es NextSigningCertificate: Wenn das neue Zertifikat schon als Folgezertifikat eingetragen ist, bevor ADFS es zum primären macht, merkt niemand den Wechsel. Das ist der ganze Trick eines unterbrechungsfreien Rollovers – und der Grund, warum die Reihenfolge wichtiger ist als die Uhrzeit.

 

Normalerweise erledigt das die Automatik

Im Standardfall musst du gar nichts tun. ADFS erzeugt mit aktivem AutoCertificateRollover rechtzeitig ein neues Token-Signing-Zertifikat, veröffentlicht es als sekundäres Zertifikat in den Federation-Metadaten und macht es einige Tage später zum primären. Entra ID fragt ab etwa einem Monat vor Ablauf des hinterlegten Zertifikats deine Metadaten ab, wiederholt das täglich und übernimmt das neue Zertifikat, sobald es dort auftaucht. Microsoft nennt dafür je nach Dokument 30 oder 35 Tage – die Größenordnung ist entscheidend, nicht der genaue Tag.

Die Automatik hat aber zwei Voraussetzungen, und an beiden scheitert es in der Praxis regelmäßig: AutoCertificateRollover muss aktiv sein, und die Federation-Metadaten unter dem Pfad /federationmetadata/2007-06/federationmetadata.xml auf sts.contoso.de müssen aus dem Internet erreichbar sein, in der Regel über den Web Application Proxy. Wenn die Sicherheitsabteilung diesen Pfad am Perimeter „aus Prinzip“ gesperrt hat, fragt Entra ID ins Leere, verschickt eine Benachrichtigung an die hinterlegten technischen Kontakte und wartet. Die Mail landet dann in einem Postfach, das seit der letzten Umstrukturierung niemand mehr liest.

Wann du selbst nachziehen musst

Es gibt eine überschaubare Liste von Situationen, in denen Entra ID dein neues Zertifikat garantiert nicht von selbst mitbekommt oder nicht rechtzeitig. Tabelle 2 fasst sie zusammen.

Situation	Warum die Automatik nicht hilft	Was du tust
AutoCertificateRollover ist aus, Zertifikat stammt aus eigener PKI	Es gibt keinen automatischen Rollover, den Entra ID beobachten könnte	bei jedem Wechsel Trust von Hand aktualisieren
Metadaten sind extern nicht erreichbar	Entra ID kann das neue Zertifikat nicht abholen	nach jeder Zertifikatserzeugung von Hand aktualisieren
Update-AdfsCertificate mit -Urgent	Das neue Zertifikat wird sofort primär, ohne Vorlauf	unmittelbar danach Trust aktualisieren
Umzug auf eine neue Farm oder Neuinstallation	Neue Schlüssel, eventuell neue Aussteller-Kennung	Trust vollständig neu abgleichen
Wiederherstellung aus einer älteren Sicherung	Farm signiert plötzlich wieder mit einem Zertifikat, das Entra ID längst verworfen hat	sofort abgleichen
Verdacht auf kompromittierten Signaturschlüssel	Das alte Zertifikat muss aus beiden Feldern verschwinden, nicht nur aus einem	Notfallrotation, siehe Abschnitt Fehlerbilder

Tabelle 2: Situationen, in denen du den Trust selbst aktualisieren musst.

WARNUNG — Das Zertifikat wechselt oft nachts, der Anruf kommt morgens Bei AutoCertificateRollover passiert der Wechsel vom sekundären zum primären Zertifikat zu einem Zeitpunkt, den ADFS bestimmt – nicht dein Änderungsprozess. Sind die Metadaten gesperrt, bricht die Anmeldung also nicht beim Erzeugen des neuen Zertifikats zusammen, sondern Tage später beim stillen Umschalten. Ohne Monitoring auf den Abgleich erfährst du davon durch das Telefon.

 

Prüfen: Fingerabdrücke abgleichen mit Microsoft Graph PowerShell

Bevor du irgendetwas änderst, stellst du fest, ob überhaupt ein Unterschied besteht. Das dauert fünf Minuten und erspart dir die Situation, in der du an einem funktionierenden Trust herumschraubst, weil eine Warnmail gut formuliert war. Microsoft weist übrigens selbst darauf hin, dass solche Benachrichtigungen gelegentlich auch dann verschickt werden, wenn kein Handlungsbedarf besteht.

Verbinden – mit so wenig Rechten wie möglich

Für den Abgleich brauchst du das Modul Microsoft.Graph.Identity.DirectoryManagement aus Microsoft Graph PowerShell. Zum Lesen reicht der Bereich Domain.Read.All. Zum Schreiben brauchst du Domain-InternalFederation.ReadWrite.All oder das umfassendere Domain.ReadWrite.All, dazu ein Konto mit einer passenden Rolle – Microsoft nennt in seinen Anleitungen den Hybrididentitätsadministrator. Globaler Administrator geht auch, ist für diese Aufgabe aber so, als würdest du zum Glühbirnenwechseln den Generalschlüssel des Hauses mitnehmen.

Install-Module Microsoft.Graph.Identity.DirectoryManagement -Scope CurrentUser Connect-MgGraph -Scopes 'Domain.Read.All' # Welche Domänen sind überhaupt föderiert? Get-MgDomain | Where-Object AuthenticationType -eq 'Federated' | Select-Object Id, AuthenticationType, IsDefault

Listing 1: Verbindung mit Leserechten und Liste der föderierten Domänen

Was Entra ID gespeichert hat

Get-MgDomainFederationConfiguration liefert die Federation-Konfiguration einer Domäne. Die Zertifikate stehen dort als Base64-Text – lesbar für Maschinen, nutzlos für Menschen. Mit zwei Zeilen .NET machst du daraus wieder ein Zertifikat mit Fingerabdruck und Ablaufdatum:

$cfg = Get-MgDomainFederationConfiguration -DomainId 'contoso.de' $cfg | Format-List Id, IssuerUri, PassiveSignInUri, SigningCertificateUpdateStatus function ConvertTo-CertInfo ([string]$Base64) { if (-not $Base64) { return '(leer)' } $c = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new( [Convert]::FromBase64String($Base64)) [pscustomobject]@{ Thumbprint = $c.Thumbprint; NotAfter = $c.NotAfter; Subject = $c.Subject } } ConvertTo-CertInfo $cfg.SigningCertificate ConvertTo-CertInfo $cfg.NextSigningCertificate

Listing 2: Die in Entra ID hinterlegten Zertifikate auslesen und lesbar machen

Die Eigenschaft Id in dieser Ausgabe ist die sogenannte InternalDomainFederationId. Die brauchst du gleich beim Aktualisieren. Notier sie dir oder, besser, lass sie im Skript in der Variablen stehen.

Was ADFS gerade verwendet

Die Gegenseite liest du auf einem ADFS-Server aus, in einer PowerShell mit Administratorrechten. Get-AdfsCertificate zeigt alle Token-Signing-Zertifikate der Farm, mit der Information, welches gerade primär ist:

Get-AdfsProperties | Select-Object AutoCertificateRollover Get-AdfsCertificate -CertificateType Token-Signing | Select-Object IsPrimary, Thumbprint, @{ n = 'NotAfter'; e = { $_.Certificate.NotAfter } }

Listing 3: Token-Signing-Zertifikate der Farm und Status der Automatik

Der Abgleich in einem Rutsch

Wenn der ADFS-Server Microsoft Graph erreicht – was im internen Netz nicht selbstverständlich ist –, kannst du beides in einem Skript zusammenführen. Das Ergebnis ist eine kleine Tabelle, die dir ohne Interpretationsspielraum sagt, ob die Welt in Ordnung ist:

$domain = 'contoso.de' $cfg = Get-MgDomainFederationConfiguration -DomainId $domain $cloud = @($cfg.SigningCertificate, $cfg.NextSigningCertificate) | Where-Object { $_ } | ForEach-Object { ([System.Security.Cryptography.X509Certificates.X509Certificate2]::new( [Convert]::FromBase64String($_))).Thumbprint } Get-AdfsCertificate -CertificateType Token-Signing | ForEach-Object { [pscustomobject]@{ Thumbprint = $_.Thumbprint IsPrimary = $_.IsPrimary NotAfter = $_.Certificate.NotAfter InEntraID = $cloud -contains $_.Thumbprint } } | Format-Table -AutoSize

Listing 4: ADFS und Entra ID nebeneinander – InEntraID muss beim primären Zertifikat True sein

Ergebnis	Bedeutung	Handlungsbedarf
Primär: InEntraID = True	Entra ID kennt das Zertifikat, mit dem ADFS signiert	keiner
Sekundär: InEntraID = True	Das kommende Zertifikat ist schon als Folgezertifikat hinterlegt	keiner – so soll es vor dem Umschalten aussehen
Sekundär: InEntraID = False	Entra ID kennt das kommende Zertifikat noch nicht	vor dem Umschalten aktualisieren
Primär: InEntraID = False	ADFS signiert mit einem Zertifikat, das Entra ID nicht kennt	sofort aktualisieren – die Anmeldung ist gerade kaputt

Tabelle 3: So liest du das Ergebnis des Abgleichs.

TIPP — Kein Graph-Zugriff vom ADFS-Server? Kein Problem Viele Farmen stehen in einem Netzsegment, aus dem heraus niemand ins Internet darf – zu Recht. Dann exportierst du auf dem ADFS-Server die Base64-Werte mit [Convert]::ToBase64String($_.Certificate.RawData) in eine Textdatei und führst den Graph-Teil auf einer Admin-Arbeitsstation aus. Es handelt sich um öffentliche Schlüssel, die ohnehin in deinen Federation-Metadaten stehen. Geheim ist daran nichts.

 

Alternativ zeigt auch das Modul Microsoft.Entra mit Get-EntraFederationProperty die Federation-Einstellungen einer Domäne an; Microsoft verwendet es in einigen seiner aktuellen Anleitungen. Für diesen Beitrag bleibe ich bei den Graph-Cmdlets, weil du mit ihnen lesen und schreiben kannst, ohne das Modul zu wechseln.

Aktualisieren mit Update-MgDomainFederationConfiguration

Steht fest, dass Entra ID hinterherhinkt, ziehst du den Trust mit Update-MgDomainFederationConfiguration nach. Das Cmdlet ist im Grunde ein PATCH auf den Datensatz aus Tabelle 1: Es ändert genau die Eigenschaften, die du übergibst, und lässt alle anderen in Ruhe. Das ist gut, denn du willst nur die Zertifikate anfassen.

Die Federation-ID finden

Das Cmdlet verlangt zwei Pflichtangaben: -DomainId, also den Domänennamen, und -InternalDomainFederationId, die Kennung des Federation-Datensatzes. Letztere liefert dir Get-MgDomainFederationConfiguration in der Eigenschaft Id. Pro Domäne gibt es genau einen solchen Datensatz, und jede Domäne hat ihre eigene Kennung. Wer die ID einer Domäne für eine andere wiederverwendet, bekommt eine Fehlermeldung – was in diesem Fall ausnahmsweise die freundlichste mögliche Reaktion ist.

Beide Zertifikate übergeben

Hier liegt der wichtigste Unterschied zum alten Weg: Das Graph-Cmdlet liest nichts von deiner Farm. Es weiß nicht, dass es ADFS gibt. Die Zertifikate übergibst du selbst, als Base64-Text des öffentlichen Teils. Lass dich also nicht von Anleitungen verwirren, die den Befehl nur mit Domäne und ID zeigen – so geschrieben ändert er an den Zertifikaten nichts.

Connect-MgGraph -Scopes 'Domain-InternalFederation.ReadWrite.All' $domain = 'contoso.de' $cfg = Get-MgDomainFederationConfiguration -DomainId $domain $ts = Get-AdfsCertificate -CertificateType Token-Signing $prim = $ts | Where-Object IsPrimary $sec = $ts | Where-Object { -not $_.IsPrimary } | Select-Object -First 1 $params = @{ DomainId = $domain InternalDomainFederationId = $cfg.Id SigningCertificate = [Convert]::ToBase64String($prim.Certificate.RawData) } if ($sec) { $params.NextSigningCertificate = [Convert]::ToBase64String($sec.Certificate.RawData) } Update-MgDomainFederationConfiguration @params -WhatIf # erst schauen Update-MgDomainFederationConfiguration @params # dann machen

Listing 5: Primäres Zertifikat als SigningCertificate, sekundäres als NextSigningCertificate eintragen

Das Muster „primär nach SigningCertificate, sekundär nach NextSigningCertificate“ bildet ab, was ADFS auch in seinen Metadaten veröffentlicht. Es funktioniert in beiden Richtungen: vor dem Umschalten, wenn das sekundäre Zertifikat das neue ist, und nach dem Umschalten, wenn das sekundäre das alte ist. Führe danach Listing 4 erneut aus. Erst wenn beim primären Zertifikat True steht, bist du fertig.

FAKTEN — Was Microsoft über die beiden Felder sagt Laut Graph-Dokumentation ist SigningCertificate das aktuelle Zertifikat, mit dem Token für die Microsoft Identity Platform signiert werden, NextSigningCertificate ein Ersatzzertifikat, das ebenfalls zum Signieren verwendet werden kann – etwa wenn das primäre abläuft. Beide Felder erwarten den öffentlichen Teil des Zertifikats als Base64-Zeichenfolge, kompatibel zur .NET-Klasse X509Certificate2. Einen privaten Schlüssel gibst du niemals heraus. Microsoft nennt als Anwendungsfälle ausdrücklich den Rollover außerhalb der Automatik, die Einrichtung eines neuen Federation Service und den Fall, dass das neue Zertifikat nach einem Wechsel nicht in den Federation-Eigenschaften auftaucht.

 

Die Reihenfolge beim geplanten Wechsel

Wenn du das Token-Signing-Zertifikat ohne Automatik tauschst – typischerweise mit einem Zertifikat aus der eigenen PKI –, hast du es in der Hand, ob der Wechsel jemand bemerkt. Die Kurzfassung: Entra ID muss das neue Zertifikat kennen, bevor ADFS damit signiert. Skizze 3 zeigt die sechs Schritte.

Skizze 3: Erst das Folgezertifikat in Entra ID hinterlegen, dann in ADFS umschalten.

Schritt 1 und 2 kannst du Tage vorher erledigen. Das neue Zertifikat liegt in ADFS als sekundäres, in Entra ID als NextSigningCertificate. Anmeldungen laufen weiter über das alte.

Schritt 3 und 4 gehören direkt hintereinander. Nach dem Umschalten in ADFS trägst du das neue Zertifikat als SigningCertificate ein, das alte rutscht nach NextSigningCertificate.

Schritt 5 prüft jede föderierte Domäne einzeln – extern über den Web Application Proxy und intern.

Schritt 6 räumt auf: altes Zertifikat aus ADFS entfernen, Listing 5 erneut ausführen, damit Entra ID ebenfalls nur noch das neue kennt.

Mit aktiver Automatik und erreichbaren Metadaten erledigt Entra ID die Schritte 2 und 4 selbst. Mit aktiver Automatik und gesperrten Metadaten erledigst du sie – am besten in dem Moment, in dem ADFS das neue sekundäre Zertifikat erzeugt hat, und nicht erst, wenn es primär geworden ist.

Mehrere föderierte Domänen

Hat dein Mandant mehrere föderierte Domänen, etwa contoso.de, contoso.com und eine Tochterdomäne, dann hat jede davon ihre eigene Federation-Konfiguration – auch wenn alle auf dieselbe Farm zeigen. Ein Update für contoso.de ändert an contoso.com gar nichts. Das Ergebnis ist ein Fehlerbild, das zunächst völlig unlogisch aussieht: Die halbe Belegschaft kommt rein, die andere Hälfte nicht.

Skizze 4: Jede föderierte Domäne hat ihre eigene Konfiguration in Entra ID und will einzeln aktualisiert werden.

Microsoft stellt in seiner Anleitung klar, dass du bei mehreren Top-Level-Domänen Domäne für Domäne vorgehen musst; den früheren Schalter -SupportMultipleDomain gibt es in den Modulen Microsoft.Graph und Microsoft.Entra nicht mehr. Das lässt sich gut in einer Schleife erledigen – mit einer Sicherung, damit du nicht versehentlich eine Domäne anfasst, die an einem anderen Identitätsanbieter hängt:

$farm = 'sts.contoso.de' $b64Prim = [Convert]::ToBase64String($prim.Certificate.RawData) $b64Sec = if ($sec) { [Convert]::ToBase64String($sec.Certificate.RawData) } Get-MgDomain | Where-Object AuthenticationType -eq 'Federated' | ForEach-Object { $cfg = Get-MgDomainFederationConfiguration -DomainId $_.Id if ($cfg.PassiveSignInUri -notlike "*$farm*") { Write-Warning "$($_.Id) zeigt nicht auf $farm – übersprungen"; return } $p = @{ DomainId = $_.Id; InternalDomainFederationId = $cfg.Id; SigningCertificate = $b64Prim } if ($b64Sec) { $p.NextSigningCertificate = $b64Sec } Update-MgDomainFederationConfiguration @p "$($_.Id): aktualisiert" }

Listing 6: Alle föderierten Domänen derselben Farm nacheinander aktualisieren

WARNUNG — Finger weg von IssuerUri und den Adressen Bei mehreren Domänen unterscheidet sich die IssuerUri je Domäne, und ADFS stellt über eine Claim Rule die passende Aussteller-Kennung in das Token. Wer beim Zertifikatsupdate „der Ordnung halber“ die IssuerUri vereinheitlicht, tauscht einen Zertifikatsfehler gegen einen Ausstellerfehler. Übergib nur die beiden Zertifikatsparameter – und lass auch FederatedIdpMfaBehavior in Ruhe, wenn du nicht gerade dein MFA-Verhalten ändern willst. Was dahintersteckt, steht in ADFS mit Entra-MFA koppeln – Adapter, Zertifikat und Fallstricke.

 

Die Alternative: Microsoft Entra Connect

Hast du die Federation ursprünglich mit Microsoft Entra Connect eingerichtet, bietet dessen Assistent unter den Federation-Aufgaben eine Funktion zum Reparieren der Vertrauensstellung zwischen ADFS und Entra ID. Sie erkennt, ob die Token-Signing-Zertifikate auseinanderlaufen, und gleicht sie ab. Das ist bequem, setzt aber voraus, dass der Connect-Server die Farm per Remoting erreicht und das Konto die nötigen Rechte auf beiden Seiten hat. In gewachsenen Umgebungen ist der PowerShell-Weg oft der kürzere, weil du genau siehst, was passiert.

So stand es früher in jeder Anleitung: der MSOnline-Weg

Wer schon länger mit ADFS arbeitet, hat einen anderen Befehl im Muskelgedächtnis. Jahrelang lautete die Antwort auf jedes Trust-Problem: Connect-MsolService, dann Update-MsolFederatedDomain -DomainName contoso.de, bei mehreren Domänen mit -SupportMultipleDomain. Das Cmdlet lief auf dem primären ADFS-Server, las die Zertifikate selbst aus der Farm und schrieb sie in die Cloud. Bequem war das, keine Frage.

# Nur zur Einordnung – so stand es früher in jeder Anleitung. # Das MSOnline-Modul ist ausgemustert und kein Weg mehr für den Betrieb. Connect-MsolService Get-MsolFederationProperty -DomainName contoso.de Update-MsolFederatedDomain -DomainName contoso.de -SupportMultipleDomain

Listing 7: Der historische Weg – bitte nicht mehr in Runbooks übernehmen

Die Module MSOnline und AzureAD hat Microsoft ausgemustert; Microsoft Graph PowerShell ist der Nachfolger. Wenn dein Betriebshandbuch für den Zertifikatswechsel noch Update-MsolFederatedDomain enthält, ist jetzt ein guter Zeitpunkt, es zu überarbeiten – bevor jemand in einer Stresssituation einen Befehl ausführt, der nicht mehr funktioniert, und dann auf Forenarchäologie angewiesen ist. Tabelle 4 übersetzt die alten Befehle.

Aufgabe	Früher (MSOnline)	Heute (Microsoft Graph PowerShell)
Anmelden	Connect-MsolService	Connect-MgGraph -Scopes …
Föderierte Domänen auflisten	Get-MsolDomain	Get-MgDomain
Federation-Einstellungen lesen	Get-MsolFederationProperty	Get-MgDomainFederationConfiguration
Zertifikate nachziehen	Update-MsolFederatedDomain (liest ADFS selbst aus)	Update-MgDomainFederationConfiguration (Zertifikate selbst übergeben)
Mehrere Domänen	Schalter -SupportMultipleDomain	Domäne für Domäne, eigene ID je Domäne
Ausführungsort	zwingend primärer ADFS-Server	beliebig; ADFS-Werte vorher auslesen

Tabelle 4: Vom MSOnline-Befehl zum Graph-Cmdlet.

TIPP — Runbook gleich mit aktualisieren Der Moment, in dem du den Graph-Weg zum ersten Mal erfolgreich durchgespielt hast, ist der beste Moment, ihn aufzuschreiben. Listing 4 als Prüfung, Listing 5 oder 6 als Aktion, Listing 4 als Kontrolle – mehr braucht das Runbook nicht. Wie du so etwas zusammen mit der ganzen Zertifikatsverwaltung übst, zeigen wir in den ADFS-Schulungen.

 

Fehlerbilder, Entscheidungshilfe und der Notfall

Die meisten Trust-Probleme kündigen sich nicht an. Sie sind einfach eines Morgens da. Umso wichtiger ist es, das Fehlerbild schnell von anderen Anmeldestörungen zu unterscheiden – denn eine ADFS-Anmeldung kann aus einem Dutzend Gründen scheitern, die meisten davon auf der Farm. Den breiten Überblick gibt ADFS-Anmeldung schlägt fehl – die häufigsten Ursachen und ihre Lösung. Hier geht es um die Symptome, die auf einen veralteten Trust hindeuten.

Symptom	Wahrscheinliche Ursache	Prüfen mit
ADFS-Seite erscheint, nach dem Kennwort folgt eine Fehlerseite von Entra ID	Signatur passt nicht zum hinterlegten Zertifikat	Listing 4
Nur Anwender einer bestimmten Domäne betroffen	Trust nur für einen Teil der föderierten Domänen aktualisiert	Listing 4 je Domäne
Problem beginnt einige Tage nach einer Warnmail von Microsoft	Automatik hat umgeschaltet, Metadaten waren nicht erreichbar	Metadaten-URL von außen aufrufen
Problem beginnt direkt nach einer Wiederherstellung	Farm signiert mit altem Zertifikat	Get-AdfsCertificate, Listing 4
Browser geht, Rich Clients nicht, oder umgekehrt	eher kein Trust-Problem – Endpunkte, WAP oder SSL prüfen	SSL-Kette, WAP-Proxy-Vertrauen
Zertifikatswarnung im Browser	SSL-Zertifikat, nicht Token-Signing	SSL-Bindungen der Farm

Tabelle 5: Welche Symptome auf einen veralteten Trust hindeuten – und welche nicht.

Die letzten beiden Zeilen der Tabelle sind die Abzweigung für alle, die an der falschen Stelle suchen: Eine Zertifikatswarnung im Browser hat mit dem Trust nichts zu tun. Die behandelt SSL-Zertifikat auf ADFS und Web Application Proxy tauschen. Und wenn nur der Weg von außen klemmt, lohnt ein Blick auf WAP-Proxy-Vertrauen erneuern – wenn der Web Application Proxy plötzlich nicht mehr will.

FAKTEN — Welche Fehlermeldung genau erscheint Die Microsoft-Fehlerreferenz kennt mehrere Codes rund um ungültige Signaturen und fehlerhafte SAML-Token, etwa AADSTS50006 (InvalidSignature) und AADSTS50008 (InvalidSamlToken). Welcher Code bei dir erscheint, hängt von Protokoll und Client ab. Verlass dich nicht auf eine bestimmte Nummer, sondern auf den Abgleich der Fingerabdrücke – der lügt nicht.

 

Die Entscheidungshilfe

Ob du überhaupt eingreifen musst, entscheidest du mit drei Fragen. Microsoft beschreibt dafür eine kleine Matrix: Mit aktiver Automatik, synchronen Zertifikaten und öffentlich erreichbaren Metadaten ist nichts zu tun. Mit aktiver Automatik, aber nicht synchronen Zertifikaten und weniger als 15 Tagen Restlaufzeit sollst du sofort von Hand erneuern. Ohne Automatik und mit weniger als 35 Tagen Restlaufzeit ebenfalls. Skizze 5 macht daraus einen Entscheidungsbaum.

Skizze 5: Muss ich den Trust von Hand nachziehen? Drei Fragen und fünf Sonderfälle.

Der Notfall: kompromittierter Signaturschlüssel

Ein Sonderfall verdient eigene Aufmerksamkeit. Wenn du befürchten musst, dass jemand den privaten Schlüssel deines Token-Signing-Zertifikats in die Hände bekommen hat – das Stichwort lautet Golden SAML –, reicht ein normaler Wechsel nicht. Microsoft beschreibt für diesen Fall eine Notfallrotation: In ADFS werden zwei neue Token-Signing-Zertifikate erzeugt, das erste mit Update-AdfsCertificate -Urgent als sofortiges primäres, das zweite als sekundäres. Beide trägst du in Entra ID ein.

Der Grund für die zwei Zertifikate ist wichtig: Entra ID merkt sich das vorherige Zertifikat. Solange das alte noch als SigningCertificate oder NextSigningCertificate hinterlegt ist, könnten mit dem gestohlenen Schlüssel signierte Token weiterhin angenommen werden. Erst wenn beide Felder mit neuen Zertifikaten belegt sind, ist das alte aus dem Spiel. Danach entfernst du das alte Zertifikat mit Remove-AdfsCertificate aus der Farm und widerrufst die Aktualisierungstoken der Anwender, damit bestehende Sitzungen nicht einfach weiterlaufen. Den Hintergrund zu Golden SAML und der Härtung der Farm beschreibt ADFS-Sicherheit: Angriffe, Härtung, Golden SAML und MFA.

WARNUNG — Die Notfallrotation ist kein Wartungsfenster, sondern ein Ausfall mit Ansage Die sofortige Rotation umgeht jede Vorlaufzeit. Alle Relying Parties, die deine Metadaten nicht selbst abholen, brechen, bis sie das neue Zertifikat kennen – nicht nur Microsoft 365. Plane die Kommunikation mit Anwendungsbetreuern und Partnern parallel zur Technik, und zieh vorher eine Sicherung der Farm, wie in ADFS sichern und wiederherstellen – Rapid Restore Tool in der Praxis beschrieben.

 

Dauerhaft vorbeugen: Monitoring auf den Abgleich

Der beste Trust-Ausfall ist der, den du einen Monat vorher in einem Bericht siehst. Listing 4 lässt sich ohne großen Aufwand als geplante Aufgabe betreiben: täglich ausführen, bei False am primären Zertifikat oder bei einem sekundären Zertifikat, das Entra ID nach einigen Tagen noch nicht kennt, eine Meldung an das Betriebsteam schicken. Dazu gehört eine gepflegte Liste der technischen Kontakte im Mandanten, damit die Warnmails von Microsoft nicht im Nichts landen. Wie sich das in eine Überwachung der Farm insgesamt einfügt, zeigt ADFS überwachen – Health Checks, Diagnose-Toolbox und Entra Connect Health.

TIPP — Automatisiert prüfen – mit eigener App-Registrierung Für eine geplante Aufgabe meldest du dich nicht interaktiv an, sondern über eine App-Registrierung mit Zertifikat und der Anwendungsberechtigung Domain.Read.All. Für das reine Prüfen braucht das Skript keine Schreibrechte – und sollte auch keine haben. Die Aktualisierung bleibt ein bewusster Schritt mit Vier-Augen-Prinzip.

 

Fazit: Zwei Felder, die über deinen Montag entscheiden

Den Microsoft-365-Federation-Trust nach einem Zertifikatswechsel zu aktualisieren, ist technisch keine große Sache. Entra ID prüft Signaturen gegen zwei gespeicherte Zertifikate pro föderierter Domäne – SigningCertificate und NextSigningCertificate. Stimmen die mit dem überein, womit ADFS signiert, läuft alles. Stimmen sie nicht, hilft dir keine noch so gesunde Farm. Mit Get-MgDomainFederationConfiguration und Get-AdfsCertificate siehst du in fünf Minuten, wie es steht; mit Update-MgDomainFederationConfiguration ziehst du nach, Domäne für Domäne, mit den Zertifikaten als Base64-Text.

Schwierig wird es nur dort, wo Automatik und Wirklichkeit auseinanderlaufen: gesperrte Metadaten, eigene PKI-Zertifikate, vergessene Zweitdomänen, eine Wiederherstellung aus alter Sicherung. Das ist kein Grund, ADFS morgen abzuschalten. Die Farm läuft in vielen Unternehmen seit über zehn Jahren zuverlässig und darf das auch weiter tun – mit einem Runbook, das den Graph-Weg kennt, und einem Monitoring, das den Abgleich prüft, bevor es das Telefon tut. Und wenn du den Ausstieg aus der Föderation planst, ist der saubere Trust die Grundlage für einen geordneten Wechsel, wie ihn Microsoft 365 von Federated auf Managed umstellen – mit Staged Rollout beschreibt. Mehr zur Cloud-Seite findest du im Themenbereich Microsoft Entra ID.

Wenn du den nächsten Wechsel lieber mit Begleitung durchziehst oder das Zertifikatsmanagement deiner Farm grundsätzlich auf solide Füße stellen willst, unterstützen wir dich im Consulting zu ADFS (Active Directory Federation Services). Die Zusammenhänge zwischen Token-Signing, Metadaten und Vertrauensstellungen vertieft das Buch – mehr dazu unter ADFS in der Praxis – das Buch im Detail.

WEITER — Passend zum Thema › ADFS Token-Signing-Zertifikat erneuern – mit und ohne AutoCertificateRollover – das Zertifikat erneuern, bevor du den Trust nachziehst › ADFS-Anmeldung schlägt fehl – die häufigsten Ursachen und ihre Lösung – wenn es doch nicht am Trust liegt › ADFS mit Entra-MFA koppeln – Adapter, Zertifikat und Fallstricke – warum FederatedIdpMfaBehavior kein Nebenschauplatz ist › Microsoft 365 von Federated auf Managed umstellen – mit Staged Rollout – der geordnete Ausstieg aus der Föderation

 

FAQ: ADFS Microsoft 365 Federation Trust aktualisieren

Warum schlägt die Anmeldung an Microsoft 365 nach einem Wechsel des Token-Signing-Zertifikats fehl?

Weil Entra ID die Signatur jedes ADFS-Tokens gegen das Zertifikat prüft, das in der Federation-Konfiguration der Domäne hinterlegt ist. Signiert ADFS mit einem neuen Zertifikat, das dort weder als SigningCertificate noch als NextSigningCertificate eingetragen ist, verwirft Entra ID das Token.

Wie prüfe ich, ob ADFS und Entra ID dasselbe Token-Signing-Zertifikat verwenden?

Lies mit Get-MgDomainFederationConfiguration die Base64-Werte aus Entra ID, wandle sie in ein X509Certificate2-Objekt um und vergleiche dessen Fingerabdruck mit der Ausgabe von Get-AdfsCertificate -CertificateType Token-Signing auf dem ADFS-Server. Das primäre ADFS-Zertifikat muss in Entra ID hinterlegt sein.

Wie aktualisiere ich den Federation Trust mit Microsoft Graph PowerShell?

Mit Update-MgDomainFederationConfiguration -DomainId, -InternalDomainFederationId sowie -SigningCertificate und optional -NextSigningCertificate. Die Zertifikate übergibst du als Base64-Text des öffentlichen Teils; die ID liefert Get-MgDomainFederationConfiguration in der Eigenschaft Id.

Wo finde ich die InternalDomainFederationId?

In der Eigenschaft Id der Ausgabe von Get-MgDomainFederationConfiguration -DomainId contoso.de. Jede föderierte Domäne hat ihre eigene Kennung.

Welche Berechtigungen brauche ich für Update-MgDomainFederationConfiguration?

Den Graph-Bereich Domain-InternalFederation.ReadWrite.All oder Domain.ReadWrite.All und ein Konto mit passender Rolle, etwa Hybrididentitätsadministrator. Für das reine Prüfen genügt Domain.Read.All.

Funktioniert Update-MsolFederatedDomain noch?

Das MSOnline-Modul ist ausgemustert und kein Weg mehr für den Betrieb. So stand es früher in jeder Anleitung; heute nutzt du Get-MgDomainFederationConfiguration und Update-MgDomainFederationConfiguration aus Microsoft Graph PowerShell.

Muss ich jede föderierte Domäne einzeln aktualisieren?

Ja. Jede föderierte Domäne hat eine eigene Federation-Konfiguration mit eigener ID. Einen Schalter wie das frühere -SupportMultipleDomain gibt es in Microsoft Graph PowerShell nicht; du arbeitest die Domänen nacheinander ab.

Muss ich nach einem SSL-Zertifikatstausch den Trust aktualisieren?

Nein. Entra ID speichert für die föderierte Domäne das Token-Signing-Zertifikat, nicht das SSL-Zertifikat. Ein Tausch des SSL-Zertifikats erfordert keine Änderung an der Federation-Konfiguration.

Aktualisiert Entra ID den Trust nicht automatisch?

Doch, wenn AutoCertificateRollover in ADFS aktiv ist und die Federation-Metadaten aus dem Internet erreichbar sind. Entra ID fragt die Metadaten rund einen Monat vor Ablauf des hinterlegten Zertifikats täglich ab und übernimmt das neue Zertifikat. Fehlt eine der Voraussetzungen, musst du von Hand nachziehen.

Was muss ich bei einem kompromittierten Token-Signing-Zertifikat tun?

Eine Notfallrotation: zwei neue Token-Signing-Zertifikate erzeugen, beide in Entra ID eintragen, damit das alte aus SigningCertificate und NextSigningCertificate verschwindet, das alte Zertifikat aus ADFS entfernen und die Aktualisierungstoken der Anwender widerrufen.