In meinen Azure-Kursen taucht das Thema Azure Files-Authentifizierung regelmäßig auf – und zwar fast immer in Verbindung mit der Frage: „Brauche ich dafür noch Active Directory?“ Die Antwort war bislang: Jein. Mit der allgemeinen Verfügbarkeit von Entra Only Identitäten für Azure Files ändert sich das nun grundlegend. Microsoft hat im Mai 2025 bekanntgegeben, dass Entra Only Authentication für Azure Files-SMB-Freigaben (Server Message Block) nun GA (Generally Available) ist. Das ist eine relevante Weiterentwicklung gegenüber dem bestehenden Entra Kerberos-Ansatz für Hybrid-Identitäten – und die Unterschiede sind praxisrelevant.
Was bisher galt: Entra Kerberos für Hybrid-Identitäten
Wer Azure Files per SMB mit Identitäten aus Microsoft Entra ID (vormals Azure AD) absichern wollte, war lange Zeit auf einen Hybrid-Ansatz angewiesen. Das Stichwort lautet Entra Kerberos – ein Verfahren, bei dem Entra ID Kerberos-Tickets für den Zugriff auf Azure Files ausstellt, aber weiterhin ein On-Premises Active Directory (AD DS) als Identitätsquelle voraussetzt oder zumindest eine Synchronisierung über Microsoft Entra Connect.
Kerberos (ein netzwerkbasiertes Authentifizierungsprotokoll) ist das Standardprotokoll für SMB-Authentifizierung in Windows-Umgebungen. Entra Kerberos macht es möglich, Kerberos-Tickets über Entra ID auszustellen – aber die Identitäten müssen dabei aus einem hybriden Verbund stammen: On-Premises-Benutzerkonten, die per Entra Connect in die Cloud synchronisiert wurden. Reine Cloud-Identitäten – also Konten, die ausschließlich in Entra ID existieren und kein synchronisiertes AD-Pendant haben – funktionieren mit Entra Kerberos nicht zuverlässig.
Ich hatte mich in diesem Zusammenhang oft gefragt, wann Microsoft hier den nächsten logischen Schritt geht. Dieser Schritt ist jetzt vollzogen.
Im Storage Account lässt sich die Authentifizierungsmethode für Azure Files direkt im Portal konfigurieren.
Was neu ist: Entra Only Identitäten – Cloud-First ohne AD-Abhängigkeit
Mit Entra Only Authentication (offiziell: „Azure AD-only authentication“ bzw. „Microsoft Entra-only identities“) löst Microsoft die Abhängigkeit vom On-Premises-AD vollständig auf. Benutzerkonten, die ausschließlich in Entra ID existieren – Stichwort Cloud-only Users – können nun direkt SMB-Zugriff auf Azure Files erhalten, ohne dass ein Kerberos-Ticket über ein hybrides Setup ausgestellt werden muss.
Das funktioniert technisch über einen anderen Authentifizierungspfad: Statt Kerberos kommt hier OAuth 2.0-basierte Authentifizierung in Kombination mit dem SMB-Protokoll zum Einsatz. Microsoft hat dafür die nötige Infrastruktur in den Azure Files-Dienst integriert. Der Client (typischerweise Windows 11 oder ein Azure-joined Device) holt sich ein Token über Entra ID und legitimiert damit den Zugriff auf die Dateifreigabe.
Voraussetzungen für Entra Only in der Praxis:
- Storage Account muss auf Entra Only Authentication umgestellt sein
- Clients müssen Microsoft Entra joined (reine Cloud-Domäne) oder Microsoft Entra hybrid joined sein
- Windows 11 22H2 oder neuer wird empfohlen; Windows 10 ist in Teilen unterstützt
- Die Benutzer müssen über RBAC-Rollen (Role-Based Access Control) auf Freigabe-Ebene berechtigt sein
Merksatz: Entra Only Authentication setzt kein On-Premises Active Directory voraus – weder für die Identitäten noch für die Ticket-Ausstellung. Das ist der fundamentale Unterschied zu Entra Kerberos.
Gegenüberstellung: Entra Kerberos vs. Entra Only
Kurz knapp und strukturiert, zum Abharken – hier die wesentlichen Unterschiede beider Ansätze:
| Merkmal | Entra Kerberos (Hybrid) | Entra Only (Cloud-only) |
|---|---|---|
| Identitätsquelle | Hybrid-Identitäten (AD DS + Entra ID Sync) | Reine Entra-ID-Konten (Cloud-only) |
| On-Premises AD erforderlich | Ja (als Identitätsquelle oder Sync-Quelle) | Nein |
| Authentifizierungsprotokoll | Kerberos (Tickets über Entra ID) | OAuth 2.0 / Token-basiert |
| Unterstützte Clients | Hybrid-joined, AD-joined Geräte | Entra-joined, Hybrid-joined Geräte |
| NTFS-Berechtigungen (ACLs) | Ja, vollständig unterstützt | Ja, via Storage-RBAC und NTFS-ACLs |
| Zielgruppe | Unternehmen mit bestehendem AD-Footprint | Cloud-native Organisationen, neue Tenants |
| GA-Status (Stand: Mai 2025) | GA seit längerem verfügbar | Neu GA (Mai 2025) |
| Azure Virtual Desktop (AVD) | Unterstützt, klassischer AVD-Use-Case | Unterstützt, besonders für Cloud-only AVD |
Der Connect-Dialog für Azure Files zeigt die verfügbaren Authentifizierungsoptionen – hier mit Entra-Identität.
Der News-Case: Warum das jetzt relevant ist
Microsoft hat die GA-Verfügbarkeit von Entra Only Identitäten in Azure Files im offiziellen Azure Blog kommuniziert. Der Hintergrund ist klar: Immer mehr Organisationen – gerade kleinere und mittlere Unternehmen sowie Cloud-native Startups – betreiben keinen eigenen Active Directory-Server mehr. Sie verwalten ihre Identitäten ausschließlich in Entra ID, nutzen Intune für das Device Management und sind nie in einem klassischen Hybrid-Verbund gewesen.
Für genau diese Zielgruppe war Azure Files als zentraler Dateiserver bislang nur bedingt tauglich, wenn es um identitätsbasierte Authentifizierung ging. Entra Only schließt diese Lücke. Gleichzeitig ist das ein Signal in Richtung Azure Virtual Desktop (AVD): Profile-Container auf Basis von FSLogix, die auf Azure Files liegen, können nun auch in rein Cloud-nativen AVD-Deployments per Entra Only gesichert werden – ohne AD DS im Hintergrund.
Praxistipp: Wer heute ein neues AVD-Deployment plant und kein On-Premises-AD betreibt, sollte Entra Only von Anfang an einplanen. Ein nachträgliches Umstellen des Storage Accounts von Hybrid auf Entra Only ist möglich, erfordert aber sorgfältige Planung der bestehenden ACL-Strukturen.
In meinen Azure-Kursen behandeln wir Azure Files-Authentifizierung im Kontext von AVD und Hybrid-Infrastrukturen regelmäßig – und diese Neuerung wird künftig einen eigenen Abschnitt bekommen.
Berührungspunkte beider Ansätze und Koexistenz
Noch mal in Kürze: Entra Kerberos und Entra Only schließen sich nicht gegenseitig aus – sie adressieren unterschiedliche Szenarien. Ein Tenant kann durchaus beide Varianten in verschiedenen Storage Accounts betreiben. Innerhalb eines einzelnen Storage Accounts ist jedoch nur eine Authentifizierungsmethode aktiv.
Der Berührungspunkt liegt beim Hybrid-joined Device: Ein Gerät, das sowohl AD DS als auch Entra ID beigetreten ist, kann theoretisch auf Storage Accounts beider Typen zugreifen – vorausgesetzt, die jeweiligen Nutzeridentitäten passen zur konfigurierten Methode. Ein Cloud-only User auf einem Hybrid-joined Device kann auf einen Entra-Only-Storage-Account zugreifen, nicht aber auf einen, der auf Entra Kerberos mit AD-Synchronisierung konfiguriert ist.
Praxisempfehlung: Welcher Ansatz für wen?
Folgendes Problem aus der Praxis: Viele KMU fragen mich, ob sie für Azure Files als zentralen Dateiserver noch einen Domain Controller in Azure betreiben müssen. Die Antwort lautet ab sofort klarer als je zuvor: Nein – sofern alle Nutzer als Cloud-only-Identitäten in Entra ID verwaltet werden und die Clients Entra-joined sind.
Eine KMU-taugliche Entscheidungsstruktur sieht so aus:
| Ausgangssituation | Empfehlung |
|---|---|
| Bestehendes On-Premises-AD, Hybrid-Sync läuft | Entra Kerberos – bewährt, keine Migration nötig |
| Neues Deployment, kein AD geplant | Entra Only – direkt und ohne AD-Overhead |
| AVD mit Cloud-only-Nutzern, FSLogix auf Azure Files | Entra Only – explizit für diesen Use-Case designed |
| Migration von On-Premises-Fileserver in die Cloud | Entra Kerberos als Übergangslösung, Entra Only als Ziel bei AD-Abbau |
Wer tiefer in die Materie einsteigen möchte – sowohl in die Identitätsverwaltung mit Entra ID als auch in Azure Files-Szenarien für AVD und Hybrid-Umgebungen – findet in meinen Azure-Kursen praxisnahe Inhalte dazu. Die Neuerung rund um Entra Only Identitäten zeigt einmal mehr: Der Weg in eine reine Cloud-Identitätswelt ist keine Zukunftsvision mehr, sondern produktionsreif.