Deployment of Active Directory 2... NTドメインの再設計
ディレクトリの論理設計
パイロットシステムの構築を通じて得られた導入経験とパフォーマンスデータ，ユーザーニーズなどに基づき，ディレクトリの設計を開始する。ディレクトリの設計は，大きく分けて，(1) 論理設計，(2) 物理設計，(3) セキュリティ設計，という3段階で構成される。
ディレクトリとは一種のデータベースであるため，システム開発におけるデータベースの開発と同様に，設計が大きな意味を持つ。設計は，管理者の便宜やユーザーの使い勝手，パフォーマンスに多く影響するだけに，十分な時間をかけて慎重に進める必要がある。可能であれば，移行チームのメンバーにデータベースシステムの専門家に参加してもらうと，さまざまな意味で有用な助言を得られるかもしれない。
NTドメインから移行する場合には，その移行コストを最低限にとどめるという点も重要な命題となるだろう。新規導入する場合であれば採用したい構成であっても，コストや移行期間などの制限から，断念せざるを得ない場合もあるかもしれない。存在するネットワーク基盤をどれだけ活用できるのか，存在するネットワーク基盤をどれだけ打開できるのかは，いずれも移行チームの力量にかかわってくる。心していただきたい。なお，組織の目的も，規模も，方向性も，将来像も，それぞれ異なるだけに，ディレクトリ設計の理想像を一般的に示すことはまず不可能である。それぞれの組織の実状に合わせて，移行チームのメンバが判断する必要がある。
論理設計で重要になるのは，ドメインの設計とネームスペースの設計という2つである。Active Directoryの場合，論理構造と物理構造を完全に分離できるわけではない。サイトの概念が導入されたことにより，NTドメインと比べれば論理構造と物理構造を分けて考えることができるようになったが，ドメインは相変わらず複製やセキュリティの境界となる点に注意してほしい。また，Active DirectoryドメインはDNSのネームスペースとマップされるため，ディレクトリのネームスペースを変更するときに，DNSのネームスペースまで変更しなければならなくなることもある。組織のプロフィット化が進展し，今後は事業持株会社制に基づく企業分割が進むこともあると思われるが，その場合でも以前と同じ電子メールアドレスを使用したいことが多いだろう。このような場合に，「企業が別である」という理由だけでディレクトリを分割してしまうと，かえって運用コストが増大してしまうこともあるので注意してほしい。
論理設計にあたっては，ディレクトリをできる限り単純にすることが望ましい。ディレクトリを複雑化させてしまうと，管理コストが向上してしまうことも珍しくない。そのため，たとえば組織構造を元にディレクトリを設計する場合でも，どこまでの組織構造をディレクトリに再現するかを十分に検討すべきである。
ディレクトリを単純化するためにも，まず，ディレクトリを論理的に上位レベルと下位レベルに分割し，上位レベルから順に設計することをお勧めする。
上位レベルのディレクトリには，あまり変化することのない静的な要素のみを配置する。部課のように比較的頻繁に変更される組織構造を上位レベルのディレクトリに格納してしまうと，組織変更のたびにすべてのディレクトリ構造を見直さなければならなくなるため，効率が悪い。ディレクトリの管理コストを低減するためにも，地理的条件，会社，事業グループ，オブジェクトの種別など，変更される可能性の少ない要素を上位レベルのディレクトリに配置するようにしたい。
下位レベルのディレクトリには，比較的変更される機会の多い要素を配置する。たとえば，事業部, 部，課，係，グループ，ユーザー，コンピュータなどは，下位レベルのディレクトリに配置するようにすべきである。
Active Directoryの場合，中規模程度かそれ以上の組織であれば，上位レベルのディレクトリをActive Directoryドメインに，下位レベルのディレクトリをOUに，それぞれ対応させるとよいだろう（これによって，複製とセキュリティの境界を制御することもできる）。これに対して，中規模程度かそれ以下の組織であれば，シングルドメインで構成し，ディレクトリの構造はOUで実装すべきである。ただし，NTドメインから移行する場合，マスタドメインとリソースドメインをどう移行し，どう統合するかを検討しなければならないので，移行コストの問題から理想的な設計には到達できないこともあり得る。NTドメインで一般的に採用されていたドメインモデルと，Active Directoryドメインへの移行については，別途詳しく説明するので参照してほしい。
Fig.10 大規模の組織におけるディレクトリ設計モデル（地理的条件による分割）
Fig.11 大中規模の組織におけるディレクトリ設計モデル（事業グループによる分割）
Fig.12 中小規模の組織におけるディレクトリ設計モデル（部門による分割）
Fig.13 小規模の組織におけるディレクトリ設計モデル（オブジェクトの種別による分割）
ところで，Active DirectoryにおけるOUはオブジェクトに対するアクセス制御に利用することはできない。たとえば，営業一課に相当するOUを作成したとしよう。このとき，営業一課に所属するユーザーにあるネットワークプリンタの利用を許可したいと思っても，そのアクセス制御にOUを用いることはできない。このような場面では，Windows NT 4.0と同様にグループオブジェクトを用いる。Windows 2000でも，アクセス制御の主体となるのはセキュリティプリンシパル（ユーザー，グループ，コンピュータ）である。残念ながら，OUはセキュリティプリンシパルには含まれない。つまり，OUの主要な役割は，(1) ネットワークリソースを階層化する，(2) ディレクトリに対する任意の権限をセキュリティプリンシパルに委譲する場合のセキュリティ境界となる，(3) グループポリシーの適用境界となる，という3つである。したがって，アクセス制御の主体としたい組織構造やプロジェクトチームなどは，グループで管理する必要がある（もちろん，組織構造をOUに反映させ，さらに重複する組織構造をグループに実装してもかまわない）。この点からも，組織構造をあまり忠実にOUで再現しないほうがよいだろう。ユーザーの利便性は高まるかもしれないが，管理者のコストは増大するからである。この点には，十分注意してもらいたい。
 |
Deployment of AD−Part1 11/17 |  |
