Azure File Share with AAD Permissions + IIS in an Azure Virtual Machine
After hearing about Azure File Shares supporting Active Directory security a little while back, I finally had a chance to give it a go! Only it didn’t go so well for what we needed 🙁
To give some backstory – We have a large file share on-premises which is used by some internal software that we have developed. One thing we want to do is move this software to the cloud but to be able to move the software we would still need access to the file shares. There is a service to recover NAS data that will be able to solve this issue in no time. A VPN connection would be required for things like access to network printers (I’ll touch on the VPN connection in another post) and while a VPN will also give access to the file shares our on-premises internet connection is limited to 50/50Mbps and initial testing showed accessing these resources via our WAN link was anywhere between 4-10x slower depending on what we were doing on the office network.
Cue Azure File Share! When we were initially planning out this move about 1.5+ years ago we ended up setting up an Azure File Share in consultations with M18 Solutions and the Azure File Sync tool on our file server on-premises. This created a copy of all of our resources in Azure while still allowing some legacy desktop software to access the on-premises shares. Brilliant. We were in a position to access the files at lightning speed in Azure while also working without interruption on-premises.
Only Azure File Shares at the time didn’t support AAD DS, it hadn’t even been announced. Not a problem we thought at the time as we waited to progress the migration and left the file sync running. One day we will be able to just map the shares, update our softwares configuration file to point to the new shares and authenticate via the Azure File Share credentials.
Turns out it’s not that easy. The time came just a few weeks ago and having noted that AAD support was now available to Azure File Shares we assumed we’d just be able to turn it on, assign permissions for a specific AAD account that our IIS account is running under and then bingo-bongo map the share to the user account and access it just like we do on-premises.
But it wasn’t that simple. The setting to turn on AAD support for our File Share wasn’t there. A little bit of research later and we found a note on the official documentation stating AAD support is only available to File Shares created after September 2018. Crap. Ours has been around a lot longer than that, just waiting for the day we could utilise it.
Feeling the kick in the guts we attempted a few quick things such as attempting to map the shares as a persistent drive on our Azure VM but even though it’s mapped when logged into the same user account that our IIS runs under, it’s still mapped using the Azure File Share credentials which the IIS user doesn’t “know”. It could see the share but didn’t have the permissions required.
We’re at the point where to do this how we want, we basically need to create a new Azure File Share, re-sync all of our on-premises files to the new share and then use AAD DS to set the permissions we need. But that’s not trivial, there are hundreds of gigabytes of data and we have a 50/50Mbps link that we can’t hammer 100% as it will grind the companies internet to a halt.
Sigh. We’re so close, better get started.
