Azure Virtual Desktop ohne Active Directory:
wie es funktioniert und wann es sich lohnt

Kurz gesagt: Mit Microsoft Entra Kerberos können Azure Virtual Desktop (AVD) und die FSLogix-Profile auf Azure Files ohne Domänencontroller funktionieren: Es ist immer Kerberos, aber die Tickets stellt die Cloud aus statt Active Directory. Für neue oder «reine Cloud»-Szenarien ist es eine echte Vereinfachung; für wer Domänenanwendungen hat (Branchenanwendungen, SQL Server) bedeutet es nicht «weg mit den Domänencontrollern», sondern eine hybride Modernisierung. Sehen wir, wie es wirklich funktioniert und — vor allem — wann es Sinn ergibt.

Vom an Active Directory verankerten Desktop zur Cloud

Azure Virtual Desktop entstand als Weiterentwicklung der Remote Desktop Services: zuerst «Windows Virtual Desktop», heute eine ausgereifte Plattform, um Desktops und Anwendungen als Service bereitzustellen. In den ersten Implementierungen wurde jedoch noch Active Directory Domain Services (AD DS) benötigt: Domänencontroller auf virtuellen Maschinen oder die On-Premise-Domäne, per VPN oder ExpressRoute in die Cloud erweitert.

Microsoft reduziert diese Abhängigkeit: Mit den in Microsoft Entra ID eingebundenen Session-Hosts und mit Entra Kerberos kann man so weit kommen, dass man den Domänencontroller nicht mehr braucht. Eine nützliche Klarstellung: Der typische Session-Host von AVD ist Windows 11 Enterprise multi-session — ein Client-Betriebssystem, das mehrere gleichzeitige Benutzer akzeptiert, der moderne Erbe der RDSH-Rolle auf Windows Server (die ohnehin unterstützt bleibt).

Das traditionelle Modell: zwei Identitäten, die zusammenarbeiten

Im klassischen (hybriden) Modell arbeiten zwei Identitätssysteme zusammen: Microsoft Entra ID verwaltet den Zugriff auf den Dienst AVD, während Active Directory die Windows-Authentifizierung und den Zugriff auf das Profil verwaltet. Hinter einer Single-Sign-on-Erfahrung passiert Folgendes:

• 1Der Benutzer öffnet den AVD-Client und authentifiziert sich bei Entra ID (Passwort, MFA, Windows Hello).
• 2Der Dienst weist einen Session-Host zu und stellt die Sitzung auf der Maschine her.
• 3Um auf die Windows-Ressourcen zuzugreifen, erhält die Maschine ein Kerberos-Ticket vom Domänencontroller.
• 4FSLogix verwendet dieses Ticket, um das Benutzerprofil auf einer SMB-Freigabe einzubinden. Alles dreht sich um den Domänencontroller: FSLogix → SMB → Kerberos → Domänencontroller.

Entra Kerberos: dasselbe Kerberos, ohne Domänencontroller

Die Idee ist ebenso einfach wie wirkungsvoll: Kerberos beibehalten, die Abhängigkeit vom Domänencontroller entfernen. Microsoft Entra ID wird zur Autorität, die fähig ist, die Kerberos-Tickets für den Zugriff auf SMB-Ressourcen wie Azure Files auszustellen. Das Protokoll ändert sich nicht: Es ändert sich, wer die Tickets ausstellt.

Im traditionellen Modell entsteht jedes Ticket auf dem Domänencontroller, in einem an die Active-Directory-Domäne gebundenen Realm (z. B. azienda.local). Mit Entra Kerberos entsteht ein Realm in der Cloud — KERBEROS.MICROSOFTONLINE.COM — und der KDC ist über das Internet erreichbar. Man sieht es mit klist: Das Ticket kommt nicht von einem Domänencontroller, sondern von einer in der Cloud verwalteten Kerberos-Autorität. Die Entra-joined Session-Hosts brauchen keine Sichtverbindung zu einem DC mehr, und das Modell funktioniert sowohl mit hybriden Identitäten (aus AD synchronisiert) als auch Cloud-only.

Authentifizierung ist nicht Autorisierung: RBAC und NTFS-ACLs

Sobald der Benutzer authentifiziert ist, wie wird der Zugriff auf die Daten autorisiert? Azure Files nutzt zwei Ebenen, die nacheinander arbeiten:

• Freigabe-Ebene — Azure RBAC. Zunächst wird überprüft, wer auf die Freigabe zugreifen kann und mit welcher Stufe (zum Beispiel Storage File Data SMB Share Reader oder Contributor). Es empfiehlt sich, die Standardberechtigungen zu deaktivieren und granulare Zugriffe an dedizierte Gruppen zu vergeben.
• Datei- und Ordner-Ebene — NTFS-ACLs. Nach der RBAC-Kontrolle gelten die klassischen Windows-Berechtigungen. Hier wird das Kerberos-Ticket wieder zentral: Außer die Identität zu beweisen, transportiert es die SIDs des Benutzers, sodass Azure Files die ACLs genau so auswertet, wie es eine Active-Directory-Umgebung tun würde. Für die Cloud-only-Identitäten ist die empfohlene Konfiguration das Panel Manage access.

Cloud-native Verwaltung: Intune statt GPOs

Ohne Domäne gibt es keine Group Policies: Die Entra-joined Session-Hosts werden mit Microsoft Intune gesteuert. Von dort aus aktiviert man das Abrufen des Cloud-Kerberos-Tickets (die Einstellung CloudKerberosTicketRetrievalEnabled, über den Settings Catalog) und verteilt die FSLogix-Richtlinien, die früher über die GPOs liefen.

Ein Punkt, der die Einstiegshürde stark senkt: FSLogix ist derselbe Agent, den man bereits auf Windows Server oder RDSH verwendet. Es ändern sich nur der Speicher (vom Fileserver zu Azure Files) und die Quelle der Tickets (vom Domänencontroller zu Entra Kerberos) sowie das Deployment-Werkzeug (von GPO zu Intune). Die Konzepte von Profile-Container, Umleitungen und Ausschlüssen bleiben identisch: Wer FSLogix bereits verwaltet, fängt nicht bei null an.

Braucht Ihr Unternehmen es wirklich? Wann es sich lohnt (und wann es nur Mode ist)

Hier liegt der Punkt, der oft fehlt: «ohne Domänencontroller» ist kein universelles Upgrade. Das Cloud-only-Modell (null DC) lohnt sich wirklich nur in genauen Szenarien, die alle das Fehlen von Domänenanwendungen gemeinsam haben:

• Greenfield — neue Unternehmen oder Niederlassungen, in der Cloud geboren, ohne On-Premise-Altlasten.
• SaaS-only- / Frontline-Mitarbeiter — wer von Microsoft 365, AVD-Desktops und einer Freigabe lebt, ohne Legacy-Branchenanwendungen.
• Externe Identitäten / B2B — Cloud-only ist das einzige Modell, das sie mit FSLogix unterstützt.
• Isolierte Umgebungen — ein Projekt, eine DMZ oder ein Perimeter, den Sie von Ihrem Active Directory getrennt halten wollen, im Sinne von Zero Trust.

Wenn es im Unternehmen hingegen Anwendungen gibt, die Mitglieder einer Domäne sind — eine Branchenanwendung, SQL Server mit Windows-Authentifizierung, ein Domänen-Fileserver — halten jene Systeme die Domänencontroller am Leben. Für sie ist der richtige Schritt nicht, dem «ohne DC» nachzujagen, sondern eine hybride Modernisierung: Entra-joined Session-Hosts, Entra Kerberos und FSLogix auf Azure Files für die Desktop-Ebene, rund um einen verschlankten Active-Directory-Kern:

• RD Gateway → ZTNA. Statt eines im Internet exponierten RDP-Gateways ein Zugriff per Zero Trust Network Access , der die einzelne Ressource pro Benutzer veröffentlicht, Identität und Gerät überprüft, ohne etwas zu exponieren.
• NPS für die MFA → Conditional Access. Die MFA wechselt zu Entra ID, das Identität, Gerät und Risiko bewertet, statt einer «blinden» MFA über RADIUS.
• GPO → Intune. Schrittweise Migration der Richtlinien zu Intune, wobei in AD nur das bleibt, was die Domänenserver wirklich brauchen.

Es bleiben dann einige Fallstricke, die man kennen sollte, bevor man loslegt: Jedes Storage-Konto akzeptiert nur eine einzige Identity Source (AD DS und Entra Kerberos mischen sich nicht); bei hybriden Identitäten müssen die ACLs der Freigabe von einer Maschine gesetzt werden, die den Domänencontroller sieht (die Session-Hosts nicht), und Benutzer und Gruppen müssen zu Entra ID synchronisiert werden; für die Cloud-only-Identitäten braucht es die Aktivierung der Cloud-Gruppen (Grenze von 1.010 SIDs pro Ticket) und die Deaktivierung der MFA auf der App des Storage-Kontos, mit noch begrenzter Verfügbarkeit in einigen Regionen. Schließlich kann das Kerberos-Hardening von April 2026 (von RC4 zu AES) die FSLogix-Profile auf nicht aktualisiertem SMB brechen: Es lohnt sich, sich vorher anzugleichen, wie wir im Artikel über den Abschied von der RC4-Verschlüsselung in Kerberos erklären.

Wie AtWorkStudio hilft

Wir beginnen immer mit einem Audit der Abhängigkeiten von Active Directory, bevor wir Vereinfachungen versprechen: Was hängt wirklich an der Domäne (Branchenanwendungen, SQL Server, GPOs, Gateways, MFA) und was lässt sich verschieben. Von dort aus gestalten wir den richtigen Weg — AVD-Desktops, hybride Identität, digitales Identitätsmanagement mit Entra ID, Intune, Conditional Access und Zero-Trust-Zugriff — im Einklang mit den Anforderungen der NIS2 und den Best Practices der ISO/IEC 27001. Keine Stilübungen: nur das, was Wert bringt.

Wir sind seit 2000 in Piacenza tätig. Wir sind nach ISO/IEC 27001, 27017, 27018 und ISO 9001 zertifiziert, ACN-qualifiziert für Cloud-Dienste, Mitglied von Clusit (Italienischer Verband für Informationssicherheit) und Confindustria Piacenza im RICT-Cluster.