Assigning permissions when using Azure Files for FSLogix Profiles in WVD

[David Schrag]

My goal is to use a share in Azure Files to house the FSLogix profiles for users in a Windows Virtual Desktop (WVD) environment that is part of an Azure Active Directory Domain Services (AADDS) domain.

I am following instructions at https://docs.microsoft.com/en-us/azure/virtual-desktop/create-profile-container-adds.

There are two places to set permissions to the fileshare -- within the Azure portal and at the virtual machine level. In the Azure portal, you assign permissions to an Azure AD identity. At the VM level, you assign permissions to an Active Directory object that exists within the AADDS domain.

If you want to assign these permissions at the user level, there doesn't seem to be a problem. But I want to assign permissions at a group level, and I'm getting stuck. As far as I can tell, in the Azure portal you can only assign permissions to Security groups, not to Microsoft 365 groups. (When I go to the Role Assignments page and click Add, my Microsoft 365 groups do not appear.) But at the VM/domain level, you can only assign permissions to objects with an email address. Microsoft 365 groups have an e-mail address, but Security groups in Azure do not.

Does this mean we have to maintain two groups for each set of WVD users with FSLogix profiles -- a matching pair of M365 and Security groups with the same membership?

[#2]

Hi David,

You have me a confused with this line:
"But at the VM/domain level, you can only assign permissions to objects with an email address. Microsoft 365 groups have an e-mail address, but Security groups in Azure do not."

How exactly are you going about this?

When you create a Security Group on AzureAD; it will get synced to the AADDS domain. In order to set the permissions on the NTFS level you are supposed to log on to a domain-joined VM, map the File Share using the Access Key and then you set the NTFS permissions directly via Windows Explorer. You should be able to use that Synced Security Group. The user you are using to do this should have SMB Elevated Contributor on that file-share as well

[#3]

@YannickJanssens1986 First you map the file share, as you describe, with a command like this:

net use <desired-drive-letter>: \\<storage-account-name>.file.core.windows.net\<share-name> /user:Azure\<storage-account-name> <storage-account-key>

But then you assign permissions to the drive you just mapped:

icacls <mounted-drive-letter>: /grant <user-email>:(M)
icacls <mounted-drive-letter>: /grant "Creator Owner":(OI)(CI)(IO)(M)
icacls <mounted-drive-letter>: /remove "Authenticated Users"
icacls <mounted-drive-letter>: /remove "Builtin\Users"

The instructions say:

• Replace <user-email> with the UPN of the user or Active Directory group that contains the users that will require access to the share.

What is the UPN of an Active Directory group in AADDS that has been synced from a Security Group in Azure AD? Is it simply the group name? I called my group "WVD Users" and couldn't figure out the right syntax. Just now I had the bright idea to put the group name in quotes, and perhaps it worked this time:

C:\Users\wvdjoinaccount>icacls F: /grant "WVD Users":(M)
processed file: F:
Successfully processed 1 files; Failed processing 0 files

 I didn't know about the requirement for the account running these commands to have the SMB Share Elevated Contributor role. Where did you see that?

[#4]

I think the MSFT instuctions confused you a little bit by mentioning the user-email thing. The command you used seems fine. You can also browse via the explorer to the mapped disk and right-click Properties/Securty in order to set permissions that way. May work a little easier.

Disregard what I said about the SMB Elevated Contributor Permissions. When you Map via the Access key you get permissions to set NTFS in a different way.

[#5]

@YannickJanssens1986 My FSLogix profiles still aren't working right. I am seeing event log errors during login that indicated access rights problems connecting to the FSLogix share. So I tried to review and modify the permissions by mapping a drive through file explorer while logged in as an AADDS domain admin. I can view the permissions but I can't modify them. I get "Failed to enumerate objects in the container." The owner of the mapped drive is shown as SYSTEM. I tried to take ownership, but got the same "failed to enumerate" error. So maybe once the share's permissions are set using the access key they can no longer be modified by a user account through the GUI?

In any case, I'm not sure what the permissions for standard users are supposed to look like. Apart from some duplication of users and groups here, is this right, particularly with respect to the "applies to" column?

Perhaps I should start over with a new share and set the permissions with the GUI instead of the command line, but I don't have guidance for doing it that way.

[#6]

Your user needs to have SMB Elevated Contributor RBAC role on the share if you want to change permissions or connect using the Access key (you'll operate under SYSTEM then).

Does the group WVD Users have SMB Contributor RBAC role on the share?

Try verifying access before logging on through WVD. Try running Powershell as one of those users (via 'Run as Different User' context menu option) and then mapping the drive like 'New-PSDrive -Name Z -PSProvider FileSystem -Root "\\xxx.file.core.windows.net\share" -Persist'

[#7]

I assigned permissions at the storage account level and they are inherited down to the share. Is that OK? My WVD Users group has SMB Share Contributor permissions, and my AAD DC Administrators group has SMB Share Elevated Contributor permissions. The wvdsetup account, which I was using to produce the screen shot in the last post and which is unable to adjust permissions, is a member of AAD DC Administrators and WVD Users.

I had no problem creating folders or text files on the share as a member of WVD Users once I logged in, so at some basic level the permissions are working OK. But profile creation isn't working. I was thinking perhaps that the problem was because the Modify rights to the share were "This folder only," instead of "This folder, subfolders, and files." That's what I was going to test if I had been able to change the permissions on the share, but I wasn't able to while using the wvdsetup account and File Explorer. But according to https://docs.microsoft.com/en-us/fslogix/fslogix-storage-config-ht?WT.mc_id=Portal-Microsoft_Azure_S..., the way it's set now should be fine.

I don't actually have a mechanism for anyone to log in other than WVD. I have no other VMs in Azure.

[#8]

I think I might have found the problem. To make sure I got the name right, I had been copying \\xxx.file.core.windows.net\share from one screen on my computer into various places in the WVD environment. I think I had been copying and pasting a hidden character as part of that process. In group policy, I rewrote the profile container location by hand, and it seems to be working better. More testing needed, but this looks promising.

[#9]

Confirmed -- one or more hidden special characters were preventing the GPO from executing properly on login.

[#10]

Glad to see you got it working!