【第6回】M365 (Entra ID) とADFSのフェデレーション信頼の確立とディレクトリ同期

本連載ではこれまで、オンプレミス環境における認証の源泉である「ADDS」、SAMLトークンを発行する「ADFS」、インターネットの脅威から認証基盤を守る防波堤「WAP」、そしてそれらのトラフィックを捌くAlmaLinux 9の「LVSロードバランサー」を構築してきました。これらの一連のコンポーネントが組み合わさることで、堅牢なオンプレミス認証基盤の「器」が完成しています。

しかし、現状ではオンプレミス側の準備が整っただけであり、クラウド側である「Microsoft 365 (Entra ID)」は社内のADのことを一切知りません。真のシングルサインオン（SSO）とハイブリッドアイデンティティを実現するためには、オンプレミスADのユーザー情報をクラウドへ安全に同期し、さらにクラウドに対して「認証は社内のADFSに任せなさい」というフェデレーション（信頼関係）を確立する必要があります。

連載第6回となる今回は、認証基盤構築のクライマックスとも言える「Microsoft Entra Connect（旧Azure AD Connect）」を用いたディレクトリ同期のメカニズムと、PowerShellを駆使したM365フェデレーションドメインの構築手順を解説します。Linuxエンジニアが苦手意識を持ちやすい「クラウドとオンプレの同期アーキテクチャ」について、プロトコルやデータ構造のレベルまで踏み込んで圧倒的な情報密度で解き明かします。

---

1. M365とオンプレミスADの同期アーキテクチャ

M365（Entra ID）とオンプレミスADを連携させるための要となるのが「Microsoft Entra Connect（旧称：Azure AD Connect）」です。Linuxの rsync コマンドやLDAPのレプリケーション機構に似ていますが、その内部ははるかに高度なメタデータ同期エンジン（Microsoft Identity Managerの系譜）で構成されています。

1-1. Microsoft Entra Connectの役割と内部構造（メタバース）

Entra Connectは、オンプレミスAD（ADDS）からユーザー、グループ、連絡先などのオブジェクト情報を読み取り、M365のクラウドディレクトリ（Entra ID）へ一方向に同期（書き込み）を行います（※デバイス情報や特定のパスワードリセット結果などをオンプレに書き戻す「ライトバック」機能もあります）。

この同期エンジンの内部には、「メタバース（Metaverse）」と呼ばれる仮想的な統合データベースが存在します。処理の流れは以下の3ステップに分かれます。

1. インポート（Import）： オンプレミスADのドメインコントローラーから、コネクタスペース（一時バッファ）へデータを読み込む。
2. 同期（Synchronization）： コネクタスペースのデータをメタバース（統合データベース）にマッピングし、データの変換やフィルタリングルール（同期ルール）を適用する。
3. エクスポート（Export）： メタバースで処理された最終的なデータを、クラウド上のEntra IDへAPI経由で書き込む（POSTする）。

この3つのプロセス（Import -> Sync -> Export）がデフォルトで30分ごとに実行されることで、社内で新入社員のアカウントを作成したり、退職者のアカウントを無効化したりした結果が、自動的にM365のライセンス管理やアクセス権限に反映されるのです。

1-2. 同期における「ソースアンカー（Source Anchor）」の重要性

オンプレミスADの「山田太郎（taro@linuxkoubou.local）」と、クラウド上の「山田太郎（taro@linuxkoubou.com）」が同一人物であることを、同期エンジンはどうやって判定しているのでしょうか？メールアドレスやUPN（User Principal Name）で判定していると思われがちですが、実は違います。これらはユーザーの異動や結婚によって変更される可能性があるため、キーとしては不適格です。

ここで登場するのが「ソースアンカー（Source Anchor）」です。
ソースアンカーとは、オブジェクトの一生を通じて絶対に変わらない不変のID（ImmutableId）のことです。従来はオンプレミスADの ObjectGUID（AD内でオブジェクトが作成された瞬間に付与される一意の128ビット値）が使われていましたが、現在Microsoftのベストプラクティスでは mS-DS-ConsistencyGuid という属性をソースアンカーとして使用することが推奨されています。この属性を使うことで、フォレスト間のユーザー移行などが行われた際にも、意図的にアンカー値を引き継がせることが可能になり、クラウド上のアカウントが別人とみなされて削除される（オーファンになる）リスクを回避できます。

1-3. セキュリティとトラフィックを考慮したOU（組織単位）フィルタリング

Linuxエンジニアがよく見落とすのが、同期対象の絞り込みです。ADDSの中には、Administratorなどの特権アカウントや、サービス起動用のシステムアカウント（前回作成したgMSAなど）が多数存在します。これらを無差別にM365へ同期することは、セキュリティ上のリスク（クラウドから特権アカウントを狙われるリスク）を増大させます。

Entra Connectの設計では、必ず「M365を利用するユーザーだけを格納する特定のOU（Organizational Unit：組織単位）」を作成し、そのOUだけを同期対象としてフィルタリングする設定（OUフィルタリング）を行うのがエンタープライズの鉄則です。これにより、無駄なAPIトラフィックを削減し、クラウドのディレクトリをクリーンに保つことができます。

2. Entra Connectのインストールと高度な同期設計

それでは、具体的にEntra Connectサーバーを構築します。Entra Connectはドメインコントローラーに同居させることも可能ですが、パフォーマンスとセキュリティの観点から、専用のメンバーサーバー（Windows Server 2025）を用意するのがベストプラクティスです。

2-1. 同期サーバーの要件とサービスアカウント（gMSA）の準備

Entra Connectも、ADFSと同様にサービスを稼働させるためのアカウントが必要です。セキュリティを高めるため、ここでもgMSA（グループ管理サービスアカウント）を使用することが推奨されます。

事前にドメインコントローラー側で、Entra Connectサーバー用のgMSAを作成しておきます。

# ドメインコントローラー（DC01）のPowerShellで実行
# Entra Connectサーバー用のセキュリティグループを作成
New-ADGroup -Name "EntraConnect_Servers" -GroupCategory Security -GroupScope Global
Add-ADGroupMember -Identity "EntraConnect_Servers" -Members "AADC01$"

# 同期サービス用のgMSAアカウントを作成
New-ADServiceAccount -Name "gmsa_adsync" -DNSHostName "aadc01.linuxkoubou.local" -PrincipalsAllowedToRetrieveManagedPassword "EntraConnect_Servers"

2-2. パスワードハッシュ同期（PHS）をフェデレーション環境でも併用する理由

Entra Connectのインストーラー（ウィザード）を起動すると、認証方式を選択する画面が表示されます。本連載では「ADFSとのフェデレーション」を構築しますが、この時、ウィザード内で「パスワードハッシュの同期（Password Hash Synchronization: PHS）」オプションに必ずチェックを入れておくことを強く推奨します。

同期されるパスワードハッシュは、オンプレミスADのハッシュ（MD4/NTLM）をそのまま送るのではなく、同期エンジン側でさらに1000回のPBKDF2（HMAC-SHA256）ストレッチング処理を行い、ソルトを付与した極めて強固な暗号学的ハッシュとしてクラウドへ送信されます。そのため、パスワードの平文が漏洩するリスクは極めて低く設計されています。

2-3. PowerShellによる同期スケジュールの制御と手動キック

Entra Connectの同期サイクルはデフォルトで「30分に1回（Delta Sync：差分同期）」です。しかし、インフラエンジニアがユーザーを追加し、「今すぐクラウドでテストしたい」という場合には30分も待っていられません。

同期を手動でキックするには、Entra Connectサーバー上でPowerShellモジュールをロードし、以下のコマンドを実行します。Linuxの cron を手動で実行したり、systemctl restart する感覚に近い操作です。

# Entra Connectサーバー（AADC01）のPowerShellを管理者権限で実行

# 同期モジュールのインポート
Import-Module ADSync

# 現在の同期設定（スケジュール）を確認
Get-ADSyncScheduler

# 差分同期（Delta Sync）を手動で即時開始
Start-ADSyncSyncCycle -PolicyType Delta

# 完全同期（Initial Sync：全データを舐め直す。構成変更時などに使用）を開始
Start-ADSyncSyncCycle -PolicyType Initial

同期の進捗やエラー（例：UPNの重複エラーなど）は、Windowsの「Synchronization Service Manager」というGUIツールから詳細なログとして確認できます。このツールの見方は、ハイブリッド認証を運用するSREにとって必須のスキルとなります。

3. ADFSとM365間のフェデレーション信頼（Trust）の確立

ディレクトリの同期が完了し、M365（Entra ID）のポータル画面に社内のユーザーが表示されるようになりました。しかし、この時点ではまだ認証はクラウド側（マネージド認証）で行われています。
いよいよ、M365のドメインを「フェデレーション（Federated）」に変更し、認証の主導権をオンプレミスのADFSに引き渡します。

3-1. MSOnline / Microsoft Graph PowerShellモジュールの導入

M365のテナント設定を変更するためには、特別なPowerShellモジュールが必要です。従来は MSOnline モジュールが使われていましたが、現在は Microsoft Graph PowerShell への移行が進んでいます。ここではハイブリッド設定において実績のあるレガシーモジュールと新しいアプローチの両方を想定しますが、フェデレーションの切り替えには古くから使われている MSOnline (または AzureAD) コマンドレットが確実です。

# ADFSサーバー（ADFS01）のPowerShellで実行
# MSOnlineモジュールのインストール（初回のみ）
Install-Module -Name MSOnline -Force

# M365（Entra ID）のグローバル管理者権限でクラウドに接続
Connect-MsolService

3-2. パブリックドメインの追加とフェデレーションへの変換

M365テナントに会社のパブリックドメイン（例：linuxkoubou.com）をカスタムドメインとして登録し、DNSのTXTレコード等で所有権の確認を済ませておきます。

その後、ADFSサーバー上で以下のコマンドを実行し、ドメインの認証方式を「マネージド（Managed）」から「フェデレーション（Federated）」へ変換します。このコマンドを実行した瞬間から、該当ドメインを持つ全ユーザーの認証がADFSへリダイレクトされるようになるため、メンテナンスウィンドウ（深夜帯など）に実行することを強く推奨します。

# ドメインの認証方式をフェデレーションに変換し、現在のADFSファームと紐付ける
# （※ADFSサーバー上で実行することで、ADFSの各種エンドポイント情報や証明書が自動的にクラウドへ送信されます）
Convert-MsolDomainToFederated -DomainName "linuxkoubou.com"

もしEntra Connectの機能を使って設定を行いたい場合は、Entra Connectのウィザードから「ユーザー サインインの変更」を選択し、「AD FS とのフェデレーション」を選ぶことでも同様の設定を安全に行うことができます。

3-3. フェデレーション設定の検証とパラメータ解説

フェデレーション化が成功したかどうか、M365側にどのような情報が登録されたかを確認します。

# フェデレーションドメインの設定状況を確認
Get-MsolDomainFederationSettings -DomainName "linuxkoubou.com"

このコマンドの出力には、Linuxエンジニアも注目すべき重要なパラメータが含まれています。

• ActiveLogOnUri: レガシークライアント（Office 2013等）がWS-Trustプロトコルで認証を行うためのエンドポイント。
• PassiveLogOnUri: ブラウザベース（Webアプリ）の認証時に、ユーザーがリダイレクトされるSAML/WS-Fedエンドポイント（例：https://sts.linuxkoubou.com/adfs/ls/）。
• LogOffUri: ユーザーがサインアウトした際に、ADFSのセッションも破棄するためのエンドポイント。
• TokenSigningCertificate: M365がSAMLトークンのデジタル署名を検証するために保持している、ADFS側の公開鍵情報（Base64文字列）。

4. M365へのログインフロー解析（Linuxエンジニア視点）

フェデレーションが確立したら、実際にクライアントPCからブラウザでM365ポータル（https://portal.office.com）にアクセスし、背後で何が起きているか（パケットフロー）を解析します。

4-1. Home Realm Discovery (HRD) によるリダイレクトの挙動

ユーザーがブラウザでログイン画面を開き、「taro@linuxkoubou.com」と入力してEnterを押した瞬間、M365（Entra ID）の認証エンドポイントは「Home Realm Discovery (HRD)」というプロセスを実行します。
M365は入力されたドメイン名（@linuxkoubou.com）を見て、「あ、このドメインはフェデレーション設定（PassiveLogOnUri）が登録されているな」と判断し、HTTP 302リダイレクトを返します。
これにより、ブラウザは自動的に https://sts.linuxkoubou.com/adfs/ls/?SAMLRequest=... というWAPのVIP（第5回で構築したAlmaLinux 9 LVS）へと飛んでいきます。

4-2. SAML/WS-Fedトークンのキャプチャとデコード検証

LVSで負荷分散され、WAPを通過してADFSへ到達した認証リクエストに対し、ユーザーはADFSのログイン画面（またはWindows統合認証によるサイレントログイン）で認証を行います。成功すると、ADFSはM365へ戻るためのHTTP POSTフォーム（SAML Assertionを含む）をブラウザに返します。

インフラエンジニアは、ブラウザのF12開発者ツール（Networkタブ）でこの POST リクエストをキャプチャし、SAMLレスポンスのペイロード（Base64）をデコードツール（SAML Tracer拡張機能など）で読み解く能力が必要です。

# SAML Assertion内のクレーム（Claims）の例（XML抜粋）
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn">
    <AttributeValue>taro@linuxkoubou.com</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID">
    <AttributeValue>v+A2B3C4D5E6F7G8H9I0Jw==</AttributeValue>
</Attribute>

ここで、ADFSが発行したトークン内の ImmutableID（先述のソースアンカー）が、クラウド上のユーザー情報と完全に一致して初めて、M365のダッシュボードが開きます。一致しない場合は「対象のプリンシパルが見つかりません」といったエラーが発生します。

4-3. トークン署名証明書の自動更新（AutoCertificateRollover）対策

第3回で「トークン署名証明書はADFSが自動で更新する」と解説しました。もしADFSが新しい証明書を生成して署名を変更したのに、M365側が古い公開鍵（TokenSigningCertificate）を持ったままだと、署名の検証（Signature Validation）に失敗し、全社的な認証ダウン障害を引き起こします。

これを防ぐため、M365フェデレーション環境では、Entra Connectの機能を用いて「証明書の自動同期」を有効にしておくか、あるいはPowerShellスクリプトを用いて定期的にクラウド側の設定を更新する運用パイプラインを組むことが必須となります。

# ADFSサーバー側で手動でクラウド側の証明書情報を最新化するコマンド（障害時の復旧コマンドとして必須）
Update-MSOLFederatedDomain -DomainName "linuxkoubou.com" -SupportMultipleDomain

5. 第6回の総まとめと次回の予告

本記事では、M365ハイブリッド認証の要となる「Microsoft Entra Connect」を用いたディレクトリ同期のアーキテクチャ（メタバース、ソースアンカーの重要性）と、PowerShellを用いたM365テナントのフェデレーション（信頼関係）の確立プロセスを詳細に解説しました。

Linuxエンジニアにとって「Windowsとクラウドの同期」はブラックボックスに見えがちですが、その裏側で動いているのはLDAPの属性同期であり、HTTP 302リダイレクトであり、Base64エンコードされたXML（SAML）のPOST送信です。これらのプロトコルの基本原理を理解していれば、パケットキャプチャやブラウザのデバッグツールを用いて、いかなる認証トラブルも論理的に解決することが可能です。

次回の【第7回】Linuxエンジニア視点でのパケットフロー解析とトラブルシューティングでは、これまで構築してきた認証基盤（ADFS、WAP、AlmaLinux 9 LVS、M365）で障害が発生したというシナリオを用意し、Wireshark/tcpdumpを用いたパケットフローの解析、LVSのセッション追跡、およびADFSのデバッグログを用いた「プロのトラブルシューティング手法（障害切り分け）」を徹底的に掘り下げます。お楽しみに！