Identitätsanbindung: woran eine Sitzung wirklich hängt

Eine Anmeldung, mehrere Instanzen

Im vorigen Modul ging es darum, wie ein Nutzer seine Ressource überhaupt zu sehen bekommt. Jetzt beginnt der schwierigere Teil: Die Ressource ist sichtbar, der Verbindungsaufbau läuft — und die Anmeldung am Session Host scheitert.

Dahinter steht eine Entscheidung, die beim Aufbau der Umgebung fällt und danach alles bestimmt: woran die Session Hosts ihre Identitäten auflösen. Microsoft Entra ID authentifiziert immer die Nutzer gegenüber dem Dienst. Wovon der Host selbst seine Kontoinformationen bezieht, ist eine davon unabhängige Frage — und die Antwort entscheidet, welche Profilspeicher, welche Anmeldeverfahren und welche Verwaltungswerkzeuge überhaupt zur Verfügung stehen.

Identitätsanbindung des Hosts — Die Art, wie ein Session Host Benutzerkonten auflöst: als Microsoft Entra ID eingebundene Maschine, als Mitglied einer Active-Directory-Domäne oder als Mitglied von Microsoft Entra Domain Services. Nicht zu verwechseln damit, wogegen sich der Nutzer beim Dienst authentifiziert — das ist immer Microsoft Entra ID.

Drei Authentifizierungsphasen, drei Fehlerbilder

Die Dokumentation trennt die Phasen namentlich, und für dieses Modul zählt vor allem die zweite. Sie ist die einzige, in der die Einbindungsart des Hosts eine Rolle spielt — und zugleich die, deren Fehlermeldungen am wenigsten verraten.

Phase 1 scheitert

Sichtbar im Entra-Anmeldeprotokoll, mit Richtlinienbezug. Der Host ist nicht beteiligt.

Phase 2 scheitert

Die Verbindung steht, die Windows-Anmeldung nicht. Hier zählen Einbindungsart, Anmelderecht und Profilzugriff.

Phase 3 scheitert

Der Desktop ist da, eine Anwendung im Inneren fragt erneut. Ein Fall für Umleitung und Kerberos, nicht für die Plattform.

Welche Kombinationen unterstützt sind

Session Hosts werden entweder demselben Microsoft-Entra-Mandanten wie die Nutzer beigetreten oder einer Active-Directory-Domäne — per Active Directory Domain Services oder per Microsoft Entra Domain Services. Nicht jede Kombination aus Hosteinbindung und Kontoherkunft ist zulässig.

Hosts in AD DS

Konten in Entra ID und AD DS, synchronisiert.

Hosts in Entra ID

Konten in Entra ID und AD DS synchronisiert — oder reine Cloud-Konten.

Hosts in Entra Domain Services

Konten in Entra ID und Entra Domain Services, synchronisiert.

Nur Entra ID

Konten ausschließlich in Entra ID, einschließlich externer Identitäten — Hosts müssen Entra-eingebunden sein.

Was ausdrücklich nicht geht

• Identitäten, die nur im lokalen Active Directory existieren, sind nicht unterstützt — Nutzer müssen über Microsoft Entra ID auffindbar sein.
• Das schließt eigenständige Active-Directory-Installationen mit Active Directory Federation Services ein. Föderation ersetzt die Synchronisierung nicht.
• Persönliche Microsoft-Konten werden nicht unterstützt.
• Sich mit einem Konto an Microsoft Entra ID anzumelden und mit einem anderen an Windows, ist nicht unterstützt — einschließlich lokaler Windows-Konten.

Praktisch entsteht dieser Zustand selten absichtlich. Er entsteht, wenn auf einem Session Host ein lokales Administratorkonto für Wartungszwecke benutzt wird, während dieselbe Person über Windows App mit ihrer regulären Identität verbunden ist — oder wenn ein Testkonto im Client hinterlegt bleibt.

Hybride Identität: UPN oder SID muss übereinstimmen

Wer Konten aus einem lokalen Active Directory synchronisiert, bekommt zwei Darstellungen derselben Person. Sie müssen sich zuordnen lassen, sonst kommt keine Sitzung zustande.

Azure Virtual Desktop unterstützt abweichende Namen nur dann, wenn entweder der User Principal Name oder die Security Identifier beider Konten übereinstimmt. Das klassische Beispiel aus der Dokumentation: Das AD-Konto user@contoso.local entspricht user@contoso.com in Microsoft Entra ID — hier weicht der UPN ab, also muss die SID tragen.

SID in beiden Welten — Gemeint ist die Objekteigenschaft ObjectSID im Active Directory und OnPremisesSecurityIdentifier in Microsoft Entra ID. Stimmen diese überein, darf der UPN abweichen — und umgekehrt.

Der Profilspeicher entscheidet mit

Hier liegt die Kopplung, die Entwürfe am häufigsten zum Einsturz bringt — weil sie zwei Entscheidungen verbindet, die in getrennten Sitzungen getroffen werden: die Einbindungsart der Hosts und die Herkunft der Nutzerkonten.

Die Folge ist unbequem: Eine Umgebung mit reinen Cloud-Konten und Entra-eingebundenen Hosts ist für sich genommen unterstützt — aber sie kann in dieser Form keinen FSLogix-Profilcontainer betreiben. Und ohne Profilcontainer ist ein gepoolter Host Pool praktisch nicht zu betreiben, weil der Nutzerzustand den Hostwechsel nicht überlebt.

Single Sign-on und was ohne es passiert

Single Sign-on lässt die Abfrage der Hostanmeldedaten entfallen und meldet den Nutzer über Microsoft-Entra-Authentifizierung an Windows an. Für Entra-eingebundene und Entra-hybrid-eingebundene Hosts ist es der empfohlene Weg; er bringt zusätzlich kennwortlose Verfahren und die Unterstützung dritter Identitätsanbieter mit.

Für Windows-Desktop- und Webclients unterstützt Azure Virtual Desktop daneben Single Sign-on über Active Directory Federation Services. Das bleibt eine Option für Umgebungen, die ihre Föderation nicht ablösen wollen.

Smartcard und Windows Hello brauchen Kerberos

Für die Anmeldung am Session Host unterstützt Azure Virtual Desktop sowohl NTLM als auch Kerberos. Zwei Verfahren sind jedoch auf Kerberos festgelegt: Smartcard und Windows Hello for Business.

Kerberos verlangt, dass der Client Tickets von einem Key Distribution Center bezieht — einem Dienst, der auf einem Domänencontroller läuft. Dafür braucht der Client eine direkte Netzsicht auf den Domänencontroller.

• Verbindung innerhalb des Unternehmensnetzes — die Sichtverbindung besteht ohnehin.
• Verbindung über VPN — die Sichtverbindung wird hergestellt.
• Ein KDC-Proxy — der dokumentierte Weg, wenn weder das eine noch das andere möglich ist.

Zwei Konfigurationen, die Hosts stillegen

Zwei Punkte aus der Dokumentation verdienen besondere Aufmerksamkeit, weil beide aus gut gemeinten Standardmaßnahmen entstehen.

Beide Fälle haben dasselbe Muster: Eine Maßnahme, die überall sonst richtig ist, trifft hier eine Komponente, die davon abhängt. Härtungsvorlagen gehören deshalb nicht unbesehen auf Session Hosts, sondern durch eine Ausnahmeliste — und die Ausnahmen gehören begründet dokumentiert, sonst entfernt sie der nächste Audit.

Was die Einbindungsart für die Verwaltung bedeutet

Hosts in AD DS, per Intune verwaltet

Verlangt Microsoft Entra Connect und Microsoft Entra hybrid join.

Hosts in Entra Domain Services

Lassen sich nicht mit Intune verwalten.

Windows Server mit Entra-Beitritt

Keine Intune-Registrierung möglich — Windows Server wird von Intune nicht unterstützt. Bleibt: Entra hybrid join mit Gruppenrichtlinien oder lokale Richtlinien je Host.

Diese Zeilen entscheiden mehr als es scheint. Wer seine Konfiguration über Intune ausrollen will und gleichzeitig Windows Server als Sitzungsbetriebssystem plant, hat einen Widerspruch im Entwurf — und merkt ihn erst, wenn die erste Richtlinie nicht ankommt.

Phase drei: Authentifizierung innerhalb der Sitzung

Der Desktop läuft, und trotzdem fragt eine Anwendung im Inneren nach Anmeldedaten. Das ist keine Störung, sondern die dritte Phase — und sie hat eigene Mechanismen, die mit der Anmeldung am Host nichts zu tun haben.

Kennwortlose Verfahren funktionieren auch innerhalb der Sitzung. Azure Virtual Desktop leitet dazu WebAuthn-Anfragen an den lokalen Rechner weiter: Windows Hello for Business oder ein angeschlossener FIDO-Schlüssel erledigen die Authentifizierung dort, wo das Gerät steht. Das geschieht automatisch, sobald Session Host und lokaler PC die dokumentierten Betriebssystemstände erreichen — für Windows 11 und Windows 10 ab Version 20H2 jeweils mit den kumulativen Updates von Oktober 2022, für Windows Server 2022 entsprechend.

WebAuthn-Umleitung — Die Weiterleitung aller WebAuthn-Anfragen aus der Sitzung an den lokalen Rechner. Sie lässt sich über die RDP-Eigenschaft redirectwebauthn steuern; der Wert 0 schaltet sie ab. Im Azure-Portal steht sie unter den Geräteumleitungen des Host Pools.

Für Smartcards in der Sitzung gilt Entsprechendes: Die Treiber müssen auf dem Session Host installiert und die Smartcard-Umleitung aktiviert sein. Ohne beides ist die Karte im Lesegerät für die Anwendung nicht vorhanden.

Diagnose: welche Phase hat versagt

Nutzer melden all diese Fälle mit demselben Satz: Die Anmeldung geht nicht. Die Phase zu bestimmen, kostet eine Rückfrage — ob der Desktop kurz sichtbar war, ob ein Kennwortdialog kam, ob es ein temporäres Profil gab — und spart die Hälfte der Suche.

• Kam ein Kennwortdialog für den Host? Dann trägt Phase eins, und Single Sign-on ist entweder nicht aktiv oder greift für diesen Nutzer nicht.
• War der Desktop kurz da und verschwand wieder? Die Windows-Anmeldung lief an und brach ab — ein Fall für Profilanbindung oder Anmelderecht, nicht für Zuweisung.
• Gab es ein temporäres Profil? Der Profilcontainer ließ sich nicht einbinden. Die Anmeldung selbst war erfolgreich, die Ursache liegt im Speicher oder in den Rechten darauf.
• Läuft der Desktop und fragt nur eine Anwendung? Phase drei — Umleitung, Kerberos-Sichtverbindung oder eine Grenze externer Identitäten.
• Trifft es nur Konten aus einer bestimmten Quelle? Dann lohnt der Blick auf UPN und SID: Ein neu in Entra ID angelegtes statt synchronisiertes Konto fällt genau so auf.