Authentication Issues using AAD Kerberos for Azure file shares

Question

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

Answer 1

Hello @Benjamin Ra ,

Welcome to the MS Q&A Forum.

This article lists common problems that are related to Microsoft Azure Files when you connect from Windows clients.

Second, try mounting Azure file share with storage account key. If the share fails to mount, download AzFileDiagnostics to help you validate the client running environment, detect the incompatible client configuration which would cause access failure for Azure Files, give prescriptive guidance on self-fix, and collect the diagnostics traces.

Third, you can run the Debug-AzStorageAccountAuth cmdlet to conduct a set of basic checks on your AD configuration with the logged on AD user. This cmdlet is supported on AzFilesHybrid v0.1.2+ version. You need to run this cmdlet with an AD user that has owner permission on the target storage account.

Unzip the files, and run a Powershell with ADM rights where you have the files:

$ResourceGroupName = "<resource-group-name-here>"  
$StorageAccountName = "<storage-account-name-here>"    
Debug-AzStorageAccountAuth -StorageAccountName $StorageAccountName -ResourceGroupName $ResourceGroupName -Verbose  

Above cmdlet performs these checks below in sequence and provides guidance for failures: (here)

PS: I don't find if this limitation is still actual, anyway I want to point to it: "Issues Description Azure files supports Kerberos authentication with AD auth with RC4-HMAC and AES 256 encryption. AES 256 encryption support is currently limited to storage accounts with names <= 15 characters in length and needs to be manually enabled for accounts which already have AD Auth enabled. "

Sincerely,
Olga Os

Answer 2

Got it working.

My colleague spotted that you need Windows 10 Enterprise rather than Win 10 Pro. Either that, or the the build wasn't high enough.

After deploying a new Win 10 Enterprise 21H2 19044.2006 and adding the registry key: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1, it connected immediately with no credentials or line of site from AD.

Also worth noting that the machine needs to be Azure AD Joined (not registered), by setting up for an organization.

References:

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.

Answer 3

I'm also investigating this at the moment. I am testing from a Windows 10 machine (not in line of sight to an DC)

I have followed the pre-requites, particularly, I am using a synced AD account in AAD, that the share has been mounted on another machine using the key and set AD permissions. (I have re-set the permissions as this storage account was initially set to use AD authentication). I have ensured the user account is a SMB contributor and the storage account has been granted the API permissions.

I have set the CloudKerberosTicketRetrievalEnabled = 1 and I have tried using an Azure joined machine (thinking that the machine needs to be logged in with AAD credentials, rather than just entering the credentials in a SMB dialog). There are no conditional access policies configured (no endpoint license) and per-user MFA is not configured on the user account, but I get 'The user name or password is incorrect' when I try and mount the SMB share.

I have also allowed RC4_HMAC_MD5 and AES256_HMAC_SHA1 in local security policy

Also worth mentioning that if you use 'Windows Hello', make sure you sign in with a password not the pin, since this doesn't normally work with AD authentication on any day.

When the dialogue first appears when trying to mount the share, I note I receive: 'The system cannot contact a domain controller to service the authentication request'
Then it precedes to show: 'The user name or password is incorrect' when trying to enter the UPN of the user. I have tried using 'AzureAD\<username>' format also.

Would really like to see this working, I guess this is why it is in preview?

Answer 4

It's going to sound super stupid but I think I found my issue.

Despite following the documentation strictly and reading if over and over. I went back to basics. Seeing error 86 every time I tried to map the share, spent a whole day trying to figure out what was going on.

My share was set up to deny access, explicit allow on a particular local AD group (Sync to AzureAD).

What I hadn't accounted for was configuring NTFS permissions on the share as well. So I logged in as another dummy account, mapped the drive using the Storage Account Key and then set NTFS permissions for the same AzureAD Group but using the local AD Group as the target.

Logged back in as my original user and the drive mapped straight away.

I'm just confirming that this is working as expected; and not somehow using a cached storage key. As I believe the storage key gives you 'superuser' access, and the user was only able to read which is how I've configured share/ntfs. So looking good.

Hope this helps someone else.

Answer 5

Also worth mentioning that if you use 'Windows Hello', make sure you sign in with a password not the pin, since this doesn't normally work with AD authentication on any day.

This matters if you're using NTLM, since that requires a cached password, however its not required for Azure Kerberos. Windows Hello / Pin is fine.