Unable to access Azure storage File Share in aads using a service account

Question

Problem Description:
We are having issues trying to resolve azure storage access for service accounts (iusr_app) on our azure ad domain service called: TESTDOMAIN
The iusr_app service account is in its own OU which is in aadds.

We have a group in Azure AD called: SETUP which contains our users, this group is linked to rbac role: Storage File Data SMB Share Contributor and syncs with TESTDOMAIN. When a user logs into TESTDOMAIN on the Azure VM and runs "net use" to map to the storage account this works without asking for any credentials.

But if we remove the user from the SETUP group in Azure or if we log into the VM using the TESTDOMAIN\iusr_app account neither can map to the storage account.
System error 5 - access denied.

We have tried setting up service principals / system managed ID and User managed ID in Azure as per the MS documentation.
But none of these seem to have any effect.

We have also tried setting up storage accounts as follow:
storage1 > config > Identity-based access for file shares Azure Active Directory Domain Services (Azure AD DS) = enabled
storage2 > config > Identity-based access for file shares Azure Active Directory Domain Services (Azure AD DS) = Disabled and firewall disabled.

Required outcome:

1. Users in SETUP should be able to continue to access Azure Storage account using mapping on TESTDOMAIN as long as they are in the SETUP group in Azure AD.
   and/or
2. For accounts like the iusr_app which is not in 365 to be able to also access the Azure Storage and map the storage without prompting for credentials.

Answer 1

@Ehsan Anwar This is my understanding of the scenario you described below. Feel free to correct me if I am wrong.

Setup: AAD DS authentication enabled on the storage account, with the client machine used for log in domain joined to AAD DS
Observed behavior: If the logged in account isn’t included in the AAD group with the rbac role, access to Azure Files is denied.

This is the expected behavior. The user credential must be in AAD with the proper RBAC assignment for share level permission enforcement. In this case, the iust_app service account is not synced to AAD hence access is denied. We would need to know the use case to better comment on alternative options.

Answer 2

@Sumarigo-MSFT

Your understanding is correct.

The scenario is that the TESTDOMAIN\iusr_app needs to be able to access the azure fileshare in order to get and install software on the box using an automated process.
The reason we have not synced this account in to Azure Active Directory is for security reason as the IUSR account will potentially be utilised by 3rd party users who are in the TESTDOMAIN.

So we need a way for the IUSR account to access fileshare without revealing the access key to 3rd party users.

Answer 3

@Sumarigo-MSFT

Just another thought but are we able to have a domain account which is sync'd in azure AD but isn't accessible beyond our aadds virtual network?