In vielen Azure-Projekten werde ich gefragt, wie sich Azure File Shares sicher und bequem mit Entra-verbundenen Geräten nutzen lassen, vor allem wenn die Clients keinen klassischen Domain Controller mehr erreichen. Seit Ende 2023 hat Microsoft dafür mit Azure Files Entra Kerberos endlich eine Antwort, die für hybride Identitäten ebenso interessant ist wie für Cloud-only-Infrastrukturen. In den vergangenen Monaten habe ich mehrere Tenants bei diesem Schritt begleitet, etwa beim Aufbau moderner Azure-Virtual-Desktop-Umgebungen oder beim schrittweisen Abschied von On-Premises-Servern.

Mit Entra Kerberos authentifizieren sich Clients direkt am File Share

Mit Microsoft Entra Kerberos müssen Clients für den NTFS-kompatiblen Zugriff auf Azure Files keinen AD-Domain-Controller mehr erreichen. Ein Entra-verbundener Client meldet sich stattdessen mit seiner Cloud-Identität direkt am File Share an. Für Zero-Trust- und Cloud-only-Szenarien bedeutet das eine deutliche Erleichterung. Voraussetzung ist ein hybrid synchronisiertes Benutzerobjekt, das in Entra ID über eine Kerberos Key Credential verfügt. Derzeit funktioniert das nur mit hybriden Identitäten, rein cloudbasierte Konten müssen sich noch gedulden.

Das folgende Diagramm zeigt, was passiert, wenn ein Entra-verbundenes Windows-Gerät per Entra Kerberos auf einen Azure File Share zugreift:

sequenceDiagram
    Teilnehmer Client
    Teilnehmer EntraID
    Teilnehmer AzureFiles
    Client->>EntraID: ["Kerberos Ticket anfordern"]
    EntraID-->>Client: ["Kerberos Ticket ausstellen"]
    Client->>AzureFiles: ["Authentifizieren mit Kerberos Ticket"]
    AzureFiles-->>Client: ["Dateizugriff gewähren"]

Abbildung: Authentifizierungsfluss mit Azure Files und Entra Kerberos

Weitere Details zu Voraussetzungen und Hintergründen finden sich direkt bei Microsoft in der Übersicht zur Active-Directory-Authentifizierung.

Die Aktivierung erfolgt im Storage Account und über RBAC-Rollen

Im Azure-Portal findet ihr die Einstellung unter Storage account → Data storage → File shares → Identity-based access. Dort schaltet ihr die Option Microsoft Entra Kerberos ein. Dafür braucht der Storage Account ein konfiguriertes Microsoft-Entra-Kerberos-Objekt. Bei der Ersteinrichtung muss ein globaler Administrator der Azure Storage Application den erforderlichen Admin Consent erteilen; das Portal fordert diesen Schritt bei Bedarf selbst an.

Danach geht es an die feingranulare Rechtevergabe. Auf Share-Ebene braucht ihr dafür RBAC-Rollen, in der Regel Storage File Data SMB Share Contributor oder Reader. Fehlt die Rollenzuweisung, bleibt der Zugriff gesperrt, selbst wenn auf Dateiebene NTFS-Berechtigungen gesetzt sind. Ein stimmiges Rechtekonzept entsteht erst, wenn RBAC und klassische Windows-ACLs zusammenspielen.

Mein Tipp: Prüft direkt nach der RBAC-Zuweisung, ob die Berechtigungen wirklich greifen. Gerade bei komplexen Gruppenstrukturen im Hybridbetrieb treten sonst gern unerwartete Nebeneffekte auf.

Die NTFS-Berechtigungen auf dem Share setzt ihr wie gewohnt mit Windows-Bordmitteln, etwa im Explorer über einen gemounteten Share oder mit icacls. Bedenkt dabei, dass euer eigener Account bereits Zugriff auf den File Share haben muss, bevor ihr die ACLs verwalten könnt.

Die Clients brauchen eine eigene Richtlinie für Cloud Kerberos

Damit Windows-Clients ihr Kerberos-Ticket tatsächlich aus der Cloud holen, muss die Policy CloudKerberosTicketRetrievalEnabled aktiviert sein. Am einfachsten erledigt ihr das in Intune mit einer Administrative-Template-Policy für den Bereich System → Kerberos. Fehlt diese Einstellung, scheitert die Verbindung zum File Share an der Authentifizierung. In Testumgebungen ist mir genau das mehrfach passiert.

So sieht die Konfiguration als Administrative-Template-Policy in Intune beispielhaft aus:

{
  "CloudKerberosTicketRetrievalEnabled": true
}

Die Policy verteilt ihr anschließend unter Intune → Gerätekonfiguration → Administrative Vorlagen → System → Kerberos.

Reine Cloud-Konten bleiben vorerst außen vor

Azure Files Entra Kerberos vereinfacht vieles, hat derzeit aber noch klare Grenzen. Unterstützt werden ausschließlich hybride Identitäten, also Benutzer, die sowohl On-Premises als auch in Entra ID existieren und synchronisiert werden. Reine Cloud-Benutzer und Gastkonten (z. B. B2B) funktionieren noch nicht. Außerdem bleibt es bei der doppelten Kontrolle: Zuerst wird die RBAC-Rolle auf dem Storage Account geprüft, danach die Windows-Dateiberechtigung auf dem Share.

Oft übersehen wird, dass die Key Credential für Kerberos nicht automatisch am Benutzerobjekt angelegt wird. Deshalb lohnt es sich, die aktuell unterstützten Registrierungsmethoden genauer anzuschauen. Microsoft beschreibt das Vorgehen ausführlich in der Dokumentation zu hybriden Identitäten.

FSLogix-Profile funktionieren jetzt auch in AVD-Umgebungen mit Entra Join

Richtig spannend wird Azure Files Entra Kerberos in Azure-Virtual-Desktop-Umgebungen, die komplett auf Entra Join setzen. Früher ließen sich Profilcontainer ohne Sicht auf einen Domain Controller nicht auf Azure Files einbinden, für hybride Benutzer klappt das inzwischen. Die Konfiguration unterscheidet sich im Prinzip nicht: Der File Share wird für Entra Kerberos aktiviert, und die Profile werden mit korrektem UPN geschrieben und gelesen. Möglich ist die Integration ab AVD-Version 1.1.1045.0. Mehr zur Entra-Join-Konfiguration im AVD-Umfeld lest ihr im Beitrag Azure Virtual Desktop mit Entra Join: kein Domain Controller?.

Hybride Identitäten erhalten damit eine solide Grundlage für Azure Files

Wer Azure Files ohne Verbindung zu einem Domänencontroller nutzen will, findet in Azure Files Entra Kerberos eine solide Basis, allerdings nur für hybride Identitäten. Nötig sind die Aktivierung im Storage Account, sauber vergebene RBAC-Rollen und NTFS-ACLs sowie die Client-Policy für Cloud Kerberos. Für viele Kunden ist das ein wichtiger Schritt weg von der Legacy-Infrastruktur und hin zu einer echten Cloud-Umgebung.