ディレクトリ設計

lpic ldap

管理したい情報の性質や組織の形態などにより、管理に適切なDITの構造は異なってくる。いったん作成したディレクトリの構造を改変するのは大変な労力がかかる為、基本構造の設計は慎重に行う。

DIT構造の設計

どのような情報をどのように管理するか検討し、適切なツリーを構築する。

ディレクトリ設計の原則
  • ディレクトリの上位から下位に向けて分類は細分化される。
  • アクセス管理を行う際、同一の権限を持つエントリが同一階層に存在する事が望ましい。
  • DNが一意になるようディレクトリを構築する。
深い階層を持つDITのメリット・デメリット
  • メリット
    • 詳細な検索ベースが得られるため、検索効率が上がる場合がある。
    • 階層をグループとして扱うことが出来る。
  • デメリット
    • 個別のエントリのDNが長くなる
    • ディレクトリのメンテナンスに手間がかかる。
浅い階層を持つDITのメリット・デメリット
  • メリット
    • 個別のエントリが短くなる。
    • ディレクトリのメンテナンスにかかる時間を軽減できる。
  • デメリット
    • 頻繁にエントリを更新する際の更新速度が低下する。
コンテナ

エントリを分類する目的のみに作られるエントリの事。


エントリの設計

エントリのオブジェクトクラス・属性の検討事項
  • エントリが持つ属性が属性値としてすべて表現できるかどうか。
  • エントリに必ず入れなければならない情報は何か、入る可能性のある情報は何か。
  • その情報はどのような値とて表現されるか(文字列/数値/画像データなど)
  • 検索の際にどのように利用されるものか(完全一致か、属性の有無のみか)


たいていの場合、あらかじめ用意されているスキーマファイルを利用すれば、一般的なデータは表現できる為、これらのスキーマファイルの内容を検討して、扱うべきデータの表現方法を検討する。

サービスクラス(Class of Service: CoS)

クライアントアプリケーションがエントリを取り出すときに計算された属性を動的に生成し、勤務地や電話番号などといった、複数のユーザが共通に利用する属性値の管理を集中化する事ができる機能。