Entra ID を使った AD FS フェデレーションのガイド

By Mirko Peters · 2026-04-30 · Updated 2026-09-13

AD FS フェデレーション、SSO、信頼関係、セキュリティを理解したうえで、AD FS から Microsoft Entra ID への移行と、よくあるトラブルシューティングの問題を確認します。

Automatically translated with AI from the original post. Read the English original

Active Directory Federation Services（AD FS）によるフェデレーションは、現代の組織がデジタル ID とシングルサインオン（SSO）を管理する上で中心的な役割を果たしています。ビジネスが成長しニーズが変化するにつれて、特にクラウドアプリケーションやコラボレーション プラットフォームの普及に伴い、AD FS を理解することがこれまで以上に重要になっています。本ガイドでは、AD FS の役割、Microsoft のエコシステム全体における位置付け、そして Entra ID や Azure AD といった高度なソリューションへの移行が企業の認証の在り方をどのように変えているのかを整理します。

フェデレーション ID のような基本的な概念から、詳細な移行戦略、セキュリティのベスト プラクティスまでを取り上げ、AD FS の動作を包括的に解説します。さらに、最新のクラウド ID へ移行を計画する際に知っておくべきポイントも扱います。既存環境のトラブルシューティングを行う場合も、新たな構成を設計する場合も、本資料は適切な判断を下し、認証の仕組みを確実に保つための手助けになります。

Active Directory フェデレーション サービスの基礎

Active Directory Federation Services（AD FS）は、多くの組織で多様な認証システムを連携させる中核となる仕組みです。特に、オンプレミスのリソースとクラウド サービスが混在している環境では重要になります。基本的な考え方は単純です。フェデレーション ID を使うと、ユーザーは普段使っている資格情報で、自身のホーム環境の外にあるアプリケーションにアクセスできます。組織やサービスの間にある壁を取り払い、関係者全員にとってアクセスをより安全かつ効率的にすることが目的です。

パートナー、ベンダー、リモート チームがシステムで作業する必要があるものの、余分なユーザー名やパスワードを大量に発行したくない場面を想像してみてください。AD FS は「信頼されたブリッジ」を作り、そうしたユーザーが社内にいるときと同じようにサインインできるようにします。「セキュリティを手放さずにリソースを共有するにはどうすればよいか」という古くからの課題に対する Microsoft の答えであり、SAML や OAuth といった標準規格に裏打ちされた豊富な技術基盤を備えています。

ID フェデレーションに入門したばかりの方も、長年ドメイン間の信頼関係を管理してきた方も、このセクションでは基礎を解説します。AD FS が実際に何をするのか、なぜ今も重要なのか、そしてクラウドやハイブリッドな企業環境とともにどのように進化してきたのかを見ていきます。詳細は後続のパートで扱いますが、Microsoft 製品中心の組織において、安全な境界をまたぐ認証の出発点となるのが AD FS である、という点をまず押さえてください。

Active Directory フェデレーションとは何か、そしてどのように動作するのか

Active Directory Federation Services（AD FS）は、組織やドメインの境界を越えて安全でシームレスな認証を実現するために Microsoft が開発したツールです。その中核にあるのが「フェデレーション ID」で、ユーザーは自社ドメインの管理外にあるシステム、アプリ、サービスに、普段の資格情報を使ってアクセスできます。そのため、業務を進めるために多数のパスワードを覚えたり、複数のサインインを使い分けたりする必要がありません。

仕組みは次のとおりです。AD FS は SAML（Security Assertion Markup Language）や OAuth といった業界標準のプロトコルを使い、自社の組織（ID プロバイダー）と外部のアプリケーションやパートナー（証明書利用者）との間に信頼関係、いわゆる「フェデレーション トラスト」を確立します。その中核となるのがクレームベースの認証です。AD FS はユーザーを検証した後、ユーザーの ID や権限に関する情報（クレーム）を含む「セキュリティ トークン」を発行します。接続先のアプリケーションはそのトークンを検証し、すべて問題がなければユーザーのアクセスを許可します。

AD FS は従来、大企業がオンプレミスのアプリケーションと Office 365 などのクラウド リソースの両方にシングルサインオン（SSO）を提供する手段として使われてきました。Entra ID のようなクラウドネイティブのディレクトリが主流になる前は、企業の境界を越えても認証をスムーズに保つための橋渡し役を担っていました。現在でも、ハイブリッド環境の基盤コンポーネントとして重要な役割を果たしています。一方で、柔軟性とセキュリティを高めるため、多くの組織がクラウドベースの ID ソリューションへの移行を計画しています。

AD FS アーキテクチャの主要コンポーネント

• フェデレーション サーバー: ユーザーの認証、クレームベースのトークンの発行、証明書利用者との信頼関係の管理を行う AD FS の中核エンジンです。
• Web Application Proxy（WAP）: ゲートウェイとして機能し、外部ユーザーに安全なプロキシアクセスを提供するとともに、フェデレーションサーバーをインターネットへの直接的な露出から保護します。
• Claims Provider: ユーザーのID情報を提供します。多くの場合 Active Directory からデータを取得し、トークンの生成とクレーム発行に利用されます。
• Relying Party Trust: AD FS のトークンを利用・検証する外部アプリケーションやシステムを表します。クレームの変換方法と、アクセスを許可するユーザーを定義します。
• Domain Controller: Active Directory に対してユーザーを認証し、トークン発行の前に資格情報を確認します。

ADFS の認証フローとフェデレーショントラストの解説

AD FS は、バックエンドが複雑であっても、エンドユーザーにとっては認証をシンプルに感じさせてくれるため、シングルサインオンと安全なアクセスの実現に優れています。その中核となるのが、AD FS による認証フローとフェデレーショントラストの仕組みです。ユーザーがサインインを試みた瞬間から、目的のアプリケーションやリソースにたどり着くまで、資格情報、トークン、クレームを安全かつ効率的にやり取りすることが重要になります。

ここで重要になるのが、SAML、WS-Federation、OAuth などのプロトコルの詳細です。プロセスは高速に進みます。ユーザーの資格情報を検証し、クレームを発行し、属性を変換して、適切なトークンを適切なシステムへ送信します。その過程で、フェデレーショントラストの関係により、認証の両側の組織が、誰がデジタルの入口を通過しているのかを確信できるようになります。

次に、AD FS の一般的な認証の流れを手順ごとに整理し、そのあとフェデレーショントラストの設定方法を詳しく見ていきます。これにより、まったく別々の二つの組織が、安全な社外間アクセスを安心して許可できるようになります。これらの概念を理解しておくと、安全なフェデレーションの構築から、後々発生するアクセスやクレームの問題のトラブルシューティングまで、IT 担当者とセキュリティチームの対応力が高まります。

ADFS の認証フローの理解

1. ユーザーがアプリケーションにアクセス: ユーザーがフェデレーションされたアプリケーションを開こうとします。外部からのアクセスであれば、まず Web Application Proxy を経由します。内部からのリクエストは、AD FS に直接送られます。
2. 認証要求の送信: アプリケーションのリライングパーティーが、アクセスしたいリソースを含む認証要求を付けて、ユーザーのブラウザーを AD FS サーバーにリダイレクトします。
3. 資格情報の検証: AD FS はユーザーにサインインを求め（Windows 資格情報、フォーム、MFA、証明書のいずれかを使用）、その情報を Active Directory のドメインコントローラーで確認します。
4. クレームの作成: 検証が完了すると、AD FS はクレームベースのトークンを作成します。このトークンには、事前に構成されたルールに基づき、ユーザー名、グループメンバーシップ、メールアドレスなど、ユーザーに関する属性が含まれます。
5. トークンの発行: クレームトークンは AD FS によって安全に署名され、ユーザーのブラウザーに返されます。
6. アプリケーションによるトークンの検証: ブラウザーはトークンを対象のアプリケーションに渡します。アプリケーションは、AD FS の証明書の公開鍵側を使って、トークンの正当性を検証します。
7. アクセスの許可: トークン、クレーム、ルールのすべてが確認できれば、アプリケーションはパスワードを再入力させることなく、ユーザーのアクセスを許可します。

この段階的なフローは、ユーザーが社内にいる場合も、フェデレーションされたパートナー経由でアクセスする場合も、一般的なシングルサインオンに適用できます。OAuth（SaaS アプリで普及しています）についても同様の考え方が当てはまり、AD FS はさまざまな認証シナリオやプロトコルに柔軟に対応できます。

組織間のフェデレーショントラストの確立

AD FS でフェデレーショントラストを設定するとは、二つの組織が互いの認証トークンを受け入れることに合意する関係を作ることです。技術的には、双方が相手を信頼されたクレームプロバイダーまたはリライングパーティーとして認識するように構成します。通信を保護するために SSL 証明書を交換し、どのクレームを受け入れるか、ユーザーIDをどのように対応付けるかを決めるカスタムの信頼ポリシーを設定します。

正しいトラストの設定は、ビジネスパートナー、ベンダー、子会社との間で安全でシームレスな SSO を実現する基盤になります。組織のセキュリティ基準を下げることなく、コラボレーションを可能にします。

AD FS 導入に関するセキュリティの考慮事項とベストプラクティス

連携（フェデレーション）やSSOが関わる場面では、セキュリティが最優先になります。信頼関係の1か所でも侵害や設定ミスがあれば、被害は一気に広がりかねません。AD FSでは、トークン発行の全体的な仕組みを守り、正しい人だけが認証できるようにし、攻撃者を最も重要なリソースから遠ざけることに重点を置きます。

想定される脅威には、資格情報のフィッシングやトークンの窃取から、サービス拒否攻撃、総当たり攻撃まで含まれます。各段階で強固な防御が必要です。強力な認証ポリシーから暗号化されたトークンの流れ、定期的なパッチ適用からリアルタイム監視まで、すべてが対象になります。こうした多層的なセキュリティは、攻撃者を遮断するだけでなく、監査やガバナンス要件への準拠にも役立ちます。

以降のセクションでは、AD FSに対して実践可能な防御策を解説し、代表的な攻撃経路とその軽減策を取り上げます。さらに、安全な構成、継続的な監査、そして幅広いセキュリティおよびガバナンスの取り組みとの統合に関するベストプラクティスをまとめます。Microsoft の Entra ID や Azure 環境から得られた教訓を含め、リスク低減の実践的な戦略を知りたい方は、ぜひ続きをお読みください。また、クラウドにおけるID、条件付きアクセス、ガバナンスの関係をさらに深く知りたい方は、こちらのID セキュリティ戦略に関するエピソードをご覧ください。

AD FSにおけるトークン発行と認証の保護

• 強力なパスワードと資格情報のポリシーを適用する: 複雑なパスワードと厳格な有効期限ルールを設定し、脆弱な資格情報が露出するリスクを減らします。
• 多要素認証（MFA）を有効にする: 電話への確認コードやハードウェアトークンなどの第2の確認手順を追加し、パスワードが漏えいした場合でも不正なサインインを防ぎます。
• 安全で暗号化されたトークン通信を使用する: すべてのトークン交換で SSL/TLS を必須にし、改ざんや盗聴を防ぐためにトークンに署名と暗号化を施します。
• トークンの有効期間を制限する: 短命のトークンを使用し、トークンが盗まれたり再利用されたりした場合の攻撃可能な期間を限定します。

MFAさえも回避する攻撃（OAuth の同意の悪用など）への対策について詳しくは、Entra ID を保護するための重要な制御策をご覧ください。

主要なセキュリティの考慮事項と脅威の軽減

• 資格情報のフィッシング: ユーザーがフィッシングを見分けられるよう教育し、サインイン時点で保護するために MFA を必須にします。
• リプレイとトークンの窃取: 短いトークン有効期間と継続的なトークン検証を使用し、傍受されたトークンによる被害を抑えます。
• サービス拒否（DoS）攻撃: AD FS とプロキシサーバーを高可用性構成で展開し、信頼されていないネットワークへの公開範囲を制限します。
• パッチ管理: 攻撃者が脆弱性を悪用する前に対処できるよう、AD FS と依存するすべてのシステムを定期的に更新します。
• 監査と監視: 不審なアクティビティを早期に検出できるよう、堅牢なログ記録と監視を実装します。ゼロトラストのより広い取り組みについては、こちらのゼロトラストのポッドキャスト エピソードをご覧ください。

AD FSの展開と監視のベストプラクティス

• 冗長化と負荷分散: 複数のフェデレーションサーバーとプロキシサーバーを展開し、単一障害点を排除するとともに、多数のユーザーをサポートします。
• 継続的な監視: 監査ログ、イベント監視、リアルタイムのアラートを活用し、不審なパターンを迅速に検出します。
• 定期的なセキュリティ監査: 構成や信頼関係にずれや不備がないかを確認し、ベストプラクティスの変更にも継続的に対応します。
• クラウドセキュリティプラットフォームとの統合: AD FS のログとイベントを Microsoft Sentinel などの SIEM ツールや、Microsoft Purview 監査と連携させ、リスクの検出とコンプライアンスのレポートを一元化します。
• ライフサイクル管理: トークン、証明書、ポリシー設定を定期的に更新し、「アイデンティティの負債」と技術的リスクを最小限に抑えます。

現代の組織におけるAD FSの制限事項とトラブルシューティングの課題

AD FSは長年、多くの組織でシステムやユーザーの接続を支えてきましたが、近代的な環境では課題も少なくありません。AD FSの基盤を運用したことがあれば、その苦労はよくご存じでしょう。保守コストがかかり、複雑な信頼構成が必要で、想定外のタイミングで更新が発生します。さらにクラウド環境の拡大が加わると、従来のやり方では対応しきれなくなりつつあります。

こうした制約は技術面だけにとどまらず、ビジネス上のリスクにもなり得ます。認証の信頼性、拡張のしやすさ、新しいSaaS要件への対応スピードなどを考えてみてください。これらが、Entra IDのようなクラウドベースのID基盤へ移行を検討するきっかけになることが多いでしょう。ただし大きな移行を始める前に、AD FS環境で注意すべき点と、障害発生時の対処方法を把握しておくことが重要です。

次に、今日のエンタープライズ企業でAD FSの足かせとなっている主な制約を取り上げ、ヘルプデスクに寄せられやすい問題について実践的なトラブルシューティング手順を解説します。これらの基本を押さえておくと、日常の運用においても、移行の準備においても、貴重な時間と自信を得られるはずです。

エンタープライズ認証におけるAD FSの主な制約

• 高い保守負荷: AD FSの展開には継続的なパッチ適用、監視、ハードウェアの保守が必要であり、運用コストの増加につながります。
• クラウド統合の制限: 従来のAD FSでは、Entra IDやAzure ADが備える、SaaSやクラウドネイティブなセキュリティとの深く標準的な統合には対応できません。
• 複雑な構成: マルチフォレストやクロスドメインのシナリオを設定すると、管理対象の要素が増え、設定ミスが発生する機会も増えます。
• スケーラビリティの課題: ユーザー数の増加やグローバルなアクセス要件に対応するには、多くの場合、サーバーの追加や複雑なネットワーク構成が必要になります。

AD FSでよくある問題のトラブルシューティング

1. 認証の失敗: AD FSのイベントログで、サービスアカウントのアクセス許可、ドメインコントローラーへの接続、ログオン失敗の記録を確認してください。イベントID 364は、トークン発行の問題を示します。
2. トークン発行エラー: 要求規則と証明書の構成を確認してください。不一致や期限切れの証明書が原因で失敗することがよくあります。
3. 信頼される対象の設定ミス: エンドポイント、信頼関係、要求変換を確認し、システム間で正しくマッピングされているかを検証してください。
4. アカウントのロックアウトやパスワードの問題: パスワードの同期とアカウントポリシーが、フォレストやドメイン全体で一貫しているかを確認してください。
5. AD FSログの監視: 関連するイベントID(トークン発行成功を示す100、構成の問題を示す300番台など)を活用して、根本原因をすばやく特定してください。

AD FSからEntra IDへの移行と、フェデレーションの今後

レガシーなAD FSを残しつつ、クラウドへも踏み出そうとしている組織にとって、今後の道筋は明確になりつつあります。Azure ADやEntra IDなどのクラウドベースのID基盤は、最新のワークロードはもちろん、以前はAD FSだけに依存していた古いアプリケーションに対しても、堅牢で柔軟かつ安全な認証を提供します。ハードウェアの負担が軽くなり、信頼モデルが単純化され、進化する脅威やコンプライアンス要件に対応できるセキュリティ体制を構築できることから、業界もこの方向へ進んでいます。

ただし、AD FSからの切り替えはスイッチを入れるだけで済む話ではありません。Entra ID(Microsoftのアイデンティティサービスを束ねる新しいブランド)への移行では、信頼関係、アプリケーション統合、条件付きアクセスやガバナンスなどのポリシーが新しい環境でどう機能するかを見直す必要があります。適切に進めれば、ユーザー満足度が向上し、クラウドとオンプレミスのシステム全体で、より強固で一貫した統制を実現できます。

以下では、AD FSとクラウドIDの直接比較と、ユーザーに影響を与えず、新たなセキュリティホールも生まない段階的な移行の実績ある戦略を紹介します。Entra IDの条件付きアクセスに伴うリスクとガバナンスの課題をまず確認したい場合は、こちらのIDセキュリティループに関する詳細解説も出発点として適しています。

AD FSとAzure AD・Entra IDによるクラウドベースのIDの比較

• AD FSの制約: オンプレミスのハードウェア要件、パッチ適用、複雑な信頼および要求規則の管理、クラウドやSaaSとのネイティブ統合の限界、新たなセキュリティ脅威への対応の遅さ。
• Azure AD と Entra ID の利点: Microsoft 365 とのネイティブな統合、設定の容易さ、条件付きアクセスの標準搭載、SaaS の迅速なオンボーディング、一貫したポリシーの適用、クラウドワークロード向けの強化された ID 保護を提供します。
• 戦略的な移行の推進要因: 保守の負担軽減、管理の合理化、拡張可能なアクセス、ビジネスの成長に合わせて適応するポリシー主導のセキュリティモデルです。

蓄積された例外や承認が「ID の負債」を生むこと、そして Entra ID における適切なガバナンスがクラウド ID のセキュリティをどのように変えるかについては、コントロールプレーンとしての ID に関するこのポッドキャストをご覧ください。

AD FS から Entra ID へのスムーズな移行のための移行戦略

• 検出: AD FS に紐づくすべての証頼当事者信頼、要求規則、統合アプリケーションを棚卸しします。依存関係を対応付け、移行可能なワークロードを特定します。
• 計画: 段階的な移行計画を設計し、Entra ID をセットアップするとともに、必要に応じてハイブリッド共存のためにクラウドコネクタを検証します。
• 共存: AD FS と Entra ID を並行して運用し、ユーザー エクスペリエンスとアクセスログを監視しながら、アプリケーションを段階的に Azure AD での認証へ移行します。
• 切り替え: ユーザーと最終的なワークロードを Entra ID へ移行し、従来の信頼関係とカスタム規則を削除したうえで、検証が完了したら、オンプレミスの AD FS 基盤を廃止します。
• 移行後のチューニング: Entra ID の条件付きアクセス ポリシー、ユーザー プロビジョニング、レポート機能を見直し、ID 運用を完結させるとともに将来にも備えます。

あわせてお聴きいただきたいエピソード

Entra ID との ADFS フェデレーションについて調べている場合は、以下のエピソードがアーキテクチャ、セキュリティ、ガバナンス、実装に関する実践的な背景を補足します:

• Microsoft AI Agent Harness – Simply Explained — オーケストレーション、ガードレール、評価、信頼性の高い AI ワークフローを理解できます。
• Microsoft Defender XDR – Simply Explained — ID と AI の判断をセキュリティ監視と対応に結び付けます。
• Microsoft Teams Governance – The Illusion of Control — ガバナンス、所有者管理、ポリシーが運用リスクを低減する仕組みを学べます。
• Azure Virtual Network – Simply Explained — クラウド接続の背後にあるアーキテクチャの文脈を理解できます。