你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
了解Azure NetApp 文档中的双重协议安全样式和权限行为
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） 设置属性。 - 使用命令时 ls ，NFS 客户端仅显示近似的 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 文档使用该标识对已配置的名称服务进行身份验证，以验证用户的标识。
- LDAP 搜索数字 ID 用于在 Active Directory 中查找用户名。
- 名称字符串使用 LDAP 搜索查找用户名，客户端和服务器会查阅 NFSv4.1 配置的 ID 域以确保匹配。
- 使用对 Active Directory 的标准 Windows RPC 调用查询 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为用户名。 映射到有效的 Windows 用户需要此用户名，因为卷上的 NTFS 权限将包含 Windows 用户名，而不是数字 ID。 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 （mode-bits 或 NFSv4.x ACL） |
| SMB | NTFS | Windows 到 UNIX | NTFS ACL （基于 Windows SID 访问共享） |
| NFSv3 | UNIX | 无 | Unix （mode-bits 或 NFSv4.x ACL*） |
| NFSv4.x | UNIX | UNIX 用户名的数值 ID | Unix （mode-bits 或 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 客户端和名称服务的网络访问权限。
下图显示了该类型配置的示例。
