Compartir a través de

排查 Azure SQL 托管实例上 Microsoft Entra 主体的 Windows 身份验证问题

  • Artículo

本文包含了在 Microsoft Entra ID（以前称为 Azure Active Directory）中实施主体 的 Windows 身份验证时使用的故障排除步骤。

注意

Microsoft Entra ID 以前称为 Azure Active Directory (Azure AD)。

验证是否正在缓存票证

使用 klist 命令显示当前缓存的 Kerberos 票证的列表。

klist get krbtgt 命令应返回本地 Active Directory 领域中的票证。

klist get krbtgt/kerberos.microsoftonline.com

klist get MSSQLSvc 命令应返回服务主体名称 (SPN) 为 MSSQLSvc/<miname>.<dnszone>.database.chinacloudapi.cn:1433 的 kerberos.microsoftonline.com 领域中的票证。

klist get MSSQLSvc/<miname>.<dnszone>.database.chinacloudapi.cn:1433

下面是一些已知的错误代码：

  • 0x6fb: SQL SPN 未找到 - 请检查是否输入了有效的 SPN。 如果已实现了基于传入信任的身份验证流，请重新访问创建和配置 Microsoft Entra Kerberos 受信任的域对象步骤，以验证是否已执行所有配置步骤。

  • 0x51f - 此错误可能与 Fiddler 工具冲突相关。 若要减少此错误，请执行以下步骤：

    1. netsh winhttp reset autoproxy运行
    2. netsh winhttp reset proxy运行
    3. 在 Windows 注册表中，查找 Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\iphlpsvc\Parameters\ProxyMgr 并删除端口配置为 :8888 的任何子项
    4. 重启计算机，然后使用 Windows 身份验证重试

  • 0x52f - 指示引用的用户名和身份验证信息有效，但某些用户帐户限制导致身份验证失败。 如果配置了 Microsoft Entra 条件访问策略，可能会发生这种情况。 若要缓解此问题，必须在条件访问规则中排除 Azure SQL 托管实例服务主体（名为 <instance name> principal）应用程序。

调查消息流故障

使用 Wireshark 或所选的网络流量分析器来监视客户端与本地 Kerberos 密钥分发中心 (KDC) 之间的流量。

使用 Wireshark 时，应为以下内容：

  • AS-REQ：客户端 => 本地 KDC => 返回本地 TGT。
  • TGS-REQ：客户端 => 本地 KDC => 返回对 kerberos.microsoftonline.com 的引用。

连接池

启用连接池功能后，驱动程序将通过以下方式管理 SQL 连接：使这些连接在池中保持打开状态，以便重复使用，而不是将其关闭。 这可能导致在安全缓存失效后仍重复使用某个连接，从而导致重新验证 Kerberos 工单。 如果连接已在池中超过 5 分钟，则工单被视为已过期，从而导致连接失败。 若要防止这种情况，请在连接字符串中将连接生存期设置为低于 5 分钟。 此更改可确保不会从池中重复使用超过指定生存期的连接。

相关内容

详细了解如何为 Azure SQL 托管实例上的 Microsoft Entra 主体实现 Windows 身份验证：