Entra Kerberos voor cloud-only identiteiten: wat de Azure Files-preview vraagt en waar het afwijkt van hybrid

Samantha Kloos-Kilkens
26-11-2025 · Samantha Kloos-Kilkens

Sinds 18 november kan Microsoft Entra Kerberos in public preview Kerberos-tickets voor Azure Files uitgeven aan gebruikers die alleen in Entra ID bestaan. Voor Azure Virtual Desktop met Entra-joined session hosts verdwijnt daarmee een van de belangrijkste redenen om AD DS en Entra Connect te laten staan: FSLogix-profielen op een SMB-share. De inrichting lijkt op het hybride scenario, maar autorisatie werkt anders, en één verplichte stap stond pas na de aankondiging in de documentatie. In deze blog: wat de preview vraagt, waar het afwijkt van hybrid en wat nog niet werkt.

Een glazen gevel waarin wolken weerspiegelen tegen een blauwe lucht Foto: Massimiliano Morosinotto via Unsplash

Wat er is aangekondigd en hoe de tickets lopen

De aankondiging (AZ527713 en de blogpost van het Azure Storage-team) kwam op 18 november, de eerste dag van Ignite, na een private preview die volgens de tijdlijn van de Azure-update in september begon. De scope is smal: Entra-joined Windows-clients, cloud-only gebruikers, SMB-toegang tot Azure Files, met AVD en FSLogix-profielcontainers als belangrijkste toepassing. Introduction to Microsoft Entra Kerberos noemt Azure Files en Azure Virtual Desktop als enige ondersteunde workloads voor cloud-only identiteiten. De storagekant staat in Enable Microsoft Entra Kerberos authentication for hybrid and cloud-only identities.

Aan de clientkant werkt het hetzelfde als bij hybrid. Bij het aanmelden krijgt het device naast de PRT een Cloud TGT voor de realm KERBEROS.MICROSOFTONLINE.COM, en als de gebruiker de share opent, vraagt Windows via de KDC proxy een service ticket aan voor cifs/<account>.file.core.windows.net. Entra ID versleutelt dat ticket met de sleutel van de service principal die het voor het storage account heeft aangemaakt. Het verschil zit in wat er in het ticket staat. Bij hybrid zijn dat de on-premises SID's van de gebruiker, en daarom blijven NTFS-ACL's op AD-accounts werken en worden ACL's voor niet-gesynchroniseerde identiteiten nooit afgedwongen. Een cloud-only gebruiker heeft geen on-premises SID, dus het ticket bevat de Entra-SID's van de gebruiker en zijn cloudgroepen: de property securityIdentifier in Graph, niet onPremisesSecurityIdentifier. Het AzureADKerberos-object in AD dat hybrid nodig heeft, is volgens de Entra Kerberos FAQ helemaal niet nodig.
Vergelijking van de hybride en cloud-only Microsoft Entra Kerberos-flow van een Entra-joined session host via Entra ID naar een Azure file share, met welke SID's het ticket bevat en hoe share- en bestandsrechten in elk geval worden ingesteld.

Voorwaarden voor de cloud-only preview

Zoals de documentatie er deze week bij staat, heb je dit allemaal nodig:
  • Een storage account in de publieke Azure-cloud met Microsoft Entra Kerberos als enige identiteitsbron. US Gov en 21Vianet ondersteunen alleen hybrid.
  • Entra-joined clients met Windows 11 Enterprise of Pro (single of multi-session) of Windows Server 2025 met de laatste cumulatieve update. Windows 10 en Server 2022 worden alleen voor hybride identiteiten ondersteund. De overzichtspagina van Entra Kerberos noemt Windows 10 of 11 voor cloud-only, maar de Azure Files-pagina heeft de expliciete lijst, en daar zou ik van uitgaan.
  • CloudKerberosTicketRetrievalEnabled op 1 op elke client. Op AVD multi-session rol je die uit via de Intune Settings Catalog: volgens de documentatie werkt de OMA-URI-route niet op multi-session hosts.
  • De WinHTTP Web Proxy Auto-Discovery Service en de IP Helper-service moeten draaien. WPAD uitzetten mag, de service uitzetten niet.
  • Admin consent op de app registration met de naam [Storage Account] <account>.file.core.windows.net voor openid, profile en User.Read.
  • De tag kdc_enable_cloud_group_sids op diezelfde app registration (zie de volgende sectie).
  • De storage account-app uitgesloten van elke Conditional Access-policy die MFA vereist. Zonder die uitsluiting faalt net use met system error 1327 ("Account restrictions are preventing this user from signing in"). Zoals ik het lees hoort MFA bij de aanmelding op Windows of AVD, omdat de ticketaanvraag voor de storage-app een MFA-challenge niet kan beantwoorden.
  • Een default share-level permission op het storage account, omdat cloud-only identiteiten in deze preview geen share-level RBAC per gebruiker of groep kunnen krijgen.
  • Komen clients via een private endpoint binnen, dan moet de privatelink-FQDN aan de app registration worden toegevoegd, net als bij hybrid.

De verplichte manifest-tag en de limiet op group SID's

De stap die de meeste mensen zullen missen is de tag. Volgens de publieke docs-repositories kreeg het Azure Files-artikel de sectie "Enable cloud-only groups support (mandatory for cloud-only identities)" pas laat op 19 november, en die instructies verhuisden op 20 november naar de Entra Kerberos-pagina. Wie dit heeft ingericht met de documentatie van de lanceringsdag, heeft de tag dus niet, en zonder de tag faalt de authenticatie voor cloud-only gebruikers.

De achtergrond is ticketgrootte. Een Kerberos-ticket bevat maximaal 1.010 group SID's, en met cloud-only ondersteuning moeten daar naast eventuele on-premises SID's ook cloudgroep-SID's in. Volgens de Entra Kerberos-pagina vertelt de tag de Kerberos-service dat aanvragen voor deze resource cloud-only identiteiten betreffen, waarmee (zoals de naam al zegt) cloudgroep-SID's in het ticket komen. Een gebruiker boven de limiet meldt zich gewoon aan en krijgt een PRT, maar faalt bij het aanvragen van het service ticket, en de Entra sign-in logs tonen dan fout 140011, KerberosUsersGroupNumberExceeded. De Entra Kerberos-pagina spreekt zichzelf hier tegen: de ene sectie zegt dat groepen boven de 1.010 worden weggelaten, de sectie over de tag zegt dat het ticket niet kan worden uitgegeven. Ik zou op het falen rekenen.

Het gedocumenteerde PowerShell-voorbeeld draait Update-MgApplication -Tags @("kdc_enable_cloud_group_sids"), en de Graph PATCH die daaruit volgt vervangt de hele tags-collectie. Elk storage account heeft zijn eigen app registration, dus dit moet per account. Ik zou eerst rapporteren en dan toevoegen, alleen voor de accounts die je voor cloud-only gebruikers wilt inzetten: 
Connect-MgGraph -Scopes "Application.ReadWrite.All"

# Rapport: alle storage account-app registrations en of ze de tag hebben
Get-MgApplication -All -Filter "startswith(displayName,'[Storage Account]')" -Property Id, DisplayName, Tags |
    Select-Object DisplayName, @{ n = 'CloudGroupSids'; e = { $_.Tags -contains 'kdc_enable_cloud_group_sids' } }

# Tag toevoegen voor één storage account zonder bestaande tags te verliezen
$name = '[Storage Account] <account>.file.core.windows.net'
$app  = Get-MgApplication -Filter "displayName eq '$name'" -Property Id, Tags
if ($app.Tags -notcontains 'kdc_enable_cloud_group_sids') {
    $tags = @($app.Tags | Where-Object { $_ }) + 'kdc_enable_cloud_group_sids'
    Update-MgApplication -ApplicationId $app.Id -Tags $tags
}
Om gebruikers in de buurt van de limiet te vinden voordat ze ertegenaan lopen, tel je transitieve groepslidmaatschappen. Dat is een benadering, want de documentatie zegt niet precies welke groepen in het ticket terechtkomen, maar het laat zien wie in de buurt zit: 
Connect-MgGraph -Scopes "User.Read.All", "GroupMember.Read.All"
$upn = '<user@domain>'
Get-MgUser -UserId $upn -Property UserPrincipalName, SecurityIdentifier | Select-Object UserPrincipalName, SecurityIdentifier
(Get-MgUserTransitiveMemberOfAsGroup -UserId $upn -All -Property Id, SecurityEnabled |
    Where-Object SecurityEnabled).Count

Autorisatie komt neer op één default permission en je ACL's

Met hybride identiteiten kun je share-level toegang per gebruiker of groep geven met de Storage File Data SMB Share-rollen. Cloud-only identiteiten kunnen alleen de default share-level permission gebruiken, en die geldt voor alle geauthenticeerde identiteiten en voor elke file share in het storage account. Iedereen in de tenant die een ticket voor het account kan krijgen, komt door de share-level controle, en de enige grens per gebruiker die overblijft is de NTFS-ACL.

Daarom doet de root-ACL ertoe. De gedocumenteerde standaard-ACL op de root van een Azure file share bevat NT AUTHORITY\Authenticated Users:(OI)(CI)(M). Zet je de default share-level permission op Storage File Data SMB Share Contributor (wat FSLogix-omgevingen doorgaans gebruiken) en laat je de root zoals hij is, dan kan elke geauthenticeerde gebruiker alles wijzigen op elke share in dat account. Voor FSLogix zou ik de aanbevolen FSLogix-ACL's zetten voordat de eerste gebruiker zich aanmeldt: CREATOR OWNER met Modify op alleen submappen en bestanden, de gebruikersgroep met Modify op alleen deze map, een beheergroep met Full Control, en overerving vanaf de root uitgezet. Shares voor verschillende doelgroepen zou ik ook in aparte storage accounts zetten, omdat de default permission ze niet uit elkaar kan houden.

Die ACL's zet je anders dan bij hybrid. icacls en File Explorer werken niet voor cloud-only identiteiten; je gebruikt Manage access in de Azure portal (de documentatie verwijst daarvoor naar https://aka.ms/portal/fileperms) of de RestSetAcls-module met Add-AzFileAce. Het gedocumenteerde RestSetAcls-voorbeeld bouwt zijn storage context met de account key, dus op een account waar je Shared Key-autorisatie hebt uitgezet, werkt dat voorbeeld niet zoals het er staat. De overzichtspagina van Entra Kerberos zegt bovendien dat er voor cloud-only "no NTFS ACL enforcement" is en dat autorisatie via Azure RBAC loopt. Dat strookt niet met de Azure Files-documentatie, die ACL's voor cloud-only gebruikers beschrijft en alleen een default share-level permission toestaat. Voor de share zelf volg ik de Azure Files-pagina's.

Wat nog niet werkt ten opzichte van hybrid

Vergeleken met hybride Entra Kerberos ontbreekt in de preview:
  • Share-level RBAC voor individuele cloud-only gebruikers of groepen.
  • ACL-beheer met icacls of File Explorer.
  • Hergebruik van bestaande ACL's. ACL's die van een AD-share zijn meegekopieerd, verwijzen naar on-premises SID's die niet in het ticket van een cloud-only gebruiker staan, dus wie gebruikers naar cloud-only overzet, moet de ACL's opnieuw zetten voor hun Entra-SID's.
  • Windows 10, Windows Server 2022 en de US Gov- en 21Vianet-clouds.
  • Gasten en gebruikers uit andere tenants, met uitzondering van externe identiteiten voor FSLogix op AVD, die de documentatie expliciet toestaat.
De rest gedraagt zich als bij hybrid. Zodra een client CloudKerberosTicketRetrievalEnabled heeft, kan hij geen storage accounts meer bereiken die aan AD DS gekoppeld zijn totdat je host-to-realm mappings toevoegt (Kerberos/HostToRealm of ksetup /addhosttorealmmap). Dat speelt als je FSLogix in stappen van een AD DS-share naar een cloud-only share migreert. Een storage account heeft nog steeds precies één identiteitsbron, dus overstappen vanaf AD DS betekent dat je die eerst uitzet, en daarmee ook de identity-based toegang tot dat account.

Een session host en het storage account controleren

Op de session host, als de gebruiker: 
dsregcmd /status                                      # SSO State: AzureAdPrt YES, CloudTgt YES
klist cloud_debug                                     # "Cloud Kerberos enabled by policy" hoort 1 te zijn
klist get "cifs/<account>.file.core.windows.net"      # service ticket van KERBEROS.MICROSOFTONLINE.COM
Voor het account voert Debug-AzStorageAccountAuth uit AzFilesHybrid 0.3.0 of later de Entra-controles uit, en Az.Storage laat de configuratie zien: 
(Get-AzStorageAccount -ResourceGroupName '<resource-group>' -Name '<account>').AzureFilesIdentityBasedAuth |
    Format-List DirectoryServiceOptions, DefaultSharePermission    # verwacht AADKERB
Controleer voordat je een pilotgroep toegang geeft bij elke storage account-app of de tag kdc_enable_cloud_group_sids erop staat, en vervang op de root van de share de regel voor Authenticated Users door de FSLogix-ACL's.

Update maart 2026: Het Azure Files-artikel noemt app management policies nu als voorwaarde. Als een tenantpolicy het toevoegen van wachtwoorden (symmetric keys) aan service principals blokkeert of de levensduur daarvan beperkt tot minder dan 366 dagen, mislukt het inschakelen van Entra Kerberos totdat je de policy aanpast of een uitzondering maakt voor de Storage Resource Provider (app ID a6aa9161-5291-40bb-8c5c-923b567bee3b). Zie de prerequisites.

Update mei 2026: Entra-only identiteiten voor Azure Files zijn generally available (AZ562359). Cloud-only gebruikers en groepen kunnen nu share-level RBAC per identiteit krijgen, eerst in een deel van de Azure-regio's, dus de default share-level permission is niet langer de enige optie. De manifest-tag blijft verplicht. Zie Assign share-level permissions.

Update augustus 2026: Share-level RBAC voor specifieke cloud-only gebruikers en groepen wordt nu in alle publieke Azure-regio's ondersteund, volgens Assign share-level permissions.

Bronnen

Geschreven door een expert van Argus IT

Zo’n expert in je team, of zelf zo werken in security, IAM of cloud?

Neem contact op Werken bij Argus IT
Samantha Kloos-Kilkens

Samantha Kloos-Kilkens

Samantha Kloos-Kilkens werkt al meer dan tien jaar in security en identity, waarvan acht jaar bij Microsoft in de productgroep Identity and Network Access. In 2023 richtte ze Argus IT op en ze heeft een zwak voor de verborgen pareltjes in Entra ID. CISSP, CCSP, CISM, CCSK en Microsoft Certified Trainer.

Blijf op de hoogte

Schrijf je in voor onze nieuwsbrief en ontvang een seintje wanneer we een nieuw artikel publiceren of nieuws te delen hebben.