Azure Files Entra Kerberos Cloud-Only Groups

Question

Azure Files Entra Kerberos Cloud-Only Groups

R Dorman 25

I am trying to use Entra cloud-only groups in NTFS ACL's using the Azure portal for assignment. I have done the following:

Setup a storage account in westcentralus
Enabled Entra Kerberos on the Storage Account
Admin consent the service principal
Updated app reg manifest for storage account with

"tags": [
		"kdc_enable_cloud_group_sids"
	],

Added the storage account to the MFA exemption in COnditional Access
Updated registry on client for cloud TGT retrieval
Confirmed cloud TGT issuance with klist
Confirmed access to Azure File share with TGT and session ticket
Confirmed individual user permissions assigned in the Azure portal reflect in Windows explorer
Confirmed that the unresolved SID shown with permissions matches the SID of the entra group
COnfirmed the user in question has less than 200 group memberships

When enumerating the groups on the logon TGT

# Check what groups are actually in the current Windows identity token
[System.Security.Principal.WindowsIdentity]::GetCurrent().Groups | 
    ForEach-Object { $_.Translate([System.Security.Principal.NTAccount]) }

I only get well known groups, no other group SIDs which is why the Azure file share permissions are not allowing the user to access the folder the has been locked down. How can I get the TGT to be populated with the group SIDs of the cloud-only groups so that I can grant Azure Files access?

VEMULA SRISAI 13,985 Reputation points Microsoft External Staff Moderator

2026-06-22T03:40:34.52+00:00
Hello **R Dorman,**Thanks for sharing the detailed troubleshooting steps — your configuration and validation look correct.Based on your findings, this behavior is expected with the current Microsoft Entra Kerberos implementation for Azure Files, especially when working with cloud-only groups.

What is happening:

In Entra Kerberos, the Cloud TGT issued to the client does not include full group SID expansion like traditional AD Kerberos.

When you check the token using: PowerShell Show more lines it will only show well-known groups, and not the Entra cloud-only group SIDs.

Due to this, NTFS ACL evaluation cannot resolve or expand those cloud-only group memberships, even though the SID is correctly present on the ACL.

Current supported behavior / recommendation:

Use on-prem AD DS groups (or synced groups via Entra Connect) for NTFS ACL assignments — these are properly expanded and evaluated

Alternatively, assign permissions directly to users at the NTFS level

You can still use Entra groups for share-level RBAC, but not reliably for NTFS authorization in cloud-only scenarios
R Dorman 25 Reputation points

2026-06-22T13:16:01+00:00

Vemula

Thanks for the info, see the accepted answer below. This may be region specific according to the docs (US is west central only) but it does work using the fix in the answer below. The logon ticket doesn't show group membership but they must be coming down with the CIFS ticket.

Answer accepted by question author

0 additional answers

Your answer

VEMULA SRISAI 13,985 Reputation points Microsoft External Staff Moderator

2026-06-22T03:40:34.52+00:00

Hello **R Dorman,**Thanks for sharing the detailed troubleshooting steps — your configuration and validation look correct.Based on your findings, this behavior is expected with the current Microsoft Entra Kerberos implementation for Azure Files, especially when working with cloud-only groups.

What is happening:

In Entra Kerberos, the Cloud TGT issued to the client does not include full group SID expansion like traditional AD Kerberos.

When you check the token using: PowerShell Show more lines it will only show well-known groups, and not the Entra cloud-only group SIDs.

Due to this, NTFS ACL evaluation cannot resolve or expand those cloud-only group memberships, even though the SID is correctly present on the ACL.

Current supported behavior / recommendation:

Use on-prem AD DS groups (or synced groups via Entra Connect) for NTFS ACL assignments — these are properly expanded and evaluated

Alternatively, assign permissions directly to users at the NTFS level

You can still use Entra groups for share-level RBAC, but not reliably for NTFS authorization in cloud-only scenarios
R Dorman 25 Reputation points

2026-06-22T13:16:01+00:00

Vemula

Thanks for the info, see the accepted answer below. This may be region specific according to the docs (US is west central only) but it does work using the fix in the answer below. The logon ticket doesn't show group membership but they must be coming down with the CIFS ticket.

Answer 1

Hello R Dorman,

Greetings! Thanks for raising this question in the Q&A forum.

You've done an impressive amount of groundwork here TGT confirmed, session ticket working, individual user permissions reflecting correctly so this is not a setup failure. The core issue is a well-known behavior of how the Cloud TGT is issued and when group SIDs get populated into the Windows identity token.

Here's what's happening: When a user signs in to a Windows device, Microsoft Entra ID issues the Cloud TGT for the realm KERBEROS.MICROSOFTONLINE.COM alongside the Primary Refresh Token (PRT). However, it also issues an OnPremTgt (partial TGT) that contains the user's SID but no group claims. This is why your WindowsIdentity.GetCurrent().Groups call only shows well-known groups the logon token at the Windows session level does not contain cloud group SIDs. The cloud group SIDs are only included in the Kerberos service ticket issued at the time the SMB connection is made to the Azure Files endpoint not in the Windows logon identity token.

In other words, checking WindowsIdentity.GetCurrent().Groups will never show Entra cloud group SIDs because that reflects the logon token, not the service ticket. This is expected behavior. Below are the steps to confirm everything is correctly wired up and to ensure the group SIDs do reach Azure Files at access time:

Step 1: Verify the kdc_enable_cloud_group_sids tag took effect correctly

Go to Entra ID > App registrations, find the app for your storage account (named [Storage Account] <storage-account-name>.file.core.windows.net), open the Manifest, and confirm the tags section looks exactly like this:

"tags": [
    "kdc_enable_cloud_group_sids"
]

This tag ensures that Entra will include cloud-only Entra ID groups in the Kerberos ticket, instead of only on-premises groups. After saving, sign out and sign back in on the client to force a fresh PRT and TGT.

Step 2: Force a fresh sign-in and purge old tickets

The TGT is baked in at logon time. After any manifest or configuration change, you must sign out of Windows completely and sign back in. Then clear stale tickets:

klist purge

Sign back in and verify the TGT is freshly issued from the cloud KDC:

klist

You should see a ticket for the realm KERBEROS.MICROSOFTONLINE.COM.

Step 3: Verify cloud group SIDs are in the service ticket, not the logon token

Instead of checking WindowsIdentity.GetCurrent().Groups (which reflects the logon session), request the service ticket for the Azure Files endpoint and inspect it:

klist get cifs/<storage-account-name>.file.core.windows.net

The group SIDs for your Entra cloud-only groups should be embedded in this service ticket. Azure Files evaluates NTFS ACLs against this ticket, not the logon token.

Step 4: Confirm the Entra group type is a Security group (not Microsoft 365 group)

Only Security groups are supported for NTFS ACL enforcement with Entra Kerberos. Microsoft 365 groups and distribution groups are not included in Kerberos tickets. Verify the group type in Entra ID > Groups.

Step 5: Confirm the group is not nested

Azure Files does not expand nested security groups. If your cloud-only group is a member of another group, the NTFS ACL must be set directly on the group the user is a member of.

Step 6: Confirm RBAC is assigned at share level as well

NTFS ACLs alone are not sufficient. The user or their group must also have a share-level RBAC role such as Storage File Data SMB Share Contributor or Reader assigned on the file share. Both layers share-level RBAC and NTFS ACL must be in place.

Step 7: Run the built-in diagnostic tool

Use the Debug-AzStorageAccountAuth cmdlet to run a full health check:

$ResourceGroupName = "<resource-group-name>"
$StorageAccountName = "<storage-account-name>"

Debug-AzStorageAccountAuth `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -Verbose

This checks admin consent, SPN registration, RBAC assignments, registry keys, and more in one pass.

Step 8: Check Entra sign-in logs for group SID errors

In Entra sign-in logs, a SID overflow appears as error 140011 – KerberosUsersGroupNumberExceeded. Even though you mentioned the user has fewer than 200 groups, it's worth confirming this error is not present in the logs under Entra ID > Monitoring > Sign-in logs, filtered by the user in question.

To summarize: the WindowsIdentity.GetCurrent().Groups output is the expected and correct behavior — it reflects the logon token, which does not carry cloud group SIDs by design. The cloud group SIDs travel in the service ticket issued when the SMB connection is established. As long as the kdc_enable_cloud_group_sids tag is in place, admin consent is granted, the group is a non-nested security group, and share-level RBAC is assigned, the access should work.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.

R Dorman 25 Reputation points

2026-06-22T12:59:24.32+00:00

Thank you for your detailed reply. The trick was the Azure RBAC for those two groups in addition to the NTFS permissions. I had granted SMB Elevated Contributor to the group not regular contributor. As soon as I flipped that over everything started to work as expected!

That said - out of curiosity - the klist

The output of the klist for the Azure Files cifs ticket does not contain any information about groups. Should it?

PS C:\Users\RyanDorman> klist get cifs/xxxx.file.core.windows.net Current LogonId is 0:0x7fe348 A ticket to cifs/xxxxx.file.core.windows.net has been retrieved successfully. Cached Tickets: (2) #0> Client: rdorman@.com @ AzureAD Server: krbtgt/KERBEROS.MICROSOFTONLINE.COM @ KERBEROS.MICROSOFTONLINE.COM KerbTicket Encryption Type: Unknown (-1) Ticket Flags 0x40810000 -> forwardable renewable name_canonicalize Start Time: 6/22/2026 8:43:44 (local) End Time: 6/22/2026 18:43:44 (local) Renew Time: 6/29/2026 8:43:44 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x400 -> 0x400 Kdc Called: TicketSuppliedAtLogon #1> Client: rdorman@.com @ AzureAD Server: cifs/xxxxx.file.core.windows.net @ KERBEROS.MICROSOFTONLINE.COM KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40000000 -> forwardable Start Time: 6/22/2026 8:44:19 (local) End Time: 6/22/2026 9:44:19 (local) Renew Time: 0 Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0 Kdc Called: KdcProxy:login.microsoftonline.com