ゼロトラスト時代の「現実的な第一歩」　AD × Azure AD/Entra ID ハイブリッドの設計要点

Ndict
目次

はじめに

この記事は、既に社内にサーバー（オンプレミスの Active Directory, AD）を持っている会社が、
マイクロソフトのクラウド（Microsoft Entra ID, 旧 Azure AD）と安全に連携（ハイブリッド化）するための、「最初の設計図」を解説します。

手順の細部は注釈（公式ドキュメント）に集約し、本文は設計判断と運用の勘所に集中します。

ゼロトラストの要点

Microsoftの公式には以下のように記載があります。

  1. 逐次検証（毎回チェックする）： ユーザー、使っているPC、場所、アクセスの危険度などを、毎回しっかりチェックします。「一度OKしたから、あとはOK」とは考えません。
  2. 最小権限（権限は最小限に）： その人が仕事をする上で「本当に必要な最小限の権限」だけを、「必要な時間だけ」与えます。
  3. 侵害前提（侵入されても大丈夫なように）： 「弊社は大丈夫」ではなく、「すでに攻撃者に入られているかもしれない」という前提で、被害が広がらない仕組みを作ります。

この「ゼロトラスト」を実現する中核が 条件付きアクセス（CA） です。

CA はポリシーエンジンとして、ユーザー・デバイス・場所・アプリ・セッション・リスクのシグナルを見て、許可／ブロック／追加認証（MFA）要求／セッション制限 などを自動判断する「セキュリティの門番」です。

1. サインイン方式の選定

結論：既定は「PHS + シームレスSSO」です。PTAは要件時の例外、AD FSは撤去前提で計画します。

各方式の比較と推奨の理由

方式 概要 推奨度 強み・適する要件 注意点・勘所
PHS
(パスワード ハッシュ同期)		 オンプレ AD のハッシュから、エージェント側で
さらに不可逆なハッシュを生成し、Entra ID に同期。
認証はクラウドで完結。［※1］		 ◎ 既定 構成が簡潔で障害切り分けが容易。
オンプレ AD 停止時もクラウド認証は継続可能（ビジネス継続性）。
Entra ID の新機能（認証強度など）へ即時対応。		 「パスワードそのもの」や「ADのハッシュ」がクラウドに保管されるわけではない、という正しい理解が必要。
シームレスSSO
(単一サインオン)		 PHS または PTA と組み合わせて利用。 ◎ 既定 社内ネットワーク上のドメイン参加端末で、Kerberos を利用し、
ユーザーがパスワードを再入力せずに Entra ID 認証を完了させる。［※2］		 ※SSO（自動サインイン）は社内ネットワーク（AD DS）到達時のみ有効。
社外からでもPHSによる認証自体は可能（パスワード入力が求められる）。［※2］
PTA
(パススルー認証)		 認証要求を Entra ID が受け、
オンプレの認証エージェント経由で AD DS に問い合わせて検証。		 △ 例外 監査要件などで、パスワード検証プロセス自体を
オンプレミスで完結させたい場合に採用。		 エージェントと AD DS への到達性が認証のSPOF（単一障害点）になり得る。
エージェントの冗長化が必須。［※3］
AD FS
(フェデレーション)		 オンプレミスに認証サーバー（AD FS）を構築・維持。
SAML/WS-* 等のクレーム（属性情報）を柔軟に発行可能。		 × 撤去前提 レガシーなSaaS/認証要件が残存する場合の
「延命措置」として。		 運用負荷（サーバー維持、パッチ適用、証明書更新）が極めて高い。
技術的負債の典型。

実務の勘所

  • ・AD FS からの移行：既存 AD FS 環境からは、Staged Rollout（段階的ロールアウト）機能を使用し、ユーザー群を少しずつ PHS+SSO に切り替えます。
    AD FS 依存アプリの洗い出しと Entra ID への移行を並行で進め、最終的な AD FS サーバーの撤去をゴールへ。［※11］
  • ・PTA の可用性：「PTAエージェントの冗長化」は必須ですが、その先の AD DS の可用性も担保されていなければ認証は停止します。
    オンプレ全体の可用性設計が問われる方式です。［※3］

公式推奨

  • ・一般的なシナリオでは PHS を既定のサインイン方式として採用することが推奨されています。[※1]

  • ・Seamless SSO は PHS/PTA と併用してユーザー体験を向上させる設計が推奨されています（企業ネットワーク到達時に自動サインイン）。[※2]

  • ・PTA を選ぶ場合は認証エージェントの冗長化など高可用性設計を必須です。[※3]

2. 同期方式の選定（Connect Sync vs Cloud Sync）

結論：機能要件で Connect Sync が必要になるケースが多いです。Cloud Sync の軽量さを活かし「併用」も現実解です。

Connect Sync（Microsoft Entra Connect）

  • 役割：高機能な「全部入り」同期エンジンです。
  • 強み：複雑な属性フロー（変換ルール）、多様なライトバック（パスワード/グループ/デバイス等）、PHS、PTA、Hybrid Azure AD Join の標準的な構成を担います。
  • 勘所：多くのハイブリッド環境で求められる機能が詰まっており、依然として「主軸」となるケースが多いです。［※11］

Cloud Sync（Microsoft Entra Cloud Sync）

  • 役割：軽量なエージェントベースの同期エンジンです。
  • 強み：構成がシンプルで、多拠点・多フォレスト（特に非接続フォレスト）に強いです。
    PHS とパスワード書き戻し（SSPR writeback）に対応し、グループ書き戻しにも対応しています。デバイス書き戻しは非対応です。（今後は Cloud Kerberos trust の利用が推奨）［※4］
  • 勘所：Hybrid Azure AD Join の構成自体は Connect Sync が担うため、要件に応じて Connect Sync との「併用構成」が有効です。［※11］

最重要：sourceAnchor (ImmutableId) の確定

どちらの方式を選ぶにせよ、オンプレ AD ユーザーと Entra ID ユーザーを紐付ける一意なキー (sourceAnchor) を最初に確定させる必要があります。

Connect Sync の既定は mS-DS-ConsistencyGuidです。

Cloud Sync も mS-DS-ConsistencyGuid を既定で使用し、未設定の場合は objectGUID をフォールバックとして使用します。

ここで選んだ属性と値は、後からの変更が事実上不可能（全ユーザーの再作成が必要）です。

設計の初期段階で、重複や変更可能性のない堅牢な属性を選定・確定することが必須です。［※5］

公式推奨

  • sourceAnchor には mS-DS-ConsistencyGuid を使用します。（Connect/Cloud Sync どちらでも既定）[※5]

  • Cloud Sync でもグループのオンプレ書き戻しが可能です。（要件に応じて Connect との併用を設計）[※4]

 

3. UPN／属性の前処理

結論：「@company.local」はNGです。検証済みドメイン（@company.com）に UPN を統一します。

  • なぜ必要か：Entra ID は、インターネットでルーティング不可能なサフィックス（.local や .internal など）を UPN (ユーザー プリンシパル 名) として扱えません。
  • 対策：オンプレ AD 側で「代替 UPN サフィックス」を追加し、検証済みドメイン（例：company.com）へ 同期前 に全ユーザーの UPN を変更します。
  • 副次的な掃除：proxyAddresses や mail 属性の重複・不整合は同期エラーの主要因。IdFix 等で棚卸しとクレンジングを行います。
  • UPN 変更の影響：UPN を変更すると OneDrive の個人サイト URL が変更され、既存の共有リンクが無効化されます（権限自体は残るが再共有が必要）。［※6］

公式推奨

  • ・同期前に IdFix で UPN/proxyAddresses の重複や不整合を洗い出し・修復してから同期を開始します。[※11]

  • ・UPN 変更は OneDrive の個人サイト URL に影響するため、事前周知と再共有手順を準備します。[※6]

4. 端末参加方式（Join vs Registered）

結論：組織所有の Windows は「Join」、私物端末 (BYOD) は「Registered」と明確に分離します。

Hybrid Azure AD Join (ハイブリッド参加)

  • 対象：既存の AD 参加済み Windows 端末（組織所有）。
  • 目的：AD 参加（GPO適用、社内リソースアクセス）と Entra ID 登録（CAの評価対象）を両立させる「過渡期」の形態です。
  • 構成：Connect Sync のウィザード構成が標準です。AD FS 環境など特定要件下では手動構成も可能です。［※7］［※12］

Entra Join (クラウド参加)

  • 対象：組織所有の新規 Windows 端末。
  • 目的：AD 依存を断ち、Intune (MDM) によるモダン管理へ移行する、ゼロトラスト時代の「本来の姿」です。
  • 勘所：社内リソース（ファイルサーバー等）へのアクセスは Windows Hello for Business Cloud Kerberos Trust 等の仕組みで補完していきます。［※8］

Entra Registered (登録)

  • 対象：私物端末（BYOD） や iOS/Android 端末。
  • 目的：端末を組織の管理下（Join）に置かず 登録のみ とします。
    CA で「準拠」や「ハイブリッド参加」を要求した場合、Registered だけでは条件を満たしません。
    BYOD に限定的アクセス（MAM 等）を許可する場合は、デバイス フィルター（例：device.trustType -eq "AzureADRegistered"）を用いた CA 設計が鍵です。［※9］

公式推奨

  • ・組織所有デバイスは Entra ID（Azure AD）Join を基本とし、クラウド管理（Intune）を前提に設計が推奨されています。[※12]

  • ・BYOD は MAM（アプリ保護）で保護し、CA のデバイス フィルターでアクセス粒度を制御するのが実務的です。[※13][※8]

  • ・社内リソースへのシングルサインオンは WHfB Cloud Kerberos trust を用いる構成を推奨されています。（ハイブリッド要件に適合）[※19]

5. 条件付きアクセス (CA) の最小セット

結論：「Report-only」で影響を可視化し、「管理者保護」から本番適用する。

  • ・Report-only (監視モード) で配備：まずは「もし適用したら、誰が・なぜブロックされるか」を可視化します。古いOS、未対応ブラウザ、レガシー認証の利用を把握します。
  • ・管理ロールの保護 (最優先)：「全体管理者」など特権ロールには フィッシング耐性 MFA（FIDO2, CBA など） を必須化します。
  • ・準拠デバイスの要求：Entra Join もしくは Hybrid Join かつ Intune 等で「準拠」と判定された端末以外を制限します。野良PCを排除します。
  • ・場所・リスクの適用（段階的）：信頼できる場所（オフィスIP）以外に MFA を要求、Identity Protection の「サインインリスク（高）」はブロックなどを段階的に追加します。

公式推奨

  • ・本番適用前に Report-only で影響評価を行い、検証ログに基づいて段階的に有効化します。[※21]

  • ・管理者アカウントには MFA を必須とし、認証強度でフィッシング耐性方式（例：FIDO2/CBA）を要求します。[※10]

  • ・BYOD と社給機はデバイス準拠・信頼区分で分離し、必要に応じてデバイス フィルターで条件分岐します。[※8]

6. 特権アクセス（PIM とブレークグラス）

結論：常時管理者をゼロにし、「PIM」による一時昇格を標準化します。

PIM (Privileged Identity Management)

  • 原則：Just-In-Time (JIT) アクセス。普段は一般権限、必要時のみ申請・承認で 一時的（例：2時間） にロールを有効化します。
  • 目的：特権アカウント侵害リスクの大幅低減。運用を「特権は一時的に借りるもの」へ転換します。

緊急アクセス (ブレークグラス)

  • 目的：CA 設定ミスや PIM 障害で全管理者が締め出された際の「最後の合鍵」です。
  • 構成：クラウド専用（.onmicrosoft.com）の全体管理者アカウントを 2つ以上に用意します。
  • 保護（重要）：これらは万一のため CA 対象外 とする一方、超長・複雑パスワードの厳重保管、サインイン監視、認証方法ポリシーで FIDO2/CBA 以外を可能な限り無効化 を徹底する必要があります。
    加えて、管理ポータル側の 認証強度 や セキュリティ既定値 により MFA が要求され得る点も考慮すべきです。［※10］［※12］

公式推奨

  • ・特権ロールは PIM の JIT（必要時のみ昇格）運用を標準とします。[※15]

  • ・ブレークグラス（緊急アクセス）アカウントを少なくとも 2 つ用意し、強固な認証方法・監査とともに管理します。[※9]

  • ・認証方法ポリシーと認証強度を併用し、SMS/音声等は可能な限り無効化してフィッシング耐性 MFA へ誘導します。[※9][※10]

7. 運用・可視化の最小セット

結論：仕組みは「作って終わり」ではない。ログとリスクのレビューを定常化します。

  • ・サインインログ / CA Insights：「誰が」「どこから」「どのアプリに」「どのCAで」アクセス/失敗したかを日々の確認が重要です。失敗ログは攻撃の予兆や設定ミスの発見に直結します。
  • ・Identity Protection：「危険なユーザー」「危険なサインイン」のアラートを常時監視が必須です。あり得ない移動 (Impossible Travel) や 漏洩資格情報 などの高リスクは即応します。

公式推奨

  • ・Identity Protection を有効化し、リスクベースの自動検知（ユーザー／サインイン リスク）を運用に組み込ます。[※20]

8. オンプレ AD 側のミニマム強化

結論：クラウド（玄関）を固めても、オンプレ（勝手口）が甘ければ侵害されます。

  • ・NTLM の監査と縮退：Pass-the-Hash の温床となる NTLM を監査し、段階的に無効化します。（Kerberos へ移行）
  • ・SMB 署名の有効化：サーバー・クライアント間の SMB 通信の 改ざん を防止します。
  • ・LSA 保護 (LSA Protection)：LSASS からの資格情報抜き取りを困難化します。

公式推奨

  • ・「NTLM の監査と段階的な縮退（Kerberos への移行）」を進めます。[※16]

  • ・SMB 署名を有効化して改ざん耐性を確保します。[※17]

  • ・LSA Protection を有効化し、資格情報の窃取耐性を高めます。[※18]

9. よくある「詰まり」と回避策

  • ・UPN が .local のまま
    症状：サインイン不能、UPN とメール不一致の混乱です。
    回避策：本稿「3. UPN／属性の前処理」を参照します。同期前 の必須作業です。
  • ・ImmutableId (sourceAnchor) の衝突・重複
    症状：テストユーザーと本番同期ユーザーが衝突し「属性値が既に使用されています」で停止します。
    回避策：安易な再同期での解消は禁物です。設計に立ち返り重複排除ロジックを確立します。最悪、クラウド側のユーザー削除と再同期が必要です。
  • ・端末の二重登録 (Registered + Hybrid)
    症状：同一デバイスが「登録済み」と「ハイブリッド参加済み」で二重に見え、CA が意図通り効きません。
    回避策：Hybrid Join 展開前にユーザーが手動で「職場/学校アカウント追加」を行うと発生します。展開前に既存の「登録済み」デバイスをクリーンアップする手順を用意します。

まとめ：設計の要点

  • ・認証は PHS + SSO：クラウド認証に寄せ、可用性と将来性を確保します。AD FS は撤去前提です。
  • ・同期は sourceAnchor が命：後から変えられないキーの選定を最優先します。
  • ・CA は「監視」から：Report-only で影響を把握し、管理者保護 から適用します。
  • ・特権は PIM で「借りる」：常時管理者をゼロにし、ブレークグラスは「超長パスワード＋厳格監視」で固めます。
  • ・オンプレ AD を忘れない：全体の強度はオンプレ側の堅牢性で決まります。

公式注釈（一次資料）

最新情報をチェックしよう！

Ndictの最新記事8件

>システム構築・保守に特化した会社です。

システム構築・保守に特化した会社です。

システムの構築・保守運用「システムガーディアン」 社内システム担当が欲しいが、専属で雇うほどの仕事量はない。 必要な時に必要なだけ頼りたいというお悩みを持つ企業様へ専門知識を持って対応を行っております。 サーバから各種システムまで自社・他社で構築されたシステムに対してサポートを行っております。

お問い合わせ
CTR IMG