>
>
最終更新日
オンプレミスのWindows Server環境で広く利用されているActive Directory（AD）。近年はクラウドサービスの普及により、ADとクラウドサービスを連携するID管理のニーズが高まっています。そこで活用されるのが、ADを用いたシングルサインオン（SSO）ソリューションである「ADFS（Active Directory フェデレーション サービス）」です。本記事ではADFSの仕組み、AD DSとの違い、導入時のリスク、そしてクラウド移行の判断基準まで解説します。
ADFSとは？
この記事でわかること
ADFSは、社内のActive Directory認証を利用して、社外のクラウドサービスへのシングルサインオン（SSO）を提供する機能です。
「社内から社外へ」の認証連携を可能にし、ユーザーの利便性とセキュリティを両立させます。
近年Microsoftは、運用コスト削減のためADFSからクラウドベースのMicrosoft Entra ID（旧Azure AD）への移行を強く推奨しています。
ADFSとは、Microsoftが提供する認証フェデレーションソリューション（Active Directory Federation Services）です。オンプレミスのActive Directoryと、外部のクラウドサービスや提携企業のシステムとの間で信頼関係を結び、一度のログインで複数サービスへのアクセスを可能にします。
例えば、従業員500名規模でオンプレミス環境とMicrosoft 365を併用するハイブリッド環境を想定しましょう。AD FSを導入すれば、従業員は毎朝出社してWindows PCにログインするだけで、そのまま各種クラウドサービスにもパスワード入力なしでアクセスできるようになります。これにより、日々の業務効率が向上し、パスワード忘れによるヘルプデスクへの問い合わせを大幅に削減できます。
ただし、最新のID管理戦略においては注意が必要です。Microsoftは現在、運用コストとセキュリティの観点から、ADFS環境からクラウドネイティブなID管理基盤であるMicrosoft Entra ID（旧Azure AD）への移行を強く推奨しています。これから新規に構築する場合は、将来的なクラウド移行も見据え、「本当にオンプレミスにサーバーを構築する必要があるか」を比較検討することが重要です。
ADFSは、既存の強固なAD環境を活かしつつ、クラウドの利便性を享受するための強力な橋渡し役となります。
ADFSの仕組みについて
ADFSは、Active Directoryと対象のクラウドサービス（アプリケーション）の間でフェデレーション（信頼関係）を構築し、認証情報の橋渡しを行います。この連携において、業界標準のプロトコルであるSAML（Security Assertion Markup Language）やOAuthなどが広く利用されています。
SAML認証フロー図解
最も一般的なSAML認証を用いたシングルサインオンの認証フローをタイムライン形式で解説します。
サービスへのアクセス要求: ユーザーがWebブラウザから利用したいクラウドサービス（Service Provider = SP）にアクセスします。
認証要求のリダイレクト: クラウドサービスは未認証のユーザーであることを検知し、認証要求（SAML Request）を生成して、あらかじめ設定されたADFS（Identity Provider = IdP）へブラウザをリダイレクトさせます。
ユーザー認証の実施: ADFSは、社内ネットワークのAD DSに対してユーザーの認証を要求します。ここでKerberos認証やフォーム認証が実行されます。
セキュリティトークンの発行: 認証が成功すると、ADFSはユーザーの識別情報や権限を含むSAMLアサーション（セキュリティトークン）を発行し、ユーザーのブラウザに返却します。
トークンの提出とアクセス許可: ブラウザは自動的にクラウドサービスへSAMLアサーションを送信します。クラウドサービスは署名を検証し、正当なユーザーであると確認した上でアクセスを許可します。
一度のAD認証で発行されたトークンを使い回すことで、利用者は多数のサービスにシームレスに接続できます。
ADFSとAD DS（Active Directory）の違い
同じActive Directoryの機能群に属していても、ADFSとAD DS（Active Directory Domain Services）は明確に異なる役割を担っています。
比較項目 | AD DS (Domain Services) | ADFS (Federation Services) |
|---|---|---|
主な役割 | 社内ネットワークのユーザー・PC・権限の一元管理 | 社内ADと社外クラウドサービス間の認証連携（SSO） |
認証の対象 | 社内（オンプレミス）のPCログイン、ファイルサーバー等 | 社外（インターネット）のWebアプリケーション、SaaS等 |
使用プロトコル | Kerberos、LDAP、NTLMなど | SAML、OAuth、WS-Federationなど |
利用シーン | 社員のPCログインや社内プリンタの利用制御 | 社外からSalesforceやMicrosoft 365へのログイン |
AD DSは社内ネットワーク向けの身分証明書を発行する基盤であり、ADFSはその身分証明書を使って外部サービスを利用するためのビザ（査証）を発行する仕組みです。
ADFSの構成要素と構築要件
ADFSを安全に運用するためには、社内ネットワークとインターネットの境界（DMZ）を意識した適切なサーバー構成とネットワーク設計が必要です。
ADFSサーバーとADFS Proxy（WAP）の違い
システムは主に以下の2つの構成要素で構築されます。
ADFSサーバー: 社内ネットワークに配置され、AD DSと直接通信して実際の認証処理とトークン発行を行います。
ADFS Proxy（Web Application Proxy: WAP）: DMZ（非武装地帯）に配置されるリバースプロキシサーバーです。外部からの認証要求を安全に受け取り、社内のADFSへ中継することで、内部インフラを直接インターネットに公開するリスクを防ぎます。
ADFS構築要件チェックリスト
オンプレミス環境でADFSを構築する際に確認すべき主な要件は以下の通りです。
サーバー台数: 高可用性を確保するため、社内ADFSサーバー2台、DMZのWAPサーバー2台の合計4台構成（＋ロードバランサー）が推奨されます（※推奨構成の詳細はMicrosoft公式ドキュメント「ADFSの展開トポロジの考慮事項」を参照してください）。
SSL証明書: 通信の暗号化のため、パブリックな認証局（CA）から発行されたSSL証明書が必要です。ADFSサーバーとWAPサーバーで同一の証明書を使用します。
ネットワーク要件: インターネットからWAPへのHTTPS（TCP/443）、WAPからADFSへのHTTPS通信、およびADFSからAD DSへの通信が許可されている必要があります。
これらを事前に確認しておくことで、構築後のトラブルを防げます。
ADFS認証を利用するリスクとデメリット
ADFSは強力な連携機能を提供しますが、オンプレミス環境に依存するアーキテクチャ特有のリスクと運用コストが伴います。導入前に運用体制を十分に検討しましょう。
よくある失敗パターン：証明書の更新忘れ
実務で非常に多く発生する重大な障害が「SSL証明書やトークン署名証明書の更新忘れ」です。ADFSは通信の暗号化やトークンの署名に証明書を使用しますが、これらの有効期限が切れると、ある日突然「全社でMicrosoft 365やすべてのクラウドサービスに一切ログインできなくなる」という大規模なログイン障害に直面します。更新作業は手動で行う部分が多く、担当者の引き継ぎ漏れなどで発生しがちなリスクです。
高い運用コストとパスワード管理工数
インフラの維持コストと管理工数も大きなデメリットです。複数台のWindows Serverのライセンス費用、定期的なパッチ適用、ロードバランサーの保守が必要です。さらに、ADFSはオンプレミスADのパスワードポリシーに依存するため、パスワードリセットの運用コストが残ります。国内外の調査では1件あたり数百〜数千円相当のコストがかかるとされており、この工数を大幅に削減することは困難です。
これらのリスクを回避するため、最新の環境ではADFSの運用を段階的に縮小し、クラウドベースのIDaaSへ移行するアプローチが主流となっています。
よくある質問（FAQ）
ADFSとMicrosoft Entra ID（旧Azure AD）のどちらを選ぶべきですか？
新規導入であれば、原則としてクラウドベースの「Microsoft Entra ID」を選択してください。オンプレミスサーバーの構築・保守が不要であり、高度なセキュリティ機能を標準で利用できるため、ADFSに比べて運用コストとリスクを大幅に削減できます。詳細については、ADFSからMicrosoft EntraへのFAQ（Microsoft Learn） をご参照ください。
ADFSは段階的に廃止できますか？
はい、段階的な廃止（マイグレーション）が可能です。Microsoftが提供する「段階的ロールアウト」機能を使用すれば、特定のユーザーグループから順番に、ADFS認証からMicrosoft Entra IDのマネージド認証（パスワードハッシュ同期など）へ切り替えることができます。
ADFSのトークン署名証明書はどのように更新しますか？
デフォルトでは「AutoCertificateRollover」機能により、有効期限が近づくと自動的に新しい証明書が生成されます。ただし、連携先のクラウドサービス（SP）側で新しい証明書のメタデータを自動で読み込めない場合は、管理者が手動で証明書をエクスポートし、各サービス側に登録し直す必要があります。
まとめ
AD FS（Active Directory Federation Services）は、既存のActive Directory資産を活用してクラウドサービスへのシームレスなアクセスを実現する、ハイブリッド環境では現実的な選択肢でした。しかし、オンプレミスサーバーの維持コストや証明書管理の運用負荷といった課題も抱えています。
これから取り組むべき最初の一歩は、「現在のAD環境と利用中のクラウドサービスの棚卸し」です。どのシステムがAD認証に依存しているかを可視化しましょう。その上で、新規にADFSを構築するのではなく、Microsoft Entra IDへの移行（Microsoft Learn） や統合を前提とした、最新のクラウド主導のID管理戦略を検討することをお勧めします。まずは現状把握から着手してみてください。
アクションチェックリスト
✅ 現在のAD環境とクラウドサービス利用状況を棚卸しする
✅ ADFSの証明書有効期限（SSL証明書・トークン署名証明書）を確認する
✅ Microsoft Entra IDへの移行可否を評価する
✅ 新規構築の場合はオンプレミスADFS構築ではなくEntra ID採用を前提に検討する
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
橋爪兼続
ライトハウスコンサルタント代表。2013年海上保安大学校本科第Ⅲ群（情報通信課程）卒業。巡視船主任通信士を歴任し、退職後、大手私鉄の鉄道運行の基幹システムの保守に従事。一般社団法人情報処理安全確保支援士会の前身団体である情報処理安全確保支援士会の発起人。情報処理安全確保支援士(第000049号)。
