Entra ID Kerberos für identitätsbasierte Authentifizierung auf Azure Files NTFS-Rechte auf Cloudspeicher - was passiert im Hintergrund ?

Mit der Azure-Files-Authentifizierungsoption „Entra Kerberos“ können Sie granulare NTFS-Berechtigungen auf Azure-Dateifreigaben implementieren, ohne dass Ihre „Clients“ eine Sichtverbindung zu einem existenten ADDS-Domain-Controller haben müssen. Einzige Einschränkung: ganz ohne ADDS-DC geht es auch hier nicht, denn die SIDs, welche letztendlich mit den gewünschten ACLs verknüpft werden, müssen aus dem AD stammen. Das erreichen Sie aber bereits durch Entra ID Connect, der in nahezu allen hybriden Umgebungen im Einsatz sein dürfte. Der Dienst schiebt Benutzeridentitäten über eine ausgehende HTTPS-Verbindung in die Cloud.

Es gibt viele Use-Cases für das beschriebene Szenario, aber ich konzentriere mich hier auf Azure Virtual Desktop (AVD) und FSLogix als Roaming-Profile-Lösung mit Azure Files als Profilspeicher für die von FSLogix generierten VHD-Container. Ich habe dieses Szenario hier im Blog bereits beschrieben. Daher geht es mir in DIESEM Beitrag nicht um das „Wie“, sondern um die technische Hintergründe, weil ich finde, dass das Feature „Entra Kerberos“ als Authentifizierungsmethode für Azure Files sehr pfiffig implementiert ist, aber auch Stolperfallen mitbringt. Diese lassen sich jedoch gut umgehen, wenn man versteht, was hier im Hintergrund passiert.

Letztendlich geht es um das Setzen von NTFS-Berechtigungen auf ein (Quasi)-Computer-Objekt, dass eine klassischen File-Server repräsentiert. Wie schon in diesem Blog beschrieben, ersetzen wir in einem AVD-Szenario den klassischen File-Server durch eine Azure-Dateifreigabe (Azure Files) in einem Storage-Account. Der Dienst unterstützt bekanntlich drei Methoden/Identitätsquellen für eine identitätsbasierte Authentifizierung im SMB/Windows-Umfeld, nämlich …

• Active Directory Domain Services (ADDS)
• Microsoft Entra Domain Services
• Microsoft Entra Kerberos

Drei interessante Authentifizierungsoptionen

In jedem Fall vergeben Sie die Freigabe-Berechtigungen sozusagen als Gatekeeper direkt hier im Azure-Portal an alle authentifizierten Benutzer oder differenzierter im IAM-Blade der Dateifreigabe an ihren „hybriden“ AVD-Benutzerkonten, bzw. Gruppen. So weit so gut. Spannend wird es bei den NTFS-ACLs, die FSLogix benötigt, um die VHD(X)-Datei der Benutzerprofile initial anlegen zu können. Außerdem müssen die authentifizierten Hybrid-Nutzer natürlich „ihre“ VHDs schreiben können und zwar „nur ihre“.

Für den Fall Active Directory Domain Services (ADDS) ist das Prinzip relativ klar. Hier wird vorausgesetzt, dass Session Hosts und Dateifreigaben via VPN oder Express Route über eine permanente Sichtverbindung zu einen On-Premise-Domain-Controller verfügen. Ein „pfiffiges“ eigens von Microsoft zu diesem Zweck entwickeltes Powershell-Modul namens AzFilesHybrid.zip sorgt dann auf magische Weise dafür, dass Ihr Storage-Account, bzw. konkret die Dateifreigabe ein Computerkonto im Active Directory erhält, welches dann der Kerberos-Ticket-Workflow für die Ticket-Anforderungen sowie die Validierung der User-SIDs nutzen kann. 

Wie das bei/mit den Entra ID Domain Services funktioniert, beschreibe ich in einem künftigen Beitrag, aber letztendlich handelt es sich hier um von MS verwaltete Domain-Controller-Objekte „in“ der Cloud, die einem vorhandenen Entra ID vertrauen.

Hier im Fokus des Entra-Kerberos-Feature ist das „Thema“ Computeridentität für Azure Files sehr spannend und „subtiler“ gelöst, als bei ADDS, denn ohne Sichtverbindung zu einem ADDS, kann dort auch kein Computerobjekt erzeugt werden; trotzdem erscheint eine virtuelle Repräsentation der Dateifreigabe in den ACLs. Wie das geht, zeige ich im Folgenden:

Basics zu SMB, NTFS und Kerberos

Dazu zunächst ein paar Grundlagen aus der IT-Steinzeit zur Erinnerung, falls Sie hier nicht mehr ganz im Bilde sein sollten. Möchten Sie auf einem gewöhnlichen SMB‑Fileserver Domänenbenutzer (oder ‑gruppen) berechtigen, muss der Server der Domäne beitreten, denn dadurch erhält dieser automatisch ein Computerkonto im AD (z. B. FS01$). Dieses ist Voraussetzung dafür, dass er „Kerberos“ gegenüber der Domäne „spricht“, um Domänen‑SIDs sauber auflösen zu können, denn für Domänenkonten auf NTFS/SMB ist eine vertrauenswürdige Authentifizierung (Kerberos/NTLM) und SID‑Auflösung zwingend.

Zwar gäbe es theoretisch die Möglichkeit der „Pass‑Through‑Authentifizierung“ mit lokalen Konten, diese ist aber fehleranfällig und nicht empfohlen für granulare Zugriffe in Domänenumgebungen. Allerdings bekommt das Computerkonto des Fileservers selbst keine NTFS‑Berechtigungen auf die Datenfreigaben. NTFS‑ACLs werden nur gegen das Benutzer-/Gruppen‑Token geprüft.

Sie sollten außerdem mit Kerberos, bzw. dem Kerberos-Ticket-Workflow im Allgemeinen vertraut sein. Kerberos selbst als passwortlose SSO-Lösung ist uralt und wurde bereits in den 1980er Jahren als Teil des Project Athena am MIT entwickelt, mit dem Ziel einer sicheren Authentifizierung in unsicheren Netzwerken ohne Klartext-Passwörter. Kerberos selbst ist seit Windows 2000 das Standard-Authentifizierungsprotokoll in Active Directory.

Aktuell wird es genutzt für SMB-Dateifreigaben (CIFS), sowie für Remote Desktop, SQL Server, IIS, Exchange und einige andere Dienste im Windows-Server-Umfeld. Weitere Vorteile neben Single Sign-On (SSO) sind Delegation (z. B. Web-App greift im Namen des Benutzers auf Ressourcen zu) und die sichere Authentifizierung ohne NTLM. 

Die Architektur um fasst drei „Akteure“, namentlich „Client“ (Benutzer/Computer), „KDC“ (Key Distribution Center) = AD-Domain Controller und dem eigentlichen „Service“, wie  z. B. Fileserver mit SPN (cifs/server.domain.local). Der Ticket-Workflow läuft dann wie folgt ..

1. Login: Benutzer authentifiziert sich beim KDC → erhält TGT.
2. Service-Zugriff: Client fordert beim KDC ein Service Ticket für den SPN des Dienstes.
3. Verbindung: Client präsentiert Service Ticket an den Server → Zugriff wird gewährt

Alles basiert auf SPNs und Shared Keys (aus AD).

Sie sollten sich dabei über die Rollen“ der beteiligten Akteure im Klaren sein. Das „Computerkonto“ eines Dateiservers bei ADDS oder die virtuelle Repräsentation eines Computerkontos für Azure Files im Kontext der Entra Kerberos-Szenarios wird primär für den Kerberos-Ticket-Workflow benötigt, während die NTFS-ACLs den Zugriff für die beteiligten SIDs aus dem ADDS auf die Dateifreigaben, sowie die Ordner und Unterordner steuern.

Der Kerberos Ticket-Workflow speziell bei Azure Files sieht dann wie folgt aus:

 Ferner sollten Sie sich für das weitere Verständnis den Unterschied zwischen Freigabeberechtigungen …

• gelten auf der SMB-Ebene (Netzwerkzugriff)
• Vollzugriff, Ändern, Lesen

und NTFS-Berechtigungen vergegenwärtigen

• Fein granular auf Datei-/Ordner-Ebene.
• Rechte wie Lesen, Schreiben, Ändern, Löschen, Ausführen.
• Basieren auf SIDs (Benutzer/Gruppen).
• Werden in der ACL gespeichert.

In der Praxis werden Beide stets kombiniert. Die effektiven Rechte ergeben sich dann aus der Schnittmenge. Mehr Details dazu finden Sie in der Azure-Files-Dokumentation, sofern es um die Funktion im Allgemeinen geht. Wie das konkret im Kontext von FSlogix umzusetzen ist, lesen Sie weiter unten.

Kerberos-Ticketworkflows und (NTFS) ACLs im FSLogix-Szenario

Wenden wir uns nun dem konkreten Szenario im Kontext von FSLogix zu. Hier übernimmt der Sessionhost mit Windows 11 Multisession die Rolle des „Clients“ und ist Entra-ID-Joined. Eine Sichtverbindung zum On-Premise-Domaincontroller besteht nicht, aber die AVD-Benutzer stammen aus dem ADDS und sind dank Entra ID Connect als hybride Konten auch im Entra ID sichtbar. Weitere Voraussetzung ist eine Speicherkonto in Azure in der gleichen Region, in der sich auch die Sessionhosts befinden mit einer Dateifreigabe für FSLogix, die mit der identitätsbasierenden Authentifizierungsmethode „Entra Kerberos“ konfiguriert ist  (s. o.).

Der technische Hintergrund sieht hier wie folgt aus:

• Das Feature Microsoft Entra Kerberos ersetzt hier den klassischen AD-KDC für den Zugriff auf Azure Files.
• Die Dateifreigabe wird durch eine Service Principal / App Registration im Entra ID repräsentiert. Dieses hat:
  • einen SPN (cifs/<storageaccount>.file.core.windows.net).
  • einen Keytab (automatisch generiert im Entra Kerberos Blade der Dateifreigabe).
  • eine GUID, die als „virtuelle Computeridentität“ dient.
• Diese Identität kann Kerberos Service Tickets ausstellen, weil Entra ID als KDC fungiert.
• Benutzer-SIDs in den ACLs hingegen stammen aus ADDS, daher müssen die Benutzer synchronisiert sein (Hybrid Join oder Entra Connect).
• Der KDC (Entra Kerberos) prüft:
  • Hat der Benutzer ein gültiges TGT (Ticket Granting Ticket)?
  • Ist er authentifiziert (Hybrid oder Cloud-only mit Kerberos-Proxy)?
  • Dann stellt er ein Service-Ticket für den SPN der Azure-Freigabe aus.

Sobald Sie den Sessionhost (z. B. via Regkey, GPOP oder Intune) in die Lage versetzt haben, Kerberos-Tickets abrufen zu können (siehe Kasten) kann dieser ein Ticket für Azure Files anfordern. Er nutzt eine automatisch von Microsoft konfigurierten Keytab der Dateifreigabe, der den Kerberos-Schlüssel für den Service Principal des Storage Accounts enthält. Dieser wird aus dem ADDS-Domain-Trust abgeleitet und  für die Ticket-Verschlüsselung genutzt. Daher ist es unumgänglich, dass Sie die Konfiguration in der Dateifreigabe mit „Domainname“ und „Domänen-GUID“ wie oben beschrieben gewissenhaft vornehmen:

1. Dann übergibt der Sessionhost das Service Ticket an Azure Files beim SMB-Connect
2. Azure Files entschlüsselt das Ticket mit dem Schlüssel aus dem Keytab.
3. Zugriff wird anhand der NTFS-ACLs und RBAC geprüft.
4. FSLogix sieht, dass der SMB-Share erreichbar ist.
5. FSLogix erstellt oder mountet die VHDX-Datei für das Benutzerprofil.
6. Ab hier läuft alles wie bei einem normalen SMB-Share.

Die folgende Abbildung für klist zeigt ein gültiges Tickes für Azure Files. Auch hier spiegelt sich der SPN der Dateifreigabe wieder.

Der gesamte Ablauf der Anmeldesequenz, sobald sich ein AVD-Nutzer über die Windows Apps oder den Web-Client bei seiner AVD-Session anmeldet sieht dann so aus, wie im folgenden Kasten:

Ticket-Abruf für Sessionhosts konfigurieren

Schließlich müssen Sie noch dafür sorgen, dass Ihr Sessionhost überhaupt Kerberos-Tickets vom Entra-based-KDC abrufen kann. Hierzu können Sie entweder

• den dazu erforderlichen Registrierungsschlüssel (im CMD oder per Regedit) direkt setzen …
  reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1
• oder die entsprechende Einstellung per Group Policies oder Intune verteilen. FSLogix liefert passende ADML/ADMX-Dateien zu diesem Zweck mit, die Sie einfach in Intune importieren können. Die Richtlinie heißt dort „CloudKerberosTicketRetrievalEnabled“ und ist im Einstellungskatalog zu finden. Oder Sie arbeiten in Intune manuell mit derOMA‑URI: ./Device/Vendor/MSFT/Kerberos/CloudKerberosTicketRetrievalEnabled).

Sie müssen außerdem sicherstellen, dass  „WinHTTP Auto‑Proxy (WinHTTP Web Proxy Auto‑Discovery)“ und „IP Helper „laufen (üblich per Default).

NFS-Berechtigungen konfigurieren

Die ACLs auf Azure Files sind NTFS-kompatibel, aber die SIDs kommen aus ADDS. Das ist der eigentliche Clou hierbei. Azure Files mappt diese SIDs gegen die Entra-ID-Objekte (Benutzer/Gruppen). Der o. e Service Principal selbst ist nicht für Zugriff zuständig, sondern für die Kerberos-Handshake und SPN-Validierung. Kurz gesagt: Die „virtuelle Computeridentität“ (App Registration) ist nötig, damit Entra Kerberos Tickets ausstellen kann. ACLs bleiben SID-basiert und erfordern ADDS-Synchronisierung. Jetzt ist nur noch zu klären, wie Sie diese Berechtigungen setzen könne, bzw. welche NTFS-Berechtigungen konkret benötigt werden.

Bis vor wenigen Wochen brauchten Sie für das initiale Setzen der NTFS-Berechtigungen – nicht für den späteren laufenden Betrieb – eine Sichtverbindung von einer „Konfigurationsmaschine“ (die wiederum vom Sessionhost direkt gesehen gesehen wird) zum On-Prem-Domain-Controller. Seit wenigen Wochen gibt es dazu auch eine Azure-Portal-basierte Option mit einigen Einschränkungen, die für eine nicht allzu komplexe Konfiguration ausreicht. Dazu unten mehr.

Bisher mussten Sie allerdings zu diesem Zweck entweder eine dauerhafte Site-to-Size-VPN-Verbindung zwischen einem AVD-Client (der dann temporär als Konfigurationsmaschine dient) oder Express-Route-Verbindung zum virtuellen Netzwerk des Sessionhosts vorhalten. Da dies in Enterprise-AVD-Umgebungen meist ohnehin gewünscht ist, stellt diese Voraussetzung für die meisten Unternehmen keine nennenswerte Einschränkung da, weil diese AVD-Hostpools und Workspaces aus Sicherheits- und Compliance-Gründen ohnehin mit privaten Endpunkten betreiben.

In kleineren Umgebungen oder VPN löse ich das Problem der initialen Konfiguration in der Regel wie folgt:

1. Bereitstellen des Azure VPN-Gateways virtuellen Netzwerk der Sessionhosts. Dazu ein Subnetz von Type „GatewaySubnet“ anlegen
2. Auf einem der AVD-Clients ein selbstsigniertes Stammzertifikat und ein Client-Zertifikat generieren. Beide werden im Benutzerzertifikatsspeicher abgelegt. Export des öffentlichen Schlüssels der CA (.cer-Datei) 
3. Bereitstellen einer P2S-Verbindung mit zertifikatsbasierter Authentifizierung und importieren des zuvor exportiertes öffentlichen Schlüssels per Copy&Paste im Azure-Portal auf der Client-Maschine.
4. Ebenfalls auf der Client-Maschine: Herunterladen und Installieren des VPN-Clients für P2S-SSTP.
5. Bereitstellen eines privaten Endpunktes im gleichen Subnetz vom Typ „Azure Storage“ (untergeordnete Zielressource=“Azure Files“)
6. Erweitern /Anpassen der DNS-Konfiguration des Clients, sodass dieser den Endpunktnamen der Dateifreigabe auf die private IP-Adresse des Endpunktes auflösen kann. Ich mache das immer durch ein temporäres Erweitern der lokalen ../etc/host-Datei, welche ich nachher wieder auflöse.
7. Die Schritte 1 bis 6 sind nur erforderlich, bzw. erlauben es, die Dateifreigabe auf dem Client einzubinden, obwohl Ihr ISP den SMB-Port 445 blockiert. Da das Einbinden der Dateifreigabe auf dem Client, bzw. der Konfigurationsmaschine nur für das initiale Setzen der NTFS-Berechtigungen erforderlich ist, können Sie das problemlos mithilfe der Kontoschlüssel tun. Ein passendes PS-Skript generiert Azure bei Bedarf automatisch.

Allein die Schritte 1 bis 7 böten genug Stoff für einen eigenständigen Artikel, was aber den Rahmen dieses  Beitrages sprengt. Ich wende mich dem Thema in Zukunft  noch einmal zu.

Sobald die Dateifreigabe erfolgreich eingebunden ist, können Sie die für FSLogix benötigten NTFS-Berechtigungen wahlweise via Windows Explorer oder icacls konfigurieren. Im konkreten Fall unseres FSLogix-Szenarios mit einer Azure-Dateifreigabe als Quasi-Fileserver mit identitätsbasierter Authentifizierung via Entra-Kerberos könnte das so aussehen:

• RBAC = Zugriff auf die Freigabe (IAM-Blade).
• NTFS = Zugriff auf Dateien/Ordner (Portal oder icacls).

Beide müssen stimmen, sonst kann FSLogix keine VHDX erstellen.

Microsoft beschreibt das Zusammenwirken von Freigabe und NTFS-Berechtigungen trefflich in der Azure-Files-Dokumentation. Im Prinzip können Sie es sich so merken:

Die für icacls relevanten Flags lauten

Windows-Explorer

Microsoft stellt für das Setzen der NTFS-Berechtigungen im Windows Explorer in seiner FSLogix-Dokumentation passende Demo-Screenshots für die Identitäts-Szenarien ADDS und Entra Kerberos zur Verfügung. In Letzterem Fall sehen diese so aus:

Für einen Abgleich mit Ihrer Konfiguration wählen Sie im Kontextmenü Ihrer Dateifreigabe „Properties / Security / Advanced“, um zu den eigentlichen NTFS-Berechtigungen zu gelangen. Achten Sie insbesondere bei der Gruppe Ihrer AVD-Benutzer darauf (der Microsoft-Screenshot zeigt nur die Standard-Berechtigungen), dass hier lediglich „Modify“ (statt „Full Control“)  und die Vererbung auf „This folder, subfolders and files“ gesetzt ist. Interessant (auch beim Microsoft-Screenshot) ist, dass hier der „virtuelle“ SPN der die Dateifreigabe im Entra ID repräsentierenden App-Registration auftaucht („Users /fslstgacct001premfiles…).

Ich meinem Screenshot sieht das ähnlich aus:

Achtung: Ich meinem Fall habe ich eine AD-Sicherheitsgruppe und einen expliziten AVD-Nutzer berechtigt. Beide tauchen im Screenshot als „Account Unknown“ auf. Das liegt daran, dass die oben skizzierte zum initialen Setzen der NTFS-Berechtigungen eingerichtete P2S-VPN-Verbindung zum Zeitpunkt des Anfertigen der Screenshots nicht mehr existierte und der Windows-Dialog die entsprechenden Objekte im AD nicht identifizieren kann, weil ich die Dateifreigabe nur temporär direkt in der Desktop-Sitzung per Speicherkontoschlüssel eingebunden habe.

Das gilt aber nicht für den virtuellen SPN der Dateifreigabe, weil dieser faktisch im Entra ID existiert, hier „avdfslsa\Users“, denn (und das zur Wiederholung):

• Entra-Kerberos stellt die Kerberos-Tickets für den Zugriff aus.
• Der Storage-Account authentifiziert über den Dienstprinzipal in Entra ID, nicht über ein AD-Objekt.
• Deshalb brauchen Sie (im Gegensatz zu ADDS) auch keinen Workaround für die Kennwortrotation bei Computerkonten im AD und keine echte AD-Join-Prozedur.

Dass ich nach Abbau meiner initialen P2-S-VPN-Sitzung, leider die Screenshots nicht noch einmal exakt anfertigen konnte, bringt mich allerdings auf ein interessantes neues Thema.

Seit einige Wochen erst stellt Microsoft eine interessante Option zur Verfügung, die NTFS-Berechtigungen dauerhaft ohne Sichtverbindung zum ADDS-Domaincontroller direkt im Azure-Portal sehen und mit einigen Einschränkungen auch setzen zu können. Die müssen dazu lediglich ihre Dateifreigabe im „Durchsuchen“-Modus (Speicherbrowser) über diesen spezifischen Link …

https://aka.ms/portal/fileperms

im Azure-Portal öffnen. Im Azure-Portal taucht dann ein zusätzlicher Button „Zugriff verwalten“ auf. Das sieht dann so aus:

Sie finden dort alle relevanten-Berechtigungen für Ihre hybriden Entra-Objekte, nur nicht die virtuelle Repräsentation der App-Registration. Diese muss aber lediglich existieren und wird so oder so nicht bearbeitet. Im Vergleich zum Explorer-Screenshot oben sehen Sie hier auch die korrekten hybriden Entra-Objekte „avd-user-local“ (eine lokale AD-Sicherheitsgruppen mit hybriden Mitgliedern), sowie den hybriden Benutzer „Thomas Drilling“.

Somit hätten wir uns also den gesamte oben skizzierten Aufwand zum Aufbau einer initialen oder dauerhaften VPN- oder Exprfess-Route-Verbindung sparen können? Nicht ganz. Es gibt ein paar Einschränkungen, die Sie der folgenden Tabelle entnehmen können. 

Kriterium	Portal-ACL (aka.ms/portal/fileperms)	icacls / Explorer (klassisch)
Identitätsquelle	Entra-ID (Cloud-only & Hybrid)	AD DS (Hybrid)
DC-Sicht erforderlich?	❌ Nein	✅ Ja (für SID-Auflösung)
Group Writeback nötig?	❌ Nein	✅ Ja (wenn Entra-Gruppen genutzt)
Vererbung aktivierbar?	❌ Nein (nur auf ausgewähltem Ordner)	✅ Ja (vollständig)
Automatisierbar?	❌ Nein (nur manuell im Portal)	✅ Ja (PowerShell, GPO)
Komplexe Strukturen	⚠️ Unpraktisch (kein Bulk)	✅ Einfach mit Skripten
Empfohlen für	Cloud-only oder Hybrid ohne DC-Zugriff	Große Hybrid-Umgebungen mit AD

Portal-ACL vs. icacls für FSLogix (Azure Files mit Entra Kerberos)

Sie sehen also, dass die Methode im Azure-Portal vor allem für kleinere, nicht allzu komplexe Szenaren geeignet ist, vor allen weil sich die Vererbung nur auf einzelnen Ordnern nachträglich per PS-Skript aktivieren lässt. Sie müssten also das im Azure-Portal bei Bedarf automatisch generierte Skript nach jedem Neuanlegen einer ACL erneut laufen lassen. Praktisch funktioniert das aber gut. Klicken Sie dazu einfach auf „Vererbung verwalten“ und kopieren das generierte Skript.

Zwar verursachte das Skript bei mir bei der ersten Ausführung in der Cloudshell einige unschöne Versionskonflikte, nachdem ich diese aber durch manuelles Neuinstallieren und Laden der benötigten PS-Module in meiner lokalen Powershell 7 lösen konnte, lief das Skript einwandfrei:

Summa summarum reichen die Portal-ACL reicht aus, wenn Sie den Stammordner (profiles) als VHD-Location nutzen und zudem keine komplexen Unterordnerstrukturen haben.

Das Werkzeug icacls hingegen eignet sich besser, wenn Sie Vererbung häufig benötigen, Sie viele Unterordner haben und das Durchsetzen der Vererbung automatisieren möchten.

Jetzt fehlt zum Vollenden des Szenarios lediglich das Installieren und Konfigurieren von FSLogix auf den Sessionhosts. Da dies aber nur mittelbar mit unserem Authentifizierungsszenario zu tun hat und der Beitrag hier zudem schon recht lang ist, erlaube ich mit, in Kürze einen Folgeartikel anzuschließen.