I need a temporary solution for an existing Windows Server 2019 system that will eventually be replaced. The server is not a domain controller and there is no on-premises Active Directory. It runs a legacy accounting application and hosts SMB shared folders that Windows 11 Pro clients map as network drives. The clients are Intune-managed and users sign in with Microsoft Entra credentials, while the server currently uses separate local accounts for file-share permissions. Is there a supported way to authenticate those SMB connections directly with Entra ID, perhaps through an LDAP service such as an Entra-to-LDAP wrapper? Could the server use that LDAP service for NTFS and share permissions, or would I need Entra Domain Services, Active Directory, Azure Files, or a different workaround?
4 Answers
If you can upgrade the file server, newer Windows scenarios may support Entra-based sign-in more directly. Windows Server 2025 can be joined to Entra ID in some configurations, and an Azure Arc Entra sign-in extension can help with interactive administration. There are also reports of using Entra users in local groups for file permissions, but SMB share behavior, client compatibility, and group support need careful testing before relying on it for production. It is not a drop-in feature for Windows Server 2019.
For a temporary setup, keeping the local accounts may honestly be the least risky choice, especially since the accounting application must remain on this server. You can automate account creation, use a password-management process, and apply permissions through local groups. If the data can be moved independently, an Entra Domain Services-backed file server or Azure Files with identity-based authentication is another path, but Azure Files should be tested for latency, WAN routing, private connectivity, and application compatibility before replacing a local share.
A generic LDAP wrapper will not normally work for Windows SMB authentication or NTFS ACLs. LDAP can validate identities, but Windows also needs security identifiers, domain trust, Kerberos or NTLM behavior, and directory-integrated group membership. The AD FS LDAP article is for federation sign-in and does not turn a standalone Windows file server into an LDAP-backed SMB server. With the current 2019 server, local accounts are essentially the native option unless you introduce AD or Entra Domain Services.
That is why the Synology setup does not necessarily translate to Windows. The NAS may have its own LDAP integration, while Windows Server's file-sharing security model is much more tightly tied to local SAM accounts or Active Directory.
The most direct supported option is Microsoft Entra Domain Services. It provides a managed, traditional AD-compatible domain that legacy SMB and Windows systems can use for Kerberos, NTLM, LDAP, and group-based NTFS permissions. You would create or use a subnet for the managed domain, configure DNS appropriately, and join the server and clients to that domain. This is separate from simply pointing Windows Server at an LDAP endpoint; Windows file sharing expects an AD-style security authority, not just LDAP authentication.
I would avoid using file synchronization as the primary workaround while the accounting application is actively writing to the files. Bidirectional sync can create conflicts or stale data, so it is safer only after confirming the application's file-locking and database behavior.