OU とセキュリティグループ
OU もセキュリティグループも共に以下の点で共通しています。
- ユーザアカウントやコンピュータアカウントを配置できる
- 階層構造を持つ
ですがこの 2 つは本質的に異なるものです。この記事では実例を用いてその使い分けを示します。
OU の用途と設計のポイント
OU とは Organizational Unit の略で、LDAP 用語です。
LDAP とは簡易なデータベースのようなもので、RFC 4511 で定められた規格です。より詳細は以下の記事をご参照下さい。
Active Directory ではユーザアカウントやコンピュータアカウントを LDAP データベースに格納しています。OU はこれらのアカウントを整理して格納する、データベース内のフォルダのようなものです。
OU の用途はアカウントの整理の意味もありますが、より重要な意味としては『グループポリシー』を適用する単位になることです。
グループポリシーでは Windows PC や Windows Server を OU 単位で設定を一括設定し、設定を統一することができます。設定できる内容は非常に幅広く、レジストリレベルの細かい設定に加え、ルート証明書を配布したり .msi 形式のインストーラを配布して自動インストールする、といったことができたりします。
グループポリシーはたくさんの設定項目がありますが、通常は実際に設定するのはそのうちのいくつかだけです。設定しないものはデフォルト値が適用されます。
グループポリシーの設定内容を『GPO (グループポリシーオブジェクト)』としてまとめ、GPO を適切な OU にリンクすると、該当 OU 配下のユーザアカウントおよびコンピュータアカウントは、GPO の内容に沿ってセットアップされます。
例えば『フォルダリダイレクト』というグループポリシー設定でユーザのプロファイル領域 (マイドキュメント等) をファイルサーバ上に配置することができますが、営業部ユーザのフォルダリダイレクト用のファイルサーバを #1 (IP = 192.168.1.201) に、開発部ユーザのフォルダリダイレクト用のファイルサーバを #2 (IP = 192.168.1.202) にしたい場合は、以下のようにします。
- "Sales" と "Devel" という2つの OU を作成し、それぞれに営業部のユーザアカウントと開発部のユーザアカウントを格納
- フォルダリダイレクトの GPO を2 種類 (Sales_policy と Devel_policy) 新規作成し、それぞれの OU にリンク (下図参照)
なお、グループポリシーはコンピュータアカウントにも適用できます。
例えば Windows PC や Windows Server の Windows Update 先として、自前構築した WSUS サーバへ向ける設定をグループポリシーにて行うことができます。ですが、数千台単位のクライアント PC の Windows Update を 1 台の WSUS サーバでは支えきれません。
そこでクライアント PC のコンピュータアカウントを ExComp1 と ExComp2 という 2 つの OU で分割し、ExComp1 配下のクライアント PC は WSUS サーバ#1 (IP = 192.168.1.203) に、ExComp2 配下のクライアント PC は WSUS サーバ#2 (IP = 192.168.1.204) に向けるように設定することで、負荷分散を図れます。
なので繰り返しになりますが、OU は『グループポリシーを適用する単位』で分割するのが一般的です。
セキュリティグループの用途と設計のポイント
一方、セキュリティグループとは、Active Directory 固有の用語です。単に『グループ』と呼ばれることもありますが、他の用語と取り違える可能性もあるため、『セキュリティグループ』と呼ぶことが望ましいです。
主な意義は『ユーザアカウントやコンピュータアカウントを取り扱うことができる様々なアプリケーションにおいて、一律同じ取り扱いにするアカウントを 1 つにまとめる』ことです。
例えば 10,000 のユーザアカウントがある場合、あるフォルダへのアクセス権を 10,000 ユーザ分設定するのは大変です。
もし同じアクセス制御設定にすべきユーザアカウントが 7,000 ユーザいるとしたら、その 7,000 ユーザを 1 つのセキュリティグループにまとめれば、フォルダのアクセス権をその 1 つのセキュリティグループに対して設定するだけで良くなります。
例えば ExGroup1 というグループに exuser0001 ～ exuser7000 をメンバーとして加え、ファイルサーバ file.example.com 上のフォルダ share1 に対して ExGroup1 の読み書きアクセス権を設定すると、exuser0001 ～ exuser7000 の全ユーザが share1 にアクセスできるようになります。
これにより、ファイルサーバを複数台で運用するときもメンテナンスが楽になります。
例えば新規ユーザーへのアクセス権追加の際には、ファイルサーバそれぞれに対してアクセス権設定を変更する手間が不要で、ドメインコントローラ上で 1 つのグループに対して 1 名のユーザアカウントを追加するだけで済むからです。
セキュリティグループはその他にも色々な使われ方が為されます。
例えば Windows 標準の Radius サーバ (NPS) では、IEEE802.1x 認証や Web 認証でユーザ認証が成功した際に、そのユーザのセキュリティグループに応じて、NW機器に返す Radius 属性値を変えることができます。この仕組みを利用して動的 VLAN を実現することができたりします。
その他にも、VDI で有名な VMwre Horizon では、シンクライアント上の Horizon Client というクライアントアプリで ID/パスワードを入力すると、ドメインコントローラからはそのユーザが所属するセキュリティグループが返され、VMware Horizon ではそのグループに応じて利用できる VDI を変えることができます。
このようにセキュリティグループはファイルサーバだけでなく、他のベンダのアプリケーションとの AD 連携時にもよく利用されますので、それらのアプリケーションが AD とどのような連携を行い、それらのアプリケーションでどのようにグループ分けをするかによって設計が変わってきます。
なのでセキュリティグループは『ファイルサーバのフォルダアクセス権を適用する単位』や『アプリケーションでグループ分けする単位』にユーザアカウントを追加していくのが一般的です。
OU とセキュリティグループの階層構造
OU とセキュリティグループはともに階層構造を持ちますが、内部構造は異なります。
OU はフォルダの階層構造と同じです。1 つのユーザアカウント/コンピュータアカウントは必ず 1 つの OU に所属します。
一方、セキュリティグループはメーリングリストの階層構造と同じです。1 つのユーザーアカウントは複数のセキュリティグループに所属できます。
なので例えば管理職だけが閲覧できるフォルダを作る、というシナリオにおいては、セキュリティグループ "Manager" を作成し、管理職のユーザアカウントをメンバにすればよいのです。
また、セキュリティグループは他のセキュリティグループに所属できます。(メーリングリストをメーリングリストに追加するイメージ)
上図の例のように、Project-X というプロジェクトを立ち上げた際、PJ メンバのユーザアカウントと Manager セキュリティグループを所属させることもできます。
もしアプリケーションのグループ分けに関する運用が不明確なら (望ましくは無いですが) 運用負荷の掛からない範囲でできるだけ細かくしておくほうが無難です。もし使わないなら大枠のセキュリティグループを作り、そこに細かいセキュリティグループを所属させればよいので。
ただし、細かくし過ぎると今度はメンテナンスが大変です。例えば 1 年単位で変更が生じるならセキュリティグループの所属変更作業が年間行事になります。ユーザ数が多ければ処理も大変でしょう。
なお、セキュリティグループは OU とは独立した単位なので、OU をまたがっているユーザアカウント同士を 1 つのセキュリティグループに格納することができます。
【厳選 3 冊】Windows を学ぶための本
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント