I have a Windows Server 2019 machine running an older accounting application and shared folders that Windows 11 clients map as drives. There is no on-premises Active Directory, so users currently connect with local accounts on the server.
Is there a temporary way to authenticate those shares with Entra credentials? An LDAP wrapper already works with a NAS, but can Windows Server use it for share authentication and permissions?
Not by pointing the server at an arbitrary LDAP directory. A standalone Windows Server uses its local accounts for this setup. An LDAP wrapper that works for a NAS does not automatically give Windows the domain identities it needs for SMB authentication and NTFS permissions.
AD FS authenticating users against LDAP is a different use case. It is not a way to make that wrapper act like a Windows domain for your file shares.
Look into Microsoft Entra Domain Services. It provides a managed domain for workloads that need traditional domain authentication. You could join the server to that domain and use domain users or groups for the share and NTFS permissions.
That is more infrastructure than a quick setting change, though. Check the networking, DNS, credential and client authentication requirements, plus the ongoing cost, before treating it as a temporary fix. Entra sign-in on the Windows 11 machines alone does not guarantee a seamless drive mapping.
For a short bridge, keeping the local server accounts may be the least disruptive option. Store each user's server credentials in Windows Credential Manager and map the drive using those credentials. It still means managing separate accounts and passwords, but it avoids changing the application or standing up a domain while you work out the replacement.
You could move the files to storage that supports an identity setup better suited to your environment, but I'd first check how that accounting application uses them. Azure Files has Entra-based options worth investigating, and the NAS setup might be another candidate. Neither should be assumed to work as a drop-in replacement for this particular application.
SharePoint and OneDrive might suit ordinary documents, but syncing application data to individual PCs is not the same thing as a shared SMB drive. Check the application's storage and locking requirements before moving anything.
A conventional AD domain with synchronization to Entra is another route, but that is a bigger change than connecting the existing server to Entra. The usual Entra Connect setup assumes an on-premises AD, which you do not have.
There were different suggestions about syncing cloud users back to a new domain. Check the current Microsoft documentation and the exact provisioning and authentication requirements before counting on that as a migration path.
Answers are reviewed before publication.
_z64~gasketlantern:
The application runs on the server and clients use its shared folder, so I need to understand that dependency before moving the files.