你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
SMB 和 NFS 使用不同的权限模型进行用户和组访问。 因此，必须将 Azure NetApp 文件卷配置为遵循协议访问所需的权限模型。 对于仅限 NFS 的环境，决策很简单 - 使用 UNIX 安全样式。 对于仅限 SMB 的环境，请使用 NTFS 安全样式。
如果需要同一数据集上的 NFS 和 SMB（双协议），则应根据两个问题做出决策：
- 用户最常通过哪个协议来管理权限？
- 所需的权限管理终结点是什么？ 换句话说，用户是否需要能够管理来自 NFS 客户端或 Windows 客户端的权限？ 或者都要？
卷安全样式实际上可以被视为权限样式，其中所需的 ACL 管理样式是决定性因素。
注释
安全样式是在创建卷时选择的。 选择安全样式后，无法更改它。
关于 Azure NetApp 文件卷安全样式
Azure NetApp 文件中的卷安全样式有两个主要选项：
UNIX - UNIX 安全样式提供 UNIX 样式权限，例如基本 POSIX 模式位（具有标准读/写/执行权限的“所有者/组/每个人”访问权限，例如 0755）和 NFSv4.x ACL。 不支持 POSIX ACL。
NTFS - NTFS 安全样式提供的功能与 标准 Windows NTFS 权限相同，ACL 中的精细用户和组以及详细的安全/审核权限。
在双协议 NAS 环境中，只有一种安全权限样式可以处于活动状态。 在选择每个安全样式之前，应评估每个安全样式的注意事项。
| 安全样式 | 注意事项 |
|---|---|
| UNIX | - Windows 客户端只能通过映射到 UNIX 属性的 SMB 设置 UNIX 权限属性（仅读/写/执行;无特殊权限）。 - NFSv4.x ACL 没有 GUI 管理。 仅使用 nfs4_getfacl 和 nfs4_setfacl 命令通过 CLI 进行管理。 - 如果文件或文件夹具有 NFSv4.x ACL，则 Windows 安全属性选项卡无法显示它们。 |
| NTFS | - UNIX 客户端无法通过 NFS 通过命令（例如 chown/chmod） 设置属性。 - NFS 客户端在使用 ls 命令时仅显示近似的 NTFS 权限。 例如，如果用户在 Windows NTFS ACL 中具有无法完全转换为 POSIX 模式位（例如遍历目录）的权限，则会将其转换为最接近的 POSIX 模式位值（例如用于执行的 1）。 |
卷安全样式的选择决定了如何执行用户的名称映射。 此操作是双协议存储卷如何保持权限可预测性的核心机制，无论使用哪种协议。
使用下表作为选择适当的卷安全样式的决策矩阵。
| 安全样式 | 主要是 NFS | 主要是 SMB | 需要精细的安全性 |
|---|---|---|---|
| UNIX | X | - | X（使用 NFSv4.x ACL） |
| NTFS | - | X | X |
名称映射在 Azure NetApp 文件中的工作原理
在 Azure NetApp 文件中，仅对用户进行身份验证和映射。 不映射组。 而是使用用户标识确定组成员身份。
当用户尝试访问 Azure NetApp 文件卷时，该尝试会将标识传递给服务。 该标识包括用户名和唯一的数字标识符（NFSv3 的 UID 编号、NFSv4.1 的名称字符串、SMB 的 SID）。 Azure NetApp Files 使用该身份对配置的命名服务进行认证，以验证用户的身份。
- LDAP 搜索数字 ID 用于在 Active Directory 中查找用户名。
- 名称字符串使用 LDAP 搜索查找用户名，客户端和服务器会查阅 NFSv4.1 配置的 ID 域 以确保匹配。
- 使用标准的 Windows 远程过程调用 (RPC) 来查询 Active Directory 中的 Windows 用户。
- 还会查询组成员身份，并将所有内容添加到凭据缓存，以便更快地处理对卷的后续请求。
- 目前，不支持自定义本地用户用于 Azure NetApp 文件。 只有 Active Directory 中的用户才能与双重协议一起使用。
- 目前，可使用双重协议卷的唯一本地用户是根用户和
nfsnobody用户。
在 Azure NetApp 文件对用户名进行身份验证和验证后，双重协议卷身份验证的下一步是映射用户名以实现 UNIX 和 Windows 互操作性。
卷的安全样式决定了名称映射在 Azure NetApp 文件中的发生方式。 Windows 和 UNIX 权限语义不同。 如果无法执行名称映射，身份验证会失败，并且拒绝从客户端访问卷。 出现这种情况的常见场景是，尝试对使用 NTFS 安全样式的卷进行 NFSv3 访问。 来自 NFSv3 的初始访问请求以数字 UID 的形式来到 Azure NetApp 文件。 如果名为 user1 且数字 ID 为 1001 的用户尝试访问 NFSv3 装载，则身份验证请求以数字 ID 1001 的形式到达。 然后，Azure NetApp 文件采用数字 ID 1001 并尝试解析 1001 为用户名。 由于卷上的 NTFS 权限包含的是 Windows 用户名而不是数字 ID，因此需要此用户名才能映射到有效的 Windows 用户。 Azure NetApp 文件将使用配置的名称服务服务器（LDAP）来搜索用户名。 如果找不到用户名，身份验证将失败，并且访问被拒绝。 此操作是为了防止对文件和文件夹进行不必要的访问而设计的。
基于安全样式的名称映射
Azure NetApp 文件中名称映射的方向（Windows 到 UNIX 或 UNIX 到 Windows）不仅取决于所使用的协议，还取决于卷的安全样式。 Windows 客户端始终需要 Windows 到 UNIX 名称映射才能允许访问，但它并不总是需要匹配的 UNIX 用户名。 如果配置的名称服务服务器中不存在有效的 UNIX 用户名，Azure NetApp 文件会提供回退默认 UNIX 用户，其数字 UID 为 65534 允许对 SMB 连接进行初始身份验证。 之后，文件和文件夹权限将控制访问权限。 由于 65534 通常与 nfsnobody 用户相对应，因此在大多数情况下，访问受到限制。 相反，如果使用 NTFS 安全样式，则 NFS 客户端只需使用 UNIX 到 Windows 的名称映射。 Azure NetApp 文件中没有默认的 Windows 用户。 因此，如果找不到与请求名称匹配的有效 Windows 用户，将拒绝访问。
下表分解了不同的名称映射排列，以及它们的行为方式取决于所使用的协议。
| 协议 | 安全样式 | 名称映射方向 | 已应用的权限 |
|---|---|---|---|
| 中小型企业 (SMB) | UNIX | Windows 到 UNIX | UNIX （模式位或 NFSv4.x ACL） |
| 中小型企业 (SMB) | NTFS | Windows 到 UNIX | NTFS ACL （基于 Windows SID 访问共享） |
| NFSv3 | UNIX | 没有 | UNIX （模式位或 NFSv4.x ACL*） |
| NFSv4.x | UNIX | 数字 ID 到 UNIX 用户名 | UNIX （模式位或 NFSv4.x ACL） |
| NFS3/4.x | NTFS | UNIX 到 Windows | NTFS ACL （基于映射的 Windows 用户 SID） |
注释
Azure NetApp 文件中的名称映射规则目前只能通过使用 LDAP 进行控制。 没有在服务中创建显式名称映射规则的选项。
使用双重协议卷的名称服务
无论使用什么 NAS 协议，双协议卷都使用名称映射概念来正确处理权限。 因此，名称服务在使用 SMB 和 NFS 访问存储卷的环境中，对系统功能的维护起着关键作用。
名称服务充当访问 NAS 卷的用户和组的标识源。 此操作包括 Active Directory，它可以作为使用标准域服务和 LDAP 功能的 Windows 和 UNIX 用户和组的源。
名称服务不是硬性要求，但强烈建议将其用于 Azure NetApp 文件双重协议卷。 服务中没有创建自定义本地用户和组的概念。 因此，若要跨协议正确进行身份验证和准确的用户和组所有者信息，LDAP 是必需的。 如果只有少数用户，并且不需要填充准确的用户和组标识信息，请考虑使用允许使用 LDAP 的本地 NFS 用户访问双重协议卷功能。 请记住，启用此功能会禁用 扩展组功能。
当客户端、名称服务和存储驻留在不同的区域时
在某些情况下，NAS 客户端可能位于具有与存储和名称服务的隔离连接的多个接口的分段网络中。
例如，如果存储驻留在 Azure NetApp 文件中，而 NAS 客户端和域服务都驻留在本地（例如 Azure 中的中心辐射型体系结构）。 在这些情况下，需要提供对 NAS 客户端和名称服务的网络访问权限。
下图显示了该类型配置的示例。
