This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(208, 98%, 30%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBR%3C/text%3E%3C/svg%3E)
I have ran and re-ran through the prerequisites.
"The Azure AD Kerberos functionality for hybrid identities is only available on the following operating systems:
Windows 11 Enterprise single or multi-session.
Windows 10 Enterprise single or multi-session, versions 2004 or later with the latest cumulative updates installed, especially the KB5007253 - 2021-11 Cumulative Update Preview for Windows 10.
Windows Server, version 2022 with the latest cumulative updates installed, especially the KB5007254 - 2021-11 Cumulative Update Preview for Microsoft server operating system version 21H2.
To learn how to create and configure a Windows VM and log in by using Azure AD-based authentication, see Log in to a Windows virtual machine in Azure by using Azure AD.
This feature doesn't currently support user accounts that you create and manage solely in Azure AD. User accounts must be hybrid user identities, which means you'll also need AD DS and Azure AD Connect. You must create these accounts in Active Directory and sync them to Azure AD. To assign Azure Role-Based Access Control (RBAC) permissions for the Azure file share to a user group, you must create the group in Active Directory and sync it to Azure AD.
You must disable multi-factor authentication (MFA) on the Azure AD app representing the storage account.
Azure AD Kerberos authentication only supports using AES-256 encryption."
I have a test environment.
and trying to use an Azure VM to authenticate to AAD.
get error:
C:\Users\username>net use n: \StorageAccount.file.core.windows.net\FileShare
Enter the user name for 'StorageAccount.file.core.windows.net': username@modeluemlab.com
Enter the password for StorageAccount.file.core.windows.net:
System error 86 has occurred.
The specified network password is not correct.
I can connected through the share access key with the username being the azure\StorageAccount
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(9.6, 85%, 10%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMV%3C/text%3E%3C/svg%3E)
I have struggled with this for a bit, turned out I had not excluded the service principal for the storage account for all conditional access policies, after fixing this, everything worked just fine.
I had the exact same issue described here but the fix was to allow the traffic through the firewall.
so strange how these errors manifest.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(262.40000000000003, 67%, 35%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMP%3C/text%3E%3C/svg%3E)
For us, it was Cloud Kerberos Tickets not arriving, because a mistake in Entra Connect Setup, because of that it was not able to match the account logging on to the on-prem machine and the account in Entra. Thus no Kerberos Ticket was issued to the Client even though the Reg entry was done.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(307.2, 78%, 39%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESA%3C/text%3E%3C/svg%3E)
Hi @Michael Patrick Richter can you elaborate further on what you did to solve this? Are you using Entra ID Kerberos Authentication for the Storage Account or using Active Directory Domain Services authentication? What did you modify in Entra Connect? Thanks for your help
@Sebastian Astua A client had the on-prem user 1234@example.com synchronized and transformed to firstname.lastname@example.com. Because of that, there was no match for the User to receive a cloud Kerberos ticket.
Solution was to synchronize 1:1 (1234@example.com - on premise to 1234@example.com - in Entra).
To keep the possibility to log on with first.last@example.com, we enabled "Email as alternate login ID" in the Entra connect settings online.
We actually rolled out this feature only to a defined group via PS Script / Graph since we did not want to have a big bang with thousands of users.
After doing that, the clients (with receive Cloud Kerberos Tickets at logon enabled) received the Cloud Kerberos Tickets and we were able to map the Azure Fileshare successfully.
How did you find this out? What exactly was miscondigured on Entra connect?