Active Directoryでファイル共有のアクセス許可を付けるときは、ユーザーを1人ずつ登録するのではなく、グループに許可を付けるのが基本です。ところが、グループを作ろうとすると「セキュリティ」と「配布」、「グローバル」「ドメインローカル」「ユニバーサル」と、選ぶ項目がいくつも出てきます。この記事では、グループの種類とスコープの違いを整理し、よく使われる組み方と、グループが多すぎると起きる問題まで説明します。
- セキュリティグループと配布グループの違い
- グローバル・ドメインローカル・ユニバーサルの3つのスコープの違いと、よく使われる組み方
- グループがトークンにどう入るか、多すぎるとなぜサインインやアクセスに失敗するのか
なぜグループを使うのか
ファイルやフォルダのアクセス許可は、ACL（だれに何を許すかの一覧）に書きます。ACLにユーザーを1人ずつ書いていくと、人とフォルダの組み合わせの数だけ設定が必要になり、異動や退職のたびに、たくさんのACLを直すことになります。
グループに許可を付けておけば、ACLは「営業部に変更を許す」のように一度書くだけで済みます。人が入れ替わったときは、グループのメンバーを直すだけです。Microsoftのドキュメントでも、共有フォルダやプリンタのアクセス許可は、個々のユーザーではなくセキュリティグループに付けるよう勧めています。
ACLに書かれるのはグループの名前ではなく、グループのSIDです。アクセスするときは、ユーザーのトークンに入っているSIDと、ACLのSIDが突き合わされます。このしくみは「アクセストークンとACL」の記事で説明しています。
2つの種類：セキュリティグループと配布グループ
グループを作るとき、最初に選ぶのが「グループの種類」です。種類は2つあります。
| セキュリティグループ | 配布グループ | |
|---|---|---|
| 主な使い道 | アクセス許可やユーザー権利を付ける | Exchange Serverなどで、メールの宛先リストにする |
| ACLに書けるか | 書ける | 書けない |
| トークンに入るか | 入る | 入らない |
| メールの宛先にできるか | できる | できる |
アクセス許可に使えるのはセキュリティグループだけです。配布グループはセキュリティの機能を持たないので、ACLに書くことができず、メンバーのトークンにも入りません。種類はあとから相互に変えられますが、ACLに書かれているセキュリティグループを配布グループに変えると、そのACLの行は無視されるようになります。
スコープの前に：ドメイン・フォレスト・信頼関係
グループのスコープは「どの範囲で使えるか」を決めるものなので、その範囲を表す言葉を先に押さえておきます。出てくるのは、ドメイン、フォレスト、信頼関係の3つです。
| 言葉 | 意味 |
|---|---|
| ドメイン | DCとアカウントをまとめて管理する単位です。corp.example.com のような名前を持ち、ユーザーやコンピュータ、グループはどれか1つのドメインに属します。 |
| フォレスト | 1つ以上のドメインの集まりです。最初に作ったドメインがフォレストの根元（フォレストルート）になり、osaka.corp.example.com のような子ドメインを足していけます。 |
| 信頼関係 | 相手のドメインのアカウントを、自分のドメインのリソースで受け入れるという約束です。 |
同じフォレストの中のドメインどうしは、ドメインを作ったときに、自動で双方向の信頼関係が結ばれます。この信頼は推移的（AとB、BとCが信頼し合っていれば、AとCも信頼し合っているものとして扱う）なので、フォレスト内のどのドメインのユーザーも、許可さえあれば、ほかのどのドメインのリソースも使えます。
いっぽうで、別のフォレストとは、何もしなければつながっていません。グループ会社や合併した会社のフォレストとリソースを共有したいときに、管理者が「フォレストの信頼」を作ったときだけつながります。
信頼には向きがあり、アクセスの向きとは逆になるので注意が必要です。
ドメインBがドメインAを信頼すると、Aのユーザーが、Bのリソースを使えるようになります。リソースを持っている側が、相手のアカウントを「信頼する」と考えると覚えやすいです。
多くの会社は、ドメインが1つだけで、それがそのままフォレストになっています。この場合、「フォレスト全体」も「自分のドメイン」も同じ範囲なので、どのスコープを選んでも使える範囲は変わりません。スコープの違いがはっきり出るのは、ドメインが複数あるときや、別のフォレストと信頼関係を結んでいるときです。
3つのスコープ
もう1つ選ぶのが「グループのスコープ」です。スコープは、そのグループに「だれを入れられるか」と「どこで許可を付けられるか」を決めるものです。
| スコープ | メンバーにできるもの | 許可を付けられる 範囲 | メンバーになれる先 |
|---|---|---|---|
| グローバル | 同じドメインのアカウント、同じドメインのグローバル | フォレスト内のどのドメインでも。信頼しているドメインやフォレストでも | ユニバーサル、同じドメインのグローバル、ドメインローカル |
| ドメインローカル | どのドメイン（信頼しているドメインを含む）のアカウントやグローバル、同じフォレストのユニバーサル、同じドメインのドメインローカル | 自分のドメインの中だけ | 同じドメインのドメインローカル、同じドメインのコンピュータのローカルグループ |
| ユニバーサル | 同じフォレストのアカウント、グローバル、ユニバーサル | フォレスト内のどのドメインでも。信頼しているフォレストでも | ユニバーサル、ドメインローカル、コンピュータのローカルグループ |
ここからは、図2と同じ「本社ドメイン」「大阪ドメイン」と、双方向の信頼を結んだ「取引先のドメイン」の3つを例に、それぞれのスコープで「だれを入れられるか」と「どこで許可を付けられるか」を図で見ていきます。ドメインが1つだけの環境でも、次の節で説明する「入れ子のルール」はそのまま当てはまります。
グローバルグループ：人をまとめる
グローバルグループに入れられるのは、同じドメインのアカウントとグローバルグループだけです。そのかわり、フォレスト内のどのドメインでも、許可を付ける相手として使えます。「営業部」「経理部」のように、同じドメインにいる人を役割ごとにまとめるのに向いています。
本社ドメインに作った GG-営業部 には、本社の user01 は入れられますが、大阪の user05 や取引先の user09 は入れられません。そのかわり、GG-営業部 は、本社、大阪、取引先のどのフォルダのACLにも書けます。「入口は狭く、使える場所は広い」グループです。
ドメインに最初からある Domain Users（ドメインのすべてのユーザー）や Domain Admins（ドメインの管理者）も、グローバルグループです。
ドメインローカルグループ：許可を受け止める
ドメインローカルグループには、ほかのドメインや、信頼している別のフォレストのアカウントやグループも入れられます。そのかわり、許可を付けられるのは、そのグループがあるドメインの中だけです。「営業資料フォルダの変更」「経費システムの閲覧」のように、特定のリソースへの許可を受け止める入れ物として使います。
グローバルグループとは逆で、「入口は広く、使える場所は狭い」グループです。本社、大阪、取引先のだれでも入れられますが、ACLに書けるのは本社ドメインのフォルダだけです。大阪のファイルサーバで同じような許可を作りたいときは、大阪ドメインにドメインローカルグループを作ります。
ユニバーサルグループ：フォレスト全体で使う
ユニバーサルグループには、フォレスト内のどのドメインのアカウントやグループも入れられ、フォレスト内のどこでも許可を付けられます。ここでいう「ユニバーサル（全体）」は、フォレストの全体という意味です。別のフォレストのアカウントは、信頼関係があっても入れられません。フォレスト全体の管理者を表す Enterprise Admins は、ユニバーサルグループです。
本社と大阪の両方の人を1つのグループにまとめ、どちらのドメインのフォルダにも許可を付けられます。入口も使える場所も広いグループですが、その分、次に説明するグローバルカタログとの関係に気を付けます。
ユニバーサルグループは、メンバーの一覧がグローバルカタログ（GC）にも載ります。グローバルカタログは、フォレスト内のすべてのドメインのオブジェクトを、よく使う属性に絞って持っているDCです。どのDCをグローバルカタログにするかは、管理者が決めます。
ドメインが複数あるフォレストでは、ユーザーが、別のドメインで作られたユニバーサルグループに入っていることがあります。自分のドメインのDCだけでは、それが分かりません。そのためDCは、ユーザーのサインインを受け付けるときに、グローバルカタログに問い合わせて、ユーザーが入っているユニバーサルグループを調べます。
DC自身がグローバルカタログなら、問い合わせは自分の中で済みます。ところが、グローバルカタログを置いていない拠点では、サインインのたびにWAN越しの問い合わせが発生します。WANが遅ければサインインに時間がかかり、グローバルカタログに届かなければサインインに失敗します。
これを避けるための機能が「ユニバーサルグループメンバーシップのキャッシュ」です。Active Directory サイトとサービスで拠点（サイト）ごとに有効にでき、有効にすると、その拠点のDCが、グローバルカタログに問い合わせた結果を覚えておくようになります。
| タイミング | 拠点のDCの動き |
|---|---|
| 1回目のサインイン | キャッシュが空なので、グローバルカタログに問い合わせる。結果をキャッシュに覚える |
| 2回目以降 | キャッシュを使うので、グローバルカタログに問い合わせない。WANが細くてもサインインが速い |
| ときどき | グループの変更を反映するため、グローバルカタログからキャッシュの中身を取り直す |
Microsoftは、ユーザーが100人に満たない小さな拠点で、本社とのWANが細いときに使うよう案内しています。また、キャッシュを取り直せるように、グローバルカタログから複製で1ホップ以内のところに置くよう求めています。なお、ドメインが1つだけのフォレストでは、どのDCもグローバルカタログのように振る舞えるので、サインインのためにグローバルカタログへ問い合わせる必要はありません。
この3つのほかに、ADの Builtin コンテナにある Administrators（S-1-5-32-544）などのグループは「ビルトインローカル」というスコープで、スコープも種類も変えられません。また、ドメインに参加したPCやサーバには、それぞれのコンピュータだけのローカルグループ（そのPCの Administrators や Users など）があります。ドメインに参加すると、Domain Admins がそのコンピュータの Administrators に自動で入ります。ローカルグループの置き場所の違いは「ワークグループとドメインの違い」の記事で説明しています。
グループの入れ子とよく使われる組み方
グループは、別のグループのメンバーにできます（入れ子）。ただし、入れられる向きはスコープで決まっています。
このルールを使った定番の組み方が、AGDLPです。アカウント（Account）をグローバルグループ（Global）に入れ、グローバルグループをドメインローカルグループ（Domain Local）に入れ、ドメインローカルグループにアクセス許可（Permission）を付ける、という頭文字を並べたものです。
こう組んでおくと、2種類の変更を別々に扱えます。
| 起きること | 直す場所 |
|---|---|
| 営業部に人が入った・抜けた | GG-営業部のメンバーだけ。フォルダのACLは触らない |
| 営業企画にも営業資料の変更を許したい | GG-営業企画を DL-営業資料-変更 に入れるだけ。フォルダのACLは触らない |
| 営業資料を読み取りだけにしたい人がいる | DL-営業資料-読み取り を別に作り、ACLに1行足す |
ドメインが複数あるフォレストでは、各ドメインのグローバルグループをユニバーサルグループにまとめ、それをドメインローカルグループに入れる組み方（AGUDLP）もよく使われます。ユニバーサルグループのメンバーを変えると、その変更はフォレスト中のグローバルカタログに複製されます。そのため、ユニバーサルグループには人を直接入れず、グローバルグループを入れておくのが一般的です。
名前の頭に GG- や DL- を付けておくと、一覧で見たときにスコープを見分けやすくなります。これは決まりではないので、社内のルールに合わせてください。
スコープは作ったあとでも変えられますが、条件があります。グローバルからユニバーサルへは、ほかのグローバルグループのメンバーになっていなければ変えられます。ドメインローカルからユニバーサルへは、メンバーにドメインローカルグループがなければ変えられます。グローバルとドメインローカルの間は直接は変えられず、いったんユニバーサルを経由します。ドメインローカルに変えると、そのSIDは同じドメインの中でしかトークンに入らなくなるので、ほかのドメインのACLで使っていた場合は効かなくなります。
グループとトークン
グループのメンバーであることは、トークンに入ったグループのSIDで表されます。ただし、すべてのグループがいつもトークンに入るわけではありません。
この節では、例の構成を確認したうえで、「トークンをだれが作るか」と「グループの情報をだれが持っているか」の2つを押さえ、最後にまとめの表を読んでいきます。
例の構成
スコープの節で使った本社ドメインと大阪ドメインを、もう少し具体的にしたものです。
| ドメイン | あるもの |
|---|---|
| 本社ドメイン | DC（グローバルカタログも兼ねる）、ユーザーの user01、user01 が使うPC01、ファイルサーバのFS01。user01 は GG-営業部（グローバル）、UG-全社（ユニバーサル）、DL-営業資料（本社のドメインローカル）のメンバー |
| 大阪ドメイン | DC、ファイルサーバのFS02。大阪のドメインローカルグループ DL-大阪資料 があり、そのメンバーに本社の user01 を入れている |
図6で見たとおり、ドメインローカルグループには別のドメインのアカウントも入れられます。DL-大阪資料 は、大阪のFS02の共有フォルダに本社の人がアクセスできるように、大阪の管理者が作ったグループだと考えてください。
この構成で、user01 は次の3つの操作をします。
- 本社のPC01にサインインする（同じ本社ドメイン）
\\fs01の共有フォルダを開く（同じ本社ドメインのサーバ）\\fs02の共有フォルダを開く（別の大阪ドメインのサーバ）
ポイントは3つ目です。user01 のアカウントは本社ドメインにありますが、FS02は大阪ドメインのサーバです。本社と大阪は同じフォレストの中で信頼し合っているので、本社のユーザーが大阪のサーバにアクセスできます。このとき、トークンに入るグループが本社のサーバのときと変わります。
トークンは、受け付けたコンピュータごとに作られる
user01 がPC01にサインインすると、PC01が user01 のトークンを作ります。そのあと \\fs01 の共有フォルダを開くと、今度はFS01が、自分の中で user01 のトークンを作ります。PC01のトークンが、そのままネットワークを通ってFS01に渡るわけではありません。FS01は、Kerberosのチケットに入っていた情報をもとにトークンを作り直し、そのトークンと自分のフォルダのACLを突き合わせます。
3つのトークンを比べると、上の3行（user01、GG-営業部、UG-全社）はどれも同じです。いっぽうで、色を付けた下の2行（ドメインローカルとローカルグループ）は、コンピュータごとに違います。特に、別のドメインにあるFS02のトークンだけ、ドメインローカルの行が DL-営業資料 ではなく DL-大阪資料 になっています。
グループの情報をだれが持っているか
下の2行が違う理由は、グループの種類によって、メンバーの情報を持っている場所が違うからです。
| グループ | 情報を持っている場所 | トークンに入るとき |
|---|---|---|
| グローバル | ユーザーのドメインのDC | サインインのときにチケットに入るので、どのコンピュータのトークンにも入る |
| ユニバーサル | グローバルカタログ | サインインのときにチケットに入るので、どのコンピュータのトークンにも入る |
| ドメインローカル | そのグループがあるドメインのDC | そのドメインのコンピュータのトークンを作るときだけ入る |
| ローカル | そのコンピュータ | そのコンピュータのトークンを作るときだけ入る |
ここからは、本社の user01 が大阪のFS02を開く③の場面で、グループのSIDがどこからFS02に届くのかを順に見ていきます。
| 流れ | 何が起きるか |
|---|---|
| ① サインイン | 本社のDCが、user01 のTGT（チケットをもらうためのチケット）を発行する。TGTには、user01 自身と、GG-営業部（グローバル）、UG-全社（ユニバーサル）のSIDが入る |
| ③-1 本社のDCに頼む | PC01が、FS02用のチケットを本社のDCに頼む。FS02は大阪ドメインのサーバなので、本社のDCは「大阪のDCに頼んで」と紹介する |
| ③-2 大阪のDCに頼む | 大阪のDCがFS02用のサービスチケットを発行する。このとき、user01 が入っている大阪ドメインのドメインローカル（DL-大阪資料）のSIDを足す |
| ③-3 FS02に見せる | FS02はチケットに入っていたSIDに、自分のローカルグループ（FS02 の Users など）を足して、user01 のトークンを作る |
この流れの中で、本社のドメインローカル DL-営業資料 を足す場面はどこにもありません。DL-営業資料 を足すのは本社のDCで、本社のDCがチケットを発行するのは、本社ドメインのサーバ（PC01やFS01）用のときだけだからです。
図15は、FS02のトークンの中身を、情報の出どころごとに並べたものです。user01 は本社の人ですが、FS02のトークンを作るときに使われるドメインローカルの情報は、FS02と同じ大阪ドメインのものだけです。本社の DL-営業資料 は、user01 が本社でメンバーになっていても、FS02のトークンには入りません。
まとめの表の読み方
ここまでの3つの場面を1つの表にしたのが図16です。
- 列：トークンを作るコンピュータです。左の2列（PC01、FS01）は user01 と同じ本社ドメイン、右の1列（FS02）は別の大阪ドメインです。
- 行：user01 が入っているグループです。
- ○ と ×：その列のコンピュータで作るトークンに、その行のグループのSIDが入るかどうかです。
まず列を縦に見ます。本社のPC01とFS01の列は、DL-営業資料 が ○ で、DL-大阪資料 が × です。大阪のFS02の列だけ、これが逆になっています。同じ user01 でも、アクセスする先が別のドメインになると、トークンに入るドメインローカルが入れ替わることが分かります。縦に読んだ中身は、図13のトークンのカードと同じです。
次に行を横に見ます。上の3行（user01、GG-営業部、UG-全社）は、どの列も ○ です。グローバルとユニバーサルは、サインインのときにもらうTGTに入っているので、どのドメインのサーバにアクセスしても一緒に届きます。下の4行は、○ が1列か2列だけです。ドメインローカルは同じドメインのコンピュータだけ、ローカルグループはそのコンピュータだけ、という決まりが行ごとに表れています。
| グループ | トークンに入るか |
|---|---|
| グローバル、ユニバーサル | どのコンピュータで作るトークンにも入る（入れ子で入っているものも含む） |
| ドメインローカル | トークンを作るコンピュータと同じドメインのものだけが入る |
| コンピュータのローカルグループ | そのコンピュータで作るトークンにだけ入る |
ドメインローカルグループが「自分のドメインの中だけ」で使えるのは、このためです。図16の DL-営業資料 は、大阪のFS02で作るトークンには入らないので、仮にFS02のACLに書けたとしても効きません。
Kerberosでは、こうしたグループのSIDは、チケットの中のPAC（認可情報）という部分に入って運ばれます。トークンやチケットはサインインしたときに作られるので、グループのメンバーを変えても、すでにサインインしている人には反映されません。サインインし直すと、新しいグループが入ったトークンになります。
グループが多すぎると起きること
1人のユーザーがたくさんのグループに入っていると、トークンやチケットが大きくなり、ある数を超えると認証やアクセスに失敗します。気を付ける上限は2つあります。
Kerberos チケットの大きさ（MaxTokenSize）
Kerberosのチケットを受け取るための入れ物の大きさが MaxTokenSize です。Windows 8 と Windows Server 2012 以降では、既定値は48,000バイトです（それより前のWindowsでは12,000バイトでした）。チケットの大きさは、次の式でおおよそ見積もれます。
TokenSize = 1200 + 40d + 8s
| 記号 | 数えるもの（Windows Server 2012 以降） |
|---|---|
| 1200 | チケットそのものの大きさの目安。ドメイン名やユーザー名の長さで変わる |
| d | ユーザーのドメインの外にあるユニバーサルグループの数と、sIDHistory（ドメインを移行したときに残る古いSID）の数の合計 |
| s | ユーザーのドメインの中にあるユニバーサルグループ、ドメインローカルグループ、グローバルグループの数の合計 |
同じドメインのグループは1つあたり8バイトで済みますが、外のドメインのグループやsIDHistoryは1つあたり40バイトになります。たとえば、次のようになります。
| 例 | 同じドメインの グループ（s） | 外のユニバーサルと sIDHistory（d） | 見積もり |
|---|---|---|---|
| 例1 | 45個 | 0個 | 1200 + 8 × 45 ＝ 1,560バイト |
| 例2 | 650個 | 0個 | 1200 + 8 × 650 ＝ 6,400バイト |
| 例3 | 650個 | 200個（50＋150） | 1200 + 40 × 200 + 8 × 650 ＝ 14,400バイト |
例3でも48,000バイトには届きませんが、Webのシステムでは先に別の上限に当たります。HTTPでKerberosのチケットを送るときは、チケットをBase64に変換してヘッダーに入れるので、大きさがおよそ4/3倍になります。IIS（HTTP.sys）は、既定ではヘッダー1つあたり16,384バイトまでしか受け取らないため、14,400バイトのチケット（変換後は約19,200バイト）は受け取ってもらえず、「HTTP 400 – Bad Request (Request Header too long)」になります。
MaxTokenSize は最大65,535バイトまで大きくできますが、Base64で大きくなることを考えて、48,000バイトより大きくしないよう勧められています。Windows Server 2012 以降のDCでは、グループポリシーの「コンピューターの構成 ›› 管理用テンプレート ›› システム ›› KDC」にある「大きな Kerberos チケットに関する警告」（英語版では Warning for large Kerberos tickets）を有効にすると、大きなチケットを発行したときにイベントID 31が記録されるようになります。
トークンに入るSIDの数（1,024個）
もう1つの上限は、アクセストークンに入れられるSIDの数です。上限は1,024個で、Windowsが自動で加えるSID（Everyone や Authenticated Users など）の分を引くと、グループの数ではおよそ1,010個が目安になります。入れ子で間接的に入っているグループやsIDHistoryも数に入ります。
この上限を超えるとトークンを作れないので、サインインそのものが失敗し、「セキュリティ ID が多すぎる」という内容のメッセージが出ます。イベントID 4625 には 0xc000015a（STATUS_TOO_MANY_CONTEXT_IDS）が記録されます。こちらはKerberosでもNTLMでも同じで、MaxTokenSize を大きくしても解決しません。
減らし方
- 使っていないグループからユーザーを外す
- アクセス許可に使っていないセキュリティグループを配布グループに変える（配布グループはトークンに入らないので、数に入らない）
- ドメインの移行で残った sIDHistory を、使っていないことを確かめてから消す
- 入れ子を深くしすぎない。1つのグループが多くのグループに入っていると、メンバー全員のSIDが一度に増える
ドメインローカルグループは、アクセス先と同じドメインのものだけがトークンに入ります。そのため、ドメインが複数ある環境では、あるドメインのサーバにはサインインできるのに、別のドメインのサーバでは失敗する、ということも起きます。
確認に使うコマンド
PC（コマンドプロンプト）：今のトークンに入っているグループを一覧で表示する
whoami /groups
PC（PowerShell）：今のトークンに入っているグループの数を数える
(whoami /groups /fo csv | ConvertFrom-Csv).Count
管理用PC（PowerShell）：ドメインのグループを、種類とスコープ付きで一覧にする
Get-ADGroup -Filter * | Select-Object Name, GroupCategory, GroupScope | Sort-Object GroupScope, Name
管理用PC（PowerShell）：グローバルのセキュリティグループを作る
New-ADGroup -Name "GG-営業部" -GroupCategory Security -GroupScope Global -Path "OU=Groups,DC=corp,DC=example,DC=com"
管理用PC（PowerShell）：ドメインローカルのセキュリティグループを作る
New-ADGroup -Name "DL-営業資料-変更" -GroupCategory Security -GroupScope DomainLocal -Path "OU=Groups,DC=corp,DC=example,DC=com"
管理用PC（PowerShell）：ユーザーをグローバルグループに、グローバルグループをドメインローカルグループに入れる
Add-ADGroupMember -Identity "GG-営業部" -Members user01, user02 Add-ADGroupMember -Identity "DL-営業資料-変更" -Members "GG-営業部"
管理用PC（PowerShell）：ユーザーが直接入っているグループを表示する
Get-ADPrincipalGroupMembership -Identity user01 | Select-Object Name, GroupScope
管理用PC（PowerShell）：入れ子をたどって、グループに入っているユーザーを全部表示する
Get-ADGroupMember -Identity "DL-営業資料-変更" -Recursive | Select-Object Name
管理用PC（PowerShell）：グループのスコープをユニバーサルに変える
Set-ADGroup -Identity "GG-営業部" -GroupScope Universal
Get-ADGroup などのコマンドには、RSATのActive Directoryモジュールが必要です。whoami /groups の一覧には、ログオンセッションのSIDなど一部のSIDが表示されないので、1,024個の上限と比べるときは目安として見てください。
まとめ
| 項目 | ひとことで |
|---|---|
| ドメイン・フォレスト | ドメインは管理の単位、フォレストはドメインの集まり。フォレストの中は自動で信頼し合い、別のフォレストとは信頼を作ったときだけつながる |
| グループの種類 | アクセス許可に使えるのはセキュリティグループだけ。配布グループはメールの宛先用で、トークンに入らない |
| グローバル | 同じドメインの人をまとめる。フォレスト内のどこでも許可を付けられる |
| ドメインローカル | どこの人やグループでも入れられ、自分のドメインの中でだけ許可を受け止める |
| ユニバーサル | フォレスト全体で使える。メンバーの一覧はグローバルカタログにも載る |
| 組み方 | AGDLP：人はグローバルに、グローバルはドメインローカルに、許可はドメインローカルに付ける |
| トークン | グローバルとユニバーサルはどこでも入る。ドメインローカルはトークンを作るコンピュータと同じドメインのものだけ、ローカルグループはそのコンピュータだけで入る |
| 多すぎるとき | Kerberosのチケットが大きくなり（既定48,000バイト、IISのヘッダー上限にも注意）、SIDが1,024個を超えるとサインインできない |
「人をまとめるグループ」と「許可を受け止めるグループ」を分けておくと、アクセス許可の見直しがずっと楽になります。グループが増えてきたら、トークンの大きさにも目を向けておくと安心です。
- Active Directory security groups（Microsoft Learn）
- Group Objects（Microsoft Learn）
- Changing a Group’s Scope or Type（Microsoft Learn）
- How trust relationships work for forests in Active Directory（Microsoft Learn）
- [MS-PAC] 2.5 KERB_VALIDATION_INFO（Microsoft Learn）
- How Security Groups are Used in Access Control（Microsoft Learn）
- Planning Global Catalog Server Placement（Microsoft Learn）
- Active Directory Replication Concepts（Microsoft Learn）
- Group membership changes don’t update over some VPN connections（Microsoft Learn）
- Problems with Kerberos authentication when a user belongs to many groups（Microsoft Learn）
- Active Directory Domain Services maximum limits and scalability（Microsoft Learn）
- Logging on a user account that is a member of more than 1,010 groups may fail（Microsoft Learn）
- HTTP 400 Bad Request (Request Header too long) responses to HTTP requests（Microsoft Learn）
- Troubleshooting HTTP 400 errors in IIS（Microsoft Learn）
- New-ADGroup（Microsoft Learn）
コメント