Forum Discussion
Assigning permissions when using Azure Files for FSLogix Profiles in WVD
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?
- 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 wellYannickJanssens1986 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 filesI 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?
- 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.
