通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

了解 Azure NetApp 文件中的 Kerberos

Kerberos 是一种身份验证协议，它使用密钥来验证主体的身份。 密钥的生成方式是使用客户端和服务器同意的加密方法（如 AES）将主体的密码转换为哈希加密密钥格式。 请参阅 Kerberos 术语部分，了解本文档中使用的术语。

Windows Active Directory 等密钥分发中心 (KDC) 维护 Kerberos 主体及其哈希密码的数据库。 在 Kerberos 中，密钥是唯一标识的证明。 因此，可以放心地使用 KDC 向任何主体验证其他主体的身份。例如，在装载时向 NFS 服务器 SPN 验证 NFS 客户端服务主体名称 (SPN)。 还可以放心地使用 KDC 向 NFS 服务器 SPN 验证用户主体的身份，以便用户访问 NAS 装入点。 作为一项额外安全措施，Kerberos 不会通过网络发送明文密码进行身份验证。

Azure NetApp 文件支持使用 Kerberos 为 SMB 和 NFS 协议提供传输中的安全性。

受支持的加密类型

Azure NetApp 文件支持具有特定加密类型的 NFS Kerberos，具体取决于所使用的操作模式和版本。

若要确保客户端使用适当的加密类型，可以限制位于 KDC（例如计算机帐户）或客户端中手动创建的密钥表文件中的对象主体的有效加密类型（如果可行），而不是在 /etc/krb5.conf 文件中全局限制，因为管理大量客户端 krb5.conf 文件可能会成为难题。 从 KDC 集中管理 Kerberos 在大型企业环境中更具可缩放性，可以更轻松地自动执行，并且在支持更强加密类型的情况下强制客户端使用这些类型。

注意

建议在客户端上的 krb5.conf 文件中将选项 allow_weak_crypto 设置为 false。 此设置可防止使用安全系数较低的enctypes进行 Kerberos 通信（如 DES 或 3DES）。

下表显示了 Azure NetApp 文件的 Kerberos（SMB 和 NFS）支持的加密类型。

协议 受支持的加密类型
SMB
  • RC4-HMAC
  • AES-128
  • AES-256
NFS AES-256

受支持的 NFS Kerberos 安全模式

除了加密类型的概念外，Kerberos 中还有安全性级别和完整性检查。 使用的安全模式各有不同，这些安全模式通过为 NFS 流量提供端到端加密来帮助防止中间人攻击。

在 Azure NetApp 文件中，这些安全模式在针对 NFS 卷设置的导出策略规则中指定，并在初始 NFS 装载期间通过 sec 装载选项定义。

例如：# mount -o sec=krb5p

注意

对于 SMB Kerberos，Kerberos 的安全模式是通过共享上的 SMB 加密设置、UNC 强化和域控制器上的 SMB 签名/密封策略进行控制的。

Azure NetApp 文件支持以下安全模式，以便与 NFS Kerberos 配合使用：

安全模式 说明
krb5 仅身份验证加密。

使用 Kerberos V5 名称字符串和用户主体名称，而不是本地 UNIX 用户 ID (UID) 和组 ID (GID) 对用户进行身份验证。
krb5i 身份验证加密和加密完整性检查。

使用 Kerberos V5 进行用户身份验证，并使用安全校验来执行 NFS 操作的完整性检查，以防止数据篡改和中间人攻击。
krb5p 加密了整个 NFS 对话。

使用 Kerberos V5 进行用户身份验证和完整性检查，并加密所有 NFS 流量，以防止数据包探查。 此设置最安全，但产生的性能开销也最大。

Kerberos 术语

本节定义了描述 Kerberos 进程时使用的关键术语。 本节旨在帮助解释对存储管理员可能比较陌生的术语。

术语 定义
密钥分发中心 (KDC) KDC 是身份验证服务器，其中包括票证授予服务 (TGS) 和身份验证服务 (AS)。 术语 KDC、AS 和 TGS 可互换使用。 在Microsoft环境中，Active Directory （AD） 域控制器是 KDC。 只能通过 修改 AD 设置来修改 KDC 值。
领域（或 Kerberos 领域） 领域（或 Kerberos 领域）可以使用任何 ASCII 字符串。 标准是以大写形式使用域名；例如，contoso.com 变为域 CONTOSO.COM。 通常在客户端和服务器上的 krb5.conf 文件中配置 Kerberos 领域。

从管理上来说，每个 principal@REALM 必须是唯一的。 为了避免单一故障点，每个领域可以有多个 KDC 共享同一数据库（主体及其密码），并具有相同的 KDC 主密钥。 Microsoft Windows Active Directory 通过 Active Directory 复制以本机方式执行此操作，默认情况下每隔 15 分钟进行一次。
主体 术语“主体”指 Kerberos 数据库中的每个实体。 用户、计算机和服务都是为 Kerberos 身份验证分配的主体。 每个主体都必须在 Kerberos 数据库中是唯一的，并且由其可分辨名称定义。 主体可以是用户主体名称 (UPN) 或服务主体名称 (SPN)。

主体名称有三个部分：
  • 主要 - 主要部分可以是用户或服务，例如 NFS 服务。 它也可以是特殊服务“主机”，表示此服务主体被设置为提供多个各种网络服务。
  • 实例 - 此部分对于用户是可选的。 用户可以有多个主体，但每个主体在 KDC 中必须是唯一的。 例如，Fred 可能有一个用于日常使用的主体 (fred@contoso.com) 和一个允许特权使用的主体，例如 sysadmin 帐户 (admin-fred@contoso.com)。 服务主体需要该实例，且该实例指定提供服务的主机的完全限定域名 (FQDN)。
  • 领域 - Kerberos 领域是在 Kerberos 服务器中注册的 Kerberos 主体集。 按照约定，领域名称通常与 DNS 名称相同，但转换为大写字母。 大写字母不是强制性的，但这一约定让 DNS 名称和领域名称容易区分。
票证 票证是一组临时凭据，可验证服务的主体标识并包含会话密钥。 票证可以是服务、应用程序票证或票证授予票证 (TGT)。 票证在客户端、服务器和 KDC 之间交换，用于 Kerberos 身份验证。
密钥 Kerberos 使用对称密钥系统，其中密钥同时用于加密和解密。 密钥是通过单向哈希函数从主体的 Kerberos 密码生成的。 KDC 存储每个主体的密码，因此可以生成主体的密钥。 对于请求 Kerberos 服务的用户，密钥通常派生自提供给 kinit 程序的密码。 服务和守护程序主体通常不使用密码，而是将单向哈希函数的结果存储在密钥表中。
密钥表 密钥表包含主体及其密钥的列表。 密钥表中的密钥通常使用随机密码创建，主要用于服务或守护程序主体。

网络端口信息

下表介绍了哪些网络端口用于 Kerberos 通信。 如果网络防火墙已准备到位，则应打开这些端口以允许适当的 Kerberos 功能。 可以在 IANA 服务名称和传输协议端口号注册表中找到有关这些端口的详细信息。

服务 端口
Kerberos 88 （TCP/UDP）
kpasswd 464 （TCP/UDP）
轻型目录访问协议 (LDAP)（用于名称映射） 389 （TCP/UDP）
管理服务器 749 （TCP/UDP）
全局目录（Windows 用户查找） 3268 （TCP/UDP）

Azure NetApp 文件中的缓存期限值

下表显示缓存条目在 Azure NetApp 文件卷中存在的时间。

缓存 缓存期限
空闲域名服务器连接 60 秒
LDAP 查询超时 10 秒
KDC TTL 的本地 DNS 主机条目 24 小时
Kerberos 票证期限 由 KDC* 和/或客户端指定

* Windows Active Directory KDC 的默认值为 10 小时
用户凭据 24 小时
Kerberos 时间倾斜 5 分钟

在 Azure NetApp 文件中正常运行 Kerberos 环境的要求

Kerberos 身份验证高度依赖于外部服务来正常运行。 在 Microsoft Active Directory 中，多数情况下大部分服务被合并为单个服务器。 例如，Active Directory 域控制器可以服务以下 Kerberos 依赖项：

  • 时间同步服务
  • DNS
  • Kerberos 密钥发行
  • 密码服务/单一登录
  • 标识服务（如 LDAP）

使用本机 Microsoft Active Directory（Azure NetApp 文件当前唯一支持的 KDC 类型），则会涵盖 Azure NetApp 文件中 Kerberos 的大部分外部依赖项，例如 DNS、KDC 和密码服务。 在某些情况下，所需的服务可能托管在 Active Directory 域之外（如 DNS）。 在这些情况下，请务必确保所需的服务已正确配置。

Azure NetApp 文件具有用于正常运行 NFS Kerberos 的特定依赖项。 继续阅读以了解详细信息。

时间同步服务

使用 Kerberos 进行身份验证时，时间同步服务是必需的，因为 Kerberos 票证机制需要客户端和服务器之间的时间倾斜在默认的 5 分钟范围内。 如果客户端或服务器上的时间设置超过了默认的五分钟范围，Kerberos 身份验证将失败并显示时间倾斜错误 (KRB_AP_ERR_SKEW)，并且拒绝对 NAS 共享的访问。 此超时是一项安全功能，可帮助防止“重放攻击”。在此类攻击中，攻击者在 KDC 和客户端之间截获消息，之后重放这些消息，假冒已经过身份验证的用户。 时间倾斜限制有助于最大程度降低这些类型攻击的风险。

时间同步问题的关键注意事项：

有关详细信息，请参阅计算机时钟同步的最大容差

域名系统 (DNS)

作为安全功能，Kerberos 必须使用域名系统 (DNS)。 主机名解析用于构建用于身份验证的 Kerberos 服务主体。 在此过程中，对主机名（A/AAAA 记录）的前向查找用于连接到利用 Kerberos 身份验证的共享。 然后，该正向查找用于生成 Kerberos 身份验证请求中使用的服务主体名称 (SPN)。 如果在 KDC 中找不到现有 SPN，Kerberos 身份验证将失败。

在 Windows SMB 环境中，可能会尝试备份身份验证方法（例如 NTLM）。 但是，NTLM 在许多情况下出于安全原因被禁用，这会在 Kerberos 身份验证失败时导致对共享的访问失败。 Windows 事件查看器通常会记录失败的根本原因（例如重复/缺失的 SPN、DNS 查找失败、NTLM 失败等）。

除了 SPN 解析之外，DNS 还广泛用于通过 SRV 记录解析域名服务的主机名和 IP 地址，例如 LDAP、Kerberos KDC 等。 有关 Azure NetApp 文件中 DNS 的更多详细信息（包括所需的 SRV 记录），请参阅关于 Azure NetApp 文件中的 DNS。

注意

如果 IP 地址用于 Kerberos 访问，则行为取决于正在使用的 NAS 协议（NFS 或 SMB）。 有关详细信息，请参阅使用 Kerberos 进行访问的 IP 地址。

LDAP

轻型目录访问协议 (LDAP) 利用后端标识数据库为 NAS 客户端和服务器提供统一的名称服务源，以便所有参与的设备就用户真实性、组成员身份和数字 ID 达成一致，然后将其用于文件权限。

对于 Kerberos，用户和服务主体以 LDAP 数据库中的条目作为主体帐户的属性存储。 默认情况下，Windows Active Directory 支持此功能。 在某些情况下（例如创建别名或服务主体时），用户和计算机需要添加或修改服务主体名称。 可以使用 Active Directory 用户和计算机 Microsoft 管理控制台 (MMC) 或 PowerShell 来满足此要求。 有关管理服务主体名称的详细信息，请参阅管理服务主体名称。

除了用于 Kerberos 身份验证的服务主体名称和数字 ID 之外，LDAP 还可用于 UNIX 用户和组标识，这些标识用于 Azure NetApp 文件中标识的名称映射，以及通过 SPN -> UNIX 用户名映射装载 NFS Kerberos 的初始身份验证。 有关详细信息，请参阅 NFS Kerberos 在 Azure NetApp 文件中的工作原理，以及 LDAP 在 Azure NetApp 文件中使用 Kerberos 的角色。

SMB Kerberos 在 Azure NetApp 文件中的工作原理

SMB Kerberos 独立于 NFS Kerberos 服务工作，原因是为每个协议创建的计算机帐户无法共享密钥表，因为一个密钥表中密钥版本号 (kvno) 的更改可能会影响另一个服务。 由于这一点和 NAS 协议的自然差异，Kerberos 的 SMB 服务的工作流和 Kerberos 的 NFS 在某些方面的功能有所不同。

SMB 服务的初始配置

Azure NetApp 文件中的 SMB 服务最初是通过设置 Active Directory 连接来配置的，该连接定义了几个用于与域服务交互的关键部分，包括：

  • 主 DNS 服务器（必需）
  • 辅助 DNS
  • Active Directory DNS 名称*
  • Active Directory 站点名称（用于 DC 发现）（必需）
  • SMB 服务器前缀名称
  • 组织单位（在其中创建了 SMB 服务器计算机帐户）
  • AES 加密启用/禁用
  • LDAP 签名启用/禁用
  • LDAP 配置
  • SMB 加密到 DC
  • 特权用户
  • 具有组织单位权限的用户的用户凭据（用户名/密码）

注意

每个帐户仅限一个 Azure Active Directory (AD) 连接。 创建 AD 连接后，任何新的 Azure NetApp 文件 SMB 卷都使用 AD 连接配置。

SMB Kerberos 计算机帐户

Active Directory 中的计算机帐户包含用于身份验证请求的相关信息，包括服务主体名称 (SPN)。 在 Azure NetApp 文件中创建 SMB 卷时，Active Directory 连接配置将用于在创建计算机帐户时进行交互，以通过 Kerberos（或已启用的 NTLM）身份验证提供对 SMB 共享的安全访问。

在服务中的特定后端资源上预配 Azure NetApp 文件 SMB 卷时，会创建新的计算机帐户。 下面显示了可能在 Azure NetApp 文件卷配置中创建或重复使用 SMB 计算机帐户的不同应用场景。

场景 结果
第一个新的 SMB 卷 新的 SMB 计算机帐户/DNS 名称
第一个 SMB 卷后连续创建的后续 SMB 卷 重复使用的 SMB 计算机帐户/DNS 名称（在大多数情况下）。
后续 SMB 卷的创建时间比第一个 SMB 卷晚得多 该服务确定是否需要新计算机帐户。 可能会创建多个计算机帐户，从而创建多个 IP 地址终结点。
第一个双协议卷 新的 SMB 计算机帐户/DNS 名称
第一个双重协议卷后连续创建的后续双重协议卷 重复使用的 SMB 计算机帐户/DNS 名称（在大多数情况下）
比第一个双重协议卷晚很多创建的后续双重协议卷 该服务确定是否需要新计算机帐户。 可能会创建多个计算机帐户，从而创建多个 IP 地址终结点
在双重协议卷之后创建的第一个 SMB 卷 新的 SMB 计算机帐户/DNS 名称
在 SMB 卷之后创建的第一个双协议卷 新的 SMB 计算机帐户/DNS 名称

为 Azure NetApp 文件 SMB（或双协议）卷创建的 SMB 计算机帐户使用遵循 Active Directory 强制实施的 15 个字符最大值的命名约定。 该名称使用[Azure AD 连接配置中指定的 SMB 服务器前缀]-[唯一数字标识符]的结构。

例如，如果已 将 AD 连接配置为 使用 SMB 服务器前缀“AZURE”，则 Azure NetApp 文件创建的 SMB 计算机帐户类似于“AZURE-7806”。同一名称用于 SMB 共享的 UNC 路径（例如 \AZURE-7806），是动态 DNS 服务用于创建 A/AAAA 记录的名称。

注意

由于名称（如“AZURE-7806”）可能难以记住，因此最好创建 CNAME 记录作为 Azure NetApp 文件卷的 DNS 别名。 有关详细信息，请参阅创建 SMB 服务器别名。

Azure NetApp 文件中多个计算机帐户/DNS 条目的关系图。

在某些情况下，在创建多个 SMB 和/或双协议卷时，配置最终可能会有多个不同的 SMB 计算机帐户和 DNS 名称。

如果需要用于跨卷用户访问的单个命名空间，这可能会导致配置难题，因为单个 CNAME 别名只能指向单个 A/AAAA 主机记录；而如果使用多个相同的 A/AAAA 记录别名，可能会导致跨不同 SMB 计算机帐户访问卷时无法预测数据访问，因为这些配置中选择 DNS 记录的轮循机制导致无法保证客户端在 DNS 查找中选择的终结点包含预期卷。

为了解决此限制，Azure NetApp 文件卷可以作为目标参与Microsoft 分布式文件系统 (DFS) 配置，这可以提供将多个 SMB 卷与单个命名空间入口点相关联的方法。

Azure NetApp 文件中的分布式文件系统示意图。

创建 SMB Kerberos SPN 的工作流

下图演示了在创建 Azure NetApp 文件 SMB 或双协议卷时如何创建 SMB Kerberos SPN。 SMB SPN 与域中的 SMB 计算机帐户对象相关联。 可以使用高级视图中的属性编辑器通过计算机帐户属性查看和管理 SPN。

Azure-SMB 属性的屏幕截图。

还可以使用 setspn 命令查看和管理属性。

“setspn”命令的屏幕截图。

此流程遵循与常规 Windows 客户端加入域时相同的步骤（对命名管道的 DNS、LDAP、Kerberos、RPC 查询）。

Kerberos 计算机帐户示意图。

在大多数情况下，不必深入了解详细步骤也可以执行日常管理任务，但在尝试在 Azure NetApp 文件中创建 SMB 卷时，这有助于排查故障。

详细步骤

有关在 Azure NetApp 文件中创建 SMB 计算机帐户的详细步骤，请展开列表。

  • 执行 DNS 查找时使用 Kerberos KDC 的 SRV 记录的 DNS 配置。 Azure NetApp 文件在其请求中使用以下 SRV 记录。

    • _kerberos._tcp.dc._msdcs.CONTOSO.COM
    • _kerberos._tcp.CONTOSO.COM（如果上一个查询未返回任何结果）

  • 使用 SRV 查询中为 KDC 的 A/AAAA 记录返回的主机名来执行 DNS 查找。

    • 执行 LDAP ping（LDAP 绑定和 RootDSE 查询），以使用查询 () 和 NetLogon 属性筛选器搜索可用的旧版 &(DnsDomain=CONTOSO.COM)(NtVer=0x00000016) 服务器。 较新的 Windows 域控制器版本（2008 以上）不存在 NtVer 值。

  • Azure NetApp 文件执行 DNS 查询，以使用以下 SRV 记录在域中查找 LDAP 服务器：

    • _ldap._tcp.CONTOSO.COM
    • _kerberos._tcp.CONTOSO.COM

    注意

    这些查询在同一调用进程中的不同部分多次发生。 DNS 问题可能会导致这些调用速度缓慢、超时或完全失败。 - 如果查询找不到条目，或者无法联系找到的条目，则 SMB 卷创建将失败。 - 如果 DNS 查询成功，则会处理后续步骤。

  • 将发送 ICMP (ping)，检查从 DNS 返回的 IP 地址是否可访问。

  • 如果防火墙策略阻止了网络上的 ping，则 ICMP 请求将失败。 如果没有，则会使用 LDAP ping。

  • 执行另一个 LDAP ping 以使用查询 (&(&(DnsDomain=CONTOSO.COM)(Host=KDChostname.contoso.com))(NtVer=0x00000006)) 和属性筛选器 NetLogon 搜索可用的旧版 NetLogon 服务器。 较新的 Windows 域控制器版本（版本号大于 2008）没有 NtVer 值。

  • 使用 Active Directory 连接配置的用户名从 Azure NetApp 文件服务发送 AS-REQ 身份验证。

  • DC 会响应 KRB5KDC_ERR_PREAUTH_REQUIRED，要求该服务安全地发送用户的密码。

  • 发送第二个 AS-REQ，其中包含通过 KDC 进行身份验证访问所需的预身份验证数据，以继续创建计算机帐户。 如果成功，则会向服务发送票证授予票证 (TGT)。

  • 如果成功，服务会发送 TGS-REQ，使用 AS-REP 中收到的 TGT 从 KDC 请求 CIFS 服务票证 (cifs/kdc.contoso.com)。

  • 使用 CIFS 服务票证执行新的 LDAP 绑定。 查询自 Azure NetApp 文件发送。

    • RootDSE 基本搜索域的 ConfigurationNamingContext DN
    • 使用属性 NETBIOSname 的筛选器 (&(&(objectClass=crossRef)(nETBIOSName=*))(dnsRoot=CONTOSO.COM)) 在为 ConfigurationNamingContext 检索的 DN 中 CN=partitions 执行 OneLevel 搜索。
    • 对 Active Directory 连接配置中指定的 OU 执行使用筛选器 (|(objectClass=organizationalUnit)(objectClass=container)) 的基本搜索。 如果未指定，则使用默认值 OU=Computers。 这会验证容器是否存在。
    • 使用筛选器 (sAMAccountName=ANF-XXXX$) 对域的基准 DN 执行子树搜索，以检查帐户是否存在。
      • 如果该帐户存在，则会重复使用该帐户。
    • 如果该帐户不存在，则会创建该帐户，前提是用户有权使用 addRequest LDAP 命令在容器中创建和修改对象。 在帐户上设置以下 LDAP 属性：
    属性 价值
    中国区 ANF-XXXX
    sAMAccountName ANF-XXXX$
    objectClass
    • 顶部
    • 人员
    • OrganizationalPerson
    • 用户
    • 计算机
    servicePrincipalName
    • HOST/ANF-XXXX
    • HOST/anf-xxxx.contoso.com
    • CIFS/anf-xxxx.contoso.com
    userAccountControl 4096
    operatingSystem NetApp 版本
    dnsHostName ANF-XXXX.CONTOSO.COM
    • 如果 addRequest 失败，则卷创建失败。 addRequest 可能由于容器对象的权限不正确而失败。
    • 如果 addRequest 成功，将使用筛选器 (sAMAccountName=ANF-XXXX$) 执行 LDAP 搜索以检索 objectSid 属性。
    • 执行 SMB2“协商协议”会话以从 KDC 检索受支持的 Kerberos mechTypes。
    • 执行使用 CIFS SPN 和受支持的最高 mechType SMB2“会话设置”，以及到 IPC$ 的“树连接”。
    • 在 IPC$ 共享中创建 SMB2 lsarpc 文件。
    • 执行与 DCERPC 的绑定。 写入 lsarpc 文件，再读取。
    • 然后执行以下 LSA 请求：

  • 执行使用 TGT 的 TGS-REQ，以检索与 kadmin/changepw 帐户关联的 krbtgt SPN 的票证。

  • 从服务向 KDC 发出 KPASSWD 请求以更改计算机帐户密码。

  • 使用筛选器 (sAMAccountName=ANF-XXXX) 执行 LDAP 查询，获取属性 distinguishedName 和 isCriticalSystemObject。

  • 如果帐户的 isCriticalSystemObject 为 false（默认值），则检索到的 DN 用于制定对属性 modifyRequest 的 msDs-SupportedEncryptionTypes。 此值设置为 30，相当于 DES_CBC_MD5 (2) + RC4 (4) + AES 128 (8) + AES 256 (16)。

  • 执行到 IPC$ 的第二个“协商协议”/Kerberos 票证交换/“会话设置”/“树连接”。 SMB 服务器的计算机帐户 (ANF-XXXX$) 充当 Kerberos 主体。

  • 已完成 NetLogon、NetrServer ReqChallenge/Authenticate2 的通信。

  • 执行第三个到 IPC$的“协商协议”/Kerberos 票证交换/“会话设置”/“树连接”；SMB 服务器的计算机帐户 (ANF-XXXX$) 用作 Kerberos 主体。

  • lsarpc 和 NetLogon 连接作为帐户的最终检查执行。

SMB 共享连接工作流 (Kerberos)

使用 Kerberos 装载 Azure NetApp 文件卷时，将在多个会话设置请求期间使用 Kerberos 票证交换，以提供对共享的安全访问。 在大多数情况下，执行日常管理任务无需深入了解详细步骤。 此知识在尝试访问 Azure NetApp 文件中的 SMB 卷时，有助于故障排查。

SMB 共享连接工作流示意图。

关于在 Azure NetApp Files 中访问 SMB 共享的步骤，请展开列表以查看详细信息。
  • 客户端尝试使用 Azure NetApp 文件中显示的 UNC 路径访问 SMB 共享。 默认情况下，UNC 路径将包括 SMB 服务器名称（如 ANF-XXXX）
  • 查询 DNS 以将主机名映射到 IP 地址
  • 进行初始 SMB2 “协商协议” 对话
    • 从客户端发送请求，以查找服务器支持哪些 SMB 方言，并包含请求客户端支持的内容
    • 服务器使用它支持的内容做出响应，包括：
      • 安全模式（签名或不签名）
      • SMB 版本
      • 服务器 GUID
      • 支持的功能（DFS、租约、大 MTU、多通道、持久性句柄、目录租约、加密）
      • 最大事务大小
      • 最大读/写大小
      • 安全 Blob（Kerberos 或 NTLM）
  • 第二个 SMB2“协商协议”对话将作为“预授权”/登录进行
    • 来自客户端的请求包括：
      • 预授权哈希
      • 支持的安全模式（签名或不签名）
      • 支持的功能（DFS、租约、大 MTU、多通道、持久性句柄、目录租约、加密）
      • 客户端 GUID
      • 支持的 SMB 方言
    • 如果接受预授权哈希，则服务器将响应以下内容：
      • 安全模式（签名或不签名）
      • 支持的功能（DFS、租约、大 MTU、多通道、持久性句柄、目录租约、加密）
      • 最大事务大小
      • 最大读/写大小
      • 安全 Blob（Kerberos 或 NTLM）
      • SMB 预授权完整性和加密功能
  • 如果协议协商成功，则会发出“会话设置”请求。
    • 设置将使用协议协商中的预授权哈希。
    • 设置将通知 SMB 服务器请求客户端支持的内容，包括：
      • StructureSize
      • 会话绑定标志
      • 安全模式（签名已启用/必需）
      • 功能
      • 支持的 Kerberos 加密类型
  • 发送“会话设置”响应。
    • 授予 SMB 额度。
    • 建立会话 ID。
    • 设置会话标志（来宾、null、加密）。
    • Kerberos 加密类型已定义。
  • 客户端发送树连接请求以连接到 SMB 共享。
    • 从服务器发送共享标志/功能和共享权限。
  • 发送 ioctl 命令 FSCTL_QUERY_NETWORK_INTERFACE_INFO 以获取 SMB 服务器的 IP 地址。
  • Azure NetApp 文件中的 SMB 服务器会报告回网络信息，包括：* IP 地址 * 接口功能（RSS 打开或关闭） * RSS 队列计数 * 链接速度
  • 客户端发送树连接请求，以连接到 IPC$ 管理共享。
    • IPC$ 共享是共享命名管道的资源，这些管道对于程序之间的通信至关重要。 在远程管理计算机和查看计算机的共享资源时使用 IPC$ 共享。 无法更改 IPC$ 共享的共享设置、共享属性或 ACL。 也不能重命名或删除 IPC$ 共享。
    • 在共享中创建名为 srvsvc 的文件，作为服务句柄。
  • 对 srvsvc 文件进行 DCERPC 绑定，以建立安全连接。
    • 将之前检索到的信息写入文件。
  • Windows 客户端向 KDC 发出 Kerberos TGS-REQ 请求，以获取 SMB 服务的服务票证 (ST)。
  • SMB 客户端向服务器运行NetShareGetInfo 命令，并发送响应。
  • 从 KDC 检索 SMB 服务票证。
  • Azure NetApp 文件尝试将请求访问共享的 Windows 用户映射到有效的 UNIX 用户。
    • 使用 SMB 服务器最初创建时的 SMB 服务器密钥表中存储的 SMB 服务器 Kerberos 凭据发出 Kerberos TGS 请求，用于 LDAP 服务器绑定。
    • 在 LDAP 中搜索映射到请求共享访问权限的 SMB 用户的 UNIX 用户。 如果 LDAP 中不存在 UNIX 用户，则 Azure NetApp 文件将使用默认 UNIX 用户 pcuser 进行名称映射（以双协议卷编写的文件/文件夹）使用映射的 UNIX 用户作为 UNIX 所有者。
  • 执行另一个协商协议/会话请求/树连接，这次使用 SMB 服务器的 Kerberos SPN 连接到 Active Directory DC 的 IPC$ 共享。
    • 通过 srvsvc 将命名管道建立到共享。
    • 将 NETLOGON 会话建立到共享，并对 Windows 用户进行身份验证。
  • 如果权限允许用户使用，共享会列出卷中包含的文件和文件夹。

注意

Azure NetApp 文件将条目添加到客户端的 Kerberos 上下文缓存。 这些条目在 Kerberos 票证生存期（由 KDC 设置并由 Kerberos 策略控制）驻留在缓存中。

创建 SMB 服务器别名

当 Azure NetApp 文件使用 [AD 连接配置中指定的 SMB 服务器前缀]-[唯一数字标识符]的命名约定创建 SMB 服务器时。 （有关唯一数字标识符的详细信息，请参阅 SMB Kerberos 计算机帐户）。 这种格式意味着 SMB 服务器名称不是以用户友好的方式构造的。 例如，“SMB-7806”比类似“AZURE-FILESHARE”的名称更难记住。

由于此行为，管理员可能想要为 Azure NetApp 文件卷创建用户友好的别名。 执行此操作需要将 DNS 规范名称 (CNAME) 指向服务器中现有的 DNS A/AAAA 记录。

在 UNC 路径请求中创建和使用 CNAME（例如 \\AZURE-FILESHARE 而不是 \\SMB-7806）时，DNS 会将 CNAME 请求 (AZURE-FILESHARE.contoso.com) 重定向到正确的 A/AAAA 记录 (SMB-7806.contoso.com)，该记录用于 Kerberos SPN 检索 (cifs/SMB-7806)。 这让 Kerberos 可以在使用别名时访问 SMB 共享。

如果创建了 DNS A/AAAA 记录（例如 AZURE-FILESHARE.contoso.com），并尝试将其用作别名，则 Kerberos 请求会失败。 失败的原因是用于向共享进行身份验证的构造 SPN (cifs/AZURE-FILESHARE) 与 SMB 服务器的 Kerberos SPN (cifs/SMB-7806) 不匹配。 如果创建另一个 SPN 并将其追加到 SMB 服务器计算机帐户（例如 cifs/AZURE-FILESHARE），则可以缓解失败。

Azure NetApp 文件中支持的 SMB 服务器功能

发出 SMB“协商协议”请求时，会查询 Azure NetApp 文件 SMB 服务器是否支持特定功能。 下表显示了在执行会话设置/树连接时查询的功能以及从 Azure NetApp 文件 SMB 卷返回的响应。

SMB 功能 Azure NetApp 文件是否支持？
DFS 目标 是
租用 是
大型 MTU 是
SMB 多通道 是
SMB 永久性句柄 是
目录租用 否
SMB 加密 是（如果已启用）

Azure NetApp 文件中支持的 SMB 共享功能和属性

在 SMB 共享访问期间，将执行“树连接”请求，客户端将向 Azure NetApp 文件服务器查询受支持的 SMB 共享功能和属性。 下表显示了查询的共享功能以及从 Azure NetApp 文件 SMB 卷返回的响应，如数据包捕获中所示。

SMB 共享功能 Azure NetApp 文件是否支持？
持续可用 (CA) 是，适用于特定工作负荷*（如果已启用）
横向扩展 否
群集 否
非对称 否
重定向到所有者 否

* 有关受支持的工作负荷，请参阅在现有 SMB 卷上启用持续可用性。

下表显示了查询的共享属性以及从 Azure NetApp 文件 SMB 卷返回的响应。

SMB 共享功能 Azure NetApp 文件是否支持？
DFS 目标 是
DFS 根 否
限制独占打开 否
强制共享删除 否
允许命名空间缓存 否
基于访问权限的枚举 是（如果已启用）
强制级别 II 操作锁定 否
启用哈希 V1 否
启用哈希 v2 否
需要加密 是（如果已启用）
标识远程处理 否
压缩输入/输出 否
隔离运输 否

NFS Kerberos 在 Azure NetApp 文件中的工作原理

NFS Kerberos 独立于 SMB 服务工作，原因是为每个协议创建的计算机帐户无法共享密钥表，因为一个密钥表中密钥版本号 (kvno) 的更改可能会影响另一个服务。 因此，Kerberos 的 SMB 服务工作流和 Kerberos 的 NFS 在某些方面的功能有所不同。

Kerberos 领域的初始配置

在 Active Directory 连接页下的 Azure NetApp 文件门户中填写 Kerberos 领域信息后，将配置 NFS Kerberos 领域。

Kerberos 领域配置的屏幕截图。

在初始创建计算机帐户时，AD 服务器名称和 KDC IP 用于连接到 AD KDC 服务。

注意

在删除 Active Directory 对象之前，无法清除 Active Directory 对象中的 KDC IP 和 AD 服务器名称字段。 只能将其更改为有效的非空值。

Azure NetApp 文件服务会利用现有域信息填写领域配置的其余部分。 例如：

Kerberos Realm: CONTOSO.COM
KDC Vendor: Microsoft
KDC IP Address: x.x.x.x 
KDC Port: 88
Clock Skew: 5
Active Directory Server Name: dc1.contoso.com
Active Directory Server IP Address: x.x.x.x
Comment: -
Admin Server IP Address: x.x.x.x
Admin Server Port: 749
Password Server IP Address: x.x.x.x
Password Server Port: 464
Permitted Encryption Types: aes-256
-    Configured by Azure NetApp Files administrator in the portal
-    Automatically configured by the service using Active Directory connection information/system defaults

配置 NFS Kerberos 领域后，会在服务中添加一个本地主机条目，该条目与配置中指定的 KDC 相关联。 在修改领域时，服务中的本地主机条目也会被修改。

Kerberos 领域配置示意图。

如果领域配置中指定的 KDC 发生 KDC 中断，并且无法通过 DNS 查询冗余 KDC，则此本地主机条目将充当最后手段。

注意

如果需要停用 Kerberos 领域中的 KDC 以进行维护（例如升级或退役服务器），建议将领域配置为使用未进行维护的 KDC 来避免中断。

初始创建计算机帐户/SPN

在 Azure NetApp 文件卷上启用 Kerberos 时，将在 Active Directory 连接的指定 OU（组织单位）的域中创建名为 NFS-{SMB-服务器-名称} 的计算机帐户/主体。 计算机帐户名在 15 个字符后被截断。

注意

将主机名大于 15 个字符的 Linux 客户端添加到 Active Directory 域时，会截断其 Kerberos 计算机帐户 SPN。 例如，名称为 MORE-THAN-FIFTEEN 的 Linux 客户端具有计算机帐户名称 MORE-THAN-FIFT$，该名称将成为 MORE-THAN-FIFT$@CONTOSO.COM 的 SPN。 当 DNS 查找客户端主机名时，它会找到更长的那个名称，并尝试在 SPN 请求中使用该名称 (MORE-THAN-FIFTEEN@CONTOSO.COM)。 由于该 SPN 不存在，客户端会尝试在请求中使用密钥表的下一个 SPN（通常是主机/主机名）。 仅计算机帐户名 SPN 本机适用于 Azure NetApp 文件 NFS Kerberos。 因此，请确保用于 Azure NetApp 文件 NFS Kerberos 的 Linux 客户端主机名不超过 15 个字符。 或者，如果要使用主机/主机名 SPN，请使用用户名“host”在 LDAP 中配置 UNIX 用户。此配置为 SPN 提供 krb-unix 名称映射。

在 Azure NetApp 文件中，使用 NFS 服务 SPN (nfs/nfs-server-name.contoso.com@CONTOSO.COM) 将 Kerberos 密钥块（或密钥表条目）添加到服务。 创建多个条目：每个受支持的加密类型都有一个条目。 在 Azure NetApp 文件中，NFS Kerberos 仅支持 AES-256 加密类型。

在大多数情况下，不必深入了解这些步骤也能执行日常管理任务，但在尝试在 Azure NetApp 文件中创建 NFS Kerberos 卷时，这些知识有助于排查故障。

创建 NFS Kerberos SPN 的工作流

下图显示了在启用了 Kerberos 的情况下创建 Azure NetApp 文件 NFS 或双协议卷时如何创建 NFS SPN。 在大多数情况下，不必深入了解详细步骤也可以执行日常管理任务，但在尝试在 Azure NetApp 文件中创建 SMB 卷时，这些知识有助于排查故障。

创建 NFS Kerberos SPN 的工作流关系图。

有关使用 Azure NetApp 文件创建 NFS Kerberos SPN 的详细步骤，请展开列表。
  • 使用 Active Directory 连接中提供的用户名传递到在领域配置中指定的 KDC 的管理员凭据 - 用户必须有权在指定 OU 中查看/创建对象。
  • Azure NetApp 文件以以下格式向 Azure NetApp 文件 Active Directory 连接配置中指定的 DNS 服务器查询 Kerberos 服务记录 (SRV)：
    • _kerberos.CONTOSO.COM 的 URI 查询
    • _kerberos master._udp. 的 SRV 查询。 CONTOSO.COM
    • _kerberos master._tcp. 的 SRV 查询。 CONTOSO.COM

注意

这些查询在同一调用进程中的不同部分多次发生。 DNS 问题可能会导致这些调用速度缓慢或完全失败。 默认情况下，Active Directory 部署中不存在这些记录，必须手动创建。

  • 如果查询找不到条目，或者找不到的条目无法联系或用作主 KDC，则作为最后手段，将使用 NFS Kerberos 领域配置中找到的领域名称的地址记录查询，通过端口 88 连接到 KDC。
  • 在配置 NFS Kerberos 期间，指定的 KDC 的静态主机条目将添加到本地主机文件中，作为 DNS 查找失败的备份。
  • 如果某个域有缓存的 DNS 条目，则会使用该条目。 如果没有，则使用本地文件条目。 只要为 DNS 记录配置了生存时间 (TTL)，就会存在缓存的 DNS 条目。 本地文件条目配置的生存时间为 86,400 秒（24 小时）。 Azure NetApp 文件中主机查找的 ns-switch 配置优先使用文件，然后再使用 DNS。 找到本地条目后，就不会再执行查询。
  • 创建 Active Directory 连接时创建的 SMB 计算机帐户将作为凭据，通过 SASL/GSS 在端口 389 执行 Active Directory LDAP 绑定，以搜索所需的 SPN 或计算机帐户名称的任何现有条目。 如果 SPN 或计算机帐户名已存在，则会发送错误。 如果 LDAP 查询中不存在 SPN，则会在指定的 OU 中创建计算机帐户，并由 Azure NetApp 文件设置以下属性的条目：
    • cn (NFS-MACHINE)
    • sAMAccountName (NFS-MACHINE$)
    • objectClass (top, person, organizationalPerson, user, computer)
    • servicePrincipalName (host/NFS-MACHINE, host/NFS-MACHINE.CONTOSO.COM, nfs/NFS-MACHINE, nfs/NFS-MACHINE.CONTOSO.COM)
    • userAccountControl (4096)
    • msDs-SupportedEncryptionTypes (AES-256_CTS_HMAC_SHA1_96)
    • dnsHostName [NFS-MACHINE.CONTOSO.COM]
  • 通过端口 464 为 NFS-MACHINE 帐户设置 NFS kerberos 计算机帐户密码。
  • NFS SPN 的 Kerberos 密钥块（密钥表）保存在 Azure NetApp 文件服务中。
  • 在 Azure NetApp Files 服务上创建一个静态名称映射规则，以确保在使用 Kerberos 时，每个 NFS Kerberos 客户端的 root 用户都被映射为 root。
  • krb5.conf 文件将添加到服务的内部系统中，其中包含 NFS 领域信息。

NFS Kerberos 装载

使用 Kerberos 安全风格通过 NFS 装载 Azure NetApp 文件卷时，将执行以下工作流。 如需了解更详细的 Kerberos 介绍，请参阅 Kerberos 网络身份验证服务 (V5) 概要。

NFS Kerberos 装载工作流的关系图。

有关使用 Azure NetApp 文件装载 NFS Kerberos 卷的详细步骤，请展开列表。
  • 客户端尝试装载到 Azure NetApp 文件中的 NFS 导出路径，并指定 -okrb5（或 krb5i/krb5p） 安全风格。
  • 使用 DNS 通过 A/AAAA 记录或 PTR（具体取决于装载命令的发出方式），向 Azure NetApp 文件请求 NFS 服务主体。
  • 客户端使用客户端的密钥表中找到的 CLIENT 主体名称，通过 AS-REQ 调用从 KDC 检索 TGT。
  • 检查导出路径，确保它存在于文件系统中。
  • 检查导出策略规则，确保允许 Kerberos 访问导出路径。<
  • 客户端通过 AP-REQ 调用向 KDC 请求 NFS 服务票证。 Azure NetApp 文件使用客户端从 KDC 获取的 TGT，检查密钥表中是否有有效加密类型的有效条目。
  • 如果 TGT 有效，则会颁发服务票证。
  • 客户端 SPN（例如 CLIENT$@CONTOSO.COM）通过 Azure NetApp 文件中的名称映射规则映射到根用户。
  • 在名称服务数据库（文件和 LDAP）中查询根用户的存在情况和组成员身份。
  • 执行使用 SMB 服务器计算机帐户的 LDAP 绑定，以允许针对根用户进行 LDAP 搜索。
  • 由于根始终存在于 Azure NetApp 文件中，此操作通常不应引发问题，但根的 LDAP 查询可能会失败。 可以忽略此类失败。
  • NFS 服务票证将返回到客户端，装载成功。 根用户可以通过客户端的计算机帐户主体（可通过客户端的 klist -e 命令查看）来访问 Kerberos 装载。
  • Azure NetApp 文件将条目添加到客户端的 Kerberos 上下文缓存。 这些条目将在 Kerberos 票证生存期（由 KDC 设置并由 Kerberos 策略控制）驻留在缓存中。
  • NFSv4.1 定期（每 20 秒）发送“keepalives”的 Kerberos 票证刷新更新。

用户主体的 NFS Kerberos 装载访问权限

当用户（不是使用计算机帐户 SPN 的根用户）访问 Azure NetApp 文件 NFS Kerberos 装载时，将执行以下工作流。

NFS Kerberos 装载访问与用户主体的关系图。

有关非根用户使用 Azure NetApp 文件访问 NFS Kerberos 卷的详细步骤，请展开列表。
  • 用户使用用户名/密码交换或通过密钥表文件登录到 KDC，通过 AS-REQ 调用获取 TGT，用于从 Azure NetApp 文件卷收集服务票证。
  • 检查导出策略规则，以确保客户端计算机被允许通过 Kerberos 访问到导出的路径。
  • Azure NetApp 文件检查是否存在缓存的 NFS 服务票证。 如果不存在，则通过 AP-REQ 调用请求 NFS 服务票证，并且使用客户端从 KDC 获取的 TGT 检查密钥表中是否存在加密类型有效的有效条目
  • 如果 TGT 有效，则颁发服务票证
  • 隐式映射用户主体名称 (UPN)。 例如，如果 UPN 为 user1@CONTOSO.COM，则服务会查询名为 user1 的 UNIX 用户。 由于该 UNIX 用户不存在于 Azure NetApp 文件的本地文件数据库中，因此使用 LDAP。
  • 尝试使用 SMB 服务器机器帐户进行 LDAP 绑定，以便执行针对映射用户的 LDAP 搜索。 执行 DNS SRV 查询以查找 Kerberos DNS 记录（_kerberos 和 _kerberos-master）。 如果没有可用的有效记录，则配置会回退到领域配置上。 这些 KDC DNS SRV 查询不在站点范围内。
  • 为了找到有效的 LDAP 服务器，会查询 LDAP SRV 记录。 这些查询在站点范围内。
  • 如果 LDAP 中不存在该用户或无法查询 LDAP（服务器关闭、DNS 查找失败、绑定失败、LDAP 搜索超时、用户不存在），则映射失败并拒绝访问。
  • 如果存在用户，则会收集组成员身份。
  • 映射成功，将 NFS 服务票证颁发给客户端（如命令中 klist -e 所示）。 访问权限基于导出路径上的文件权限。

LDAP 对 Azure NetApp 文件中 Kerberos 的作用

Azure NetApp 文件的 NFS Kerberos 依赖于 LDAP。 Azure NetApp 文件中的 NFS Kerberos 需要 Kerberos 实现针对传入用户 SPN 的 UNIX 名称映射。 由于 Azure NetApp 文件不支持创建本地 UNIX 用户，因此需要 LDAP 在请求名称映射时查找 UNIX 用户。

  • 创建 Active Directory 连接时，Active Directory 域名用于指定查找 LDAP 服务器的过程。
  • 需要 LDAP 服务器时，使用 _ldap.domain.com 执行 LDAP 服务器的 SRV 查找。
  • 发现服务器列表后，将最佳可用服务器（基于 ping 响应时间）用作通过端口 389 进行连接的 LDAP 服务器。
  • 尝试使用 SMB 计算机帐户通过 GSS/Kerberos 进行 LDAP 绑定。
  • 如果没有缓存的连接或 Kerberos 凭据，则会发出 Kerberos 票证的新请求。 Azure NetApp 文件中名称服务器的缓存连接生存期为 60 秒。 如果空闲超过 60 秒，则会清除连接缓存。
  • 使用 DNS 通过 SRV 记录查找适当的 Kerberos KDC 服务器。
  • 如果通过 DNS 查询找不到 KDC，则使用在 krb5.conf 文件中为 SMB 服务指定的 KDC。
    • 如果 KDC 无法访问或无法处理 Kerberos 请求，则 LDAP 绑定会失败。 名称查找也会失败。 由于未完成有效的身份验证，访问装载被拒绝。
    • 如果绑定成功，则对用户及其凭据执行 LDAP 查询。 如果搜索时间超过 10 秒，则搜索失败。
  • 如果查找找到了用户，则映射成功，并且通过 Kerberos 授予访问权限（前提是票证有效/尚未过期）。

使用 Kerberos 进行访问的 IP 地址

默认情况下，Kerberos 身份验证利用主机名到 IP 地址解析来构建用于检索 Kerberos 票证的服务主体名 (SPN)。 例如，使用通用命名约定路径 (UNC)（例如 \SMBVOLUME.CONTOSO.COM）访问 SMB 共享时，会针对完全限定的域名 SMBVOLUME.CONTOSO.COM 发出 DNS 请求，并检索 Azure NetApp 文件卷的 IP 地址。 如果不存在 DNS 条目（或当前条目不同于所请求的内容，例如别名 /CNAME），则无法检索适当的 SPN，Kerberos 请求会失败。 因此，如果禁用回退身份验证方法（如新技术 LAN 管理器），则不允许访问卷。

Azure NetApp 文件中的 DNS 条目是使用动态 DNS 自动创建的，并使用 SMB 服务器的名称进行构建。 对于已定义名称的任何变体/别名，应创建手动 DNS CNAME 记录并指向动态 DNS 条目。 有关详细信息，请参阅了解 Azure NetApp 文件中的 DNS。

NFSv4.1 Kerberos 以类似的方式运行 SPN 检索，其中 DNS 查找是身份验证过程不可或缺的一部分，也可用于 Kerberos 领域发现。

如果在对 Azure NetApp 文件卷的访问请求中使用 IP 地址（而不是主机名），则 Kerberos 请求将以不同的方式运行，具体取决于所使用的协议。

使用 IP 地址和 DNS 名称的 SMB Kerberos 行为

使用 SMB 时，默认使用 IP 地址（例如 \\x.x.x.x）的 UNC 路径请求会尝试使用 NTLM 进行身份验证。 在出于安全原因不允许使用 NTLM 的环境中，使用 IP 地址的 SMB 请求在默认情况下无法使用 Kerberos 或 NTLM 进行身份验证。 因此，Azure NetApp 文件卷访问被拒。 在更高版本的 Windows 版本中（从 Windows 10 版本 1507 和 Windows Server 2016 开始），Kerberos 客户端可配置为支持 SPN 中的 IPv4 和 IPv6 主机名进行 SMB 通信，以解决此问题。

使用 IP 地址和 DNS 名称的 NFSv4.1 Kerberos 行为

使用 NFSv4.1 时，使用其中一个 sec=[krb5/krb5i/krb5p] 选项对 IP 地址发出的装载请求通过 PTR 使用反向 DNS 查找，将 IP 地址解析为主机名。 然后，该主机名用于构建 Kerberos 票证检索的 SPN。 如果将 NFSv4.1 与 Kerberos 配合使用，则 Azure NetApp 文件卷应具有 A/AAAA 和 PTR，以涵盖对装载的主机名和 IP 地址访问权限。 Azure NetApp 文件创建动态 DNS A/AAAA 记录。 如果该子网存在反向 DNS 区域，则也会自动创建 PTR 记录。 对于偏离标准 Azure NetApp 文件主机名约定的情况，请使用 CNAME 记录作为 DNS 别名。

有关详细信息，请参阅了解 Azure NetApp 文件中的 DNS