リモートワークや拠点分散が当たり前になった今、Windows 11 クライアントから遠隔地の Windows Server 2019 へ RDP 接続する機会は急増しています。しかし、その裏側で動く Kerberos 認証の詳細なフローや、マルチドメイン／複数サイト構成の Active Directory 環境で「パスワード変更」がどう複製されるのかまで正しく説明できる人は多くありません。本記事では、実運用を意識した視点から仕組みと設計ポイントを分かりやすく解説します。
Kerberos認証とは？Windowsドメインで使われる標準認証プロトコル
Windows のドメイン環境では、ユーザーやコンピューターの認証に Kerberos 認証 が標準で使われています。古くからある NTLM と比べて、パスワードをネットワークに流さず、チケットベースで安全かつ効率的に認証できるのが特徴です。
まずは、RDP やパスワード複製の詳細に入る前に、Kerberos の登場人物と基本用語を整理しておきましょう。
Kerberos認証に登場する主なコンポーネント
- クライアント
Windows 11 など、ユーザーがログオンする端末。RDP を開始する側です。 - ドメインコントローラー (DC)
Active Directory をホストするサーバー。Kerberos の世界では KDC (Key Distribution Center) でもあります。 - RDP サーバー
Windows Server 2019 など、リモートデスクトップの接続先となるサーバー。ドメイン参加しており、コンピューターアカウントを持ちます。 - ユーザーアカウント
ドメインに存在するユーザー。パスワードから Kerberos 用の秘密鍵が生成されます。 - SPN (Service Principal Name)
サービスとサービスアカウントを対応づける識別子。RDP ではTERMSRV/<サーバー名>などの SPN が利用されます。
Kerberosで扱うチケットの種類
Kerberos では、認証に次の 2 種類のチケットが登場します。
| チケット種類 | 発行者 | 暗号化の鍵 | 用途 |
|---|---|---|---|
| TGT (Ticket-Granting Ticket) | DC (KDC) | ドメイン内の krbtgt アカウントの秘密鍵 | 「サービスチケットをください」と KDC にお願いするためのパスポート的チケット |
| サービスチケット | DC (KDC) | 対象サービス (RDP サーバーなど) の秘密鍵 | 実際にサービス (RDP, SMB, HTTP など) にアクセスするときに提示するチケット |
ユーザーはまず TGT を取得し、その TGT を使って個々のサービス (RDP など) 用のサービスチケットを要求し、それを提示してサービスにアクセスします。
Windows 11からWindows Server 2019へのRDPで見るKerberos認証フロー
ここからは、質問にもあったシナリオ：
- クライアント：Windows 11
- 接続先：Windows Server 2019 (RDP)
- ドメイン環境：Active Directory ドメインに両者が参加
を前提に、「いつ・誰が・どの情報を」送るのかをタイムライン形式で整理します。
Kerberos認証とRDP接続の全体タイムライン
| フェーズ | タイミング | 通信内容 (平文パスワードは流れない) | 主な暗号化キー | 代表ポート |
|---|---|---|---|---|
| ① AS_REQ / AS_REP | ユーザーが Windows 11 にログオンした直後 | クライアント → DC に AS_REQ 送信 (ユーザー名＋前認証データ) DC → クライアントに AS_REP 返却 (TGT + セッションキー) | TGT: KDC の秘密鍵で暗号化 セッションキー: ユーザーのパスワードハッシュ由来の鍵で暗号化 | UDP/TCP 88 (Kerberos) |
| ② TGT キャッシュ | ログオン処理完了後 | クライアントが TGT を復号し、ローカルのチケットキャッシュ (LSASS) に保存 | — | 通信なし |
| ③ TGS_REQ / TGS_REP | ユーザーが RDP 接続を開始したタイミング | クライアント → DC に TGS_REQ 送信 (TGT + オーセンティケータ) DC → クライアントに TGS_REP 返却 (RDP 用サービスチケット) | サービスチケット: RDP サーバーのコンピューターアカウント秘密鍵で暗号化 | UDP/TCP 88 (Kerberos) |
| ④ サービスアクセス (AP_REQ) | RDP セッション確立時 | クライアント → RDP サーバーへ サービスチケット + 新オーセンティケータを送信 RDP サーバー側でチケット検証し、認証成功ならセッション確立 | チケット内部はサーバー秘密鍵＋セッションキーで保護 | TCP 3389 (RDP) |
重要なのは、フェーズ④の「RDP サーバーへの接続」では Kerberos 専用ポート 88 は使われないという点です。Kerberos に関するやり取りはあくまで「クライアント ↔ DC」の間で行われ、RDP サーバーとは 3389/TCP 上の RDP プロトコルの一部として認証情報が交換されます。
フェーズ①：ユーザーがWindows 11にログオンするときのAS_REQ / AS_REP
ユーザーが Windows 11 のログオン画面にドメインユーザー名とパスワードを入力すると、クライアント内部では次のような流れになります。
- ユーザーが入力したパスワードから、クライアント側で Kerberos 用の秘密鍵 (実体としてはパスワードハッシュを元にした鍵) を生成。
- クライアント → DC に AS_REQ を送信。前認証として「現在時刻をパスワード由来の鍵で暗号化したデータ」などが含まれます。
- DC は、Active Directory に保存されているユーザーのパスワードハッシュから同じ鍵を生成し、前認証データを復号できるかを確認。
- 問題なければ AS_REP を返却。その中に
- ユーザー用のセッションキー (ユーザー鍵で暗号化)
- TGT (KDC の秘密鍵で暗号化されており、クライアントは中身を直接読めない)
- クライアントはユーザー鍵でセッションキーを復号し、TGT とともにローカルにキャッシュします。
この時点で、ユーザーのパスワードそのものがネットワークを流れることはありません。あくまで「パスワードから作った鍵で暗号化されたデータ」が送られ、DC 側で正しく復号できるかどうかで認証を行っています。
フェーズ③：RDPサービス用のサービスチケット取得 (TGS_REQ / TGS_REP)
ユーザーが mstsc.exe を起動して RDP 接続を開始するタイミングで、クライアントは既に持っている TGT を使って DC に「RDP 用のサービスチケットをください」と要求します。
- クライアントは RDP 接続先サーバー名から SPN (
TERMSRV/<FQDN>など) を組み立てます。 - クライアント → DC に TGS_REQ を送信。中には以下が含まれます。
- 先ほど取得した TGT
- オーセンティケータ (現在時刻等を TGT セッションキーで暗号化したもの)
- 要求するサービスの SPN (RDP サーバー)
- DC は KDC の秘密鍵で TGT を復号し、ユーザー情報と TGT セッションキーを取り出します。
- 取り出した TGT セッションキーでオーセンティケータを復号し、時刻・再利用などを検証します。
- 問題なければ TGS_REP を返却し、その中に
- RDP サーバー用サービスチケット (RDP サーバーのコンピューターアカウント秘密鍵で暗号化)
- クライアントと RDP サーバー間で使うセッションキー (TGT セッションキーで暗号化)
クライアントはこれを受け取り、RDP サーバー用のサービスチケットをローカルキャッシュに保存します。
フェーズ④：RDPサーバーへの接続とAP_REQ
続いて、クライアントは取得したサービスチケットを使って RDP サーバーに接続します。この通信は TCP 3389 上で行われ、必要に応じて TLS で暗号化されています。
- クライアント → RDP サーバーに接続し、ログオンプロトコル (通常は NLA＋Kerberos/NTLM) のネゴシエーションが行われます。
- Kerberos を使う場合、クライアントは AP_REQ メッセージとして
- サービスチケット
- オーセンティケータ (クライアント時刻などをサービスセッションキーで暗号化)
- RDP サーバーは、自身のコンピューターアカウント秘密鍵でサービスチケットを復号し、チケット内部のセッションキーを取り出します。
- 取り出したセッションキーでオーセンティケータを復号し、時刻・再利用チェックを行います。
- 問題なければクライアントを正当なユーザーとして認め、必要に応じて AP_REP で相互認証を返し、その後通常の RDP セッションが開始されます。
ここでも、RDP サーバーとの間で ユーザーの平文パスワードが流れることはありません。RDP サーバーは DC から発行されたチケットを検証するだけで、「ユーザーが誰であるか」を判断しています。
認証後のアクセス制御：RDPログオン権限の確認
Kerberos 認証が成功すると、RDP サーバーはチケット内のユーザー SID やグループ SID を元にローカルの Windows セキュリティポリシー (ユーザー権利の割り当て) を評価します。
- 「リモート デスクトップ サービスを通じてログオンを許可」 にユーザーや所属グループが含まれているか
- ネットワークレベル認証 (NLA) が有効かどうか
- Firewall / ネットワークポリシーで 3389/TCP が許可されているか
ここで許可されて初めて、RDP のデスクトップセッションが表示されます。
マルチドメイン／複数サイト構成でのパスワード変更と複製
次に質問のもう一つのポイント、「複数ドメイン／複数サイト構成でのパスワード変更の複製」について見ていきます。例として、次のような構成を考えます。
- Active Directory フォレスト内に複数サイト (北米サイト・南米サイトなど)
- ドメインは 1 つとし、そのドメインの PDC エミュレーター が北米サイトに存在
- 南米サイトにも複数の DC が存在 (ユーザーの最寄り DC)
このとき、南米サイトのユーザーがパスワードを変更すると、どのようにパスワード情報が複製されるのかを順に追ってみます。
PDCエミュレーターの役割を整理する
Active Directory には 5 つの FSMO ロールがありますが、パスワード変更に特に関わるのが PDC エミュレーター です。PDC エミュレーターは、同じドメイン内の DC から見て「パスワードの権威」として扱われます。
- パスワード変更は、原則として PDC エミュレーターに即時レプリケーションされる
- ユーザーが最近パスワードを変更した直後でも、他の DC は PDC に問い合わせることで最新パスワードを確認できる
- 古いパスワードでログオンしようとする場合も、一度だけ PDC に問い合わせてみる挙動がある
この仕組みによって、「パスワードを変えた直後に、別サイトのサーバーへアクセスしてもログオンできない」といったトラブルを軽減しています。
同一ドメイン内、別サイトのパスワード変更フロー
南米サイトユーザーがパスワードを変更した場合の典型的な流れを、ステップごとに整理します。
| ステップ | 動作 | 関与するDC | ポイント |
|---|---|---|---|
| 1. パスワード変更要求 | ユーザーは Windows の「パスワードの変更」画面や Ctrl+Alt+Del からパスワード変更を実行 | 最寄りの南米サイト DC | クライアントは通常、サイト情報と DNS をもとに最も近い DC を選択 |
| 2. DC への送信 | クライアント → 南米サイト DC に、新旧パスワードを含むパスワード変更要求を送信 (Kerberos なら UDP/TCP 464) | 南米サイト DC | 平文パスワードではなく、プロトコルに従った安全な方法で送信される |
| 3. PDC への即時転送 | 南米サイト DC は、パスワード変更を北米サイトの PDC エミュレーターへ「緊急レプリケーション」として即時転送 | PDC エミュレーター (北米サイト) | 通常のレプリケーションスケジュールとは別枠で、できるだけ早く伝達される |
| 4. PDC での更新 | PDC がユーザーオブジェクトのパスワードハッシュを更新 | PDC エミュレーター | この時点で「正」のパスワード情報は PDC に存在する |
| 5. 通常レプリケーション | PDC から他サイト・同サイトの DC へ通常の AD レプリケーションにより変更が複製される | 各サイトの DC | サイトリンクのレプリケーション間隔に依存するが、パスワード変更は比較的優先度が高い |
この仕組みによって、南米サイトでパスワードを変更しても、短時間のうちに北米サイトを含む全 DC に新パスワードが行き渡ります。
パスワード変更直後のログオンはどう扱われるか
とはいえ、レプリケーションが完了する前に別サイトの DC に対してログオンしてしまうケースは現実的にあり得ます。その場合、AD には次のような挙動があります。
- ユーザーが新パスワードでログオンしようとし、ローカル DC の情報が古かった場合
- DC は一度だけ PDC エミュレーターに問い合わせて、「最新パスワード」で認証できるか確認
- PDC で認証が成功すれば、その結果を元にログオンを許可し、ローカル DC の情報も更新
- ユーザーが古いパスワードでログオンしようとした場合
- 同様に PDC に問い合わせを行い、そこでも失敗した場合はログオン失敗となる
この挙動により、「パスワード変更直後なのに別拠点サーバーへログオンしたら認証が通らない」といった問題が起こりにくくなっています。
複数ドメイン環境で考慮すべきポイント
フォレスト内に複数ドメインがある場合、パスワード情報はドメイン単位で管理されます。つまり、「ユーザーが所属するアカウントドメイン」の中でのみパスワードが複製され、別ドメインには直接複製されません。
- ユーザーアカウントは「ユーザードメイン」に属する
- RDP サーバーなどのリソースは「リソースドメイン」に属する場合がある
- この場合、Kerberos は「クロスドメインのチケット (信頼関係に基づく referral)」を使って認証する
ただし、ユーザーのパスワードそのものはユーザードメインでのみ管理・複製される点は変わりません。RDP サーバーが別ドメインにあっても、最終的な「ユーザーの正しさ」を保証するのはユーザードメインの DC (およびその PDC エミュレーター) です。
リモート環境で開放すべきポート整理：KerberosとRDP、AD参照系
質問の「リモート環境で開放すべきポート」について、Kerberos 認証付き RDP を成立させるための最低限を整理しておきます。ここでは、クライアントがリモートサイトの DC と RDP サーバーにアクセスするケースを想定します。
クライアント ↔ DC (Kerberos認証・パスワード変更)
| ポート | プロトコル | 方向 | 用途 |
|---|---|---|---|
| 88 | TCP / UDP | クライアント ↔ DC | Kerberos 認証 (AS_REQ / TGS_REQ など) |
| 464 | TCP / UDP | クライアント ↔ DC | Kerberos パスワード変更 (kpasswd プロトコル) |
Kerberos 認証を利用する場合、少なくとも上記ポートはクライアントから DC へ到達できる必要があります。
クライアント ↔ DC (Active Directory参照系)
アプリケーションや管理ツールが LDAP 経由で Active Directory を参照する場合、次のポートも必要です。
| ポート | プロトコル | 方向 | 用途 |
|---|---|---|---|
| 389 | TCP | クライアント ↔ DC | LDAP (ユーザー・グループなどのディレクトリ参照) |
| 636 | TCP | クライアント ↔ DC | LDAPS (LDAP over SSL/TLS) |
| 3268 | TCP | クライアント ↔ グローバルカタログ | GC (フォレスト全体検索) |
| 3269 | TCP | クライアント ↔ グローバルカタログ | GC over SSL/TLS |
純粋に「ドメインログオンと RDP だけ」が目的であれば、LDAP 参照系のポートは必須ではない場合もありますが、運用やアプリ連携を考えると開放が必要になるケースが多いです。
クライアント ↔ RDPサーバー (RDP本体)
| ポート | プロトコル | 方向 | 用途 |
|---|---|---|---|
| 3389 | TCP | クライアント ↔ RDP サーバー | リモートデスクトップ (RDP) 本体 |
Kerberos で認証するか NTLM で認証するかに関わらず、RDP 本体の通信は 3389/TCP を利用します。Kerberos のチケットは、このポート上の RDP プロトコル内でやり取りされるだけであり、RDP サーバー側でポート 88 を開ける必要はありません。
時刻同期：NTPポートの重要性
Kerberos 認証においては、クライアントと DC の時刻差が大きいと、「再生攻撃を防ぐ」観点からチケットが拒否されます。一般的な許容範囲は 5 分程度と言われており、時刻ずれがあるだけで認証エラーが頻発することもあります。
| ポート | プロトコル | 方向 | 用途 |
|---|---|---|---|
| 123 | UDP | クライアント ↔ 時刻サーバー (DC を兼ねることが多い) | NTP による時刻同期 |
マルチサイト環境では、各サイトの DC が信頼できる NTP ソースから時刻同期するように設計し、「時刻ズレが Kerberos 失敗の原因になっていないか」を常に意識しておきましょう。
実運用で役立つトラブルシューティングと設計Tips
ここまでの仕組みを踏まえて、現場でよく遭遇する問題と、そのチェックポイント・設計のコツをいくつか挙げておきます。
Kerberos認証が失敗するときの典型パターン
- 時刻ずれ
- サイト間で NTP の上位ソースが異なり、数分以上のズレが発生
- 仮想環境でホスト時刻とゲスト時刻がズレている
- SPN の不整合
- RDP サーバーのコンピューターアカウントに正しい SPN (TERMSRV/…) が登録されていない
- 重複した SPN が別アカウントに登録されている
- Firewall / ネットワーク制限
- クライアントから DC への 88/TCP, 464/TCP が閉じており、Kerberos が使えず NTLM フォールバックしている
- VPN 経由で特定ポートのみ許可されており、必要なポートが足りない
- DNS の誤設定
- クライアントが社外 DNS を参照しており、ドメインコントローラーを正しく名前解決できない
- 逆引きや SRV レコードが壊れている
現場で使える確認コマンド例
Kerberos や AD レプリケーションの状態を確認するために、次のようなコマンドが役立ちます。
klist
現在のユーザーが保持している TGT やサービスチケットを確認できます。「RDP 接続前後でどのチケットが増えたか」を見ると理解が深まります。
setspn -L <コンピューターアカウント名>
指定したアカウントに登録されている SPN を確認できます。RDP サーバーの SPN が正しく登録されているかチェックする際に利用します。
nltest /dsgetdc:<ドメイン名>
クライアントから見て、どのドメインコントローラーが選択されているかを確認できます。サイト設定や DNS が適切かどうかの検証に有用です。
repadmin /replsummary
ドメインコントローラー間のレプリケーションの状態を俯瞰できます。パスワード変更が各 DC に届いているか確認する一助になります。
マルチサイトAD設計の実践的ポイント
- サイトとサブネットの設計
- 南米・北米など、実際のネットワーク遅延を反映したサイト設計を行う
- クライアントの IP アドレス範囲が正しくサイトに紐づいていることを確認
- サイトリンクとレプリケーション間隔
- パスワード変更が拠点をまたいでも遅延しないよう、レプリケーション間隔を過度に長くしない
- 帯域制限が厳しい場合でも、パスワードやロックアウト情報は優先的に伝搬されるように設計
- PDCエミュレーターの配置
- ユーザー数が多い拠点、もしくは管理者操作が集中する拠点に配置するのが一般的
- 遠隔拠点の DC から PDC までのネットワーク品質 (遅延・帯域) に注意
- 時刻同期のトポロジ設計
- フォレストルートドメインの PDC を最上位の NTP ソースにし、他 DC が階層的に同期する構成を検討
- 仮想化基盤とゲスト OS の両方で時刻同期が二重にならないようにする
まとめ：Kerberosとパスワード複製を理解して安全なRDP環境を構築する
本記事では、
- Windows 11 クライアントから Windows Server 2019 への RDP 接続時に、いつ・誰が・どの情報をやり取りして Kerberos チケットを取得するのか
- マルチドメイン／複数サイト構成の Active Directory 環境で、パスワード変更がどのように PDC エミュレーター経由で複製されるのか
- リモート環境で Kerberos 認証付き RDP を成立させるために、どのポートを開放すべきか
という 3 つの観点から、Kerberos 認証と AD レプリケーションの実像を解説しました。
ポイントをあらためて整理すると、
- パスワードそのものはネットワークを流れず、常にハッシュや暗号化されたデータとして扱われる
- RDP サーバー自体は Kerberos ポートを使わず、DC とクライアントの間だけで Kerberos が完結する
- パスワード変更は PDC エミュレーターへ即時転送され、さらに通常レプリケーションで各 DC へ行き渡る
- 時刻同期と適切なポート開放が Kerberos 認証の成立条件として非常に重要
これらを理解しておくことで、単に「なんとなくドメイン参加して RDP が動いている」から一歩進んで、設計意図を持って安全かつトラブルに強いリモートデスクトップ環境を構築できるようになります。特に拠点分散・マルチドメイン環境では、Kerberos と AD レプリケーションの仕組みをきちんと押さえておくことが、将来の障害対応コストを大きく下げることにつながります。
コメント