Active DirectoryのRSATについて理解する

はじめに

Active Directoryの管理をしていると、必ずどこかで「ADサーバーに直接ログインしたくないんだけど、どうやって運用するんだ？」という壁にぶつかります。 DCにRDPできる人を増やせば増やすほどセキュリティ的なリスクは高まりますし、監査の観点でも「DCに誰がいつログインしたか」を気にしないといけません。本来DCには誰もログインしないのが理想で、運用は手元の端末から行うのが筋です。

そこで登場するのが RSAT（Remote Server Administration Tools） です。この記事では、自分が実案件でRSATを導入したときに引っかかったポイントを軸に、必要な権限とネットワーク要件まで含めてまとめておきます。「DCに直接ログインしないAD運用を作りたい」という人にちょうどいい内容になるはずです。

RSATとは

RSATは、Microsoftが提供するWindowsクライアント向けのリモート管理ツール群です。ざっくり言うと、サーバーに入っている「サーバーマネージャー」や「Active Directory ユーザーとコンピューター」などの管理スナップインを、Windows 10 や Windows 11 のクライアント端末にインストールして使えるようにするものです。

代表的なものを並べると、

Active Directory ユーザーとコンピューター（dsa.msc）
Active Directory サイトとサービス（dssite.msc）
グループポリシーの管理（gpmc.msc）
DNSマネージャー（dnsmgmt.msc）
DHCPマネージャー
Active Directory 管理センター（dsac.exe）

このあたりが含まれています。普段ADの運用で触るツールはほぼ網羅されていて、RSATさえあれば、DCにRDPする必要はほとんどなくなります。

なお、Windows 10 1809 以降は「設定 → アプリ → オプション機能」から「機能の追加」でインストールできるようになりました。それ以前のバージョンではMicrosoft公式サイトからインストーラーをダウンロードしてくる必要がありましたが、今は標準機能として組み込まれているので、導入のハードルは大きく下がっています。

なぜDCに直接ログインさせないのか

一応「RDPでDCに入ればいいじゃん」と思う方もいるかもしれないので、少し調べた理由を軽く整理しておきます。

DCにログインできる＝ドメイン全体に対して影響を及ぼせる立場を手に入れること。認証チケットがメモリ上に載るため、DC上でMimikatz系のツールが動けば、Domain Admins相当の資格情報が抜かれるリスクがある。
DCに入れる人が多いと、変更の履歴が追いにくくなり、インシデント時の原因特定が大変になる。
監査要件上、「DCへのインタラクティブログオンは誰？」が問われることが多い。人が増えるほど説明コストが増える。

この3点だけ考えても、DCへのインタラクティブログオンはできるだけ減らすのが正解です。「管理作業は手元の端末からリモート管理ツールで行う」という運用に切り替えるだけで、だいぶ健全な姿になります。

実案件での使われ方

自分が経験した案件では、「ADサーバーには絶対にRDPさせないが、AD上のユーザーアカウントの追加や端末オブジェクトの削除はやらせたい」という要件がありました。これを実現するためにRSATを導入しました。

構成のイメージはこんな感じです。

[管理用端末（Windows 11 + RSAT）]
        │
       UTM
        │  Kerberos / LDAP / SMB / RPC
        ▼
[ドメインコントローラー]

管理用端末は普段業務で使っているクライアントとは別に用意して、原則「AD管理操作専用」として運用しました。ジャンプサーバーを建てるほど大袈裟にはしたくないが、業務PCに管理権限を持たせたままにするのも避けたい、という要件にRSATはぴったりハマります。

インストール時にハマったポイント：ローカル管理者権限が必要

ここが地味に注意点でした。 RSATを「機能の追加」からインストールする時、対象端末の ローカル管理者権限が必要 です。RSATは結局のところOSの機能を有効化するので、当然と言えば当然なのですが、自分はここを忘れていて「なぜか機能が出てこない」と一瞬詰まりました。

対策として、社内のヘルプデスク用端末にはあらかじめRSATを仕込んだイメージを配布しておくか、Intune や SCCM で機能の有効化スクリプトを流す形にしておくとスムーズです。手動で1台ずつ管理者権限を渡してインストールするのは現実的ではありません。

権限はインストール先端末のログオンユーザーに紐づく

ここも見落とされがちな重要ポイントです。 RSATをインストールしただけでは、ADを操作する権限は付きません。RSATはあくまで「リモートから操作するためのGUI」を提供しているだけで、実際にADに対して何ができるかは、RSATをインストールしている端末にログオンしているユーザーの権限 に紐づきます。

つまり、

ヘルプデスク担当のADアカウント自体に必要な権限を持たせる
もしくは、AD側で「制御の委任」によってOU単位で必要な権限を委任する

のどちらかが必要です。セキュリティ的にはDomain Adminsを渡すのは最小権限の原則に反するので、自分の案件では「制御の委任」によってOU単位で必要な権限を委任しました。OU単位で必要な権限だけ渡す方法は、別の記事「Active DirectoryのOUについて理解する」にまとめているので、合わせて読むとイメージが湧くと思います。

つい忘れがちですが、「RSATが入っている端末＝AD管理できる端末」ではなく、「RSATが入っている端末で、AD管理権限を持ったアカウントでログオンしている時のみ、AD管理ができる」という関係性です。

ネットワーク要件：開けるべきポート

ここが一番ハマるポイントかもしれません。 DCと管理用端末の間にUTMなどのファイアウォールがある構成では、AD固有のプロトコルは別途開放する必要があります。

自分の案件で開けた典型的なポートは以下です。

ポート	プロトコル	用途
53	TCP/UDP	DNS
88	TCP/UDP	Kerberos認証
389	TCP/UDP	LDAP
445	TCP	SMB（SYSVOL、ファイル共有）
135	TCP	RPC エンドポイントマッパー
49152〜65535	TCP	RPC 動的ポート（Ephemeral）

特に注意したいのが RPC 動的ポート（49152〜65535） です。 RPCはまずポート135で「これからどの動的ポートで通信するか」を端末に教え、その後、教えられた動的ポートで実際の通信を開始します。なので「135だけ開ければOK」と思って設定すると、最初の一覧取得まではうまくいっても、ユーザー作成やオブジェクトの参照が途中で失敗します。 LDAPS（636）やグローバルカタログ（3268, 3269）は、利用するスナップインやスキーマ操作の有無で必要になるので、要件に応じて追加してください。最低限上記の表が通れば、日常的なユーザー・コンピューター操作は問題なくできるはずです。

もう一点、DNSの依存関係も忘れがちです。RSATが接続するDCは名前解決を経由することが多く、管理端末側のDNSサーバーがDC（もしくはドメイン名を解決できるDNS）を向いている必要があります。別セグメントに管理端末を置く場合、DNSフォワーダーの設定を忘れるとKerberosの認証そのものが失敗するので、ここも合わせて確認しておきたいポイントです。

運用上の小ネタ

最後に、自分が実際にやってよかった運用ノウハウをいくつか書いておきます。

管理端末側でも監査ログを取る：ADに対する操作はDC側のセキュリティログにも残りますが、管理端末側のイベントログに「いつ・誰がdsa.mscを起動したか」が残ると、調査が圧倒的に楽になります。
ショートカットを整備する：dsa.msc、dssite.msc、gpmc.mscはタスクバーにピン留めしておくと、運用効率が地味に上がります。
管理端末のIPは固定する：DCのファイアウォールルールでソースIPを絞れるので、踏み台化リスクが下がります。
管理アカウントは日常業務と分ける：いわゆる「Tier 0アカウント」の考え方に近いですが、普段のメール・ブラウジング用アカウントとAD管理用アカウントは分けておくと、フィッシングで業務アカウントがやられてもADに波及しません。運用負荷は少し上がりますが、体感としてはそれ以上にメリットが大きい施策でした。
PowerShell（ActiveDirectoryモジュール）もセットで覚える：GUIで完結するように見えても、同じ操作を繰り返すならPowerShellの方が圧倒的に早いです。RSATをインストールすると Import-Module ActiveDirectory でモジュールが使えるようになるので、ちょっとした一括操作だけでもPowerShell化しておくと便利です。

まとめ

RSATは「DCにログインしないAD運用」を実現するためのほぼ必須ツールです。ただし、

インストールにはローカル管理者権限が必要
ADへの権限はログオンユーザーに紐づく（RSATが権限を持つわけではない）
ファイアウォールではKerberos・LDAP・SMB・RPC（特に動的ポート）の開放が必要

という点を押さえください。

DCに対するアクセスを最小化するというのは、最近のゼロトラスト的な文脈とも相性がいい話なので、まだRSATを使った運用に切り替えていない現場があれば、ぜひ検討してみてもらえればと思います。