グループの入れ子を最小限に抑える

　グループを入れ子（ネスト）にするのは最小限に抑える。グループを入れ子にすると、管理の負担（オーバーヘッド）が増加し、有効なアクセスのトラブルシューティングを行う難しさが増すためだ。グローバルグループには個々のADユーザーアカウントだけを設定する。そして、ドメインローカルグループにはグローバルグループだけを設定する。

有効なアクセス許可を表示する「有効なアクセス」タブ

　Microsoftの「Windows Server」OSとクライアントOSには、「有効なアクセス」という機能がある。この機能は、ファイルやフォルダのプロパティシート内の「セキュリティの詳細設定」ダイアログボックスにある。このダイアログボックスで、ユーザー、グループ、PCの特定のアカウントにとって有効なアクセスをモデル化する。だが、この機能を使って分析を複数のフォルダに拡張することはできない。複数のフォルダのアクセス許可を分析する場合は、この機能を複数回実行する必要がある。

　マルチドメイン環境では、入れ子は避けられない。そのため、可能な限りシングルドメインのトポロジーを保つようにする。

ADのクロスドメインリソースアクセス構成

　このトポロジーでは、グローバルグループに含めることができるのは部門独自のドメインのADユーザーアカウントのみになる。だが、グローバルグループは任意のフォレストドメインの随意アクセス制御リストに追加できる。このトポロジーでは以下のことが実施されている。

• A：グローバルグループは、「contoso.com」ドメインと「corp.contoso.com」ドメインに参加するマーケティング部門の従業員を表す。
• B：アプリサーバに「Mktg App Access」というドメインローカルグループを作成し、そのグループに両方のグローバルグループを設定する。
• C：基幹業務マーケティングアプリケーションのアクセス許可を「Mktg App Access」ドメインローカルグループに割り当てる。

　ここまでユニバーサルグループに触れていないことを不思議に感じるかもしれない。ユニバーサルグループの説明を避けてきたのは、グローバルカタログでユニバーサルグループのメンバーシップの照合が実施されることで、ユーザーのログオン時間が遅くなるためだ。また、ユニバーサルグループは、グループの作成やリソースアクセス戦略がずさんになりやすいこともある。

ハイブリッドクラウド向け設計方法

　Microsoftは、クラウドIDサービス用に「Microsoft Azure Active Directory」（以下、Azure AD）を提供している。Azure ADはオンプレミスのADユーザーやグループと同期することができる。だが、組織単位をサポートしない。Azure ADはユーザーアカウントとグループアカウントのフラットなリストを使用する。これは、IDを目的とした場合には適切に機能する。

　この構造を念頭において、ユーザーとグループに適切な名前を付けることが重要になる。また、Azureクラウドでこうしたアカウントの管理を容易にするため、ADのプロパティをしっかりと設定することも必要だ。

　ADのグループを編成する必要があるときは、チームの全てのメンバーが理解できる命名規則を考え、それを守ることが大切だ。

　よくあるグループ命名パターンの1つは、プレフィックスを含めることだ。例えば、全てのグローバルグループ名の前に「GL_」を、ドメインローカルグループ名には「DL_」を付ける。「Microsoft Exchange Server」を使用する場合は、ADセキュリティグループに加えて配布グループも用意する。その場合は、「DI_」プレフィックスを使用するとよい。