AD FS 疑難排解 - Microsoft Entra ID

發行項
02/29/2024

隨著雲端的發展，許多公司已經開始將 Microsoft Entra ID 用於其各種應用程式和服務。與 Microsoft Entra ID 同盟已成為許多組織的標準做法。本文件將涵蓋針對此同盟所引發問題進行疑難排解的一些層面。一般疑難排解文件中的幾個主題仍與 Azure 同盟有關，因此本文將著重於 Microsoft Entra ID 和 AD FS 互動的具體資訊。

重新導向至 AD FS

當您登入 Office 365 之類的應用程式時，重新導向便會發生，而您會被「重新導向」到您的組織 AD FS 伺服器以登入。

Redirection screen to AD FS

首先要檢查的事項

如果重新導向未發生，有一些您需要檢查的事項

登入 Azure 入口網站並檢查 Microsoft Entra Connect 下方，確保已針對同盟啟用 Microsoft Entra 租用戶。
按一下 Azure 入口網站中 [同盟] 旁的網域，確定已驗證您的自訂網域。
最後，您需要檢查 DNS，並確定 AD FS 伺服器或 WAP 伺服器正在從網際網路進行解析。確認此可解析，以及您能夠瀏覽至其中。
您也可以使用 PowerShell Cmdlet Get-MgDomain 來取得此資訊。

您收到未知的驗證方法錯誤

您可能會遇到「未知的驗證方法」錯誤，指出當您從 Azure 重新導向時，AD FS 或 STS 層級不支援 AuthnCoNtext。

在使用強制實施驗證方法的參數將 Microsoft Entra ID 重新導向至 AD FS 或 STS 時，最常見到這種情況。

若要強制執行驗證方法，請使用下列其中一種方法：

對於 WS-同盟，請使用 WAUTH 查詢字串來強制執行偏好的驗證方法。
對於 SAML2.0，請使用下列方法：
```
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
```
當強制執行的驗證方法以不正確的值傳送時，或如果 AD FS 或 STS 上不支援該驗證方法，您會在進行驗證之前收到錯誤訊息。

所需的驗證方法	wauth URI
使用者名稱和密碼驗證	urn:oasis:names:tc:SAML:1.0:am:password
SSL 用戶端驗證	urn:ietf:rfc:2246
Windows 整合式驗證	urn:federation:authentication:windows

支援的 SAML 驗證內容類別

驗證方法	驗證內容類別 URI
使用者名稱和密碼	urn:oasis:names:tc:SAML:2.0:ac:classes:Password
以密碼保護的傳輸	urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
傳輸層安全性 (TLS) 用戶端	urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
X.509 憑證	urn:oasis:names:tc:SAML:2.0:ac:classes:X509
整合式 Windows 驗證	urn:federation:authentication:windows
Kerberos	urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos

若要確定 AD FS 層級支援驗證方法，請檢查下列項目。

AD FS 2.0

在 /adfs/ls/web.config下，確定驗證類型的項目存在。

<microsoft.identityServer.web>
<localAuthenticationTypes>
<add name="Forms" page="FormsSignIn.aspx" />
<add name="Integrated" page="auth/integrated/" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" />
</localAuthenticationTypes>

AD FS 2012 R2

在 [AD FS 管理] 下，按一下 AD FS 嵌入式管理單元中的 [驗證原則]。

在 [主要驗證] 區段中，按一下 [全域設定] 旁的 [編輯]。您也可以以滑鼠右鍵按一下 [驗證原則]，然後選取 [編輯全域主要驗證]。或者，在 [動作] 窗格中，選取 [編輯全域主要驗證]。

在 [編輯全域驗證原則] 視窗的 [主要] 索引標籤上，您可以將設定設為全域驗證原則的一部分。例如，針對主要驗證，您可以在 [外部網路] 和 [內部網路] 底下選取可用的驗證方法。

**確定已選取必要的驗證方法核取方塊。

AD FS 2016

在 [AD FS 管理] 下，按一下 AD FS 嵌入式管理單元中的 [服務] 和 [驗證原則]。

在 [主要驗證] 區段中，按一下 [編輯]。

在 [編輯驗證方法] 視窗的 [主要] 索引標籤上，您可以將設定設為驗證原則的一部分。

Edit Authentication Methods window

AD FS 所發出的權杖

Microsoft Entra ID 在權杖發出後擲回錯誤

AD FS 發出權杖後，Microsoft Entra ID 可能會擲回錯誤。在此情況下，請檢查下列問題：

AD FS 在權杖中發出的宣告應與 Microsoft Entra ID 中使用者的個別屬性相符。
Microsoft Entra ID 的權杖應包含以下必要的宣告：
- WSFED：
  - UPN：此宣告的值應與 Microsoft Entra ID 中使用者的 UPN 相符。
  - ImmutableID：此宣告的值應與 Microsoft Entra ID 中使用者的 sourceAnchor 或 ImmutableID 相符。

若要取得 Microsoft Entra ID 中的使用者屬性值，請執行以下命令列：Get-AzureADUser –UserPrincipalName <UPN>

Screenshot of the PowerShell window showing the results of the Get-AzureADUser command.

SAML 2.0：
- IDPEmail：此宣告的值應與 Microsoft Entra ID 中使用者的使用者主體名稱相符。
- NAMEID：此宣告的值應與 Microsoft Entra ID 中使用者的 sourceAnchor 或 ImmutableID 相符。

如需詳細資訊，請參閱使用 SAML 2.0 身分識別提供者來實作單一登入。

AD FS 和 Microsoft Entra ID 之間的權杖簽署憑證不符

AD FS 會使用權杖簽署憑證，來簽署傳送給使用者或應用程式的權杖。 AD FS 和 Microsoft Entra ID 之間的信任是基於此權杖簽署憑證的同盟信任。

但是，如果因自動憑證變換或某些干預而變更了 AD FS 端的權杖簽署憑證，則必須在同盟網域的 Microsoft Entra ID 端更新新憑證的詳細資訊。當 AD FS 上的主要權杖簽署憑證與 Microsoft Entra ID 不同時，AD FS 發出的權杖不會受 Microsoft Entra ID 的信任。因此，不允許同盟使用者登入。

若要解決此問題，您可以使用更新 Office 365 和 Microsoft Entra ID 的同盟憑證中概述的步驟。

其他要檢查的常見事項

以下是檢查 AD FS 和 Microsoft Entra 互動是否遇到問題的快速清單。

Windows 認證管理員中的過時或已快取認證
信賴憑證者信任上針對 Office 365 設定的安全雜湊演算法設定為 SHA1

後續步驟

AD FS 疑難排解

Share via