Directory first step 5... ディレクトリ構築において考慮すべきポイント
ディレクトリ設計フェーズ
プロトタイプで十分にユーザーニーズを検証し，導入経験から考慮すべき点を洗い出したら，構築方針に基づいてディレクトリを設計する。ディレクトリサービスの構築に成功するかどうかは，ディレクトリ設計の良し悪しに大きく依存する。ディレクトリの設計は，時間をかけて検討してほしい。
ディレクトリ設計にあたって検討すべき主なポイントは，次のとおりである。ただし，ディレクトリサービス製品によって，異なる用語を用いていたり，設計ポイントが微妙に異なっていたりすることもあるので，注意してもらいたい。
ディレクトリツリー
ディレクトリを設計する場合には，ディレクトリツリーを論理的に上位レベルと下位レベルに分割し，ディレクトリツリーの上位レベルから順に設計してゆく。
上位レベルのディレクトリツリーには，変動の少ない静的なコンテナオブジェクトのみを配置する。たとえば，部や課のように変動する可能性の高いコンテナオブジェクトを上位レベルに配置してしまうと，組織変更のたびに全ディレクトリ構造を変更しなければならなくなる。これでは，運用や管理のコストを非常に増大させてしまう。また，Active Directoryのように最上位レベルのルートは変更できないものある。したがって，ディレクトリ構造全体に与える影響を小さくするためにも，たとえば会社（関連会社などを含む）や事業グループなど，変動の少ない静的なコンテナオブジェクトのみを上位レベルのディレクトリツリーに配置すべきである。ワールドワイドで展開されている多国籍企業であれば，組織ではなく地理的条件（アジアとか日本とか）を上位レベルのディレクトリツリーに格納する方法もあるだろう。いずれにせよ，上位レベルのディレクトリツリーに格納されるコンテナオブジェクトは，件数も少なくなり，階層も浅くなる。
下位レベルのディレクトリツリーには，比較的変動の激しいコンテナオブジェクトやオブジェクトを配置する。つまり，事業部, 部，課，係，グループ，ユーザー，コンピュータなど，組織の諸条件に応じて変動しやすいオブジェクトを格納するのである。
Fig.15 ディレクトリツリーの設計
ディレクトリのサイズ
ディレクトリには，ユーザーやコンピュータ以外にも，さまざまなオブジェクトや属性が格納されるようになる。そのため，従来型のディレクトリ以上に，格納される情報量は膨大になってゆく。たとえば，Windows NT 3.5/4.0におけるSAMでは，性能上問題にならないディレクトリサイズは40Mバイトまでであるとされてきた。しかし，今日的なディレクトリであれば，ハードウェアの性能が向上し，限界容量が増大していることもあって，この規模のデータ量であればそれほど問題になることはない。
しかし，たとえばWindows 2000で提供されるActive Directoryであれば，1ユーザーあたり約3Kバイトのディスク容量が必要となる（Windows NT 3.5/4.0におけるSAMであれば，約1Kバイトにしかならない）。ユーザーオブジェクトに必須プロパティ以外の属性を登録すれば，求められるディスク容量はさらに増大する。格納するオブジェクトや属性の数に応じてディレクトリのサイズも増加するので，用意するストレージ容量を慎重に検討しなければならない。また，ディレクトリのサイズが増大するのに伴って，検索性能が低下したり，レプリケーショントラフィックが増大したりするようであれば，その性能劣化も問題になる。
ディレクトリサーバーの台数
小規模なネットワークであれば，1台のディレクトリサーバーですべてを管理できる可能性もある。しかし，フォルトトレラントを向上させるためには，バックアップ用のディレクトリサーバーを最低限1台は用意しておいたほうがよい。
もし大規模なネットワークであれば，管理上の条件，地理的な条件，サービスの応答性能条件，フォルトトレラントの必要といった理由で，複数台のディレクトリサーバーを導入し，分散配置しなければならないだろう。そのため，設置すべきディレクトリサーバーの台数と設置場所，それに伴って発生するレプリケーショントラフィックを，十分に検証かつ検討する必要がある。
レプリケーショントラフィック
複数台のディレクトリサーバーが分散配置されている場合には，そのディレクトリサーバー間でディレクトリを同期させるため，レプリケーションが必要になる。その場合，レプリケーションによって得られる可用性と，ネットワークトラフィックの増大というトレードオフが発生する。ネットワークトラフィックを減少させるためには，レプリケーションの頻度とレプリケーション単位（フル，差分，増分）を検討しなければならない。
ユーザー認証と認証局
ディレクトリの目的は，ユーザーにさまざまな情報を提供することにある。しかし，だからといって，すべてのユーザーに対して無条件にディレクトリの情報を提供するわけではない。ディレクトリの情報を提供するときには，セキュリティの設定に従って制限が課せられる。ユーザーがディレクトリから情報の提供を受けるためには，ディレクトリの利用者として認証され，かつディレクトリの情報に対するアクセス権を所持している必要がある。ユーザー認証にあたって，オペレーティングシステムに固有の認証システムを利用するか，Kerberosのような標準化された認証システムを利用するかを検討する必要があるだろう。
もし第三者発行の電子証明書の機能を利用するのであれば，認証局（Certification Authority）が必要となる。この場合，認証局を社内に設置する（Windows 2000 Serverファミリに標準添付されるCertification Serverや，Netscape Certificate Serverなどを利用する）のか，外部の第三者機関を利用する（Verisignなどを利用する）のかを検討しなければならない。電子商取引システムでディレクトリサービスを使用するのであれば，外部の第三者機関を利用したほうがよいだろう。その場合には，相互運用性についても十分にチェックしておく必要がある。
たとえば，KerberosはRFCで提唱されている標準化された認証システムであるため，一見するとWindows 2000 Serverファミリに実装されているKerberosシステムは，それ以外のKerberosシステムとも相互運用できそうに思える。しかし，Kerberosのプロトコル仕様書に準拠した仕様になっていても，ベンダー固有のフィールドを定義できるようになっているため，必ずしもベンダー間で互換性があるとは限らない。Windows NTやWindows 2000のユーザー認証は，ログオン名ではなく，実際にはSID（Security IDentifier）という値に基づいて処理される。Windows 2000 Serverファミリに実装されているKerberosシステムは，SIDなどの情報を格納して認証に利用するため，ほかのKerberosシステムが発行したチケット――たとえばUNIX上のKerberosシステムが発行したチケット――をWindows 2000でそのまま認証することはできない。どうしてもこのような処理を実現させたければ，ログオン名をSIDに変換する仕組みを実装するか，あるいはサードパーティが提供するブリッジ製品を購入する必要がある。
ディレクトリサービスの実装とリソースの登録フェーズ
十分にディレクトリ設計を検討したら，その設計結果に従ってディレクトリサービスを実装し，リソースなどを登録してゆく。
 |
Directory first step（後編） 4/14 |  |
