Hardening Azure File Share SMB Security to Maximum

Azure Files exposes SMB shares over the network, and by default a storage account accepts a fairly permissive range of protocol versions, authentication methods, and cipher suites. That flexibility is convenient when you have older clients, but it also means an attacker on the same network path can negotiate the weakest option you allow. This Lensix check, storage_filesmbsecurity, looks at the SMB security profile on each storage account and fails it when anything below maximum hardening is permitted.

Maximum security means four things together: SMB 3.1.1 only, Kerberos-only authentication, AES-256-GCM channel encryption, and AES-256 for Kerberos ticket encryption. If any one of those allows a weaker fallback, the check fails.

---

What this check detects

The check inspects the fileServiceProperties and SMB protocol settings on each Azure storage account that has file shares enabled. It fails when the account permits any of the following:

• SMB 2.1 or 3.0 as a negotiable protocol version. Only 3.1.1 should be allowed.
• NTLMv2 authentication. Only Kerberos should be accepted.
• AES-128-CCM or AES-128-GCM channel encryption. Only AES-256-GCM should be allowed.
• RC4-HMAC Kerberos ticket encryption. Only AES-256 ticket encryption should be allowed.

---

Why it matters

SMB has a long history of protocol-level attacks, and most of them depend on the server accepting something weaker than it should.

Downgrade attacks

An attacker positioned between a client and your file share can tamper with the SMB negotiation to force a weaker protocol or cipher. SMB 3.1.1 introduced pre-authentication integrity precisely to stop this, by hashing the negotiation messages so tampering is detected. If you still allow SMB 3.0, that protection does not apply to connections that land on the older version, and the session is open to manipulation.

NTLM relay

NTLMv2 authentication is vulnerable to relay attacks, where an attacker captures an authentication attempt and replays it against another service to impersonate the user. This is one of the most common lateral-movement techniques in real intrusions. Kerberos, when configured correctly, is not susceptible to the same relay pattern. Allowing NTLMv2 on a file share keeps that attack surface open.

Weak encryption

AES-128 is not broken, but AES-256-GCM gives you a larger key and authenticated encryption, which protects both confidentiality and integrity of data in transit. RC4-HMAC for Kerberos tickets is genuinely weak and has been deprecated by Microsoft. RC4 tickets are the entry point for Kerberoasting attacks, where an attacker requests service tickets and cracks them offline to recover account passwords.

---

How to fix it

The SMB security settings live under the file service properties of the storage account. You set them once per account and they apply to all file shares within it.

Option 1: Azure CLI

First check the current settings so you know what you are changing:

az storage account file-service-properties show \
  --account-name mystorageacct \
  --resource-group my-rg \
  --query "protocolSettings.smb"

Then apply the hardened profile. This restricts the account to SMB 3.1.1, Kerberos auth, AES-256-GCM channel encryption, and AES-256 Kerberos ticket encryption:

az storage account file-service-properties update \
  --account-name mystorageacct \
  --resource-group my-rg \
  --versions "SMB3.1.1" \
  --authentication-methods "Kerberos" \
  --kerberos-ticket-encryption "AES-256" \
  --channel-encryption "AES-256-GCM"

Confirm the change took effect:

az storage account file-service-properties show \
  --account-name mystorageacct \
  --resource-group my-rg \
  --query "protocolSettings.smb"

You should see only the hardened values listed for each setting.

Option 2: Azure portal

1. Open your storage account and go to Data storage → File shares.
2. Select File share settings (or Configuration, depending on portal version).
3. Under the SMB security section, set SMB versions to SMB 3.1.1 only.
4. Set Authentication methods to Kerberos only.
5. Set Kerberos ticket encryption to AES-256.
6. Set SMB channel encryption to AES-256-GCM.
7. Save.

Option 3: Terraform

If you manage storage accounts with Terraform, set the SMB block on the azurerm_storage_account resource so the hardened profile is enforced on every apply:

resource "azurerm_storage_account" "files" {
  name                     = "mystorageacct"
  resource_group_name      = azurerm_resource_group.main.name
  location                 = azurerm_resource_group.main.location
  account_tier             = "Premium"
  account_kind             = "FileStorage"
  account_replication_type = "LRS"

  share_properties {
    smb {
      versions                        = ["SMB3.1.1"]
      authentication_types            = ["Kerberos"]
      kerberos_ticket_encryption_type = ["AES-256"]
      channel_encryption_type         = ["AES-256-GCM"]
    }
  }
}

---

How to prevent it from happening again

One-off fixes drift. The hardened profile needs to be enforced at provisioning time and continuously checked afterward.

Azure Policy

Use a custom Azure Policy with a deny or audit effect that inspects the SMB protocol settings. A deny policy stops anyone from creating or updating a storage account with weak SMB options in the first place. Here is the shape of the policy rule:

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Storage/storageAccounts/fileServices"
      },
      {
        "not": {
          "field": "Microsoft.Storage/storageAccounts/fileServices/protocolSettings.smb.versions[*]",
          "equals": "SMB3.1.1"
        }
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

Extend the conditions to cover authentication methods, channel encryption, and ticket encryption so the policy enforces the full profile, not just the protocol version.

CI/CD gates

If your storage accounts are defined in Terraform or Bicep, run a policy-as-code scan in your pipeline before apply. Tools like Checkov, tfsec, or Conftest with OPA can fail the build when the SMB block is missing or includes weak values. That catches the misconfiguration in the pull request rather than in production.

# Example: fail the pipeline if Checkov finds storage misconfigurations
checkov -d ./infra --framework terraform \
  --check CKV_AZURE_* --compact

Continuous monitoring

Provisioning gates do not catch manual changes made through the portal or CLI after deployment. Run storage_filesmbsecurity on a schedule with Lensix so any account that drifts back to a weak profile surfaces as a finding, with the offending settings spelled out.

---

Best practices

• Inventory clients before hardening. The biggest risk with this change is breaking legacy clients. Know your SMB client versions first, then upgrade or isolate anything that cannot do 3.1.1.
• Apply the full profile, not a subset. Hardening the protocol version but leaving NTLMv2 enabled still leaves the relay attack open. All four settings work together.
• Combine with private endpoints. SMB hardening protects the session, but you also want to keep file share traffic off the public internet. Use private endpoints and disable public network access where you can.
• Prefer identity-based access (Kerberos) over storage account keys. Kerberos-only authentication pairs naturally with Microsoft Entra Domain Services or AD DS integration, giving you per-user access control and audit trails instead of a shared key.
• Audit regularly. Encryption and protocol standards shift over time. AES-128 was fine years ago, RC4 was once standard. Re-check your storage posture as Microsoft deprecates older options.

Once the hardened profile is in place and enforced through policy, this is a low-maintenance control. The work is in the initial inventory and rollout. After that, the gates and monitoring keep it from quietly slipping back.