
1. はじめに
初めまして。合同会社Artopeerの越川と申します。
記事をご覧いただきありがとうございます。
私は10年以上にわたり、ウェブアプリケーション開発からデータベース、サーバー構築まで、多岐にわたるプロジェクトで技術と経験を培ってきました。 最近はシステムの安定稼働やデータ保護、そして現代のサイバー脅威からビジネスを守る技術に注力しています。
私の経験上、ビジネスをサイバー脅威から守る基本は「認証」ですが、その管理は多くの企業で課題となっています。
業務システムやクラウドサービスの増加に伴い、ID/パスワード管理は利便性とセキュリティの両面で大きな課題です。この課題を解決する技術が「シングルサインオン(SSO)」であり、その実現方法の一つがMicrosoftのActive Directory Federation Services(ADFS)です。
Azure ADが主流の今、「ADFSは古い」と思われがちですが、オンプレミスとの親和性や特定要件下での優位性から、今なお重要な選択肢です。
本稿では、ADFSの基礎から応用までをエンジニア視点で解説します。皆様が最適な認証基盤を設計するための一助となれば幸いです。
2. ADFSとはなにか
ADFSの役割:フェデレーション認証の実現
ADFSとは、異なる組織やドメイン間で、安全に認証情報を連携するための「フェデレーション認証」を実現するWindows Serverのサーバー機能です。
具体的には、社内のActive Directory(AD)で管理されているユーザー情報を用いて、Microsoft 365やSalesforce、Google Workspaceといった外部のクラウドサービスへの認証を可能にします。
これにより、ユーザーは社内ADのIDとパスワード一つで、許可された様々なサービスへログインできるシングルサインオン(SSO)が実現します。
対応プロトコル:多様なサービスとの連携を支える標準技術
ADFSの強みは、標準的な認証プロトコルをサポートしている点にあります。
- SAML (Security Assertion Markup Language)
クラウドサービスとのSSOで最も広く利用されているXMLベースのプロトコルです。
- OAuth (Open Authorization)
主に、ユーザーの許可に基づき、アプリケーションに特定のリソースへの限定的なアクセス権を与えるために利用されます。
- WS-Federation
Microsoft製品群を中心に利用されてきたフェデレーションプロトコルです。
これらのプロトコルに対応することで、Microsoft製品に限らず、非常に多くのサードパーティ製アプリケーションとの認証連携が可能になります。
フェデレーション認証の仕組み
フェデレーション認証の基本的な流れは、ユーザー、サービス提供者(SP: Service Provider)、IDプロバイダー(IdP: Identity Provider)の3者間でやり取りが行われます。ADFS環境では、ADFSサーバーがこのIdPの役割を担います。
フェデレーション認証(SAML)の基本的なフロー図

参考文献:https://manual.iij.jp/iid/faq/19644038.html
この一連の流れにより、クラウドサービス側(SP)はパスワードを直接扱うことなく、信頼するIdP(ADFS)の認証結果を基にユーザーを受け入れることができます。
3. なぜ今、ADFSが活用されるのか
Azure AD Connectによる同期やパススルー認証など、クラウド連携の方法が多様化する中で、あえてADFSが選ばれるのには、次のような明確な理由があります。
既存AD資産の最大活用
長年運用してきたオンプレミスのActive Directoryのポリシーや複雑なグループ構成をそのまま活かしたい場合に、ADFSは最も親和性の高いソリューションです。
複雑な認証要件への柔軟な対応
多要素認証(MFA)に特定のハードウェアトークンを利用したい、あるいは特定のクライアント証明書を持つデバイスからのみアクセスを許可したいなど、Azure ADの標準機能だけでは実現が難しい、きめ細やかなアクセスポリシーを独自に構築して適用できます。
高いセキュリティポリシーへの準拠
企業のセキュリティポリシーとして、認証情報(特にパスワードハッシュ)をクラウドに同期・保持することを禁止している場合があります。
ADFSは認証処理がオンプレミス内で完結するため、こうした厳しい要件を満たすことが可能です。
オンプレミス完結型SSOの実現
インターネットに接続しない閉域網内のシステム間でのSSOや、オンプレミスで稼働する多数のWebアプリケーションとのSSOハブとして活用したい場合に、ADFSは依然として強力な選択肢です。
4. ADFSの具体的な導入ステップ
ADFS環境の構築は、いくつかのコンポーネントを計画的に組み合わせて行います。
ここでは、基本的な導入ステップの概要を解説します。
参考文献:
https://learn.microsoft.com/ja-jp/windows-server/identity/active-directory-federation-services
Step 1: インフラストラクチャの準備
ADFSの構築には、以下のコンポーネントが必須となります。
- Active Directoryドメイン
ADFSの認証基盤となるADドメインサービスが正常に稼働していること。
- ADFSサーバー
Windows Server OS上にADFSの役割をインストールします。
認証の中核を担うため、耐障害性を考慮した冗長構成(NLBによる負荷分散)が強く推奨されます。
- Web Application Proxy (WAP) サーバー
インターネットからの認証リクエストを安全に社内のADFSサーバーへ中継するためのリバースプロキシです。
DMZ(非武装地帯)に設置するのが定石です。
- SSL証明書
ADFSのサービス名(例:sts.example.com
)に使用する、パブリックな認証局から発行されたSSL証明書が必須です。
証明書の有効期限管理は運用上の最重要ポイントの一つです。
Step 2: ADFSのインストールとファーム構成
サーバーの準備が整ったら、ADFSの役割をインストールし、構成ウィザードを実行します。
ここで、ドメイン管理者アカウント、準備したSSL証明書、サービスアカウントなどを指定して、ADFSファームの基本構成を完了させます。
Step 3: WAPの構成とADFSとの連携
DMZに配置したWAPサーバーを構成し、ADFSサーバーとの信頼関係を確立します。
その後、公開ルールを作成し、外部からの認証リクエストを内部のADFSサーバーへ安全に転送できるよう設定します。
Step 4: 証明書利用者信頼の構成
最後に、連携したいクラウドサービスやアプリケーション(SP)をADFSに登録します。
この設定は「証明書利用者信頼」と呼ばれ、認証連携の要となります。
SP側が提供するメタデータ(設定情報が記述されたXMLファイル)をインポートし、どのユーザー情報を連携するかを定義する「要求発行ポリシー」を設定するのが一般的な流れです。
5. ADFSのメリットと主要IDaaSとの比較
メリット:SSOによる利便性向上と管理負荷軽減
ADFSを導入する最大のメリットは、シングルサインオンによるユーザーの利便性向上と、それに伴うヘルプデスクのパスワードリセット対応などの工数削減です。
また、標準プロトコルに基づくことで、企業間の認証連携をセキュアかつスムーズに実現できる点も大きな利点です。
IDaaSとの機能・コスト比較
ここでは、主要なID管理ソリューションであるAzure ADやOktaといったIDaaS(Identity as a Service)とADFSを比較してみましょう。
比較項目 | ADFS (Active Directory Federation Services) | Azure AD (Microsoft Entra ID) | Okta |
---|---|---|---|
提供形態 | オンプレミス(サーバー構築・運用が必要) | クラウド (IDaaS) | クラウド (IDaaS) |
主な特徴 | 既存AD資産との高い親和性、柔軟なカスタマイズに対応 | Microsoft 365とのシームレスな統合、豊富なクラウド連携 | 幅広いSaaSアプリ連携、開発者向けAPIの充実 |
認証情報 | オンプレミスのADで一元管理 | クラウド上に同期・保持 | クラウド上で管理 |
構築・運用 | サーバー等の管理が必要。運用負荷は高い。 | SaaSのため構築不要。運用負荷は低い。 | SaaSのため構築不要。運用負荷は低い。 |
カスタマイズ性 | 高い。独自の認証ロジックやクレームルールを実装可能 | 標準的な機能が中心。条件付きアクセスポリシーなどで制御 | 柔軟なポリシー設定やワークフローの自動化が可能 |
コスト | Windows Serverライセンスは必要だが追加費用はなし。ただし、サーバーや運用人件費といったTCOは考慮が必要。 | ユーザー数ベースのサブスクリプション。機能に応じたプラン(Free, P1, P2)がある。 | ユーザー数ベースのサブスクリプション。製品ラインナップが豊富。 |
最適なケース | オンプレミス環境が主体で、認証情報をクラウドに置けない要件がある場合。 | Microsoft 365を全面的に利用しており、クラウド中心の環境を目指す場合。 | Microsoft以外の多様なSaaSを利用しており、ベストオブブリードな構成を求める場合。 |
6. ADFSの活用事例と実践的な活用シナリオ
ADFSは具体的にどのような場面で活用されるのでしょうか。
ここでは実例と代表的な活用シナリオをいくつか紹介します。
活用事例
事例1:東京大学、早稲田大学など多数の大学
- テーマ
学術認証フェデレーションとの連携によるSSO環境の実現 - 概要
国立情報学研究所(NII)が運営する「学術認証フェデレーション(GakuNin)」には、東京大学や早稲田大学をはじめとする多くの大学・研究機関が参加しています。
これらの大学では、組織内のActive Directoryと連携するIdP(Identity Provider)としてADFSを構築しています。 これにより、学生や教職員は大学の統合IDとパスワードを使うだけで、契約している電子ジャーナルや他大学の研究システムなど、GakuNinに参加している様々な外部学術サービスへシングルサインオンできるようになります。
ADFSが組織内の認証を担い、ユーザーの所属情報などを安全に外部サービスへ連携する橋渡し役として機能している典型的な事例です。
参考文献:国立情報学研究所 学術認証フェデレーション GakuNin
https://www.gakunin.jp/
事例2:Desjardins Group(カナダの大手金融グループ)
- テーマ
45,000人を超える従業員のためのセキュアなSSO基盤 - 概要
カナダを拠点とする大手金融協同組合であるDesjardins Groupは、45,000人以上の従業員とエージェントに対し、オンプレミスとクラウドのハイブリッド環境にまたがる多数のアプリケーションへのアクセスを提供する必要がありました。
同社はADFSを導入し、ID管理と認証のハブとして活用。これにより、ユーザーは一度のログインで必要なアプリケーションへ安全にアクセスできるようになり、セキュリティの強化とヘルプデスクへの問い合わせ削減を同時に実現しました。
事例3:大手自動車部品メーカー(ソリトンシステムズ連携事例)
- テーマ
ADFSとICカード認証を連携させたMicrosoft 365のセキュリティ強化 - 概要
ある大手自動車部品メーカーでは、Microsoft 365の利用拡大に伴い、ID・パスワードだけの認証では不十分だと判断し、セキュリティ強化を検討していました。
そこで、ADFSとソリトンシステムズが提供するICカード認証ソリューション「SmartOn」を連携。
ユーザーがMicrosoft 365にアクセスするとADFSにリダイレクトされ、そこでICカードによる物理デバイス認証が追加で要求される仕組みを構築しました。
これにより、なりすましなどの不正アクセスリスクを大幅に低減し、ゼロトラスト時代に求められる強固な多要素認証を実現しています。
参考文献:ソリトンシステムズ 導入事例
https://www.soliton.co.jp/
実践的な活用シナリオ
シナリオ1: Microsoft 365とのハイブリッド認証
最も一般的な活用例です。
ADFSをIdPとすることで、社内ADのID/パスワードでMicrosoft 365にサインインできます。
これにより、オンプレミスで適用しているパスワードポリシーやアカウントロックアウトポリシーをクラウドサービスにも一貫して適用可能です。
シナリオ2: 各種SaaSとのSSO連携
Salesforce、Box、Slackなど、多くのSaaSはSAML認証に対応しています。
ADFSをIdPとして連携させることで、これらのサービスへのSSOを実現し、ID管理を一元化します。
シナリオ3: BtoB(企業間連携)での認証基盤
取引先やパートナー企業向けに提供するポータルサイトの認証にADFSを利用するケースです。
各取引先が自社で運用するIdP(ADFSやAzure ADなど)とフェデレーションを組むことで、取引先のユーザーは自社のIDでポータルにログインでき、セキュアで効率的な企業間連携が実現します。
シナリオ4: オンプレミスWebアプリのSSO統合ハブ
社内に点在する複数のレガシーなWebアプリケーションの認証をADFSに集約する活用方法です。
WAPと連携することで、これらのアプリケーションへのセキュアなリモートアクセスも同時に提供できます。
7. まとめ
ADFSの現在地と強み
本記事では、Active Directory Federation Services(ADFS)について、その仕組みから導入、活用方法、そして他のソリューションとの比較までを解説しました。
ADFSは、オンプレミスのActive Directoryという既存資産を最大限に活用し、セキュアなシングルサインオン環境を構築するための、今なお強力なソリューションです。
特に、複雑な認証要件や、認証情報をクラウドに置けないといった制約がある環境において、その価値を最大限に発揮します。
将来を見据えたID基盤戦略の重要性
一方で、世の中は「ゼロトラスト」という新たなセキュリティモデルへと移行しつつあります。
あらゆるアクセスを信頼せず、都度検証するというゼロトラストの考え方において、ユーザーやデバイスを認証・認可するID基盤の役割はますます重要になっています。
ADFSは、クラウドへの完全移行を目指す企業にとっては過渡期的なソリューションと位置づけられるかもしれません。
しかし、オンプレミスとクラウドが共存するハイブリッドな環境は今後も長く続くと考えられ、その橋渡し役としてADFSが担う役割は依然として大きいと言えるでしょう。
これからの認証基盤を考える上では、ADFSという選択肢に固執するのではなく、Azure ADをはじめとするIDaaSの利点を深く理解し、自社のビジネス要件や将来のIT戦略に合わせて、ADFSとの併用や段階的な移行といったシナリオを戦略的に描くことが求められます。