Nov 04 2020 02:58 PM - edited Nov 04 2020 06:49 PM
Nov 04 2020 02:58 PM - edited Nov 04 2020 06:49 PM
In the last 3 weeks, I have been getting a lot of questions around Azure Files. The main question has been “Can computer accounts have access Azure Files?”. This combined with my work on MSIX app attach (which also uses Azure Files) has prompted the creation of this post.
Azure Files supports multiple authentication mechanisms. This article is focused on authenticating with
AD DS, as described here. Hence the prerequisites are:
1. Create AD DS security group.
2. Add the computer accounts for all session hosts as members of the group
3. Synch AD DS group to Azure AD
4. Create storage account
5. Create file share under the storage account
6. Join storage account to AD DS
7. Assign the AD DS group that has been synched to Azure AD, the Storage File Data SMB Share Contributor role assignment on the storage account
8. Mount file share on any session host
9. Grant NTFS permissions on the file share to the AD DS group
This group will be used in later steps to grant share level and (files share) permissions.
Note: it is not mandatory to create a new group, an existing group can be used.
Note: If this is a new group it may take up to 1 hour to sync with Azure AD.
For brevity we will assume there is already a storage account with a file share. If required, please reference this article on how to create storage accounts. If you’re creating a new storage account, it is mandatory to create a file share.
Note: if you are creating a Premium storage account make sure Account Kind is set to FileStorage.
In this step we are going to join our storage account to AD DS. The full article is available here. Please note our steps here have been modified to achieve the desired scenario.
Note: Run the script using an on-premises AD DS credential that is synced to your Azure AD. The on-premises AD DS credential must have either the storage account owner or the contributor Azure role permissions.
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser
$SubscriptionId = "<your-subscription-id-here>" $ResourceGroupName = "<resource-group-name-here>" $StorageAccountName = "<storage-account-name-here>"
Join-AzStorageAccountForAuth ` -ResourceGroupName $ResourceGroupName ` -StorageAccountName $StorageAccountName ` -DomainAccountType "ComputerAccount" ` -OrganizationalUnitDistinguishedName "<ou-here>" ` -EncryptionType "'RC4','AES256'"
To be able to authenticate with AD DS computer accounts against an Azure Files storage account, we must also assign NTFS level permission in addition to the RBAC permission we set up earlier.
net use <desired-drive-letter>: \\<storage-account-name>.file.core.windows.net\<share-name> /user:Azure\<storage-account-name> <storage-account-key>
Note: Make sure that the output of the command above is “The command completed successfully”.
If not, repeat and verify input.
Note: Make sure that domain name matches your AD DS domain name, if it doesn’t the storage account has not been domain joined.
Common challenges with granting machine accounts access to Azure Files share authenticated with Azure AD are captured in the sections below.
When a VM is added to an AD DS group that VM needs to be restarted in order to pick up its membership to the group.
The Azure Files team have excellent troubleshooting document available here. There are few errors that I have observed occurring with higher frequency:
The synch interval between AD DS and Azure AD is 30 minutes by default. If the AD DS group was create in the last 30 minutes and cannot be assigned to the storage account, option 1 is to wait, option 2 is to force the AD DS -> Azure AD sync. Sample script, here.
For MSIX app attach and FSLogix the minimum RBAC permissions on the storage account are Storage File Data SMB Share Contributor.
For MSIX app attach and FSLogix the minimum NTFS permissions on the storage account are Read & Execute, and List folder content.
Nov 05 2020 08:15 AM
Nov 05 2020 08:17 AM
Jan 29 2021 02:30 PM
Have you gotten app attach to work on on azure file share with Azure ADDS? Despite having Azure AD DS enabled on the storage, and the session host's managed identity added to the file share SMB share contributor role and able to mount the file share successfully from the session host and have assign full access in the NTFS permissions for the the session host's account and users, getting an 'Error accessing virtual disk' when trying to enter the msix image path (see screenshot below). Any ideas?
Jan 29 2021 02:40 PM
Jan 29 2021 04:54 PM
Thanks Dean - found a response from Stefan and Tom Hickling on another forum post from earlier this month so I'm guessing its still not a workable scenario at this point.
Feb 07 2021 08:09 AM
@JeremyWallace I tried the SAS key approach and can't get that to work either. It would be nice if Stefan could give us actual steps.
Feb 08 2021 07:35 AM
@mobilejon thanks for the suggestion. We will consider it. Two things to keep in mind we are working on something that may render the need for Azure AD DS obsolete and Azure AD DS has a very low adoption in enterprise (last time I checked less than 3%)
Feb 08 2021 07:39 AM
@Stefan Georgiev for our organization, the need for LDAP translation from cloud-only accounts is very important.
Do you have steps to actually make this work in AAD-DS that have been tested and actually work?
Apr 08 2021 12:25 PM
@JeremyWallace , were you able to find a solution for this issue? We have same setup. Cloud only users and AADDS. Can't get MSIX app attach to work. Have you tried a file share on an Azure VM? Not sure what other options there might be. Just looking for ideas. Amazing how hard it's been to find info on this. Usually they will tell you that Hybrid Auth is REQUIRED or something like that but they don't in the documentation. Pretty frustrating. Thanks for any ideas.
Apr 08 2021 01:14 PM
@Chrisvanaz I don't believe that MSIX App Attach is supported with Azure AD Domain Services at all today.
I believe part of this limitation is that you don't have any rights in the AADDS Domain to assign NTFS permissions.
Apr 08 2021 01:27 PM
Apr 22 2021 10:57 AM
@Dean Cefola you are correct, we are adding this disclaimer to our documentation