【第5回】Entra ID Connectを用いたハイブリッドアイデンティティとパスワードハッシュ同期(PHS)の実装

前回の第4回では、オンプレミス環境における最強の高可用性IdP基盤として、LinuxのIPVS（LVS）とWindows ServerのADFS/WAPを組み合わせたLayer4（DR方式）のロードバランシングアーキテクチャを構築しました。これにより、社内ネットワークにおける認証リクエストを捌く堅牢な「頭脳と盾」が完成しました。

しかし、認証基盤がどれほど強固でも、クラウド側（M365/Entra ID）に「誰がアクセスしてくるのか」というユーザー情報（アイデンティティ）が存在しなければ、認証プロセス自体を開始することができません。
連載第5回となる今回は、オンプレミスの社内ネットワークの奥深くにあるADDS（Active Directory Domain Services）のユーザーデータベースを、クラウドのEntra IDへ安全かつ継続的に同期する架け橋、「Entra ID Connect (旧 Azure AD Connect)」のアーキテクチャと構築手法を徹底解説します。

Linuxエンジニアにとって馴染み深い /etc/passwd や LDAP のプロビジョニング概念と照らし合わせながら、Entra ID Connectの内部で動くメタバース（Metaverse）の仕組みや、セキュリティの要となる「パスワードハッシュ同期（PHS）」の暗号化メカニズム、そしてステージングモードを用いたエンタープライズ品質の高可用性設計まで、プロの視点で深く解剖していきます。

---

1. プロビジョニングと認証の分離：ハイブリッドアイデンティティの本質

エンタープライズのアイデンティティ管理において、「プロビジョニング（Identity Provisioning）」と「認証（Authentication）」は完全に異なるレイヤーのプロセスです。

• プロビジョニング（Entra ID Connectの役割）： 社内のADDS上にユーザー（例：kou-kun）が作成されたり、部署移動で属性情報（OUや役職名）が変更された際、その情報をクラウド（Entra ID）へコピーし、「クラウド上の名簿」を常に最新状態に保つ作業です。Linuxにおける useradd や usermod を自動化してリモートサーバーに反映させるデーモンに相当します。
• 認証（ADFSの役割）： クラウド上に実体があるユーザーがM365にログインしようとした際、「本当にそのユーザー本人か」をパスワードや証明書を用いて検証し、許可証（SAMLトークン）を発行する作業です。Linuxにおける PAM (Pluggable Authentication Modules) の処理に相当します。

つまり、我々が目指す「ハイブリッドアイデンティティ」とは、社内のADDSを唯一のマスターデータ（Source of Truth）とし、Entra ID Connectがクラウドへ名簿を同期（プロビジョニング）し、ログイン認証のトランザクションはすべて社内のADFSへリダイレクトして処理させる、という強固な三位一体のアーキテクチャなのです。

2. 同期エンジンの内部構造：コネクタスペースとメタバース

Entra ID Connectは、単なる「LDAP情報のコピーツール」ではありません。バックエンドに「SQL Server Express LocalDB」を内包した、極めて高度なデータ変換エンジン（Microsoft Identity Managerの技術がベース）です。インフラエンジニアとして、データがどのように流れていくのか、その内部アーキテクチャ（メタバース空間）を理解しておく必要があります。

1. インバウンド同期 (ADDS → CS)： 社内ADDSからデータを読み取り、Entra ID Connect内部の「ADコネクタスペース（CS）」という一時領域にキャッシュします。
2. プロジェクションとジョイン (CS → Metaverse)： コネクタスペースのデータを、中央データベースである「メタバース (MV)」に投影します。ここで「同期ルール」と呼ばれるフィルタリングや属性の変換（例：sAMAccountName を userPrincipalName にマッピングする等）が実行されます。
3. アウトバウンド同期 (Metaverse → クラウドCS)： メタバースで加工・統合された最終的なデータを「Entra IDコネクタスペース」へ書き出します。
4. エクスポート (クラウドCS → Entra ID)： 最後に、Entra IDのGraph APIを叩いて、クラウド上のユーザー情報を実際に更新（Export）します。

このプロセスは、デフォルトで30分間隔（Delta Sync：差分同期）で自動実行されます。万が一同期エラーが発生した際は、この「4つの空間のどこでデータが詰まっているか」を切り分けるのがプロのトラブルシューティングです。

3. PHS（パスワードハッシュ同期）の高度な暗号化メカニズム

M365環境において、認証はADFS（フェデレーション）で行うため、クラウド側（Entra ID）にパスワードを持たせる必要は本来ありません。
しかし、Microsoftはフェデレーション環境であっても「パスワードハッシュ同期（PHS：Password Hash Sync）」を併用することを強く推奨しています。

なぜフェデレーション環境にPHSが必要なのか？（Disaster Recovery）

もし社内のADFSファームやLVSロードバランサーが大規模なネットワーク障害やDDoS攻撃で完全にダウンしてしまった場合、全社員のM365へのログインが停止します。
しかし、裏側でPHSを有効にしておけば、クラウドのEntra IDの管理画面から「フェデレーションからクラウド認証（マネージド認証）へ切り替える」という緊急コマンドを叩くだけで、数分以内にクラウド側で認証を代行させ、業務を即座に復旧させる（DR：ディザスタリカバリ）ことが可能になるのです。

PHSは「パスワードを平文で送る」のではない

セキュリティ要件が厳しい企業では、「クラウドに社員のパスワードを送るなんて危険だ」という指摘が必ず上がります。インフラエンジニアはこの懸念を暗号化アルゴリズムの論理で論破しなければなりません。PHSの仕組みは以下の通り、極めて堅牢です。

1. ADDS上のハッシュ： WindowsのADDSは、パスワードをMD4アルゴリズムでハッシュ化して保存しています（平文は保持していません）。
2. Entra ID Connectの抽出： 同期エンジンは、この「MD4ハッシュ」を抽出します。
3. 強力な再ハッシュ（PBKDF2）： 抽出したMD4ハッシュに対して、さらに HMAC-SHA256 アルゴリズムを用いて、ランダムなソルト（Salt）を付与し、1,000回の反復ハッシュ処理 (PBKDF2) を実行します。
4. クラウドへの送信と保存： TLS 1.2以上の暗号化通信でEntra IDへ送信され、クラウド上にはこの「ハッシュのハッシュ」のみが保存されます。

4. PowerShellを用いたEntra ID Connectの運用・強制同期コマンド

Entra ID ConnectはWindows Serverにインストールしますが、日常の運用においてGUIを開くことはほぼありません。すべてPowerShellモジュール ADSync を用いて操作します。

同期スケジュールの確認と強制同期の実行

人事異動などでADDS上のユーザー属性（役職や所属OUなど）を変更した際、デフォルトの30分を待たずに即座にクラウドへ同期（差分同期）させるため、インフラエンジニアは以下のコマンドを頻繁に使用します。

# ADSyncモジュールのインポート（初回のみ必要）
Import-Module ADSync

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

# 【通常用】差分同期（Delta Sync）の強制実行
# 変更があったオブジェクトのみを同期するため、数秒〜数十秒で完了します。
Start-ADSyncSyncCycle -PolicyType Delta

# 【障害復旧・構成変更時用】完全同期（Initial Sync）の強制実行
# メタバースの全ルールを再評価し、すべてのオブジェクトを再同期します。組織規模によっては数時間かかります。
Start-ADSyncSyncCycle -PolicyType Initial

OU（組織単位）フィルタリングによる同期対象の制御

セキュリティの鉄則として、ADDS上の「Domain Admins」などの特権アカウントや、サービスアカウント（gMSAなど）は絶対にクラウドへ同期してはいけません。クラウド側が侵害された際のリスクを最小化するためです。
Entra ID Connectの構築ウィザードで「OUベースのフィルタリング」を設定し、同期専用のOU（例：OU=CloudUsers,DC=linuxkoubou,DC=local）配下のオブジェクトのみを同期するよう、厳格な境界線を設けるのがエンタープライズの基本です。

5. ステージングモードによる高可用性（Active/Standby）設計

前回の第4回では、LVS（Layer 4ロードバランサー）を用いてADFSを高可用性化しました。では、Entra ID Connectも複数台立ててLVSで負荷分散すればよいのでしょうか？
答えは「絶対にNG」です。

Entra ID Connectは「データベース同期エンジン」です。もし2台のサーバーが同時に稼働してクラウドへデータを書き込もうとすると、競合（スプリットブレイン）が発生し、メタバースのデータが致命的に破損します。LinuxのHAクラスタ（Pacemaker + Corosync + DRBD）における「デュアルプライマリの恐怖」と全く同じです。

ステージングモード（Standbyサーバー）の構築

この問題を解決するため、Entra ID Connectには「ステージングモード（Staging Mode）」という機能が備わっています。

• プライマリサーバー（Active）： データの読み取り、メタバースでの処理、そしてEntra IDへの「書き込み（Export）」をすべて行います。
• ステージングサーバー（Standby）： データの読み取りとメタバースでの処理までは行いますが、最後のEntra IDへの「書き込み（Export）」だけを実行せずに破棄します。

これにより、ステージングサーバーは常に「本番と同じデータ状態」を維持したまま、安全に待機（コールドスタンバイ）することができます。

# ステージングモードの状態確認（PowerShell）
# Trueが返ればステージングモード（Standby）、Falseならプライマリ（Active）です。
Get-ADSyncGlobalSettingsParameter | Where-Object {$_.Name -eq "StagingMode"} | Select-Object Value

フェールオーバーの手順：
プライマリサーバーがハードウェア障害等でダウンした場合、インフラエンジニアは手動でスタンバイサーバーにログインし、Entra ID Connectの構成ウィザードから「ステージングモードを無効化する」チェックを外して保存します。これだけで、数分以内にスタンバイ機がプライマリ機に昇格し、同期がシームレスに再開されます。

6. 生成AIを活用した同期ルールの正規表現・スクリプト解析

Entra ID Connectを運用していくと、「特定の属性（例：department）に『Test』という文字列が含まれているユーザーだけは、クラウドに同期させない」といった複雑なカスタム同期ルールを作成する要件が必ず発生します。
この同期ルールは独自の宣言型プロビジョニング関数（関数名が難解なスクリプト言語）で記述する必要があり、インフラエンジニアを悩ませる要因の一つです。

ここで、ChatGPT（GPT-4o）やClaude 3.5 Sonnetなどの強力な生成AIが真価を発揮します。Microsoft独自の同期ルールの構文を深く学習しているAIに、以下のようなプロンプトを投げることで、正確な式を一瞬で生成できます。

【効果的なプロンプト例（生成AI向け）】
「Entra ID Connectのカスタム同期ルールを作成しています。オンプレミスADの extensionAttribute1 の値が『NoSync』であるか、または department の値が『Guest』から始まる場合のみ、メタバースの cloudFiltered 属性に True をセットしてクラウド同期を除外する宣言型プロビジョニング関数（式）を記述してください。正規表現や IIF 関数を用いて、最もパフォーマンスの良いコードにしてください。」

生成AIを活用することで、ベンダー固有のニッチなスクリプト言語の学習コストを削減し、我々Linuxエンジニアはアーキテクチャ全体の可用性設計やトラブルシューティングといった「より高度なレイヤー」に集中することができます。

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

本記事では、オンプレミスとクラウドをアイデンティティレベルで結びつける「Entra ID Connect」の深い技術要素を解説しました。

• プロビジョニングの独立性： 認証を行うADFSとは異なり、Entra ID Connectはクラウド上に「アイデンティティの実体（名簿）」を継続的に供給するメタバースエンジンである。
• PHS（パスワードハッシュ同期）の安全性とDR： ADDSのMD4ハッシュをさらに1,000回再ハッシュ（PBKDF2）して同期するため極めて安全であり、ADFSダウン時の最強のディザスタリカバリ対策となる。
• 高可用性設計の使い分け： データベース同期エンジンであるEntra ID Connectは、LVSによる負荷分散ではなく「ステージングモード（Active/Standby）」によってスプリットブレインを防ぎつつ冗長化を行う。

ここまでの5回の連載で、ADDS、ADFS、WAP、LVS、そしてEntra ID Connectという、M365ハイブリッド認証を構成する「すべてのコンポーネントの設計と構築」が完了しました。
次回の【第6回】では、この複雑に絡み合ったネットワークインフラにおいて、「万が一認証エラーが発生した際、どのように原因を特定するか」にフォーカスします。我々Linuxエンジニアの伝家の宝刀 tcpdump と Wireshark を駆使し、TLSハンドシェイクからSAMLトークンのパケットレベルでの解析、そしてWindowsイベントログとの相関分析を用いた、プロのトラブルシューティング手法を大公開します！