Troubleshooting: Microsoft Entra ID Hybrid Join schlägt fehl

Ein Microsoft Entra ID Hybrid Join klingt in der Theorie simpel: Ein Gerät ist in der lokalen Active Directory-Domäne eingebunden und wird zusätzlich in Entra ID registriert, damit Single Sign-On, Conditional Access und Intune-Richtlinien greifen. In der Praxis bleibt genau dieser zweite Schritt aber gerne stecken – manchmal so subtil, dass die eigentliche Ursache tief im Identitäts-Design vergraben liegt. Dieser Artikel beschreibt einen realen Fall aus dem Support, in dem der Hybrid Join scheinbar funktionierte, die zugewiesenen Richtlinien aber trotzdem nicht ankamen. Am Ende steht eine klare Kausalkette und ein konkreter Weg zur Behebung – plus die Diagnosebefehle, mit denen Du solche Fälle selbst einkreisen kannst.

Problembeschreibung

Auf einem verwalteten Client-Gerät funktionierte eine bereitgestellte Anwendung nicht wie erwartet. Die Analyse zeigte schnell, dass die Ursache nicht in der Anwendung selbst lag, sondern darin, dass das Gerät seine über Microsoft Intune zugewiesenen Konfigurationsrichtlinien nicht korrekt verarbeitete. Zugewiesene Policies wurden auf dem Gerät nicht im wirksamen Zustand übernommen. Auch ein manuell ausgelöster Sync brachte zunächst keine Besserung – das Gerät zog die aktualisierten Richtlinien nicht zuverlässig.

Im Zuge der Eingrenzung fiel ein entscheidendes Detail auf: Mit dem regulären Benutzerkonto (on-prem AD, Suffix @domäne.local) schloss der Synchronisationsvorgang nicht sauber ab. Erst die Anmeldung mit dem Device Enrollment Manager (DEM)-Konto stieß einen erfolgreichen Sync an. Die Richtlinien wurden daraufhin korrekt verarbeitet, und das Gerät funktionierte anschließend einwandfrei.

Genau dieses Verhalten – Sync und Policy-Verarbeitung scheitern mit dem regulären Konto, funktionieren aber mit dem DEM-Konto – war der entscheidende Hinweis auf die eigentliche Ursache. Es verlagerte den Fokus weg von Anwendung und Intune-Zuweisung hin zur Frage: Warum bekommt dieses Gerät mit diesem Benutzer keine funktionierende Cloud-Authentifizierung?

Ursache und Erklärung

Der Kern des Problems ist der on-prem-UPN-Suffix domäne.local. Dieser Suffix ist nicht-routbar und in Entra ID nicht verifizierbar. Entra akzeptiert als Domain nur öffentlich verifizierte Suffixe – der Nachweis erfolgt über einen öffentlichen DNS-Eintrag. Für ein .local-Suffix gibt es keinen solchen Nachweis. Entra kennt das Suffix daher schlicht nicht.

Was beim Login passiert

Der Benutzer meldet sich am Client mit seinem AD-Konto @domäne.local an. Die lokale Anmeldung gegen den Domänencontroller läuft über Kerberos und funktioniert – das ist nicht das Problem. Sobald aber die Entra-Authentifizierung ansteht, also die Beschaffung des Primary Refresh Token (PRT), präsentiert Windows genau diesen UPN.

Entra führt daraufhin eine Home-Realm-Discovery auf dem Suffix domäne.local durch, findet kein verifiziertes Domain und quittiert mit:

AADSTS90002: Tenant 'domäne.local' not found.

Das Ergebnis: Die on-prem-Anmeldung ist erfolgreich, die Cloud-Authentifizierung schlägt fehl. In der Diagnose (siehe unten) äußert sich das als AzureAdPrt : NO.

Warum die Konten in der Cloud trotzdem existieren

Wird ein Konto mit nicht-verifiziertem Suffix nach Entra synchronisiert, ersetzt Entra Connect das UPN-Suffix automatisch durch das initiale, immer verifizierte Tenant-Domain – im konkreten Fall domänegroup.onmicrosoft.com. Der Benutzer existiert in der Cloud daher unter einer routbaren Identität, auch wenn er on-prem weiterhin @domäne.local heißt.

Die Konten-Zuordnung läuft dabei über die ImmutableID / sourceAnchor, nicht über den UPN-String. Der Home-Realm-Discovery-Schritt schaut jedoch ausschließlich auf den Suffix – und der ist beim on-prem-Login eben das nicht-routbare .local.

Meldet man sich am Client hingegen mit der Cloud-Identität Benutzer@domänegroup.onmicrosoft.com an, präsentiert Windows einen routbaren, verifizierten Suffix. Die Home-Realm-Discovery löst sauber auf, das PRT wird ausgestellt, der Client synchronisiert problemlos – und damit werden auch die gerätebezogenen Richtlinien korrekt verarbeitet. Das ist zugleich der Grund, warum der DEM-Login funktioniert hat: Das DEM-Konto trägt ebenfalls einen routbaren Suffix.

Die Kausalkette

Damit schließt sich der Kreis:

nicht-routbarer domäne.local-UPN → Entra kennt den Suffix nicht → keine PRT-/Cloud-Authentifizierung → Gerät verarbeitet die zugewiesenen Intune-Richtlinien nicht im wirksamen Zustand → die für die Anwendung benötigte Konfiguration greift nicht → Anwendung funktioniert nicht.

Der gemeinsame Knoten war die nicht-routbare Cloud-Identität. Solange der on-prem-UPN-Suffix nicht in Entra verifizierbar ist, ist jeder Login mit diesem Suffix zum Scheitern verurteilt – unabhängig davon, wie sauber Intune-Zuweisung und Anwendung selbst konfiguriert sind.

Diagnose mit dsregcmd

Bevor Du an die Behebung gehst, lohnt sich die Bestätigung des Zustands. Das Werkzeug der Wahl ist dsregcmd. Öffne eine Eingabeaufforderung und führe aus:

dsregcmd /status

Achte im Abschnitt Device State und SSO State auf folgende Felder:

• AzureAdJoined : YES – bestätigt, dass das Gerät grundsätzlich hybrid verbunden ist.
• DomainJoined : YES – bestätigt die on-prem-Domänenmitgliedschaft.
• AzureAdPrt : NO – das ist der Fingerabdruck des Problems. Steht hier NO, konnte für die aktuelle Benutzersitzung kein Primary Refresh Token beschafft werden. Genau das erwartest Du im beschriebenen Fall, solange der Benutzer mit dem .local-UPN angemeldet ist.

Zum Vergleich: Nach einer Anmeldung mit der routbaren @…onmicrosoft.com-Identität sollte AzureAdPrt : YES erscheinen. Dieser Unterschied ist der praktische Beweis, dass es an der Identität und nicht am Gerät liegt.

Weitere nützliche Aufrufe:

dsregcmd /status
dsregcmd /leave

dsregcmd /leave (in einer Eingabeaufforderung mit erhöhten Rechten) hebt die Geräteregistrierung auf und wird bei einigen Behebungsszenarien benötigt (siehe unten).

Behebung – Schritt für Schritt

Für das Suffix-Problem gibt es drei Wege, geordnet von pragmatisch bis sauber.

Option 1: Kurzfristig und pragmatisch

Anmeldung bzw. Provisioning mit der routbaren @…onmicrosoft.com-Identität. Das funktioniert zuverlässig, weil Windows dann sofort einen verifizierten Suffix präsentiert und das PRT ausgestellt wird.

Nachteil: kosmetisch unschön und für den Endanwender ungewohnt. Als Dauerlösung nicht empfehlenswert, als Sofortmaßnahme oder zur Verifikation der Ursache aber ideal.

Option 2: Die saubere Lösung – verifiziertes Domain und UPN-Umstellung

Der nachhaltige Weg besteht darin, das nicht-routbare Suffix loszuwerden:

1. In Entra ein eigenes, verifiziertes routbares Domain anlegen (z. B. domäne.de) und über den öffentlichen DNS-Eintrag verifizieren.
2. Dieses Suffix als zusätzlichen UPN-Suffix in der on-prem AD ergänzen (Active Directory-Domänen und -Vertrauensstellungen).
3. Die Konten-UPNs von @domäne.local auf @domäne.de umstellen.

Danach tragen die Benutzer auch on-prem einen routbaren Suffix. PRT und SSO funktionieren dann unabhängig davon, mit welcher Schreibweise sich der Benutzer anmeldet. Das ist die architektonisch korrekte Lösung, weil sie die Home-Realm-Discovery dauerhaft auflöst.

Option 3: Alternative ohne UPN-Umstellung

Lässt sich der UPN aus organisatorischen Gründen nicht umstellen, konfigurierst Du in Entra Connect eine Alternate Login ID. Dabei wird ein routbares Attribut (z. B. mail) als Cloud-UPN synchronisiert, während der on-prem-UPN unangetastet bleibt. Voraussetzung ist, dass das gewählte Attribut sauber gepflegt und ebenfalls routbar ist.

Sonderfall: Geräte im Status „Ausstehend"

Neben dem Suffix-Problem gibt es einen zweiten häufigen Stolperstein beim Hybrid Join – Geräte, die im Status „Ausstehend" (Pending) hängen bleiben. Der Status „Ausstehend" existiert ausschließlich für hybrid verbundene Entra-Geräte.

Ursache des Pending-Status

Wenn Du in Microsoft Entra Connect die Hybrid-Join-Aufgabe für Deine lokalen Geräte konfigurierst, synchronisiert diese die Geräteobjekte nach Entra ID und setzt den Registrierungszustand zunächst auf „Ausstehend" – und zwar bevor das Gerät die eigentliche Geräteregistrierung abgeschlossen hat. Das Geräteobjekt muss dem Verzeichnis erst hinzugefügt werden, bevor es registriert werden kann. So weit ist das normal.

Problematisch wird es in zwei Szenarien:

1. Ein neues on-prem-Domänenmitglied bleibt hängen. Ein neues Gerät verharrt im Status „Ausstehend", wenn es den Geräteregistrierungsprozess nicht abschließen kann – etwa weil es keine Verbindung zum Registrierungsdienst herstellen kann. Hier hilft es, die Registrierungs-Konnektivität zu testen (Netzwerk, Proxy, erforderliche Endpunkte) und die Problembehandlung für Hybridgeräte durchzugehen.

2. Ein zuvor registriertes Gerät wechselt zurück auf „Ausstehend". Dieser Fall entsteht durch eine ungünstige OU-Verschiebung:

1. Das Geräteobjekt wird in eine andere Organisationseinheit (OU) verschoben, die nicht im Synchronisierungsbereich von Entra Connect Sync liegt.
2. Entra Connect Sync interpretiert diese Änderung als gelöschtes Geräteobjekt im lokalen AD und löscht das Gerät daraufhin in Entra ID.
3. Das Geräteobjekt wird wieder in eine OU innerhalb des Synchronisierungsbereichs verschoben.
4. Entra Connect Sync erstellt daraufhin ein neues, ausstehendes Geräteobjekt in Entra ID.
5. Der Geräteregistrierungsprozess kann nicht abgeschlossen werden, weil das Gerät lokal bereits als registriert gilt.

Behebung des Pending-Status

Um den Konflikt aufzulösen, hebst Du die Registrierung des Geräts auf und stößt sie neu an. Führe in einer Eingabeaufforderung mit erhöhten Rechten aus:

dsregcmd /leave

Anschließend startest Du das Gerät neu. Der Geräteregistrierungsprozess wird daraufhin über die geplante Aufgabe erneut initiiert. Bei Windows-10-basierten Geräten findest Du diese Aufgabe in der Aufgabenplanung unter:

Aufgabenplanungsbibliothek > Microsoft > Windows > Workplace Join > Automatic-Device-Join Task

Ausstehende Geräte auflisten

Um einen Überblick über die betroffenen Geräte zu bekommen, hilft das Microsoft Graph PowerShell SDK. Melde Dich zunächst am Tenant an:

Connect-MgGraph

Alle ausstehenden Geräte zählen:

(Get-MgDevice -All -Filter "TrustType eq 'ServerAd'" | Where-Object{($_.ProfileType -ne "RegisteredDevice") -and (-not $_.AlternativeSecurityIds)}).count

Die Liste als CSV exportieren:

Get-MgDevice -All -Filter "TrustType eq 'ServerAd'" | Where-Object{($_.ProfileType -ne "RegisteredDevice") -and (-not $_.AlternativeSecurityIds)} | Select-Object -Property AccountEnabled, Id, DeviceId, DisplayName, OperatingSystem, OperatingSystemVersion, TrustType | Export-Csv pendingdevicelist-summary.csv -NoTypeInformation

So bekommst Du schnell einen Überblick, wie viele Geräte betroffen sind, und kannst gezielt aufräumen.

Fazit

Der beschriebene Fall zeigt, wie weit die sichtbare Störung von ihrer eigentlichen Ursache entfernt sein kann: Eine Anwendung funktioniert nicht, doch der wahre Grund ist ein nicht-routbarer .local-UPN-Suffix, an dem die Cloud-Authentifizierung scheitert. Der schnellste Weg zur Diagnose ist dsregcmd /status mit Blick auf AzureAdPrt. Für die dauerhafte Behebung führt kaum ein Weg an einem verifizierten, routbaren UPN-Suffix vorbei. Und wenn Geräte im Status „Ausstehend" hängen, lohnt zuerst der Blick auf OU-Verschiebungen und Registrierungs-Konnektivität, bevor Du mit dsregcmd /leave und Neustart neu ansetzt.

Wer den UPN-Suffix von Anfang an routbar plant, erspart sich diese ganze Fehlerkette – ein .local im on-prem AD ist heute in hybriden Umgebungen mehr Bürde als Bequemlichkeit.