Mapping On-Prem File Shares with Entra ID Only
Mapping On-Prem File Shares with Entra ID Only
No on-prem Active Directory. No Kerberos KDC. Just a Windows Server 2025 box, Azure Arc, and a decades-old authentication protocol most people have forgotten exists. Here's the fully validated, step-by-step build — including the lab evidence that proves it actually works.
Same files everywhere: users reach Azure directly over Entra Kerberos, reach the on-prem server directly over PKU2U when they're on that network, and Azure File Sync quietly keeps the server and the cloud share identical in the background.
1Architecture Overview
Three pieces work together so that both on-prem-reachable and fully remote users can get to the same data — without a domain controller anywhere in the picture.
sharetesting
Direct Azure Files access for cloud-only Windows 11 devices. Mapped via Intune, authenticated with Entra Kerberos. No server involved.
AZ-Filez-01
Non-domain-joined Windows Server 2025, connected to Azure Arc. Local sharetesting2 share reachable via PKU2U + Entra ID — no AD, no Kerberos KDC. Lab-validated below.
sharetesting2 (Azure)
A File Sync cloud endpoint mirroring the server's local share, so users who can't reach the on-prem box get the same data straight from Azure.
2Part 1 — On-Prem Access via Azure Arc + PKU2U
This is the interesting part: mapping a drive to a server with zero Active Directory, using an authentication protocol most admins have never had a reason to touch.
Prerequisites
| Requirement | Detail |
|---|---|
| Server OS | Windows Server 2025, not domain-joined (workgroup) |
| Server connectivity | Connected to Azure Arc (azcmagent connect) |
| Extension | AADLoginForWindows deployed to the Arc machine — Entra-joins the server (does not by itself enable SMB auth) |
| Tenant match | Server and client must be Entra-joined to the same tenant |
| Client | Windows 11, Entra-joined (cloud-only), Intune-managed |
| Name resolution | Real DNS or hosts entry — PKU2U does not work against a bare IP |
How it actually works
AADLoginForWindows only handles interactive/RDP sign-in via Azure RBAC (VM Administrator/User Login roles) — it registers nothing in the SMB stack. What actually authorizes a mapped drive with no domain and no Kerberos KDC is:
- PKU2U (Negotiate SSP
NegoExtender) — lets two Entra-joined, non-domain machines authenticate an SMB session using online (Entra) identities. - NTFS ACLs keyed to Entra identities (
AzureAD\<upn>) — authorization is still local NTFS; there's no Azure RBAC governing file-level access on a self-hosted server, unlike Azure Files.
Setup steps
Connect the server to Azure Arc and deploy AADLoginForWindows
Confirm the join state before doing anything else:
dsregcmd /status
# AzureAdJoined : YES / DomainJoined : NOEnable PKU2U on both the server and every Windows 11 client
New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\pku2u" -Force
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\pku2u" -Name "AllowOnlineID" -Value 1 -Type DWordDeploy this to Windows 11 clients at scale via Intune → Settings Catalog rather than by hand.
Create the share and folder on the server
New-Item -Path "C:\Shares\sharetesting2" -ItemType Directory -Force
New-SmbShare -Name "sharetesting2" -Path "C:\Shares\sharetesting2" -FullAccess "Everyone"Share permissions are left open — access is controlled entirely by NTFS ACLs in the next step (standard pattern).
Grant NTFS access to each Entra identity that needs it
icacls "C:\Shares\sharetesting2" /grant "AzureAD\<user-upn>:(OI)(CI)M"Confirm resolution — icacls should show the resolved display name, not a raw SID:
icacls "C:\Shares\sharetesting2"Map the drive from a Windows 11 client
Via Intune drive-mapping policy/script:
net use Z: \\az-filez-01\sharetesting2Verify it authenticated via PKU2U, not NTLM or domain Kerberos
Get-SmbConnectionUserName/Credential should show AzureAD\<DisplayName>. On the server's Security event log, filter 4624 events and check AuthPackage — expect NegoExtender (this is how PKU2U-based logons are labeled in the LSA).
3Part 2 — Bridging to Azure Files with Azure File Sync
Gives the same data a second access path — directly from Azure — for users who can't reach the on-prem server over the network.
| Item | Value |
|---|---|
| Storage account | datasharetesting (existing) |
| Azure file share (cloud endpoint) | sharetesting2 — same name as the local server share, for clarity |
| Server endpoint (local path) | C:\Shares\sharetesting2 on AZ-Filez-01 |
| Cloud tiering | Disabled — full local copy always kept on the server |
| Region | Storage Sync Service in the same region as datasharetesting |
Prerequisites
- Outbound HTTPS 443 from the server to Azure (the sync engine uses REST calls over 443, not SMB).
- An Azure AD account with Contributor rights on the Storage Sync Service, used once to register the server.
- Latest Azure File Sync agent compatible with Windows Server 2025.
Setup steps
Create the cloud endpoint share
New-AzStorageShare -Name "sharetesting2" -Context (Get-AzStorageAccount -ResourceGroupName "<rg>" -Name "datasharetesting").ContextCreate a Storage Sync Service
New-AzStorageSyncService -ResourceGroupName "<rg>" -Name "contoso-sync" -Location "<region>"Install the Azure File Sync agent and register the server
Download from aka.ms/afs/agent, run the installer, and sign in interactively with the Contributor account when the Server Registration UI launches. Select the subscription, resource group, and Storage Sync Service. This creates a registered server resource in Azure — independent of the Arc connection from Part 1.
Create a Sync Group and endpoints
$syncGroup = New-AzStorageSyncGroup -ResourceGroupName "<rg>" -StorageSyncServiceName "contoso-sync" -Name "sharetesting2-syncgroup"
New-AzStorageSyncCloudEndpoint -ResourceGroupName "<rg>" -StorageSyncServiceName "contoso-sync" `
-SyncGroupName "sharetesting2-syncgroup" -StorageAccountResourceId "<storage-account-resource-id>" -AzureFileShareName "sharetesting2"
New-AzStorageSyncServerEndpoint -ResourceGroupName "<rg>" -StorageSyncServiceName "contoso-sync" `
-SyncGroupName "sharetesting2-syncgroup" -ServerId "<registered-server-id>" -ServerFolder "C:\Shares\sharetesting2" `
-CloudTiering $falseMonitor the initial sync
Since the local folder already has data, Azure File Sync performs a namespace merge, uploading existing files to the new cloud endpoint. Watch Portal → Storage Sync Service → Sync Group → Server Endpoint → Health until it reads "Healthy" / "Up to date".
Enable identity-based access on the new share
Microsoft Entra Kerberos is a storage-account-level setting, so sharetesting2 inherits it automatically from datasharetesting. Assign RBAC (e.g. Storage File Data SMB Share Contributor) to the users/groups who need direct cloud access.
Map the drive for users who can't reach the on-prem server
New-PSDrive -Name Y -PSProvider FileSystem -Root "\\datasharetesting.file.core.windows.net\sharetesting2" -PersistResulting access matrix
| User group | Path | Mechanism |
|---|---|---|
| Cloud-only, on-prem network reachable | \\az-filez-01\sharetesting2 | PKU2U + Entra ID |
| Cloud-only, no on-prem network path | \\datasharetesting.file.core.windows.net\sharetesting2 | Entra Kerberos |
| Both groups | Same underlying data | Kept in sync by Azure File Sync |
4Validation Evidence
Tested and confirmed on AZ-Filez-01 — this isn't theoretical.
- ✓ Server & client Entra-joined, same tenant
- ✓ PKU2U enabled both ends
- ✓ NTFS ACL resolved Entra UPN → cloud identity
- ✓
net usesucceeded, no credential prompt - ✓
Get-SmbConnectionshowsAzureAD\<user>identity - ✓ Server Security log
4624—AuthPackage = NegoExtender(PKU2U) - ✓ Read + write access confirmed
- ✓ Survives reboot (remembered mapping + manual reconnect)
- ✓ Share permissions alone are insufficient — NTFS ACL is the real enforcement point
icacls, the mapped drive connected but dir/mkdir returned Access is denied. After granting the ACL, both succeeded immediately — no re-mapping or reboot needed. Authorization is enforced entirely by the local NTFS ACL, not the share permission list.
Still to validate
- ○ Negative test — a different Entra user not in the ACL is denied access
- ○ Intune-deployed drive mapping reproduces the same result unattended
- ○ Behavior after PRT refresh / longer elapsed time
- ○ Azure File Sync namespace merge completes cleanly and NTFS ACLs replicate as expected
5Known Prior Art / References
There is no official Microsoft Learn documentation for the Arc + PKU2U SMB file-share combination used in Part 1. Here's what exists publicly.
Identifies PKU2U as the mechanism enabling Entra-only SMB file share access. Confirms in the comments that both an Azure-hosted Server 2022+ VM and an on-prem Arc-attached Server 2025 box were tested — but the on-prem Arc case isn't documented step-by-step, and there's no event-log-level proof (4624/NegoExtender) shown.
Documents the Arc + AADLoginForWindows extension deployment itself, including the mdmId="" workaround needed on Arc machines. Explicitly labels the whole approach POC-only, not production-ready. Covers RDP sign-in only — no mention of PKU2U or file shares.
Microsoft support staff confirm AADLoginForWindows was not officially supported on hybrid Arc machines at that time.
What appears original here: a single validated runbook combining on-prem Arc-attached WS2025, PKU2U-secured local SMB access for Intune-managed cloud-only clients, and Azure File Sync bridging the same data into Azure Files — with concrete validation evidence. This full combination, documented end-to-end with test evidence, doesn't appear to exist publicly elsewhere as of this writing.
6Risk Assessment / Long-Term Viability
Be clear-eyed about what could break this — none of it requires Microsoft to "target" the approach specifically.
| Risk | Likelihood | Notes |
|---|---|---|
| Customer security baseline disables PKU2U | High | Microsoft Security Baselines and CIS Benchmarks commonly recommend disabling "Allow PKU2U authentication requests to use online identities." If a baseline is applied via Intune/GPO, this can silently break the solution with zero Microsoft involvement. Check for existing baselines before deployment. |
| Microsoft further restricts PKU2U | Medium | Not unprecedented — CVE-2021-25195 already led Microsoft to change PKU2U's default posture on domain/hybrid-joined devices. |
AADLoginForWindows on Arc changes behavior |
Medium | Explicitly unsupported/POC per community sources and Microsoft support. No compatibility guarantee for an undocumented use case. |
| PKU2U protocol removed entirely | Low | Deeply embedded in Windows' Negotiate/SPNEGO stack; used elsewhere (e.g. Entra-joined-to-Entra-joined RDP). |
| Direction of travel is favorable | — | Microsoft is actively investing in cloud-only auth (Entra Kerberos for Azure Files, Entra sign-in for Arc VMs) — this isn't fighting the roadmap, just ahead of official support. |
Before shipping this to a customer
- ✓ Do not present this as a Microsoft-supported architecture
- ✓ Get written customer sign-off acknowledging the risk
- ✓ Check for existing security baselines that touch PKU2U — the most likely failure mode
- ✓ Define a rollback/exit plan up front (domain-join + Kerberos, or full migration to Azure Files)
- ✓ Monitor Windows/Entra release notes as an ongoing task, not a one-time check