Azure Files SMB 现已支持纯 Entra 身份认证：云原生身份体系再补一块拼图

预计阅读时间：8 分钟

过去要让 Azure Files SMB 共享支持身份认证，你得先把本地 Active Directory 同步到云端——要么用 Azure AD Connect 做混合身份，要么单独注册域控制器。对于完全云原生的团队来说，这套依赖就像为了开一扇门先盖一整栋楼。现在 Azure Files SMB 正式 GA 了 Entra-Only identities，意味着纯云端的 Microsoft Entra ID 用户和组可以直接访问 SMB 文件共享，不再需要任何本地 AD 的影子。

为什么这件事值得关注

此前 Azure Files SMB 支持三种身份源：本地 AD DS、Azure AD DS（已停止新部署）、以及混合 Entra ID。三种方案都绕不开"本地域"这个概念。对于以下场景，这个限制一直很痛：

全云团队——没有本地域控制器，也不想为了文件共享搭一个。
SaaS /初创公司——身份全在 Entra ID，本地 AD 从未存在。
多租户环境——不同租户的 Entra ID 用户需要访问各自文件共享，混合同步根本不可行。

Entra-Only 模式把这些门槛全部拆掉：Entra ID 里的用户就是合法身份，直接映射到 SMB 共享的 NTFS 权限。

工作原理简述

核心变化在存储账户的身份源配置。启用 Entra-Only 后：

存储账户关联到 Microsoft Entra ID tenant（不再关联任何本地域）。
SMB 共享的权限分配直接引用 Entra ID 的用户和组对象。
客户端通过 Kerberos 向 Entra ID 获取令牌，Azure Files 验证令牌后按 NTFS ACL 授予访问。

客户端侧要求 Windows 10 21H2+ 或 Windows Server 2022+，并需要安装 AzFilesHybrid 模块执行一次 Kerberos 配置（注册 SPN 等），但这一步不再依赖本地域。

实操：从零配置一个 Entra-Only SMB 共享

下面用 Azure CLI + PowerShell 完成完整流程。假设你已有存储账户和 Entra ID tenant。

第一步：在存储账户上启用 Entra-Only 身份源

# 设置存储账户使用 Entra-Only 身份源（不再关联本地 AD）
az storage account update \
  --name mystorageaccount \
  --resource-group myrg \
  --default-share-tier StandardSS \
  --account-type StorageV2

# 关键：配置身份源为 Entra ID（纯云）
az rest --method put \
  --url "/subscriptions/{subscriptionId}/resourceGroups/myrg/providers/Microsoft.Storage/storageAccounts/mystorageaccount?api-version=2023-05-01" \
  --body '{
    "properties": {
      "azureFilesIdentityBasedAuthentication": {
        "directoryServiceOptions": "AADKERB"
      }
    }
  }'

AADKERB 是 Entra-Only 的标识值。此前混合模式用的是 AAD。确认你的 API 版本支持此值（2023-05-01 及以后）。

第二步：用 AzFilesHybrid 注册 Kerberos SPN

这一步让 Entra ID 能为 Azure Files 发出 Kerberos 票据。在本地或云端 VM 上执行：

# 安装模块（需要 PowerShell 5.1+）
Install-Module AzFilesHybrid -Force

# 登录 Entra ID
Connect-AzAccount

# 为存储账户配置 Kerberos——纯 Entra 模式不需要本地域凭据
Join-AzStorageAccountForAuth `
  -StorageAccountName "mystorageaccount" `
  -ResourceGroupName "myrg"

执行完成后，模块会自动在 Entra ID 中注册必要的 SPN 和 Kerberos 密钥。你可以验证：

# 检查配置状态
Get-AzStorageAccount `
  -ResourceGroupName "myrg" `
  -Name "mystorageaccount" | `
  Select-Object -ExpandProperty AzureFilesIdentityBasedAuthentication

输出应显示 DirectoryServiceOptions: AADKERB。

第三步：为 Entra ID 用户/组分配 SMB 共享权限

# 获取 Entra ID 组的对象 ID
az ad group show --group "FinanceTeam" --query objectId -o tsv

# 赋予该组对 SMB 共享的 "Storage File Data SMB Share Contributor" 角色
az role assignment create \
  --role "Storage File Data SMB Share Contributor" \
  --assignee <group-object-id> \
  --scope "/subscriptions/{subscriptionId}/resourceGroups/myrg/providers/Microsoft.Storage/storageAccounts/mystorageaccount/fileServices/default/fileshares/myshare"

可用的 RBAC 角色按权限粒度从高到低：

角色	能做什么
Storage File Data SMB Share Elevated Contributor	修改 NTFS ACL + 读写文件
Storage File Data SMB Share Contributor	读写文件，不能改 ACL
Storage File Data SMB Share Reader	只读

第四步：客户端挂载共享

在满足版本要求的 Windows 客户端上：

# 映射网络驱动器——使用 Entra ID 身份（无需本地域凭据）
net use Z: \\mystorageaccount.file.core.windows.net\myshare

如果客户端已登录 Entra ID（通过公司设备加入或 Azure AD Join），Kerberos 票据会自动获取，挂载无需额外输入密码。

边界与取舍

Entra-Only 不是万能替代，几个现实限制需要提前评估：

本地 AD 用户无法直接使用——如果你的环境中仍有大量本地 AD 用户且未同步到 Entra ID，这些用户访问不了 Entra-Only 共享。混合环境仍需混合身份源。
Kerberos 依赖客户端配置——Linux 客户端目前需要手动配置 Kerberos 和 cifs-utils，流程比 Windows 复杂得多。
NTFS ACL 仍需 Windows 工具设置——共享级别的 RBAC 通过 Azure CLI/Portal 完成，但文件/目录级别的 NTFS ACL 需要从一台已挂载的 Windows 机器用 icacls 或文件管理器设置——这一步没有纯 CLI 替代。
不支持 DFS-N 命名空间——Entra-Only 模式下暂不支持 DFS 命名空间抽象，大规模部署需要自行规划路径映射。

什么时候该切换

简单判断：如果你的组织没有本地域控制器，或者所有用户已经完全在 Entra ID 中管理，Entra-Only 是默认选择。 它省掉了 Azure AD Connect 同步、域控制器运维、以及混合身份的调试成本。

如果你仍在混合身份阶段，可以逐步迁移：新建存储账户用 Entra-Only，旧账户保持混合模式。两种身份源可以在同一 tenant 下并存，只是不能在同一个存储账户上混用。

一个快速检查清单：

☐ 所有需要访问文件共享的用户是否都在 Entra ID 中？
☐ 客户端是否满足 Windows 10 21H2+ / Server 2022+？
☐ 是否有 Linux 客户端访问需求？（需额外 Kerberos 配置）
☐ 是否依赖 DFS-N？（目前不支持）
☐ 是否有工具机可用于设置 NTFS ACL？

全绿则直接上 Entra-Only；有红灯项就先评估替代路径或等待后续更新。这个 GA 版本把云原生身份体系在文件存储上的最后一道门打开了，但门外的路还需要你自己走一段。