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

[アーティクル]
02/13/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 portal にサインインし、Microsoft Entra Connect で確認することで、Microsoft Entra テナントがフェデレーションに対して有効になっていることを確認します。
Azure portal の [フェデレーション] の横にあるドメインをクリックして、カスタムドメインが検証されていることを確認します。
最後に、DNS を確認し、AD FS サーバーまたは WAP サーバーがインターネットから解決されていることを確かめます。これが解決されていることと、それに移動できることを検証します。
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 でその認証方法がサポートされていない場合は、認証される前にエラーメッセージが表示されます。

必要な認証方法	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 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 のトラブルシューティング

次の方法で共有