共用方式為


針對 Azure SQL 受控執行個體上 Microsoft Entra 主體的 Windows 驗證進行疑難排解

本文包含在 Microsoft Entra ID 中實作 Windows 驗證主體時所使用的疑難排解步驟 (之前稱為 Azure Active Directory)。

注意

Microsoft Entra 標識符 先前稱為 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.windows.net:1433kerberos.microsoftonline.com 領域傳回票證。

klist get MSSQLSvc/<miname>.<dnszone>.database.windows.net: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

下一步

深入了解在 Azure SQL 受控執行個體上為 Microsoft Entra 主體實作 Windows 驗證: