Active Directoryには、Domain Admins や Enterprise Admins のように、入っているだけでドメインやフォレストのほぼすべてを操作できるグループがあります。こうしたグループを「特権グループ」と呼びます。便利だからと何となくメンバーを増やしてしまうと、そのうちの1人のアカウントが盗まれただけで、ドメイン全体が乗っ取られます。この記事では、主な特権グループの役割と、なぜ守る必要があるのか、どう守ればよいのかを説明します。
- Enterprise Admins、Schema Admins、Domain Admins、Administrators、各種 Operators の役割と置き場所
- 特権グループのアカウントが盗まれると何が起きるのか
- 特権グループを守るための基本（ふだんは空にする、Tier モデル、Protected Users、AdminSDHolder）
特権グループとは
ADの管理者は、大きく2種類に分けて考えられています。DCそのものやADの設定を管理する「サービス管理者」と、ADに入っているユーザーや、ドメインに参加したサーバ・PCのデータを管理する「データ管理者」です。特権グループは、主にサービス管理者のためのグループで、メンバーになるとDCを自由に操作できます。
DCを操作できるということは、ドメインのすべてのアカウントのパスワードを変えたり、グループのメンバーを変えたり、グループポリシーで全部のPCに設定を配ったりできる、ということです。そのため、特権グループのメンバーのアカウントが盗まれたときの被害は、ふつうのアカウントとは比べものになりません。
攻撃者がADを狙うとき、最終的な目標になるのがこの特権グループです。どのグループがどれだけ強いのかを知っておくことが、守り方を考える出発点になります。
主な特権グループの置き場所
特権グループには、フォレストに1つだけあるものと、ドメインごとにあるものがあります。ここでは、本社ドメインがフォレストルート（最初に作ったドメイン）で、その下に大阪ドメインがある構成で見てみます。フォレストやドメインの関係は「グループの種類とスコープ」の記事で説明しています。
| グループ | スコープ 置き場所 | できること |
|---|---|---|
| Enterprise Admins | ユニバーサル フォレストルートだけ | フォレスト全体の変更（子ドメインの追加など）。すべてのドメインの Administrators に入っている |
| Schema Admins | ユニバーサル フォレストルートだけ | スキーマ（ADに保存できるデータの形の定義）の変更 |
| Domain Admins | グローバル ドメインごと | ドメインの管理。同じドメインの Administrators と、ドメインに参加したすべてのコンピュータのローカルの Administrators に入っている |
| Administrators | ビルトイン ローカル ドメインごと | ドメインのDCを完全に管理できる。ADのほとんどのオブジェクトの所有者 |
| 各種 Operators | ビルトイン ローカル ドメインごと | アカウント、DCの保守、バックアップ、プリンタなど、一部の管理作業を任せるためのグループ |
Enterprise Admins、Schema Admins、Domain Admins、Administrators の既定のメンバーは、ドメインを作ったときにできる組み込みの Administrator アカウントです。
Enterprise Admins と Schema Admins：フォレスト全体の管理者
Enterprise Admins は、フォレストの全体に対する管理者です。フォレストルートにだけあり、すべてのドメインの Administrators グループに既定で入っています。そのため、大阪ドメインのDCも含めて、フォレストの中のすべてのDCを管理できます。
Schema Admins は、ADのスキーマを変更できるグループです。スキーマは、ユーザーやコンピュータなどのオブジェクトがどんな属性を持てるかを決める設計図で、フォレスト全体で1つです。Exchange Server の導入など、スキーマを拡張するときにしか使いません。
Domain Admins と Administrators：ドメインの管理者
Domain Admins は、ドメインの管理者です。ドメインごとにあり、本社の Domain Admins は本社ドメインを、大阪の Domain Admins は大阪ドメインを管理します。
Domain Admins は、同じドメインの Administrators グループに入っているので、DCを管理できます。さらに、PCやサーバをドメインに参加させると、Domain Admins がそのコンピュータのローカルの Administrators にも自動で入ります。つまり、Domain Admins のメンバーは、ドメインのすべてのDC、サーバ、PCの管理者です。
Administrators は、ADの Builtin コンテナにあるグループで、SIDは S-1-5-32-544 です。DCではドメインの管理者グループとして働き、ADのほとんどのオブジェクトの所有者になっています。Domain Admins や Enterprise Admins の権限の多くは、この Administrators に入っていることで得られています。
Operators と名の付くグループ
Builtin コンテナには、管理作業の一部だけを任せるためのグループもあります。名前だけ見ると権限が小さそうですが、どれもDCの上で強い力を持ちます。
| グループ | 注意したい点 |
|---|---|
| Account Operators | ほとんどのユーザーやグループを作成・変更でき、DCにローカルでサインインできる。管理者グループやそのメンバーは変更できない |
| Server Operators | DCでサービスの開始・停止、共有の作成、バックアップと復元ができ、DCにインストールされたプログラムを変更できる |
| Backup Operators | ファイルのアクセス許可に関係なく、すべてのファイルをバックアップ・復元できる。DCでもバックアップと復元ができる |
| Print Operators | DCに接続したプリンタを管理でき、すべてのDCでデバイスドライバを読み込み・解除できる。Microsoft もメンバーの追加には注意するよう書いている |
4つとも、既定ではメンバーがいません。Microsoft の Tier モデル（後で説明します）でも、Backup Operators や Server Operators のような組み込みのグループは、Domain Admins と同じ最上位の Tier 0 に入っています。「Domain Admins ほどの権限は渡したくないから Operators に入れておこう」という使い方は、安全とは言えません。
Group Policy Creator Owners（グループポリシーを作成・編集できる）のように、メンバーになると多くのPCに影響を与えられるグループはほかにもあります。グループの一覧と既定の権利は、Microsoft の「Active Directory security groups」にまとまっています。自分の環境でどのグループにだれが入っているかを、一度確かめておくと安心です。
なぜ守る必要があるのか
特権グループのアカウントが盗まれる典型的な流れは、次のようなものです。
Windowsにサインインすると、そのPCのメモリ（LSASS）には、シングルサインオンのための資格情報が残ります。攻撃者がすでに入り込んでいるPCに、管理者が Domain Admins のアカウントでサインインしてしまうと、その資格情報を盗まれ、攻撃者は Domain Admins としてDCを操作できるようになります。資格情報がメモリに残るしくみは「LSASS・SSPI・Negotiate」の記事で説明しています。
つまり、特権グループを守るとは、「特権アカウントの資格情報を、信頼できない場所に置かない」ことです。そのための考え方が、次の Tier モデルです。
Tier モデル
Microsoft は、AD の資産と管理者を3つの階層（Tier）に分けて、階層をまたいで資格情報を使わないようにする「Tier モデル」を勧めています。
| Tier | 入るもの |
|---|---|
| Tier 0 | ID の中枢。DC、AD CS、AD FS、Microsoft Entra Connect、Domain Admins などの管理アカウントとグループ（Backup Operators や Server Operators を含む）、DCを管理するバックアップや監視のしくみ |
| Tier 1 | メンバーサーバ、Exchange や SQL Server などのサーバアプリ、業務アプリと、その管理者 |
| Tier 2 | 利用者のPCやスマートフォンと、ヘルプデスクなどの管理者 |
ルールはシンプルで、上の Tier のアカウントで、下の Tier のコンピュータにサインインしません。図5の例では、Tier 0 の admin01 で Tier 2 の PC02 にサインインしたことが問題でした。管理作業は、その Tier 専用に用意した管理用のPC（PAW：特権アクセスワークステーション）から行います。Microsoft は、Domain Admins と同じ強さの権限を持つ人を5人未満に抑えることを、よくある目安として挙げています。
特権グループの守り方
Microsoft のドキュメントに書かれている守り方のうち、基本になるものを挙げます。
| やること | 内容 |
|---|---|
| ふだんは空にしておく | Enterprise Admins、Domain Admins、Administrators には、ふだん使うアカウントを入れない（守りを固めた組み込みの Administrator だけは残してよい）。必要なときだけ一時的に入れて、作業が終わったらすぐ外す |
| アカウントを分ける | 管理者には、メールやWebを使う普段用のアカウントとは別に、管理用のアカウントを1人1つずつ用意する。管理用のアカウントは共有しない |
| 一般のPCやサーバにサインインさせない | メンバーサーバとPCのOUにリンクしたGPOで、Domain Admins などを「ネットワーク経由のアクセスを拒否」「ローカルログオンを拒否」「リモートデスクトップ経由のログオンを拒否」などのユーザー権利に入れる |
| Operators は空のままにする | 既定どおりメンバーを空にしておく。メンバーを入れる場合は、Domain Admins と同じ Tier 0 のアカウントとして扱う |
| 既定の入れ子は変えない | Domain Admins をローカルの Administrators から外したり、Enterprise Admins を各ドメインの Administrators から外したりしない。障害から戻すときに必要になる |
| 変更を監視する | 特権グループのメンバーやプロパティが変わったら通知されるように監査を設定する |
Protected Users グループ
Protected Users は、メンバーの資格情報が盗まれにくくなるように、認証のやり方を強制的に絞るグループです。特権アカウントを入れておくと、図5のような盗難に強くなります。
| メンバーになると | 内容 |
|---|---|
| NTLM などが使えない | NTLM、ダイジェスト認証、CredSSP では認証できない。Kerberos だけになる |
| 弱い暗号を使わない | Kerberos の事前認証で DES や RC4 を使わず、AES だけを使う |
| 委任されない | Kerberos の制約付き委任・制約なし委任の対象にならない |
| チケットの寿命が短い | TGT の有効期間が4時間になり、4時間ごとに認証し直す |
| 資格情報を残さない | Windows 8.1 以降のPCでは、パスワードがキャッシュされない |
ただし、この制限には抜け道がありません。Domain Admins のメンバーを全員いきなり入れると、NTLMしか使えない場面などで全員がサインインできなくなるおそれがあります。Microsoft も、影響を十分に試してから入れるよう注意しています。サービス用のアカウントやコンピュータアカウントは、入れても守れないので入れません。
AdminSDHolder と SDProp
特権グループは、AD の中でもう1つの仕掛けに守られています。それが AdminSDHolder と SDProp です。
AdminSDHolder は、各ドメインの CN=System の下にあるオブジェクトで、特権グループとそのメンバーに付けるべきアクセス許可の「ひな形」を持っています。PDCエミュレータの役割を持つDCでは、SDProp という処理が既定で60分ごとに動き、保護の対象になっているグループとアカウントのアクセス許可を、ひな形と比べます。違っていれば、ひな形どおりに上書きして戻します。
保護の対象は、Domain Admins、Enterprise Admins、Schema Admins、Administrators、Account・Backup・Print・Server の各 Operators、Domain Controllers、krbtgt などです。たとえ攻撃者が Domain Admins グループに「メンバーを変更できる」というアクセス許可をこっそり足しても、次に SDProp が動いた時点で消えます。
保護の対象になったアカウントには adminCount という属性が 1 で付き、アクセス許可の継承がオフになります。ヘルプデスクに委任したパスワードリセットが一部のユーザーだけ効かない、といったときは、そのユーザーが過去に特権グループに入っていなかったかを確かめてみてください。
確認に使うコマンド
管理用PC（PowerShell）：Domain Admins のメンバーを、入れ子もたどって表示する
Get-ADGroupMember -Identity "Domain Admins" -Recursive | Select-Object Name, objectClass
管理用PC（PowerShell）：フォレストルートの Enterprise Admins と Schema Admins のメンバーを表示する
Get-ADGroupMember -Identity "Enterprise Admins" -Recursive -Server corp.example.com | Select-Object Name Get-ADGroupMember -Identity "Schema Admins" -Recursive -Server corp.example.com | Select-Object Name
管理用PC（PowerShell）：ドメインの Administrators のメンバーを表示する
Get-ADGroupMember -Identity "Administrators" -Recursive | Select-Object Name, objectClass
管理用PC（PowerShell）：Operators の4つのグループが空かどうかを確かめる
"Account Operators", "Server Operators", "Backup Operators", "Print Operators" | ForEach-Object { $_; Get-ADGroupMember -Identity $_ | Select-Object Name }
管理用PC（PowerShell）：AdminSDHolder の保護の対象になっているユーザーを表示する
Get-ADUser -Filter 'adminCount -eq 1' | Select-Object Name
管理用PC（PowerShell）：管理用のアカウントを Protected Users に入れる
Add-ADGroupMember -Identity "Protected Users" -Members admin01
メンバーサーバ（コマンドプロンプト）：そのコンピュータのローカルの Administrators のメンバーを表示する
net localgroup Administrators
特権グループのメンバーの変更は、DCのセキュリティログに記録されます。グローバルグループ（Domain Admins など）への追加はイベントID 4728、ローカルグループ（Administrators など）への追加は 4732、ユニバーサルグループ（Enterprise Admins など）への追加は 4756 です。記録するには、「セキュリティグループの管理」の監査を有効にします。
まとめ
| 項目 | ひとことで |
|---|---|
| Enterprise Admins | フォレスト全体の管理者。ルートにだけあり、すべてのドメインの Administrators に入っている |
| Schema Admins | スキーマを変更できる。スキーマを拡張するときだけ使う |
| Domain Admins | ドメインの管理者。DCと、ドメインに参加したすべてのサーバ・PCの管理者になる |
| Administrators | DCを完全に管理できるビルトインのグループ。ADのほとんどのオブジェクトの所有者 |
| 各種 Operators | 名前に反してDCの上で強い力を持つ。既定どおり空にしておく |
| 守り方 | ふだんは空にする、管理用アカウントを分ける、上の Tier のアカウントで下の Tier にサインインしない、Protected Users を試して使う、変更を監視する |
| AdminSDHolder | 特権グループとそのメンバーのアクセス許可を、60分ごとにひな形どおりに戻すしくみ |
特権グループは「入れておくと便利なグループ」ではなく、「必要なときだけ、決まった場所から使うグループ」です。まずは Domain Admins と Operators のメンバーを確かめ、ふだん使っているアカウントが入っていないかを見てみてください。
- Active Directory security groups（Microsoft Learn）
- Implementing Least-Privilege Administrative Models（Microsoft Learn）
- Appendix E: Securing Enterprise Admins Groups in Active Directory（Microsoft Learn）
- Appendix F: Securing Domain Admins Groups in Active Directory（Microsoft Learn）
- Appendix G: Securing Administrators Groups in Active Directory（Microsoft Learn）
- Appendix C: Protected Accounts and Groups in Active Directory（Microsoft Learn）
- Reducing the Active Directory Attack Surface（Microsoft Learn）
- Tier model for Active Directory Domain Services（Microsoft Learn）
- Legacy privileged access guidance（Microsoft Learn）
- Protected Users security group（Microsoft Learn）
- Guidance about how to configure protected accounts（Microsoft Learn）
- Troubleshoot insufficient access rights error（Microsoft Learn）
- Appendix L: Events to monitor（Microsoft Learn）
コメント