none
How to manage Folder level security in gen 2 HNS RRS feed

  • Question

  • Hi,

     I have an ADLS gen2 storage account with Hierarchical Namespace enabled. I want to test the folder level security but don't seem to get the expected result. What I dis is the following:

    -          I created a container named ‘testcontainer’. Public access level: private.

    -          In the container I created three folders:

    o   Folder1 had the default ACL rights

    o   For folder2 I gave the account me@company.com Read rights (on top de default rights for superusers)

    o   For Folder3 I gave the account me@company.com Read, write and Execute rights (on top de default rights for superusers).

    -          All the right are set using Azure Storage Explorer.

    -          The account me@company.com is in Azure AD and has no roles or rights on this subscription, resourcegroup, storageaccount or container. Only ACL assignments on the folders.

     What I expected to find is that, when I login with this account, I would be able to see Folder2 and Folder3. I expected to see the content of folder3 and perhaps also folder2 (not sure if you need execute rights). And last but not least, I expected to be able to upload files to Folder3.

    To test this I use Azcopy and login with me@company.com. Then I run these three command, which all generate the error ‘ResourceNotFound’:

    -          azcopy list https://<storageaccount>.blob.core.windows.net/testcontainer

    -          azcopy list "https://<storageaccount>.blob.core.windows.net/testcontainer/Folder2"

    -          azcopy list "https://<storageaccount>.blob.core.windows.net/testcontainer/Folder3"

    I don’t understand stand why the last two generate errors.

    Then I tried copying files like so:

    -          azcopy.exe cp "C:\Temp\Upload\*.txt" "https:// <storageaccount>.blob.core.windows.net/testcontainer/Folder3" --recursive=true

    The copy starts but end up as a failed transfer. The log has this error: UPLOADFAILED: %5C%5C?\C:\Temp\Upload\UploadFile.txt : 404 : 404 The specified resource does not exist.. When Uploading blob.

    I also tried both listing and copying with the dfs endpoint instead of the blob. The list will give this error “invalid path passed for listing. given source is of type 5 while expect is container / container path”. The copy action generates this error “RESPONSE ERROR (ServiceCode=AuthorizationPermissionMismatch) ===== Description=403 This request is not authorized to perform this operation using this permission.”

    When I assign this user the “Storage Blob Data Contributor” role to the container, I can upload and list correctly with the same commands but I can do so to all folders (which I know is by design).

    So, my question is, what am I missing here?


    Friday, November 1, 2019 12:52 PM

Answers

  • Hi,

    I figured out the problem. If you want to give read/write access to Folder1A (seem example above) to Principal X, than you need to grant principal X 'Execute' rights to all folders above it and the container itself. So in this case, execute rights should be goven to Folder1 and ContainerA.

    With the execute right the user cannot see the content but it is needed to traverse the structure. In the MS article mentioned above it is said that this is only necessary voor service principals but apparently it is necessary for all principals.

    Thursday, November 7, 2019 8:30 PM

All replies

  • Hi Thijs,

    It can take 5 minutes for role changes to take full effect. So if you tried immediately after the change, it may be just that you tried to soon. If you may have done all your testing within 5 or 10 mins of the permission change, could you retest one more time please?

    Oh, and if using --tenant-id, remember that it must be the tenant id that owns the storage account (i.e. what you want to authenticate to). (The difference is important in cases where the account's home tenant is not the one where the storage account lives).


    This should resolve the issue. Note that you can assign a role to parent subscription or resource group, but it takes time for the assignment to propagate down to the storage account. If you assign the role to the subscription or resource group and then create the storage account after that, the assignment should be inherited immediately. In terms of completing tutorial, if you already have a storage account that you're using, it's best to assign directly to the storage account so that you aren't blocked and you don't have to wait.

    Ref- https://github.com/MicrosoftDocs/azure-docs/issues/25273

    https://github.com/Azure/azure-storage-azcopy/issues/499

    Hope this helps.

    Wednesday, November 6, 2019 7:07 AM
    Moderator
  • HI ChiragMishra,

    Thanks for your reply!

    The thing is, I have not assigned a role at all. The user I use has no role assigned to the container. Nor does it have any roles assigned at a higher level (storage account, resource group or subscription). The only rights have I have granted it are on a folder inside a container. So I want to use ACL assignment, not the role assignment as these are to coarse. I based this on this MS article: https://docs.microsoft.com/en-us/azure/storage/blobs/data-lake-storage-access-control . In it, it explicitly states that Roles will always overrule the ACL based rights. Remember that I am using ADLS gen2 with Hierachical namespace enabled so folder level security should be possible. 

    So my question is, if I have the underlying structure, is it possible give a user read and write acces to 'Folder1A' (and all subfolders/files like Folder1A1 and Folder1A2) but not given it any read rights on any of the other folders? And, if so, what need I do differently than I described above?

    StoarageAccountA
    --ContainerA
    ----Folder1
    ------Folder1A
    --------Folder1A1
    --------Folder1A2
    ------Folder1B
    ----Folder2
    ------Folder2A


    Hope you can help me. Kind regards.

    Wednesday, November 6, 2019 3:55 PM
  • Hi,

    I figured out the problem. If you want to give read/write access to Folder1A (seem example above) to Principal X, than you need to grant principal X 'Execute' rights to all folders above it and the container itself. So in this case, execute rights should be goven to Folder1 and ContainerA.

    With the execute right the user cannot see the content but it is needed to traverse the structure. In the MS article mentioned above it is said that this is only necessary voor service principals but apparently it is necessary for all principals.

    Thursday, November 7, 2019 8:30 PM
  • Glad to hear that the prob was resolved. Thanks for sharing the resolution :)
    Friday, November 8, 2019 11:13 AM
    Moderator