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

はじめに

自分が初めてActive Directoryの管理を担当した時、一番混乱したのが「OU」と「セキュリティグループ」と「Builtinグループ」の区別でした。名前は似ているし、どちらもユーザーやコンピュータをまとめている。なんとなく権限みたいなものに使う、という曖昧な理解のまま触っていて、あるとき権限委任の設定をする必要が出てきて、初めて「自分は何も理解していなかったんだな」と気付かされました。

この記事では、当時の自分が読みたかった内容を中心に、OUとは何か、セキュリティグループとどう違うのか、そして実案件でやった「制御の委任」の話まで一気に書いていきます。Active Directoryを触りはじめた人がつまづきがちなポイントは、だいたいこのあたりに集中している気がするので、同じところで悩んでいる人の参考になればと思います。

OU（組織単位）とは

OUは Organizational Unit の略で、日本語では「組織単位」と訳されます。身も蓋もない言い方をすると、Active Directory上のオブジェクト（ユーザー、コンピュータ、グループなど）を入れておく「フォルダ」のようなものです。

ただ、ただのフォルダと違うのは、

グループポリシー（GPO）をリンクできる
管理権限を「このOUに対してだけ」と委任できる
LDAP的に階層構造で扱える

という点で、Active Directoryを運用するうえでは設計の中心になります。フォルダとして単にユーザーをまとめるだけなら、わざわざOUを使わずに「Users」コンテナで十分なのですが、OUを使うことでGPOと委任という二大機能が解放される、というイメージで捉えると分かりやすいです。

例えば、OUを「ユーザー用OU」「端末用OU」「サーバー用OU」と分けておくと、サーバーには適用したくないGPOをユーザーや端末だけにリンクできますし、「端末用OUに対してだけパスワードリセットを許可」みたいな細かい権限分離ができます。

OU・セキュリティグループ・Builtinグループの違い

ここが最初の壁です。当時の自分は「ユーザーをまとめるならOUでもセキュリティグループでもいいじゃん」と思っていましたが、用途は全く違います。

種類	主な用途	入れ子	GPOリンク
OU	オブジェクトの配置場所、GPOリンク先、委任の単位	階層的	できる
セキュリティグループ	リソースへのアクセス権の付与単位	できる	できない
Builtinグループ	ADやWindowsにあらかじめ用意された特権グループ	一部可	なし

ざっくり言うと、OUは「どこに置くか」、セキュリティグループは「何にアクセスできるか」、Builtinグループは「ADやWindowsそのものの管理権限」と考えるとスッキリします。Entra IDでいうところのRBACロールの権限の塊みないなイメージです。

たとえば「営業部のユーザーが営業用ファイルサーバにアクセスできるようにしたい」のなら、

営業部用OUを作って営業部ユーザーをそこに入れる（OU＝配置）
「営業部」というセキュリティグループを作って営業部ユーザーをメンバーに入れる（グループ＝アクセス権の単位）
ファイルサーバの共有フォルダに「営業部」グループの読み書き権限を付与する（権限の付与）

という流れになります。OUだけでアクセス権を実現することは基本的にありません。逆に「営業部のユーザーだけEdgeのスタートページを固定したい」というGPOを配りたい時は、セキュリティグループではなくOUに対して仕掛けるのが基本です（厳密にはセキュリティフィルタリングでグループを使うこともできますが、まずはOUベースで考えるのが一般的です）。

Builtinグループは少し別物で、Domain Admins、Enterprise Admins、Account Operators あたりがその代表です。これらは権限が強力すぎるので、運用上は「個人アカウントを安易に入れない」のが鉄則です。Domain Adminsを渡せば確かに何でもできますが、ヘルプデスクやITベンダーに気軽に渡してしまうと、有事の際の被害範囲が一気に広がります。代わりに、必要最小限の権限だけを後述する「制御の委任」で渡すのがベストプラクティスです。

実案件でのOU設計

自分が経験した複数の案件を振り返ると、ほぼ例外なくOUは「ユーザー用」と「端末用」を最低限分ける構成になっていました。これはMicrosoftが推奨しているベストプラクティスでもあります。

contoso.local
├─ Corp
│   ├─ Users          ← ユーザー用OU
│   │   ├─ Sales
│   │   ├─ HR
│   │   └─ IT
│   ├─ Computers      ← 端末用OU
│   │   ├─ Sales-PC
│   │   ├─ HR-PC
│   │   └─ IT-PC
│   └─ Servers
└─ Service Accounts

なぜユーザーと端末を分けるかというと、GPOは「ユーザー構成」と「コンピュータ構成」で別々の設定を持っていて、リンク先を間違えると意図しないところに効いてしまうからです。たとえば「Edgeのスタートページを固定する」のはユーザー構成、「BitLockerを強制する」のはコンピュータ構成です。OUを混ぜると、GPOのスコープ管理がすぐにカオスになります。

部署ごとにOUを細かく切るかどうかは案件次第ですが、自分の経験上は「ユーザー/端末」と「部署」の二段階くらいで切るのがよいのではないでしょうか。あまり細かく切りすぎると、人事異動のたびにオブジェクトの移動作業が発生して運用負荷が増加しますし、GPOの継承関係も追いづらくなります。最初の設計時点で「異動があったらどうするか」などIDのメンテナンス面もシミュレーションしておくと、後から後悔しにくいです。

OUの真価：制御の委任

ここからが本題です。OUを使うと一番強力にメリットを感じるのは「制御の委任」です。

ある案件で、お客様から「ヘルプデスク担当には、特定の部署のパスワードリセットだけはやらせたい。でもDomain Adminsは渡したくない」「使わなくなった端末の削除も、限定的にやらせたい」という要望がありました。

繰り返しになりますが、Domain Adminsを渡してしまえば確かに何でもできます。ただ、それはセキュリティ的に最小の権限ではないので、ヘルプデスクが踏み台にされた瞬間にドメイン全体が乗っ取られます。最小権限の原則を考えると、OU単位で必要な操作だけを渡すのが正解です。

パスワードリセットの委任

これはとても簡単でした。対象のOUを右クリックして「制御の委任」を開き、ウィザードに従って、対象ユーザー（ヘルプデスク担当グループ）と「ユーザーアカウントのパスワードのリセット」という事前定義されたタスクを選ぶだけです。

委任ウィザードには、よく使う操作（パスワードリセット、ユーザー作成、グループメンバー変更など）が事前にメニューとして用意されているので、定型的な権限委任ならGUIで完結します。検証環境で動作確認したら、ヘルプデスクのテストアカウントから対象OUのユーザーのパスワードを実際にリセットできることを確認して、本番に展開しました。

端末削除の委任：ウィザードに無い権限

ところが、「端末（コンピュータオブジェクト）の削除」だけはウィザードのメニューにありませんでした。ここで地味に時間を取られました。

色々と検証した結果、ウィザードに無い細かい粒度の権限を委任するには、OUのプロパティから直接アクセス制御エントリ（ACE）を編集する必要があると分かりました。

具体的には次のような手順です。

対象OUを右クリック → プロパティ
「セキュリティ」タブ →「詳細設定」
「アクセス許可エントリ」で「追加」
プリンシパル（委任先のヘルプデスクグループ）を選択
適用先を「Computer オブジェクト」に絞り込む
「削除」と「サブツリーの削除」にチェック

これでOU配下のコンピュータオブジェクトに限って削除権限が委任されます。なお、「適用先」の指定をミスると、ユーザーオブジェクトまで削除可能になってしまうので、ここはスクリーンショットを残すくらい慎重に確認した方がいいです。検証環境で必ず一度試してから本番投入することを強くおすすめします。

ちなみに、ウィザードで設定したパスワードリセットの権限も、内部的には同じくACEとして書き込まれているだけです。なのでウィザードはあくまで「よく使うACE設定の組み合わせを楽にしてくれるもの」と捉えると、ウィザードに無い設定が必要になっても怖くなくなります。

委任を運用するときの注意

運用するときの注意として、「OUを移動した瞬間に委任の効きが変わる」という挙動です。委任はOUに対して付与しているので、対象オブジェクトが別のOUに移動すれば、当然効かなくなります。これ自体は理屈通りなのですが、人事異動などでオブジェクトを大量に動かす運用を始めると「昨日まで効いていた権限が突然なくなった」というインシデントに直結するので、OUの移動と委任設計はセットで考えておくと安全です。

加えて、委任先のセキュリティグループに「直接ユーザーを追加する」のではなく、「役割グループ → 委任グループ」という二段構成にしておくのもおすすめです。たとえば「ヘルプデスク役割グループ」を作り、そのグループを「パスワードリセット委任グループ」「端末削除委任グループ」のメンバーに追加しておくと、人の入れ替わりがあった時に「役割グループへの追加・削除」だけで運用できます。委任そのものを触り直す必要がなくなるので、事故が減ります。

まとめ

OUは単なる「フォルダ」ではなく、「GPOを当てる単位」「委任の単位」として設計するものだ、と理解できるとActive Directoryへの解像度がぐっと上がります。セキュリティグループやBuiltinグループとの役割の違いを区別できるようになると、設計レビューの議論についていけるようになりますし、「Domain Adminsをむやみに渡さない」という最小権限の話も腹落ちしてきます。

振り返ってみると、自分が最初に詰まった原因は「機能を一つずつ別個のものとして覚えようとしていたこと」でした。OU・グループ・委任・GPOは全部つながっていて、OUを軸に並べてみると「GPOはOUに当てる」「委任はOUに対して行う」「セキュリティグループは委任先・GPOフィルタとして使う」というふうにきれいに整理できます。一度この構造が見えると、設計書を読んだ時の理解スピードが段違いに変わりました。

自分のように、当時は名前で区別がつかなかったという人は意外と多い気がするので、この記事が同じところで詰まっている誰かの助けになれば嬉しいです。次回は同じくAD周りでハマりがちな「RSAT」や「GPO」の話も書く予定なので、よければそちらも覗いてもらえればと思います。