Storage Account File Share Permissions

Copper Contributor

I'm new to Azure and am testing a storage account file share using file sync to pull some test data. I'm using AAD Kerberos authentication and am playing with the interaction between share-level permissions and NTFS ACLs. I'm getting results that don't seem to follow expectations.

 

I have a test group of users I've assigned 'Storage File Data SMB Share Contributor' roles to. I'm on a domain-joined machine as admin with the file share mapped using the storage account name and access key. I'm attempting to add ACLs for test user accounts, but the object search of the storage account won't return users or groups, it is only able to locate Built-in security principals. But I have discovered if I add test account ACLs on a domain machine, they do show up on the storage account share, and I can then edit the ACLs. Is this expected behavior?

 

I've also found permissions aren't following the most restrictive ones as I expect. Test accounts are read-write (from share-level 'Contributor' role), and I've just set ACLs of List for the account at the root of the share, yet in testing I'm able to read, write, and delete files. Any thoughts where I'm going wrong?

 

2 Replies

@Kidd_Ip 

Thanks for this. Per the article, I can see I haven't joined the Storage Account to local AD. Unfortunately, both the article and the Microsoft script (https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-ad-ds-enable) are failing.

 

I was running this on a local domain joined machine and the local network connectivity provider blocks port 445, so those are some of the errors I got. I'll re-try  on a remote domain-joined machine where I know 445 is open and I have VPN path to ADDS.

 

I got some additional errors on setting Samaccountname (A parameter cannot be found that matches parameter name 'SamAccountName').