Why is authentication required for Azure FileShare mapping via 'traditional' GPO?

Question

Hi All,

I encountered an issue with mapping network drives via GPO from an azure DC to a cloud VM.

The users would connect to this VM via remote apps and part of the applications function would be related to browsing through local & mapped directories. For reasons stated on the forums for this bit of software we had to map the Azure FileShare drives via group policy from the DC (as opposed to an intune mapping policy for example).

I managed to fix the issue where the drives were refusing to map by simply authenticating with MFA as the user on the VM, done through signing into OneDrive with them and prividing MFA when prompted.

My questions is why the mapping failed, despite event viewer showing no errors or issue with the application of the policy and no issues with the mapping of the drive? My prior experience with GPOs like this and on-prem storage is that even if the user doesn't have access to the drive it would still map but in a disconnected state as the policy has no eyes on the access side of things, it just checks is the resource exists and then maps it. I am incorrect in saying that?

I not, then what is it specifically with Azure FileShares that causes this to behave differently and where can one find the logs in the future for troubleshooting this? When researching the issue the general consensus I found from multiple online sources was that no licences were needed, as you pay for the storage, which implies there would be no need to authenticate as one cannot auth in Azure without a valid licence.

As mentioned prior event viewer showed no errors with the mapping, no warnings, all the expected messages you would see following a successful mapping of the drive, locating the policy, downloading it, applying it, all that good stuff. However, the drive would not be mapped at all, not in a disconnected state, nothing when running net use. Gone.

Hoping one of you wizards who are far more knowledgeable than I can shed some light on this one for me.

Thanks in advance.

Answer 1

Joseph hi,

great question, and thanks for bringing this up ))

unlike traditional on prem shares, azure files requires active authentication before it even lets u see the drive. its not just about checking if the resource exists like u said. azure files is picky like that ))

the key difference? azure files uses smb 3.0 with identity based auth. this means it wont even show u a disconnected drive if u dont prove who u are first https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-active-directory-enable

aha, and about those logs u asked for? check azure storage analytics logs. they'll show u the auth attempts that failed silently. its different from regular file server logs, i know ))

make sure u enabled ad ds auth for azure files first (link above), use group managed service accounts if u can. they handle the auth automatically https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-ad-ds-enable. For remote app users, consider azure ad join instead of pure gpo. works smoother in cloud setups.

worth looking into the mfa thing u did actually created a fresh auth token. thats why it suddenly worked! azure ad was like 'oh finally u proved its u' ))

As well check the ntfs permissions on the share itself. sometimes they block things silently too. this might help in other tools too always look for hidden auth requirements in cloud storage. they love doing that nowadays.

let me know if the gmsa route works for u..

rgds,

Alex