By the end of this build sheet you have a working Azure file share on the provisioned v2 billing model, reachable over the internet with encrypted SMB, mounted as a drive letter on an Entra-joined Windows 11 device, authenticated with your Entra credentials and no domain controller anywhere. This is the starter posture: real enough to evaluate honestly, small enough to build in an hour.
Prerequisites: an Entra ID tenant; an Azure subscription where you hold Owner or Contributor plus the ability to grant admin consent (Global Administrator or Privileged Role Administrator for one consent prompt); a test device that is Microsoft Entra joined (not hybrid, not domain-joined) running Windows 11 24H2 with at least KB5079391 (build 26100.8116 or later), 25H2, 26H1, or Windows Server 2025 (Windows 10 is not supported for cloud-only identities); and an internet connection that allows outbound TCP 445 (Step 6 tests this before you waste time on it). No Azure Files feature here requires a specific Microsoft 365 license.
Step 1: Create the storage account
Azure Files lives inside a storage account, and the account kind decides which billing models you can use. You want the FileStorage kind with a provisioned v2 SKU. For a first share, HDD media is the right call: it is dramatically cheaper and its performance floor is far above what one person evaluating a share will notice.
In the portal, create a storage account and in the create flow set the primary service to Azure Files, the performance/billing selection to the provisioned v2 model on HDD (the portal presents this as the file-share billing choice on a Standard account created for Files), and redundancy to LRS for a test. Name it within the global storage rules: 3 to 24 characters, lowercase letters and numbers only. The name becomes your UNC path, so pick something you can read aloud: I use a pattern like stvcio<purpose><seq>, for example stvciofiles01.
The consolidated CLI equivalent:
az group create --name rg-files-pilot --location eastus
az storage account create `
--name stvciofiles01 `
--resource-group rg-files-pilot `
--location eastus `
--kind FileStorage `
--sku StandardV2_LRSExpected result: an account of kind FileStorage with SKU StandardV2_LRS. If the SKU is rejected, your chosen region does not offer HDD provisioned v2 yet; pick a major region. The classic failure mode here is creating a StorageV2 account out of habit, which silently lands you on the legacy pay-as-you-go model, the one with transaction billing. Check the kind before moving on: az storage account show --name stvciofiles01 --query kind must return FileStorage.
Step 2: Confirm the security defaults
Portal-created accounts now require encryption in transit for SMB by default, which is exactly what you want for a share you are about to reach over the internet. Verify rather than assume, because accounts created through CLI and templates leave the setting unset for backward compatibility. On the storage account, under the file share settings, confirm that encryption in transit is required and that the SMB security profile allows only SMB 3.1.1 with AES-128-GCM or AES-256-GCM channel encryption. Leave NTLMv2 enabled for now; it is what the storage account key uses, and Step 7’s troubleshooting fallback needs it. Retiring NTLMv2 properly is covered in the private endpoint build sheet.
Step 3: Create the share
Provisioned v2 asks you for three numbers: storage, IOPS, and throughput. For a pilot, take the smallest sane values; you can raise any dial at any time (lowering is locked for 24 hours after any raise, which is the one rule worth remembering).
| Setting | Value | Why |
|---|---|---|
| Name | pilot | Share names are lowercase; this one is disposable and the name should say so. |
| Provisioned storage | 100 GiB | Provisioned v2 HDD floors at 32 GiB; 100 GiB costs under a dollar a month at list price and gives room for a real test dataset. |
| Provisioned IOPS | 500 (the recommended default) | The HDD floor. One evaluator cannot feel the difference above it. |
| Provisioned throughput | 60 MiB/s (the recommended default) | The HDD floor, and still faster than most home upload links. |
az storage share-rm create `
--storage-account stvciofiles01 `
--resource-group rg-files-pilot `
--name pilot `
--quota 100 `
--provisioned-iops 500 `
--provisioned-bandwidth-mibps 60Expected result: the share appears under the account’s file shares with 100 GiB provisioned and the default IOPS and throughput for that size. On a provisioned v2 account the portal shows all three dials on the share’s configuration; confirm you see provisioned IOPS and throughput listed, because their presence is your proof you are on v2 and not the legacy model.
Step 4: Enable Microsoft Entra Kerberos
This is the step that was impossible for cloud-only estates before May 2026, and it is now two actions: enable the identity source, then consent to the application it creates.
On the storage account, open the file shares settings and under identity-based access enable Microsoft Entra Kerberos. In PowerShell:
Set-AzStorageAccount `
-ResourceGroupName "rg-files-pilot" `
-StorageAccountName "stvciofiles01" `
-EnableAzureActiveDirectoryKerberosForFile $trueEnabling the source auto-creates an Entra application named [Storage Account] stvciofiles01.file.core.windows.net. It needs admin consent for its sign-in permissions (openid, profile, User.Read). Find it in Entra admin center under enterprise applications and grant admin consent once. Do not otherwise touch this app, with one exception you will meet in the identity build sheet (a manifest tag for cloud-only groups). Failure mode: skip the consent and every mount attempt fails with a generic credential error that says nothing about consent; if your first mount fails, check this before anything else.
Step 5: Grant share-level permission
Azure Files authorizes in two layers: an Azure RBAC gate at the share level, then NTFS ACLs beneath it, and the most restrictive of the two wins. For the starter build, set the default share-level permission so every authenticated user in your tenant passes the gate as a contributor, and let ACLs do the fine work later. This is also the setting that works in every region, which matters because assigning RBAC roles to specific cloud-only users is still region-limited.
Set-AzStorageAccount `
-ResourceGroupName "rg-files-pilot" `
-StorageAccountName "stvciofiles01" `
-DefaultSharePermission StorageFileDataSmbShareContributorExpected result: the storage account reports the default share permission as Contributor. RBAC changes can take up to 30 minutes to propagate; start Step 6 while you wait. A default permission for all authenticated users sounds loose, and for production it is; the identity build sheet replaces it with named groups. For a pilot share holding nothing sensitive, it is the right simplification.
Step 6: Prepare the client and test the path
Two client-side facts decide whether the mount works. First, the device must be told to request cloud Kerberos tickets. On an Intune-managed device, deploy the setting Kerberos > Cloud Kerberos Ticket Retrieval Enabled from the settings catalog; on a lone test machine, set the registry value directly and reboot:
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters `
/v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1 /fSecond, outbound TCP 445 must actually reach Azure. Most US cable providers and phone hotspots block it; fiber, business circuits, and most corporate egress usually allow it. Test before you troubleshoot anything else:
Test-NetConnection -ComputerName stvciofiles01.file.core.windows.net -Port 445Expected result: TcpTestSucceeded : True. If it is False, nothing in Azure is wrong; your network path is eating port 445. Move to a network that allows it for this pilot (tether to a hotspot that permits 445, or run the test from an office circuit), and take the hint: your production access path will be a private endpoint over VPN or Global Secure Access, both of which have their own build sheets in this series.
Step 7: Mount and validate
Sign in to the test device as a normal Entra user (not a local account), then mount:
net use Z: \\stvciofiles01.file.core.windows.net\pilotNo username, no password, no key. Expected result: the command completes and Z: opens in Explorer. Prove the authentication is what I claim it is:
klist get cifs/stvciofiles01.file.core.windows.netYou should see a Kerberos ticket for the share’s service principal issued by the realm KERBEROS.MICROSOFTONLINE.COM. That realm name is the whole story of this article: the ticket came from Entra ID, not from a domain controller, because there is no domain controller.
The end-to-end test: create a file on Z:, then open the share in the portal’s file browser and confirm the file is there. Then do it in reverse, upload a file in the portal and watch it appear in Explorer. If both directions work, you have a functioning cloud file share with identity-based access.
If the mount fails with a credential prompt or system error 1327 and your tenant enforces MFA broadly through Conditional Access, you have met the platform’s most important limitation early: the SMB flow cannot satisfy an MFA requirement, and the storage account’s app must be excluded from MFA policies. The identity article covers why, and what I do about it. As a last-resort diagnostic (not a fix), mounting with the storage account key isolates whether the problem is identity or network: net use Z: \\stvciofiles01.file.core.windows.net\pilot /user:Azure\stvciofiles01 <storage-key>. If the key mounts and Kerberos does not, work the identity chain: consent, RBAC propagation, the registry value, the sign-in account.
Where this leaves you
You now have the starter posture: a hardened public endpoint, encrypted SMB, Entra Kerberos, one share, one drive letter. It is a real deployment in miniature, and everything from here is a deliberate upgrade of one layer at a time. The identity doctrine article and its build sheet replace the default share permission with named groups and real ACLs. The networking articles decide whether production traffic rides this public endpoint, a private endpoint over your VPN, or Global Secure Access. Keep the pilot share; the rest of the series keeps using it.
Azure Files
‹ Previous: [AF 1] Azure Files: The File Server Question, Re-Asked
Next: [AF 2] Identity: Who Your File Server Trusts Now ›
