【Windows Server上級 第9回】ID連携の架け橋。AD FS (Federation Services) とSAML/OIDC連携

「またパスワード忘れたんですか？」その問い合わせ、ゼロにできます。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、バックアップと災害復旧（WSB/VSS）について学びました。
システムを守る準備ができたら、次はシステムを「外の世界」と繋げていきましょう。

今や企業システムは、社内サーバーだけで完結しません。
AWS、Salesforce、Microsoft 365、Slack……業務で使うクラウドサービス（SaaS）は増える一方です。
エンジニアとして一番面倒なこと、それは「サービスごとのID管理」ではないでしょうか？

本記事では、SAML/OIDCといった認証プロトコルの基礎、AD FSの構築手順、外部公開用のWAPサーバーの配置、そしてAWS等を例にした実際の連携設定までを徹底解説します。

---

第1章：フェデレーションとは？ パスワードを渡さない認証

従来の「ID連携」といえば、LDAP同期などで「パスワードハッシュをコピーする」方法が主流でした。
しかし、クラウドサービス側に社内のパスワード情報を渡すのはリスクがあります。

チケット（トークン）ベースの認証

フェデレーション（Federation）では、以下のような流れでログインが行われます。

1. ユーザーがクラウドサービス（例：AWS）にアクセスする。
2. AWSは「ログインしてないね。うちが信頼しているIdP（Identity Provider = AD FS）で認証してきて」とリダイレクトする。
3. ユーザーはAD FSの画面で、社内のADパスワードを入力してログインする。
4. AD FSはADに問い合わせ、認証OKなら「トークン（証明書で署名された入館証）」を発行する。
5. ユーザーはそのトークンを持ってAWSに戻る。
6. AWSはトークンの署名を検証し、「AD FSが本人だと言っているなら信じよう」とログインを許可する。

AWS側にはパスワードは一切流れません。
「信頼関係（Trust）」だけで成り立つ、非常にセキュアな仕組みです。

---

第2章：SAML vs OIDC。プロトコルの違いを理解する

AD FSは主に2つのプロトコルをサポートしています。
連携先（SP: Service Provider）がどちらに対応しているかによって使い分けます。

SAML (Security Assertion Markup Language)

• 形式： XMLベース。重厚長大。
• 用途： 企業の業務アプリ、Salesforce、AWS、ZoomなどのエンタープライズSaaS。
• 特徴： 歴史が長く、機能が豊富。設定が少し複雑（メタデータXMLの交換が必要）。

OIDC (OpenID Connect) / OAuth 2.0

• 形式： JSON/RESTベース。モダンで軽量。
• 用途： スマホアプリ、モダンなWebアプリ、API連携。
• 特徴： 実装が容易。開発者（プログラマー）に好まれる。AD FS 2016以降で本格サポート。

---

第3章：AD FSの構築。証明書が全ての鍵を握る

AD FSの構築自体は難しくありませんが、事前準備（特に証明書）が重要です。

必要な証明書

1. SSL証明書（サービス通信証明書）： ログイン画面（HTTPS）用。公的CA（DigiCertなど）または社内CA（AD CS）から発行されたもの。
   ※クライアントPCが信頼している必要があります。
2. トークン署名証明書： トークンにハンコを押すための証明書。通常は自己署名で自動生成されます。
3. トークン暗号化解除証明書： トークンを暗号化する場合に使用。

構築手順（PowerShell）

AD FS用のサービスアカウントとして、gMSA（グループ管理サービスアカウント）を作成するのがベストプラクティスです。
パスワード管理が不要になり、運用が楽になります。

# 1. KDSルートキーの作成（初回のみ）
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

# 2. gMSAの作成
New-ADServiceAccount -Name "gmsa_adfs" -DNSHostName "adfs.corp.example.com" -ManagedPasswordIntervalInDays 30

# 3. AD FS役割のインストール
Install-WindowsFeature ADFS-Federation -IncludeManagementTools

# 4. AD FSファームの構成
# 事前にSSL証明書（cert.pfx）をインポートし、Thumbprint（拇印）を取得しておくこと
$thumbprint = "A1B2C3D4..." 
Install-AdfsFarm `
    -CertificateThumbprint $thumbprint `
    -FederationServiceDisplayName "My Company SSO" `
    -FederationServiceName "adfs.corp.example.com" `
    -GroupServiceAccountIdentifier "CORP\gmsa_adfs$"

構築後、DNSに adfs.corp.example.com のAレコード（AD FSサーバーのIP）を登録するのを忘れずに。

---

第4章：信頼関係の構築（Relying Party Trust）

AD FSとクラウドサービス（SP）を紐付ける設定を「証明書利用者信頼（Relying Party Trust）」と呼びます。
今回はSAML連携の例として解説します。

メタデータの交換

SAML連携はお見合いのようなものです。
お互いのプロフィール（メタデータXML）を交換し合います。

1. SP側（例: AWS）の設定： AD FSのメタデータURL（https://adfs.../FederationMetadata/2007-06/FederationMetadata.xml）を入力するか、XMLファイルをアップロードします。
2. AD FS側の設定： 「証明書利用者信頼の追加」ウィザードで、SPから提供されたメタデータファイルを読み込みます。

手動設定の場合のポイント

メタデータがない場合、以下の項目を手動で設定します。

• 識別子 (Entity ID)： SPを一意に識別するURL（例: urn:amazon:webservices）。
• エンドポイント (ACS URL)： AD FSがトークンをPOSTする先のURL（例: https://signin.aws.amazon.com/saml）。

---

第5章：クレームルールの魔術。属性を変換せよ

ここがAD FS最大の難所です。
ADはユーザー情報を「LDAP属性（sAMAccountName, mail, memberOf）」で持っていますが、クラウドサービス側は「SAMLアサーション（NameID, Role）」を要求します。
この翻訳ルールを定義するのが「要求規則（Claim Rules）」です。

よくある変換パターン

1. メールアドレスを NameID として送る
最も一般的なパターンです。

• 規則テンプレート： LDAP 属性を要求として送信
• 属性ストア： Active Directory
• LDAP属性： E-Mail-Addresses
• 出力方向の要求の種類： Name ID

2. カスタムルール言語による高度な変換

GUIのテンプレートでは対応できない場合、独自の言語で記述します。
例：ADのグループ名 AWS-Admin を、AWSのIAMロールARNに変換して送る。

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-...-1234"]
 => issue(Type = "https://aws.amazon.com/SAML/Attributes/Role", Value = "arn:aws:iam::123456789012:role/Admin,arn:aws:iam::123456789012:saml-provider/ADFS");

Linuxエンジニアなら、この「正規表現のようなロジック」には親近感が湧くかもしれません。
このルールを駆使することで、ADの所属グループに応じて、AWSのAdmin権限やReadOnly権限を動的に割り当てることができます。

---

第6章：WAP (Web Application Proxy) によるインターネット公開

AD FSサーバーはADドメインに参加しているため、通常は社内LAN（イントラネット）に配置されます。
しかし、社員が自宅やカフェからSSOするには、インターネットからAD FSにアクセスできなければなりません。
かといって、ドメインコントローラーと通信する重要なサーバーをDMZに晒すのは危険です。

WAPの役割

そこで登場するのが Web Application Proxy (WAP) です。
これはAD FS専用の「リバースプロキシ」です。

• 配置場所： DMZ（ドメイン参加不要）。
• 役割： インターネットからのHTTPSリクエストを受け取り、社内LANのAD FSへ転送する。
• セキュリティ： AD FSへの事前認証を行い、不正なリクエストを遮断する。

構築手順

1. DMZ上のサーバーに「リモートアクセス」役割をインストール。
2. ウィザードで「Web アプリケーション プロキシ」を選択。
3. バックエンドのAD FSサーバー名と、管理者の資格情報を入力。

これで、インターネット上のクライアント → WAP (DMZ) → AD FS (LAN) → AD (LAN) というセキュアな認証フローが完成します。
Linuxで言うところの Nginx リバースプロキシと同じ構成ですが、AD FSとの連携設定が自動化されている点が強みです。

---

まとめ：IDこそが、新しいセキュリティ境界線

お疲れ様でした！
上級編第9回は、AD FSによるID連携とSSO環境の構築について解説しました。

今回の重要ポイント：

• フェデレーションを使えば、パスワードを渡さずにクラウド連携ができる。
• AD FS構築にはSSL証明書が必須。gMSAを使えば運用が楽になる。
• クレームルールを書けば、ADの属性を自由自在にクラウドへ渡せる。
• インターネット公開時は、必ずWAPをDMZに置いてプロキシさせる。

さて、ID連携で利便性は上がりましたが、サーバー自体のセキュリティはどうでしょうか？
「管理者権限があれば何でもできる」状態は危険です。
特定のアプリしか実行できないようにロックダウンしたり、誰が何をしたか完全に追跡したりする必要があります。

次回、第10回は「セキュリティの硬化。AppLockerと監査ログによる要塞化」です。
ホワイトリスト方式でマルウェアを封殺するAppLockerと、”いつ誰がどのファイルにアクセスしたか” を記録する高度な監査設定について解説します。お楽しみに！