AD FS のトラブルシューティング - Microsoft Entra ID

クラウドの成長に伴い、多くの会社がさまざまなアプリやサービスでの Microsoft Entra ID の使用に移行してきました。 Microsoft Entra ID とのフェデレーションは、多くの組織での標準的な慣行になりました。 このドキュメントでは、このフェデレーションで発生する問題のトラブルシューティングのいくつかの側面について説明します。 一般的なトラブルシューティング ドキュメントのいくつかのトピックは、引き続き Azure とのフェデレーションに関連するものであるため、このドキュメントでは Microsoft Entra ID と AD FS のインタラクションの詳細のみに焦点を当てていきます。

AD FS へのリダイレクト

リダイレクトは、Office 365 などのアプリケーションにサインインし、組織の AD FS サーバーに "リダイレクト" してサインインすると発生します。

最初の確認項目

リダイレクトが発生していない場合は、いくつかの項目を確認する必要があります

1. Azure portal にサインインし、Microsoft Entra Connect で確認することで、Microsoft Entra テナントがフェデレーションに対して有効になっていることを確認します。

   

2. Azure portal の [フェデレーション] の横にあるドメインをクリックして、カスタム ドメインが検証されていることを確認します。

   

3. 最後に、DNS を確認し、AD FS サーバーまたは WAP サーバーがインターネットから解決されていることを確かめます。 これが解決されていることと、それに移動できることを検証します。

4. PowerShell コマンドレット Get-MgDomain を使用して、この情報を取得することもできます。

   

不明な認証方法エラーが発生している

Azure からリダイレクトされた場合、AD FS または STS レベルで AuthnContext がサポートされていないことを示す "不明な認証方法" エラーが発生することがあります。

これは、認証方法を実施するパラメーターを使用して、Microsoft Entra ID が AD FS または STS にリダイレクトする際によく起きます。

認証方法を強制するには、次のいずれかの方法を使用します。

• WS-Federation の場合は、WAUTH クエリ文字列を使用して、優先認証方法を強制します。

• SAML 2.0 の場合は、以下を使用します。

  <saml:AuthnContext>
  <saml:AuthnContextClassRef>
  urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
  </saml:AuthnContextClassRef>
  </saml:AuthnContext>
  

  強制認証方法が正しくない値で送信された場合、あるいは AD FS または STS でその認証方法がサポートされていない場合は、認証される前にエラー メッセージが表示されます。

サポートされている SAML 認証コンテキスト クラス

認証方法が 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 スナップインの [サービス] と [認証方法] をクリックします。

[プライマリ認証] セクションで、[編集] をクリックします。

[認証方法の編集] ウィンドウの [プライマリ] タブで、認証ポリシーの一部として設定を構成できます。

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> を実行します。

• SAML 2.0:
  • IDPEmail: この要求の値は、Microsoft Entra ID のユーザーのユーザー プリンシパル名と一致している必要があります。
  • NAMEID: この要求の値は、Microsoft Entra ID のユーザーの sourceAnchor または ImmutableID と一致している必要があります。

詳細については、「シングル サインオンを実装するための SAML 2.0 ID プロバイダーの使用」を参照してください。

ADFSとMicrosoft Entra IDの間のトークン署名証明書の不一致

AD FS ではトークン署名証明書を使用して、ユーザーまたはアプリケーションに送信されるトークンに署名します。 AD FS と Microsoft Entra ID との間の信頼は、このトークン署名証明書に基づくフェデレーション信頼です。

しかし、証明書の自動ロールオーバーまたは何らかの介入によって AD FS 側のトークン署名証明書が変更された場合は、フェデレーション ドメインの Microsoft Entra ID 側で新しい証明書の詳細を更新する必要があります。 ADFSのプライマリトークン署名証明書がMicrosoft Entra IDと異なる場合、ADFSによって発行されたトークンはMicrosoft Entra IDによって信頼されません。 そのため、フェデレーション ユーザーはログオンを許可されません。

これを解決するには、「Office 365 および Microsoft Entra ID のフェデレーション証明書の更新」で説明されている手順を使用できます。

その他の一般的な確認項目

AD FS と Microsoft Entra とのインタラクションに関する問題があるかどうかを確認する項目のクイック リストを以下に示します。

• Windows Credential Manager の古いまたはキャッシュされた資格情報
• Office 365 の証明書利用者信頼で構成されているセキュア ハッシュ アルゴリズムが SHA1 に設定されている

次の手順

• AD FS のトラブルシューティング