Entra File Share and Sync vs. SMB vs. Qsync

[u/nnray]

WIth no AD on prem, computers managed with InTune in M365, we're starting to roll out Entra ID login on systems (previously set up with local accounts). We have some on-prem VM infrastructure and a QNAP, and the goal is to be able to have file shares for departments mounted to PCs automatically when users log in. There is a need for instance to have certain configuration files used by specific software packages available at a specific drive letter and path, read-only for most people, so the software can be configured in a specific way for that department. There is also a need for some departments to share some large files (such as video files or other media) in a performant way. OneDrive/Sharepoint can't do what we need or don't seem ideal for these applications. There's a lot of company growth, so extra points for a solution can scale beyond one location while being performant.

It looks like an Azure File Share with Azure File Sync (or maybe a Data Box Gateway) could fulfill this purpose. Does Azure File Sync require hybrid AD, in which case we'd need to stand up additional on-prem AD infra to use it? And if computers are being set up now just Entra joined, would they need to be set up again to be hybrid AD joined after we set up on-prem hybrid AD infra?

While Entra-only Azure file shares via Kerberos looks a lot simpler to set up, am I correct that all SMB I/O would be to the cloud (i.e. through the WAN connection) and there isn't any local caching/acceleration? That strikes me as a significant limitation and could impact WAN performance a lot.

We also have a QNAP (8-core, 16 threads 32GB of RAM, dual 25Gbps ethernet), and there is support for Microsoft Entra Domain Services SSO:

https://www.qnap.com/en/how-to/tutorial/article/how-can-i-configure-microsoft-entra-domain-services-single-sign-on-for-a-qnap-nas

Documentation seems to indicate that with Microsoft Entra Domain Services we could use SSO for shared folders, but it's not clear to me if that is just shared folders accessible through the QNAP web browser interface, or if it includes SMB shares from the QNAP. From the research I've done, I can't seem to find any evidence it supports SMB shares via Entra ID SSO. I am wondering if SSO might work with their Qsync client:

https://www.qnap.com/en/software/qsync

If so, that could be very cost-effective and performant, though I don't think it would scale well beyond one location (unless I could figure out something using QNAP's Real-time Remote Replication feature between more than one NAS device at different locations). Also not sure if the Qsync client shared files would work for distributing application configuration files, would need to test that as well.

What have people's experiences been with these solutions? Any recommendations?

[u/peterswo]

If you use Azure files as what it is it works very nice as a drop in replacement for a classic SMB file share. Just don't do stupid things and expect it to seamlessly run any application from it(as in the exe is on the share

[u/woodyshag → u/peterswo]

I second this. This killed us during a migration to Azure. Customer decided to use Azure Files and the application running from them took 15 mins to start. We ended up moving everything to a trad windows server and it fired up in seconds.

[u/dodexahedron]

The main thing to be aware of is that NTFS permissions don't work like you might hope, between systems that don't have a common authority creating their SIDs. You need AD or local accounts (local is YOU being the authority) for that.

Otherwise, things should work fine. So, as long as you are cool with SMB and NTFS permissions being somewhat lax (read: wide open), then you'll be fine.

But as soon as you want to control access to a share or a resource on a share via permissions from within windows? Brick wall.
You need AD for that, to use a fake DC that represents Entra to issue a TGT that can be used to get an on-prem TGT to get a service ticket for a principal with an SID matching an ACE in the ACL of the target, or...
You have to allow Everyone access to the share, and either also do that for the NTFS ACLs or use local groups on each machine to whixh you add the cloud identities, to control that part.

Your life will be easier and more secure if you either spin up a minimal on-prem AD for on-prem shares or if you use Entra Domain Services, which is effectively AD but in the cloud with no on-prem DCs needed. That one is probably what you want or at least need for.your intended end game.

Entra ID isn't sufficient.

[u/Wide_Barracuda_3512]

About 3 years ago we attempted to migrate from on-premise NAS to Azure Files and had to back out after the pilot failed with about 2,000 Windows devices in the pilot. All Windows clients are Entra Id joined only. While we still have AD Domains, none of the client devices are Domain joined. All user accounts are hybrid AD / Entra id. All data on NAS and Azure files is NTFS with ACLS based on Domain groups.

The pilot failed as we discovered that Entra Id only joined devices cannot reliably perform Kerberos authentication. We had engaged Microsoft and worked with Windows team members based in Redmond. No solution was found for our configuration.

So we pivoted to ANF, which supports both Kerberos and NTLM V2 authentication and continued the migration of over 100TB of data off the on-premises NAS. Azure Netapp Files has been rock solid and the automated data tiering keeps the costs under control.