适用于： ✔️ SMB Azure 文件共享
在开始本文之前，请确保使用 Azure 基于角色的访问控制（RBAC） 为标识分配共享级别权限 。
分配共享级别权限后，可以在根、目录或文件级别配置 Windows 访问控制列表 (ACL)（也称为 NTFS 权限）。
重要
若要为混合标识配置 Windows ACL，您需要一台运行 Windows 的客户端计算机，该计算机需与域控制器保持畅通的网络连接。 如果通过 Active Directory 域服务 (AD DS) 或 Microsoft Entra Kerberos 对 Azure Files 进行身份验证以处理混合标识，则需要确保与本地 AD 的网络连接畅通无阻。 如果使用 Microsoft Entra 域服务，则客户端计算机必须对由 Microsoft Entra 域服务管理的、位于 Azure 内的域的域控制器保持未受阻碍的网络连接。
Azure RBAC 和 Windows ACL 如何协同工作
虽然共享级别权限（RBAC）充当高级守护程序，用于确定用户是否可以访问共享，但 Windows ACL（NTFS 权限）在更精细的级别运行，以控制用户可以在目录或文件级别执行的作。
当用户尝试访问文件或目录时，将强制实施共享级别和文件/目录级权限。 如果其中任一项之间存在差异，则仅应用限制性最大的一个。 例如，如果用户在文件级别具有读取/写入访问权限，但在共享级别只具有读取权限，则该用户只能读取该文件。 如果权限被逆转，则适用相同的规则：如果用户在共享级别具有读/写访问权限，但只能在文件级别读取，则他们仍然可以读取该文件。
下表显示了共享级别权限和 Windows ACL 的组合如何协同工作，以确定对 Azure 文件中文件或目录的访问权限。
| 无 RBAC 角色 | RBAC - SMB 共享读取器 | RBAC - SMB 共享贡献者 | RBAC - SMB 共享高级贡献者 | |
|---|---|---|---|---|
| NTFS - 无 | 访问被拒绝 | 访问被拒绝 | 访问被拒绝 | 访问被拒绝 |
| NTFS - 读取 | 访问被拒绝 | 读取 | 读取 | 读取 |
| NTFS - 运行和执行 | 访问被拒绝 | 读取 | 读取 | 读取 |
| NTFS - 列表文件夹 | 访问被拒绝 | 读取 | 读取 | 读取 |
| NTFS - 写入 | 访问被拒绝 | 读取 | 读取、运行、写入 | 读取和写入 |
| NTFS - 修改 | 访问被拒绝 | 读取 | 读取、写入、运行、删除 | 读取、写入、运行、删除、向自己的文件夹/文件应用权限 |
| NTFS - 完整 | 访问被拒绝 | 读取 | 读取、写入、运行、删除 | 读取、写入、执行、删除，对任何人的文件夹及文件进行权限应用 |
注意
获取 ACL 配置的文件夹或文件的所有权需要额外的 RBAC 权限。 使用 SMB 管理员的 Windows 权限模型，可以通过分配包含权限的内置 RBAC 角色存储文件数据 SMB 管理员takeOwnership来授予此权限。
支持的 Windows ACL
Azure 文件存储支持全套基本和高级 Windows ACL。
| 用户 | 定义 |
|---|---|
BUILTIN\Administrators |
表示文件服务器的管理员的内置安全组。 此组为空，无法将用户添加到其中。 |
BUILTIN\Users |
表示文件服务器的用户的内置安全组。 默认情况下，它包括 NT AUTHORITY\Authenticated Users。 对于传统的文件服务器，可以为每个服务器配置成员身份定义。 对于 Azure 文件存储，没有托管服务器，因此 BUILTIN\Users 包含与 NT AUTHORITY\Authenticated Users 相同的一组用户。 |
NT AUTHORITY\SYSTEM |
文件服务器操作系统的服务帐户。 此类服务帐户在 Azure 文件存储上下文中不适用。 它包含在根目录中，以便与混合方案的 Windows 文件服务器体验保持一致。 |
NT AUTHORITY\Authenticated Users |
AD 中可获取有效 Kerberos 票证的所有用户。 |
CREATOR OWNER |
每个对象（目录或文件）都有该对象的所有者。 如果向该对象分配了 CREATOR OWNER ACL，则此对象的所有者的用户有权访问 ACL 定义的对象。 |
文件共享的根目录包含以下权限：
BUILTIN\Administrators:(OI)(CI)(F)BUILTIN\Users:(RX)BUILTIN\Users:(OI)(CI)(IO)(GR,GE)NT AUTHORITY\Authenticated Users:(OI)(CI)(M)NT AUTHORITY\SYSTEM:(OI)(CI)(F)NT AUTHORITY\SYSTEM:(F)CREATOR OWNER:(OI)(CI)(IO)(F)
有关这些权限的详细信息，请参阅 icacls 的命令行参考。
使用管理员级访问权限装载文件共享
在配置 Windows ACL 之前，请装载具有管理员级访问权限的文件共享。 可以采用两种方法：
使用 SMB 管理员的 Windows 权限模型：分配内置的 RBAC 角色 存储文件数据 SMB 管理员，其中包括配置 ACL 的用户所需的权限。 然后使用 基于标识的身份验证 装载文件共享并配置 ACL。 此方法更安全，因为它不需要存储帐户密钥来装载文件共享。
使用存储帐户密钥（不建议）：使用存储帐户密钥装载文件共享，然后配置 ACL。 存储帐户密钥是敏感凭据。 出于安全原因，仅当无法使用基于标识的身份验证时，才使用此选项。
注意
如果用户拥有 完全控制 ACL 和 存储文件数据 SMB 共享高级贡献者 角色（或具备必要权限的自定义角色），他们可以在不使用 Windows 权限模型处理 SMB 管理功能或存储帐户密钥的情况下配置 ACL。
使用 SMB 管理员的 Windows 权限模型
建议对 SMB 管理员使用 Windows 权限模型，而不是使用存储帐户密钥。 借助此功能，你可以向用户分配内置的 RBAC 角色 存储文件数据 SMB 管理员 ，以便他们拥有文件或目录的所有权，以便配置 ACL。
存储文件数据 SMB 管理员 RBAC 角色包含以下三个数据操作：
Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/actionMicrosoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/actionMicrosoft.Storage/storageAccounts/fileServices/takeOwnership/action
若要使用 SMB 管理员的 Windows 权限模型，请执行以下步骤：
将 存储文件数据 SMB 管理员 RBAC 角色分配给配置 ACL 的用户。 有关如何分配角色的说明，请参阅 使用 Azure 门户分配 Azure 角色。
让用户使用其域标识装载文件共享。 只要为存储帐户配置 了基于标识的身份验证 ，就可以装载共享并配置和编辑 Windows ACL，而无需使用存储帐户密钥。
登录到已加入域的设备，或网络连接畅通无阻可以访问域控制器的设备（如果 AD 源是 Microsoft Entra 域服务，则以 Microsoft Entra 用户身份登录）。 通过运行以下命令打开 Windows 命令提示符并装载文件共享。 将
<YourStorageAccountName>和<FileShareName>替换为自己的值。 如果 Z: 已在使用中，请将其替换为可用的驱动器号。使用
net use命令在此阶段挂载共享，而不要使用 PowerShell。 如果使用 PowerShell 装载共享，则共享对 Windows 文件资源管理器或 cmd.exe不可见，并且很难配置 Windows ACL。net use Z: \\<YourStorageAccountName>.file.core.chinacloudapi.cn\<FileShareName>
使用存储帐户密钥挂载文件共享（不推荐）
警告
如果可能，请使用 SMB 管理员的 Windows 权限模型 装载共享，而不是使用存储帐户密钥。
登录到已加入域的设备，或网络连接畅通无阻可以访问域控制器的设备（如果 AD 源是 Microsoft Entra 域服务，则以 Microsoft Entra 用户身份登录）。 打开 Windows 命令提示符，并通过运行以下命令装载文件共享。 将 、 和 替换为自己的值<YourStorageAccountName><FileShareName><YourStorageAccountKey>。 如果 Z: 已在使用中，请将其替换为可用的驱动器号。 可以通过在 Azure 门户中导航到存储帐户并选择“安全 + 网络”“访问密钥”找到你的存储帐户密钥，也可以使用 > PowerShell cmdlet 找到它。
使用net use命令在此阶段挂载共享，而不要使用 PowerShell。 如果使用 PowerShell 装载共享，则共享对 Windows 文件资源管理器或 cmd.exe不可见，并且很难配置 Windows ACL。
net use Z: \\<YourStorageAccountName>.file.core.chinacloudapi.cn\<FileShareName> /user:localhost\<YourStorageAccountName> <YourStorageAccountKey>
配置 Windows ACL
可以使用 icacls 配置 Windows ACL，也可以使用 Windows 文件资源管理器。 还可以使用 Set-ACL PowerShell 命令。 如果本地文件服务器中有针对 AD DS 标识配置的 Windows ACL 中的目录或文件，则可以将其复制到 Azure 文件存储，同时使用传统文件复制工具（如 Robocopy 或 最新版本的 Azure AzCopy）来保留 ACL。 如果通过 Azure 文件同步将目录和文件分层到 Azure 文件存储，ACL 会以原生格式传递并保留。
重要
如果使用 Microsoft Entra Kerberos 对混合标识进行身份验证，则必须将混合标识同步到 Microsoft Entra ID 才能强制实施 ACL。 可以为未同步到 Microsoft Entra ID 的标识设置文件和目录级别 ACL。 但是，不会强制实施这些 ACL，因为用于身份验证和授权的 Kerberos 票证不包含尚未同步的身份标识。 如果使用本地 AD DS 作为 AD 源，则可以在 ACL 中包含未同步的标识。 AD DS 将这些 SID 放入 Kerberos 票据中，并执行 ACL 规则。
使用 Azure 门户配置 Windows ACL
如果Microsoft Entra Kerberos 配置为标识源，则可以使用 Azure 门户为每个 Entra 用户或组配置 Windows ACL。
登录到 Azure 门户。
导航到您想要配置 Windows ACL 的文件共享。
在服务菜单中，选择“ 浏览”。 如果要在根文件夹中设置 ACL，请从顶部菜单中选择 “管理访问权限 ”。
若要为文件或目录设置 ACL，请右键单击文件或目录，然后选择“ 管理访问权限”。
现在应会看到可用的用户和组。 可以选择性地添加新用户或组。 选择任何用户或组最右侧的铅笔图标，添加或编辑用户/组访问指定文件/目录的权限。
编辑权限。 拒绝始终优先于允许，当两者都设置时。 两者均未设置时，将继承默认权限。
选择 “保存” 以设置 ACL。
使用 icacls 配置 Windows ACL
若要向文件共享下的所有目录和文件（包括根目录）授予完全权限，请在与 AD 域控制器的网络连接不受阻碍的计算机上运行以下 Windows 命令。 请务必将示例中的占位符值替换为你自己的值。 如果 AD 源是 Microsoft Entra 域服务，则 <user-upn> 为 <user-email>.
icacls <mapped-drive-letter>: /grant <user-upn>:(f)
若要详细了解如何使用 icacls 设置 Windows ACL，以及各种受支持的权限，请参阅 icacls 的命令行参考。
使用 Windows 文件资源管理器配置 Windows ACL
如果登录到已加入域的 Windows 客户端，可以使用 Windows 文件资源管理器向文件共享下的所有目录和文件（包括根目录）授予完全权限。
重要
如果你的客户端未加入域，或者如果你的环境有多个 AD 林，请勿使用 Windows 资源管理器来配置 ACL。 请改用 icacls。 存在此限制，因为 Windows 文件资源管理器 ACL 配置要求客户端联入与存储帐户所在的 AD 域。
按照以下步骤使用 Windows 文件资源管理器配置 ACL。
- 打开 Windows 文件资源管理器，右键单击文件或目录，然后选择“ 属性”。
- 选择“安全”选项卡。
- 选择“编辑...”以更改权限。
- 更改现有用户的权限，或选择“ 添加...” 以向新用户授予权限。
- 在添加新用户的提示窗口中，在“输入要选择的对象名称”框中输入要向其授予权限的目标用户名，然后选择“检查名称”以查找目标用户的完整 UPN 名称 。 你可能需要为本地 AD 指定域名和域 GUID。 可以从域管理员处或从已加入本地 AD 的客户端获取此信息。
- 选择“确定”。
- 在“安全性”选项卡中，选择要授予新用户的所有权限。
- 选择“应用”。