Azure Files Security: Harden SMB and NFS Shares Against Misuse and Ransomware

An Azure file share often holds the same department folders, user profiles and application data that used to live on a Windows file server, and it can be reached by anyone holding the storage account key. Azure Files supports identity based SMB access through Active Directory Domain Services, Microsoft Entra Domain Services or Microsoft Entra Kerberos, so access can follow users and groups rather than a shared secret. This guide covers how identity and share permissions fit together, SMB security settings, storage account key use, network isolation, Azure File Sync, logging, and the soft delete, snapshot and backup layers that let you recover from deletion or ransomware. It is written for infrastructure engineers, Azure administrators and security teams. Blob storage, SAS tokens and account wide settings are covered in the Azure Storage Security Guide; this page stays on file shares.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public Azure Files documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Move users to identity based access. Enable one identity source per storage account, grant share-level RBAC roles to groups, and manage file and folder access with Windows ACLs.
• Treat the storage account key as a master key. NTLMv2 with the account key bypasses every share and file permission; remove it from the SMB authentication methods once identity access works.
• Use the Maximum security SMB profile where clients allow. Require encryption in transit, SMB 3.1.1, AES-256-GCM, Kerberos only and AES-256 Kerberos tickets.
• Keep shares off the internet. Use private endpoints and disable public network access; NFS shares are network authenticated, so network controls are their main defence.
• Layer recovery. Soft delete, share snapshots, Azure Backup and resource locks protect against different failures; ransomware recovery needs copies an attacker with share access cannot change.

How identity and access work in Azure Files

Access to an SMB share is decided by three things together: authentication (who you are), share-level permission (Azure RBAC on the share) and file or directory permission (Windows ACLs). Network access must also be in place. Identity based authentication is free of extra service charges and supports SMB shares; NFS shares use network based authentication instead.

Only one identity source can be enabled per storage account, and it applies to every share in it. Changing the source temporarily interrupts identity based access to all shares, so plan it as a change window. Kerberos must be enabled under Authentication methods in the account's SMB security settings for any of the three sources.

Microsoft Entra Kerberos specifics

• Admin consent: Enabling it creates an app registration named [Storage Account] <account>.file.core.windows.net. Grant admin consent for openid, profile and User.Read, and do not change the service principal beyond the documented steps.
• Conditional Access: SMB access through Entra Kerberos is authorised without an MFA prompt, so exclude the storage account app from Conditional Access policies that require MFA for all apps; otherwise net use fails with system error 1327. Compensate by protecting the device sign-in itself with strong authentication and device compliance.
• Ticket encryption: Kerberos tickets from Entra Kerberos always use AES-256.
• Group limits: A Kerberos ticket holds at most 1,010 group SIDs across on-premises and cloud groups; users over the limit cannot get tickets.
• Cloud-only users: Supported on current Windows 11 and Windows Server 2025 builds in Azure public cloud, with a mandatory group SID limit tag added to the app manifest. File and folder permissions for cloud-only identities are managed in the Azure portal or with RestSetAcls.

Kerberos fundamentals are covered in the Kerberos Security Guide.

Admin roles and privileged access

Azure Files share-level roles grant data access over SMB. Some are ordinary user roles and some override Windows ACLs entirely, which makes them privileged.

Control plane roles matter as much. Owner, Contributor and Storage Account Contributor include listKeys, which returns the storage account keys and therefore full data access. Keep these roles for a small platform group, make them eligible rather than permanent, and see the Azure RBAC and Service Principals Guide.

Default share-level permission

The default share-level permission starts as None. You can enable a permission for all authenticated users and groups, which applies the chosen role to every share in the account. Microsoft recommends specific user and group assignments for most deployments. The default is the right tool in narrower cases: identities in AD DS that are not synced to Entra ID, such as gMSAs, sMSAs and computer accounts (which cannot hold Azure RBAC assignments), an AD DS synced to a different Entra tenant, or a decision to enforce access only through Windows ACLs. When both apply, a user gets the higher of the two permissions, so a generous default quietly overrides narrow assignments.

Integrations, API tokens and service accounts

• Storage account keys: Mounting with the account key uses NTLMv2 and grants full access regardless of ACLs. Once users and applications use identity access, remove NTLMv2 from the SMB authentication methods, which blocks key based mounting.
• Disallowing Shared Key: Setting AllowSharedKeyAccess to false rejects Shared Key requests with 403 and also denies service and account SAS. Microsoft cautions that the Azure portal uses Shared Key by default for file shares and that Storage Explorer connects to File storage with keys, and suggests moving file workloads to a separate account before disallowing Shared Key on mixed accounts. Assign data roles first, test, then disable. The built-in Azure Policy definition "Storage accounts should prevent shared key access" can audit before it denies.
• Service accounts and gMSAs: Application servers that use group managed service accounts reach shares through Kerberos with AD DS. Because gMSAs cannot hold Azure RBAC roles, they rely on the default share-level permission plus tight Windows ACLs.
• Azure File Sync: The agent talks to the Storage Sync Service and the share over HTTPS on port 443 only, never SMB, and never sends unencrypted requests. Registration needs the Azure File Sync Administrator, Owner or Contributor role on the Storage Sync Service. Prefer the managed identity deployment, where the File Sync identity holds roles such as Storage File Data Privileged Contributor, over key based access. When assigning Azure File Sync Administrator, use a role assignment condition that limits which roles that person can delegate. Use a separate Storage Sync Service per group that needs strict isolation, and keep everything in one Entra tenant.
• Customer-managed keys: Data is encrypted at rest with Microsoft-managed keys by default, and classic file shares can use customer-managed keys. Revoking key access makes the share unreachable over SMB and FileREST, so protect the key vault as carefully as the data. See the Azure Key Vault Security Guide.
• Endpoint protection on sync servers: Antivirus scans that read tiered files trigger recalls and egress charges. Microsoft Defender skips tiered files only during on-demand scans, so confirm your endpoint product is compatible with tiering.

SMB security settings and network isolation

SMB security settings on the storage account offer Maximum compatibility (the default), Maximum security and Custom profiles. Stricter settings can block older clients, which then receive STATUS_ACCESS_DENIED.

If you allow only AES-256-GCM, configure clients to match, for example with Set-SmbClientConfiguration -EncryptionCiphers "AES_256_GCM". RC4 retirement in Kerberos is covered in the Kerberos RC4 Deprecation guide.

SMB uses TCP 445, which many ISPs block, so on-premises access normally runs over VPN or ExpressRoute to a private endpoint. A private endpoint gives the share a private IP in your virtual network and creates a CNAME to privatelink.file.core.windows.net; on-premises clients need DNS forwarding, for example through Azure DNS Private Resolver. The public endpoint stays reachable until you disable public network access. ExpressRoute private peering does not encrypt traffic by default, so keep SMB encryption on. NFS shares cannot be reached from the internet, use network rather than user authentication, and can use the AzNFS mount helper to tunnel traffic through TLS 1.2 or 1.3. For NFS, the network boundary is the access control: limit it to the subnets that need it. See the Azure Virtual Network Security Guide.

Ransomware protection and recovery

Ransomware against file shares usually arrives through a compromised client or account that already has write access, so the share's own recovery features must sit outside what that identity can change.

Snapshots are deleted with their share, and soft delete works only at share level, so you need both, plus a lock on the account. An identity with write rights on the storage account can delete snapshots and disable soft delete, and an Owner or User Access Administrator (or any role with Microsoft.Authorization/locks/* rights) can remove locks, which is why control plane roles must be guarded. With Azure File Sync, do not back up a server endpoint that has cloud tiering enabled: tiered files are skipped or recalled. Back up the Azure file share directly instead. Vault protections are covered in the Azure Backup and Recovery Services Vault Security Guide and wider cloud patterns in the Cloud Ransomware Guide.

Logging and detection

Logs are not sent anywhere by default. Create a diagnostic setting on the file service of each storage account and send the StorageRead, StorageWrite and StorageDelete categories to a Log Analytics workspace, where they land in the StorageFileLogs table. Logs cover authenticated requests using Kerberos, NTLM or SAS.

• Key based access: Use the Transactions metric filtered by Authentication equal to Account Key and SAS to find clients still using keys before you disable them.
• Mass change: Alert on spikes in write, rename and delete operations from one caller, a common sign of encryption in progress, and on unusual Egress (Microsoft's sample alert uses more than 500 GiB in a day).
• Control plane: Alert in the Activity Log on listKeys and key regeneration, changes to SMB security settings, soft delete being disabled, lock removal, snapshot deletion and new private endpoint or network rule changes.
• Identity: Monitor changes to the storage account app registration and share-level role assignments.

Metrics that show the controls are working:

• Percentage of SMB transactions authenticated with Kerberos rather than the account key.
• Storage accounts with NTLMv2 removed and the Maximum security or equivalent Custom profile applied.
• Shares with soft delete on, at least daily snapshots and a backup policy.
• Storage accounts with public network access disabled.
• Time from a mass change alert to client isolation.

See the Azure Monitor, Activity Log and Diagnostic Settings Guide for collection at scale.

Hardening baseline

1. Inventory: List storage accounts with file shares, their protocols, identity source, SMB profile, network settings and current key usage from metrics.
2. Enable identity access: Choose the identity source, assign share-level roles to groups, keep the default share-level permission at None unless a documented case needs it, and set Windows ACLs.
3. Pilot: Move one share and a pilot group of users and applications to Kerberos access; confirm Previous Versions restores work.
4. Tighten SMB: Apply the Maximum security profile or a Custom profile with Kerberos only, AES-256 tickets and encryption required. Test older clients first.
5. Retire keys: Remove NTLMv2 once metrics show no key use; consider disallowing Shared Key where file workloads allow, auditing with Azure Policy first. Rotate both account keys afterwards.
6. Isolate: Add private endpoints and DNS, then disable public network access.
7. Protect recovery: Confirm soft delete retention, schedule snapshots or Azure Backup, and apply a CanNotDelete lock to the account.
8. Roll back: SMB settings and authentication methods can be reverted in minutes if a critical client breaks; keep a record of the previous profile and re-tighten after the client is fixed.

Common misconfigurations

• Account key mounts left in scripts: Mapped drives and scripts with the storage key give full access and survive staff changes. Replace them with identity based mounts and remove NTLMv2.
• Default share-level permission set to Elevated Contributor: Every authenticated user can then change ACLs on every share. Use group assignments.
• Privileged roles given to users: Privileged Contributor and SMB Admin override ACLs. Keep them for sync identities and break glass administrators.
• Snapshots treated as backup: Snapshots disappear with the share and can be deleted by an account administrator. Add soft delete, a lock and Azure Backup.
• Public endpoint left open: Disabling public network access is a separate step after creating a private endpoint. Complete it.
• Accounts created by script with encryption not required: Accounts created with PowerShell or CLI do not select Require Encryption in Transit for SMB. Set it explicitly in templates.

Framework mapping

Practitioner checklist

• Enable one identity source per account and assign share-level roles to groups, not users.
• Keep the default share-level permission at None unless gMSAs or unsynced identities need it, and document why.
• Restrict Privileged Contributor, SMB Admin and key-listing control plane roles to a small, eligible group.
• Apply Maximum security or a Custom SMB profile with Kerberos only, AES-256 tickets and encryption required.
• Find key based clients with metrics, migrate them, remove NTLMv2 and rotate both keys.
• Use private endpoints with private DNS and disable public network access.
• Keep soft delete on with a retention that matches detection time, schedule snapshots or Azure Backup, and lock the account.
• Use the Azure File Sync managed identity deployment and back up the cloud share, not tiered server endpoints.
• Send StorageFileLogs to Log Analytics and alert on mass changes, key listing and protection changes.
• Apply vendor security updates to clients and sync agents promptly, and keep sync agents within their support window.

Standards and references

• Microsoft Learn: Overview of Azure Files identity based authentication for SMB access
• Microsoft Learn: Assign share-level permissions for Azure file shares
• Microsoft Learn: Enable Microsoft Entra Kerberos authentication for Azure Files
• Microsoft Learn: SMB file shares in Azure Files
• Microsoft Learn: Azure Files networking considerations
• Microsoft Learn: Prevent Shared Key authorization for an Azure Storage account
• Microsoft Learn: Enable soft delete on Azure file shares
• Microsoft Learn: Overview of share snapshots for Azure Files

Related NHI Mgmt Group resources: Azure Storage Security Guide · SMB Protocol Security and Signing Guide · Azure Backup and Recovery Services Vault Security Guide · Cloud Ransomware Guide · Kerberos Security Guide