Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

Directory Server の計画と設計

Red Hat Directory Server 12

効果的なディレクトリーサービスを計画するための概念と設定オプション

Red Hat Customer Content Services

概要

ディレクトリーツリー、スキーマ、トポロジー、レプリケーション、セキュリティーの設計など、ディレクトリー設計の側面を説明します。ディレクトリーサービスの利点とオプション、Directory Server の実装ストラテジー、および一般的な設定例を詳しく説明します。

Red Hat Directory Server に関するフィードバックの提供
リンクのコピー

Red Hat のドキュメントおよび製品に関するご意見をお待ちしております。ドキュメントの改善点があればお知らせください。改善点を報告する場合は、以下のように行います。

  • Jira を通じて Red Hat Directory Server ドキュメントに関するフィードバックを送信する場合 (アカウントが必要):

    1. Red Hat Issue Tracker にアクセスしてください。
    2. Summary フィールドにわかりやすいタイトルを入力します。
    3. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも追加してください。
    4. ダイアログの下部にある Create をクリックします。

  • Jira を通じて Red Hat Directory Server 製品に関するフィードバックを送信する場合 (アカウントが必要):

    1. Red Hat Issue Tracker にアクセスしてください。
    2. Create Issue ページで、Next をクリックします。
    3. Summary フィールドに入力します。
    4. Component フィールドでコンポーネントを選択します。

    5. Description フィールドに以下の内容を入力します。

      1. 選択したコンポーネントのバージョン番号。
      2. 問題を再現するための手順、または改善のための提案。
    6. Create をクリックします。

第1章 ディレクトリーサービスの概要
リンクのコピー

Red Hat Directory Server は集中型ディレクトリーサービスを提供します。Directory Server は既存のシステムと統合し、従業員、顧客、サプライヤー、パートナーの情報を統合するための集中化されたリポジトリーとして機能します。Directory Server を使用すると、ユーザープロファイルと認証を管理できます。

以下の章では、ディレクトリーを設計する前に理解しておく必要のある事項を説明します。

1.1. ディレクトリーサービスについて
リンクのコピー

ディレクトリーサービス とは、企業に関する情報を保存し、ユーザーにこの情報へのアクセスを提供するソフトウェア、ハードウェア、およびプロセスの集合を指します。ディレクトリーサービスは、少なくとも 1 つの Directory Server インスタンスと 1 つのディレクトリークライアントアプリケーションで構成されます。クライアントアプリケーションは、ディレクトリーに保存されている名前、電話番号、住所、その他のデータにアクセスできます。

ディレクトリーサービスの例としては、ドメインネームシステム (DNS) サーバーがあります。DNS はコンピューターのホスト名を IP アドレスにマッピングします。DNS クライアントは DNS サーバーに要求を送信し、サーバーは server.example.com の IP アドレスを応答します。したがって、すべてのホストは DNS サーバーのクライアントになります。さらに、ユーザーは IP アドレスではなくホスト名を記憶することで、ネットワーク上のコンピューターを簡単に見つけることができます。DNS サーバーの制限は、ホスト名と IP アドレスの 2 タイプの情報のみを保存することです。真のディレクトリーサービスは、ほぼ無制限のタイプの情報を保存します。

Red Hat Directory Server では、ネットワークでアクセス可能な 1 つのリポジトリーに次のデータを保存できます。

  • 組織内のプリンターに関するデータ (場所、製造元、購入日、シリアル番号など) などの物理デバイス情報。
  • 公務員情報: 氏名、メールアドレス、部門。
  • 従業員の個人情報: 給与、政府発行の身分証明書番号、自宅住所、電話番号、給与等級。
  • 契約またはアカウント情報: クライアントの名前、最終納期、入札情報、契約番号、プロジェクト日付。

Directory Server は、そこに含まれる情報にアクセスするための標準プロトコルとアプリケーションプログラミングインターフェイス (API) を提供し、多くのアプリケーションのニーズに応えます。

1.1.1. グローバルディレクトリーサービスについて
リンクのコピー

Red Hat Directory Server は、さまざまなアプリケーションに情報を提供することで、グローバルディレクトリーサービスを提供します。最近まで、多くのアプリケーションには、そのアプリケーションに固有のユーザー情報を含む独自のプロプライエタリーユーザーデータベースがバンドルされていました。プロプライエタリーデータベースは、1 つのアプリケーションのみを使用する場合は便利ですが、複数のデータベースで同じ情報を管理する場合は、管理上の負担になります。

たとえば、ある会社が 3 つの異なるプロプライエタリーメールシステムを実行しており、各メールシステムには独自のプロプライエタリーディレクトリーサービスがあるとします。ユーザーが 1 つのディレクトリーでパスワードを変更した場合、その変更は他のディレクトリーに自動的にレプリケートされません。同じ情報を異なる場所で管理すると、ハードウェアと人件費が増加します。メンテナンスのオーバーヘッドの増加は、n+1 ディレクトリー問題 と呼ばれます。

グローバルディレクトリーサービスは、あらゆるアプリケーションからアクセスできる集中リポジトリーを提供することで、n+1 ディレクトリーの問題を解決します。ただし、さまざまなアプリケーションにディレクトリーサービスへのアクセスを許可するには、アプリケーションとディレクトリーサービス間のネットワークベースの通信手段が必要です。

Red Hat Directory Server は、アプリケーションがグローバルディレクトリーサービスにアクセスするように LDAP を使用します。

1.1.2. LDAP について
リンクのコピー

LDAP は、クライアントアプリケーションとサーバーが相互に通信するために使用する共通の言語を提供します。LDAP は、ISO X.500 標準で説明されている Directory Access Protocol (DAP) の "軽量" バージョンです。

DAP は、拡張可能かつ堅牢な情報フレームワークを使用して、アプリケーションアクセスを提供しますが、管理コストが高まります。DAP は、インターネット標準プロトコルではなく、複雑なディレクトリーの名前規則を持つ通信層を使用します。

LDAP は DAP の最良の機能を維持し、管理コストを削減します。LDAP は、TCP/IP を介して実行するオープンディレクトリーアクセスプロトコルを使用し、簡素化したエンコーディングメソッドを使用します。ハードウェアおよびネットワークインフラストラクチャーへの投資を抑えながら、データモデルを保持し、数百万のエントリーをサポートすることができます。

1.2. Directory Server の概要
リンクのコピー

Red Hat Directory Server にはいくつかのコンポーネントがあります。ディレクトリーコアは、LDAP プロトコルを実装するサーバーです。Red Hat Directory Server では、さまざまな LDAP クライアント、LDAP SDK を使用して作成されたサードパーティー製アプリケーション、カスタムアプリケーションを使用できます。

Red Hat Directory Server のインストールには、次の要素が含まれます。

Directory Server は、他の LDAP クライアントアプリケーションなしでイントラネットまたはエクストラネットの基盤を提供します。互換性のあるサーバーアプリケーションは、従業員、顧客、サプライヤー、パートナーデータなどの共有サーバー情報の中央リポジトリーとしてディレクトリーを使用します。Directory Server は、ユーザー認証、アクセス制御、ユーザー設定を管理します。ホストされる環境では、パートナー、顧客、およびサプライヤーは、ディレクトリー部分を管理し、管理コストを削減できます。

Directory Server は、データベース層、レプリケーション、データベースのチェイニングなどの追加機能のために プラグイン に依存しています。コアディレクトリーサービス操作に関連しないプラグインを無効にすることができます。

1.2.1. Directory Server フロントエンドの概要
リンクのコピー

Directory Server はマルチスレッドアプリケーションです。つまり、複数のクライアントを同時に同じネットワーク上でサーバーにバインドできます。ディレクトリーサービスが拡張されて、より多くのエントリーや地理的に分散したクライアントが含まれるようになると、ネットワーク上の戦略的な場所に配置された複数の Directory Server もサービスに含まれるようになります。

Directory Server のサーバーフロントエンドは、LDAP over TCP/IP および LDAP over Unix ソケット (LDAPI) を使用して、ディレクトリークライアントアプリケーションとの通信を管理します。

Directory Server は、クライアントが接続に TLS を使用するようにネゴシエートするかどうかに応じて、Transport Layer Security (TLS) を使用してセキュアな (暗号化された) 接続を確立できます。クライアントに証明書が発行されている場合、Directory Server は TLS を使用して、クライアントがサーバーにアクセスする権限を持っていることを確認できます。さらに、TLS は、メッセージの整合性チェック、デジタル署名、サーバー間の相互認証など、その他のセキュリティーアクティビティーを実行するために使用されます。

1.2.2. 基本的な Directory Server ツリーの概要
リンクのコピー

ディレクトリーツリーは、ディレクトリー情報ツリー (DIT) とも呼ばれ、ほとんどのファイルシステムで使用されるツリーモデルを反映しています。インストール時に、Directory Server はデフォルトのディレクトリーツリーを作成します。

デフォルトのディレクトリーツリー

dg introduction1

インストール後、ディレクトリーには次の root 接尾辞とサブツリーが含まれます。

  • Root DSE (Root DSA 固有のエントリー) は、LDAP サーバーの特別なエントリーです。Root DSE 識別名 (DN) は長さがゼロの文字列です。
  • cn=config には、サーバーの内部設定に関する情報が含まれています。
  • cn=monitor には、サーバーおよびデータベースのモニタリングが統計が含まれます。
  • cn=schema には、現在サーバーにロードされているスキーマ要素が含まれます。
  • user root suffix は、セットアップ時に Directory Server が作成するデフォルトのユーザーデータベースの接尾辞です。Directory Server インスタンスを作成するときに、ユーザーの root 接尾辞名を定義します。多くの場合、ユーザー root 接尾辞には dc=example,dc=com などの dc 命名規則が適用されるか、o=example.com などの組織を表す o 属性が使用されます。ユーザー接尾辞の命名については、接尾辞の選択 を参照してください。root ユーザー接尾辞は、userRoot データベースに関連付けられています。後で LDIF ファイルをインポートするか、エントリーを作成してデータベースにデータを入力します。

ディレクトリーのインストールに関連するデータを追加することで、デフォルトのディレクトリーツリーを拡張できます。ディレクトリーツリーの詳細は、ディレクトリーツリーの設計 を参照してください。

1.3. Directory Server のデータストレージ
リンクのコピー

データベースは、ストレージ、パフォーマンス、レプリケーション、およびインデックス化の基本単位です。データベースに対して、インポート、エクスポート、バックアップ、復元、インデックス作成などの操作を実行できます。Directory Server は、データを LDAP Database Manager (LDBM) データベースに保存します。LDBM データベースは、ディレクトリーと共に自動的にインストールされるプラグインとして実装され、デフォルトで有効になります。

デフォルトでは、Directory Server は root 接尾辞に対して 1 つのバックエンドデータベースインスタンスを使用します。ディレクトリーツリーを含めるには、1 つのデータベースで十分です。このデータベースは、数百万のエントリーを管理できます。このデータベースは、データ損失を最小限に抑えるために、データのバックアップと復元の高度な方法をサポートしています。

ただし、複数のデータベースを使用して Directory Server のデプロイメント全体をサポートし、単一のデータベースに保存できる量よりも多くのデータを管理できます。

1.3.1. ディレクトリーエントリーについて
リンクのコピー

LDAP データ交換形式 (LDIF) は、ディレクトリーエントリーを記述する標準的なテキストベースの形式です。エントリーは LDIF ファイル内の複数の行で構成され、組織内の人物やネットワーク上のプリンターなどのオブジェクトに関する情報を含んでいます。

エントリーに関する情報は、属性とその値のセットとして表されます。各エントリーには、エントリーが記述するオブジェクトのタイプを指定し、エントリーに含まれる追加属性のセットを定義するオブジェクトクラス属性があります。各属性は、エントリーの特定の特性を記述します。

たとえば、エントリーには、そのエントリーが組織内の人物を表すことを示す organizationalPerson オブジェクトクラスを設定できます。このオブジェクトクラスは、givenName 属性および telephoneNumber 属性をサポートします。これらの属性に割り当てられた値は、エントリーに表示される人物の名前と電話番号を定義します。

Directory Server は、サーバーが計算する読み取り専用の 操作属性 も使用します。管理者は、アクセス制御やその他のサーバー機能のこれらの操作属性を手動で設定できます。

ディレクトリーエントリーの検索を実行する

ディレクトリーツリーは、エントリーを階層構造で格納します。LDAP は、データベースのエントリーにクエリーを行い、ディレクトリーツリー内のブランチの下にあるすべてのエントリーを要求するツールをサポートしています。ブランチサブツリーの root は、ベース識別名、または ベース DN と呼ばれます。たとえば、ou=people,dc=example,dc=com のベース DN を指定して LDAP 検索要求を実行する場合、検索操作では dc=example,dc=com ディレクトリーツリー内の ou=people サブツリーのみがチェックされます。

デフォルトでは、LDAP 検索ではすべてのエントリーが返されず、ldapsubentry オブジェクトクラスを持つ管理エントリーが除外されます。管理エントリーを使用してロールまたはサービスクラスを定義できます。これらのエントリーを検索応答に含めるには、クライアントアプリケーションは ldapsubentry オブジェクトクラスを使用してエントリーをさらに検索する必要があります。

1.3.2. ディレクトリーデータの分散
リンクのコピー

ディレクトリーツリーの一部を別のデータベースに保存すると、ディレクトリーはクライアント要求を並行して処理できるため、パフォーマンスが向上します。さらにパフォーマンスを向上させるために、データベースを別のマシンに保存することもできます。ディレクトリーの一部を接続するために、Directory Server はデータベースリンクとチェイニングを使用します。データベースリンクとチェイニングの詳細は、Directory Server でのリファラルの使用 を参照してください。

1.4. 設計プロセスの概要
リンクのコピー

  1. ディレクトリーデータの計画

    ディレクトリーには、ユーザー名、電話番号、グループの詳細などのデータが含まれます。計画の章では、組織内のさまざまなデータソースを分析し、それらの関係を理解するのに役立ちます。ディレクトリーに保存できるデータのタイプと、Directory Server のコンテンツを設計するために実行するタスクを理解します。

  1. ディレクトリースキーマの設計

    ディレクトリーは、1 つ以上のディレクトリー対応アプリケーションをサポートするように設計されています。これらのアプリケーションには、ファイル形式など、ディレクトリーに保存されるデータに対する要件があります。ディレクトリースキーマによってこのデータの特性が決まります。Directory Server に同梱される標準スキーマ、スキーマをカスタマイズする方法の説明、および一貫したスキーマを維持するためのヒントを説明します。

  1. ディレクトリーツリーの設計

    データ階層設計の概要および例を読んだ後、保存されたデータをどのように整理して参照するかを決定します。

  1. ディレクトリートポロジーの設計

    ディレクトリーを複数の物理 Directory Server に分割する予定の場合のトポロジー設計と、これらのサーバーが相互に通信する方法を説明します。

  1. レプリケーションプロセスの設計

    レプリケーションの概念、レプリケート可能なデータのタイプ、さまざまなレプリケーションシナリオ、高可用性ディレクトリーサービスのヒントを説明します。

  1. セキュアなディレクトリーの設計

    ディレクトリーを保護する方法を確認します。セキュリティーの脅威、セキュリティーメソッドの概要、セキュリティー分析の手順、ディレクトリーデータの整合性を保護するためのアクセス制御の設計に関するヒントを説明します。

  1. 同期の設計

    混合プラットフォームインフラストラクチャーでは、Microsoft Active Directory データベースに保存されている情報との同期を検討してください。

1.5. ディレクトリーのデプロイ
リンクのコピー

まず、テストサーバーインスタンスをインストールして、サービスがユーザーの負荷を処理できることを確認します。サービスの初期設定が最適でない場合は、設計を調整して再度テストします。企業のニーズを満たすまで設計を調整します。

適切なテスト用 Directory Server インスタンスを作成して調整した後に、ディレクトリーサービスを実稼働環境に移行するための計画を作成します。計画には、以下の考慮事項を含めます。

  • 必須リソースの推定
  • 達成すべき事項および時期に関するスケジュール
  • 導入の成功を測定するための基準セット

第2章 ディレクトリーデータの計画
リンクのコピー

ディレクトリーデータには、ユーザー名、メールアドレス、電話番号、ユーザーグループ、その他の情報が含まれます。ディレクトリーに保存するデータの種類によって、ディレクトリー構造、データに与えられるアクセス権、およびこのアクセスの要求方法と許可方法が決まります。

2.1. ディレクトリーデータの概要
リンクのコピー

ディレクトリーに適したデータには、次の特性があります。

  • データは書き込まれるよりも頻繁に読み取られます。
  • データは属性値形式 (例: surname=jensen) で表現できます。
  • データは、個人やグループだけに役立つものではありません。たとえば、複数のユーザーやアプリケーションが従業員名やプリンターのロケーションを使用する場合があります。
  • データは複数の物理的なロケーションからアクセスされます。

たとえば、ソフトウェアアプリケーションに対する従業員の環境設定は、アプリケーションの 1 つのインスタンスのみが情報にアクセスする必要があるため、ディレクトリーには適していません。ただし、アプリケーションがディレクトリーから環境設定を読み取ることができ、ユーザーがさまざまなサイトから独自の環境設定に応じてアプリケーションを使用したい場合は、そのような設定をディレクトリーに含めると便利です。

2.1.1. ディレクトリーに含める情報
リンクのコピー

人物やアセットに関する有用な情報を属性としてエントリーに追加できます。以下に例を示します。

  • 電話番号、物理アドレス、メールアドレスなどの連絡先情報
  • 従業員番号、ジョブタイトル、マネージャーまたは管理者 ID、仕事に関する興味などの説明情報
  • 組織の連絡先情報 (電話番号、物理アドレス、管理者 ID、ビジネスの説明など)
  • プリンターの物理的なロケーション、プリンターの種類、プリンターが 1 分あたりに印刷できるページ数などのデバイス情報。
  • 企業の取引パートナー、取引先、および顧客に関する連絡先および請求情報
  • 顧客の名前、納期、ジョブの説明、課金情報などのコントラクト情報
  • 個別のソフトウェア設定またはソフトウェア設定情報
  • Web サーバーへのポインター、または特定のファイルまたはアプリケーションのファイルシステムなどのリソースサイト

Directory Server をサーバー管理目的以外にも使用するには、他にどのようなタイプの情報をディレクトリーに格納するかを計画する必要があります。たとえば、以下のような種類の情報を含めることができます。

  • コントラクトまたはクライアントアカウントの詳細
  • 給与データ
  • 物理デバイス情報
  • 自宅連絡先情報
  • 企業内のさまざまな拠点のオフィス連絡先情報

2.1.2. ディレクトリーから除外する情報
リンクのコピー

Red Hat Directory Server は、クライアントアプリケーションが読み取り、時々更新する大量のデータを適切に管理しますが、Directory Server は、イメージやその他のメディアなどの大規模で構造化されていないオブジェクトを処理するようには設計されていません。これらのオブジェクトはファイルシステムで管理する必要があります。ただし、ディレクトリーには、FTP、HTTP、およびその他の URL タイプを使用して、これらのタイプのアプリケーションへのポインターを保存できます。

2.2. ディレクトリーニーズの定義
リンクのコピー

ディレクトリーデータを設計する場合は、現在必須なデータだけでなく、ディレクトリー (および組織) が時間の経過と共にどのように変化する可能性があるかも考慮できます。設計プロセス中にディレクトリーの今後のニーズを検討することは、ディレクトリー内のデータの構造と配布方法に影響を及ぼします。

以下の点も考慮してください。

  • 今日、ディレクトリーには何が必要ですか?
  • ディレクトリーをデプロイすることで解決したい当面の問題は何ですか?
  • 使用しているディレクトリー対応アプリケーションに当面必要なことは何ですか?
  • 近い将来、ディレクトリーに何を追加したいですか? たとえば、企業は現在 LDAP をサポートしていない会計パッケージを使用していますが、この会計パッケージは数カ月以内に LDAP 対応になる予定です。LDAP 対応アプリケーションで使用されるデータを特定し、技術が利用可能になった時点でデータをディレクトリーに移行する計画を作成します。
  • 今後ディレクトリーに保存したい情報は何ですか?たとえば、ホスティング会社は、イメージやメディアファイルの保存など、現行の顧客とは異なるデータ要件を持つ顧客を今後持つ可能性があります。このように計画すると、まったく考慮していなかったデータソースを特定するのに役立ちます。

2.3. サイト調査の実行
リンクのコピー

サイト調査 は、ディレクトリーの内容を検出し特徴付けるための正式な方法です。ディレクトリーアーキテクチャーの準備は非常に重要なので、調査の実行にはさらに時間を割くよう計画してください。サイト調査は次のタスクで構成されます。

  • ディレクトリーを使用するアプリケーションを特定する。

    エンタープライズ全体にデプロイされるディレクトリー対応アプリケーションとそのデータのニーズを判断する。

  • データソースを特定する。

    企業を調査し、Active Directory、その他の LDAP サーバー、PBX システム、人事データベース、メールシステムなどのデータソースを特定します。

  • ディレクトリーに含まれる必要のあるデータを特徴付ける。

    ディレクトリーに存在すべきオブジェクト (例: 人またはグループ) と、ディレクトリーで維持すべきこれらのオブジェクトの属性 (ユーザー名とパスワードなど) を決定します。

  • 提供するサービスレベルを決定する。

    クライアントアプリケーションのディレクトリーデータの可用性を決定し、それに応じてアーキテクチャーを設計します。ディレクトリーの可用性は、リモートサーバーに保存されているデータを接続するためのデータレプリケーションおよびチェイニングポリシーを設定する方法に影響を及ぼします。

  • データサプライヤーを特定する。

    データサプライヤーには、ディレクトリーデータのプライマリーソースが含まれます。負荷分散と回復の目的で、このデータを他のサーバーにミラーリングすることができます。各データのデータサプライヤーを決定します。

  • データの所有者を決定する。

    データごとに、データ更新の責任者を決定します。

  • データアクセスを決定する。

    他のソースからデータをインポートする場合は、一括インポートと増分更新の両方のストラテジーを立てます。このストラテジーの一部として、データを 1 カ所で管理し、データを変更できるアプリケーションの数を制限するようにします。また、任意のデータに書き込みするユーザーの数を制限します。グループを小さくすると、管理オーバーヘッドが削減され、データの整合性が確保されます。

  • サイト調査を文書化します。

ディレクトリーが複数の組織に影響を与える場合は、影響を受ける各組織の代表者を含むディレクトリーデプロイメントチームを編成してサイト調査を実施することを検討してください。

企業には、一般的に、人事部門、経理部門、製造部門、営業部門、および開発部門があります。これらの各組織の代表者を含めると、調査プロセスを実行し、ローカルデータストアから集中型ディレクトリーに移行しやすくなります。

2.3.1. ディレクトリーを使用するアプリケーションの特定
リンクのコピー

ディレクトリーにアクセスするアプリケーションおよびこれらのアプリケーションのデータニーズが、ディレクトリー内容の計画におけるガイドとなります。ディレクトリーを使用するさまざまな一般的なアプリケーションには、以下があります。

  • オンライン電話帳などのディレクトリーブラウザーアプリケーション。ユーザーが必要とする情報を決定し、それをディレクトリーに含めます。
  • 電子メールアプリケーション (特に電子メールサーバー)すべてのメールサーバーでは、ディレクトリー内でルーティング情報が利用可能である必要があります。ただし、ユーザーのメールボックスが保存されるディスク上の場所、休暇通知の詳細、IMAP と POP などのプロトコル情報など、より詳細な情報が必要になる場合もあります。
  • ディレクトリー対応人事アプリケーション。これらには、政府発行の身分証明書番号、自宅住所、自宅電話番号、生年月日、給与、役職などの追加の個人情報が必要です。
  • Microsoft Active Directory.Windows User Sync を使用すると、Windows ディレクトリーサービスを統合して、Directory Server と連携して機能させることができます。どちらのディレクトリーにも、ユーザー情報とグループ情報を保存できます。既存の Windows サーバーのデプロイメントの後に Directory Server のデプロイメントを設定して、ユーザー、グループ、およびその他のディレクトリーデータを同期できるようにします。

ディレクトリーを使用するアプリケーションを評価するときは、各アプリケーションが使用する情報の種類を考慮してください。次の表は、アプリケーションとそのアプリケーションが使用する情報の例を示しています。

表 2.1.アプリケーションデータニーズの例

Expand
アプリケーションデータのクラスデータ

電話帳

人

名前、メールアドレス、電話番号、ユーザー ID、パスワード、部署番号、マネージャー、メール停止

Web server

人、グループ

ユーザー ID、パスワード、グループ名、グループメンバー、グループ所有者

カレンダーサーバー

人、会議室

名前、ユーザー ID、部屋番号、会議室名

アプリケーションと各アプリケーションが使用する情報を特定すると、複数のアプリケーションで使用されるデータの種類がわかります。この計画手順により、ディレクトリー内のデータの冗長性を防ぎ、ディレクトリーに依存するアプリケーションに必要なデータを明確に示すことができます。

ディレクトリーに保持されるデータの種類と、情報をディレクトリーに移行するタイミングに関する最終決定には、次の要因が影響します。

  • さまざまなレガシーアプリケーションとユーザーが必要とするデータ
  • レガシーアプリケーションの LDAP ディレクトリーと通信する能力

2.3.2. データソースの特定
リンクのコピー

ディレクトリーに含めるすべてのデータを決定するには、既存のデータストアの調査を実行します。調査には以下を含める必要があります。

  • 情報を提供する組織を特定する。

    情報サービス、人事、給与、経理部門など、重要な情報を管理するすべての組織を特定します。

  • 情報ソースであるツールおよびプロセスを特定する。

    情報の一般的なソースには、ネットワークオペレーティングシステム (Windows、Novell Netware、UNIX NIS)、電子メールシステム、セキュリティーシステム、PBX (電話交換) システム、および人事アプリケーションなどがあります。

  • 各データの集中化がデータ管理にどのような影響を与えるかを判断します。

    集中データ管理では、新しいツールおよび新しいプロセスが必要になる場合があります。場合によっては、集中化により組織内での人員配置や人員削減が必要になることがあります。

調査中は、次の表のように企業内のすべての情報ソースを特定するマトリックスを作成します。

表 2.2.情報源の例

Expand
データソースデータのクラスデータ

人事データベース

人

名前、住所、電話番号、部署番号、マネージャー

E メールシステム

人、グループ

名前、メールアドレス、ユーザー ID、パスワード、メール設定

ファシリティーシステム

ファシリティー

ビル名、フロア名、部屋番号、アクセスコード

2.3.3. ディレクトリーデータの特徴付け
リンクのコピー

ディレクトリーに含めるデータを次の方法で特徴付けます。

  • 形式
  • サイズ
  • 各種アプリケーションで発生回数
  • データの所有者
  • 他のディレクトリーデータとの関係

ディレクトリーに含めるデータの共通の特性を見つけます。これにより、ディレクトリースキーマの設計 で説明したスキーマ設計段階での時間を節約できます。

ディレクトリーデータの特徴を示す以下の表を検討してください。

表 2.3.ディレクトリーデータの特性

Expand
データ形式サイズ所有者関連

従業員名

テキスト文字列

128 文字

人事

ユーザーエントリー

Fax 番号

電話番号

14 桁の数字

ファシリティー

ユーザーエントリー

メールアドレス

Text

多くの文字

情報システム部門

ユーザーエントリー

2.3.4. サービスレベルの決定
リンクのコピー

提供するサービスレベルは、ディレクトリー対応アプリケーションを利用するユーザーの期待に応じて異なります。各アプリケーションに必要なサービスレベルを決定するには、アプリケーションがいつ、どのように使用されるかを決定します。

ディレクトリーは、進化するにつれて、実稼働レベルからミッションクリティカルなレベルまで、さまざまなサービスレベルをサポートする必要が生じる場合があります。ディレクトリーのデプロイメント後にサービスレベルを上げることは難しいため、初期設計が将来のニーズを満たしていることを確認してください。

たとえば、完全な障害のリスクを排除するには、複数のサプライヤーが同じデータを処理するマルチサプライヤー設定を使用します。

2.3.5. データサプライヤーの検討
リンクのコピー

データサプライヤー は、データを供給するサーバーです。同じ情報を複数の場所に保存すると、データの整合性が低下します。データサプライヤーにより、複数のロケーションに保存されているすべての情報の一貫性が保たれ、正確性が確保されます。次のシナリオではデータサプライヤーが必要です。

  • Directory Server 間のレプリケーション
  • Directory Server と Active Directory との間の同期
  • Directory Server データにアクセスする独立したクライアントアプリケーション

マルチサプライヤーレプリケーションを使用すると、Directory Server は複数のサーバー上に情報のメインコピーを含むことができます。複数のサプライヤーが changelog を保持し、競合を安全に解決します。変更を受け入れ、レプリカサーバーまたはコンシューマーサーバーにデータをレプリケートできるサプライヤーサーバーの数を制付きで設定できます。 [1].複数のデータサプライヤーサーバーは、サーバーがオフラインになった場合に安全なフェイルオーバーを提供します。マルチサプライヤーレプリケーションの詳細は、TBA[レプリケーションプロセスの設計] を参照してください。

同期を使用すると、Directory Server のユーザー、グループ、属性、およびパスワードを Microsoft Active Directory のユーザー、グループ、属性、およびパスワードと統合できます。ディレクトリーサービスが 2 つある場合は、同じ情報を管理するかどうか、その情報をどの程度共有するか、どのサービスがデータを提供するかを決定します。可能ならば、データを管理するために 1 つのアプリケーションを選択し、同期プロセスによって他のサービスのエントリーを追加、更新、または削除します。

ディレクトリーと間接的に通信するアプリケーションを使用する場合は、データのサプライヤーソースを考慮してください。データ変更プロセスをできるだけシンプルに保ちます。データを管理する場所を決定したら、そこに含まれる他のすべてのデータを同じ場所で管理します。企業全体でデータベースの同期が失われた場合、1 カ所にデータがあるとトラブルシューティングが簡単になります。

データを提供するには、次の方法を実装できます。

  • ディレクトリーと、ディレクトリーを使用しないすべてのアプリケーションの両方でデータを管理します。

    複数のデータサプライヤーを維持する場合、データを転送するためのカスタムスクリプトは必要ありません。この場合、企業全体でデータの非同期化を防ぐために、他のすべてのサイトでデータを変更する必要がありますが、これはディレクトリーの目的に反します。

  • ディレクトリー以外のアプリケーションでデータを管理し、そのデータをディレクトリーにインポートするためのスクリプト、プログラム、またはゲートウェイを作成します。

    すでにアプリケーションを使用してデータを管理している場合は、ディレクトリー以外のアプリケーションでデータを管理することが最も理想的です。また、ディレクトリーは、オンラインの企業電話帳などの検索にのみ使用します。

データのメインコピーをどのように維持するかは、特定のディレクトリーのニーズによって異なります。ただし、メンテナンスは常にシンプルかつ一貫したものにしてください。たとえば、複数の場所でデータを管理し、競合するアプリケーション間でデータを自動的に交換するような試みは行わないでください。このような試みが行われると、更新が失われ、管理オーバーヘッドが増加します。

たとえば、ディレクトリーは、LDAP ディレクトリーと人事データベースの両方に保存されている従業員の自宅電話番号を管理します。人事アプリケーションは LDAP 対応であり、LDAP ディレクトリーから人事データベースへ、またその逆方向にデータを自動的に転送できます。

LDAP ディレクトリーと人事データベースの両方で従業員の電話番号の変更を管理しようとすると、電話番号が最後に変更された場所の情報が他のデータベースの情報を上書きします。これは、データを書き込んだ最後のアプリケーションに正しい情報があった場合にのみ許容されます。

その情報が古くなっている場合 (たとえば、人事データがバックアップから復元された場合)、LDAP ディレクトリー内の正しい電話番号は削除されます。

2.3.6. データの所有者の決定
リンクのコピー

データの所有者 は、データを最新の状態に維持する人または組織を指します。データ設計フェーズで、ディレクトリーにデータを書き込むことができるユーザーを決定します。データの所有権を決定するための一般的なストラテジーは次のとおりです。

  • ディレクトリーコンテンツマネージャーの小さなグループ以外のすべてのユーザーに対して、ディレクトリーへの読み取り専用アクセスを許可します。
  • 個々のユーザーが、パスワード、組織内でのロール、自動車のナンバープレート番号、電話番号やオフィス番号などの連絡先情報、自分自身の説明情報など、戦略的な情報のサブセットを管理できるようにします。
  • 人事マネージャーが、連絡先情報や役職など、その人事情報の戦略的なサブセットを書き込むことを許可します。
  • 組織管理者がその組織のエントリーを作成および管理できるようにし、ディレクトリーコンテンツマネージャーとして機能できるようにします。
  • 読み取りまたは書き込みアクセス権限を持つユーザーグループのロールを作成します。人事、財務、会計のロールを作成できます。これらの各ロールに、グループが必要とするデータへの読み取りアクセス、書き込みアクセス、またはその両方を許可します。これには、給与情報、マイナンバー、および自宅電話番号および住所が含まれる可能性があります。

複数の個人が同じ情報への書き込みアクセス権を必要とする場合があります。たとえば、情報システムまたはディレクトリー管理グループでは、従業員のパスワードへの書き込みアクセス権が必要になる場合があります。また、従業員には自分のパスワードへの書き込みアクセス権が必要です。複数の人が同じ情報にアクセスできますが、データの整合性を確保するために、このグループを小規模かつ識別可能な状態に保つようにしてください。

関連情報

2.3.7. データアクセスの決定
リンクのコピー

データの所有権を決定した後、各データを読み取るアクセス権を誰が持つかを決定します。たとえば、従業員の自宅電話番号はディレクトリーに保存できます。このデータは、従業員マネージャーや人事部門を含む多くのユーザーにとって役立つ可能性があります。従業員は、検証目的でこの情報を読み取ることができる必要があります。ただし、自宅の連絡先情報は機密情報とみなされる可能性があります。

ディレクトリーに保存されるすべての情報について、次の点を考慮してください。

  • 誰かが匿名でデータを読むことはできますか?

    LDAP プロトコルは匿名アクセスをサポートし、情報を簡単に検索できるようにします。ただし、匿名性により誰でもディレクトリーにアクセスできるため、この機能は慎重に使用してください。

  • 誰かが企業全体でデータを広く読み取ることができますか?

    アクセス制御は、クライアントが特定の情報を読み取るためにディレクトリーへログイン (またはバインド) する必要があるのと同じ方法で設定できます。匿名アクセスとは異なり、このタイプのアクセス制御では、組織のメンバーのみがディレクトリー情報にアクセスできます。さらに、Directory Server のアクセスログには、情報にアクセスしたユーザーに関する記録が含まれます。

    アクセス制御の詳細は、アクセス制御の設計 を参照してください。

  • データにアクセスする必要がある、識別可能な人々またはアプリケーションのグループはありますか?

    データへの書き込み権限を持つユーザーは、読み取りアクセスも必要です (パスワードへの書き込みアクセスを除く)。ディレクトリーには、特定の組織またはプロジェクトグループに固有のデータも含めることができます。これらのアクセスのニーズを特定することは、ディレクトリーが必要とするグループ、ロール、およびアクセス制御を把握するのに役立ちます。

    グループとロールの詳細は、ディレクトリーツリーの設計 を参照してください。アクセス制御の詳細は、アクセス制御の設計 を参照してください。

ディレクトリーデータごとに、これらの決定を行うと、ディレクトリーのセキュリティーポリシーが定義されます。これらの決定は、サイトの性質と、そのサイトですでに利用可能なセキュリティーによって異なります。たとえば、ファイアウォールがあったりインターネットに直接アクセスできない場合は、ディレクトリーがインターネットに直接配置される場合よりも匿名アクセスのサポートは安全です。さらに、一部の情報では、アクセスを適切に制限するためにアクセス制御と認証手段のみが必要になる場合があります。その他の機密情報は、データベースに保存される際に暗号化する必要がある場合があります。

ほとんどの国のデータ保護法では、企業が個人情報をどのように維持し、アクセスするかを規定しています。たとえば、法律により、情報への匿名アクセスが禁止されていたり、ユーザーが自分を表すエントリーの情報を表示および編集する権限を持つことが求められたりする場合があります。組織の法務部門に問い合わせて、ディレクトリーのデプロイメントが企業が運営されている国のデータ保護法に準拠していることを確認します。

セキュリティーポリシーの作成とその実装方法は、安全なディレクトリーの設計 で詳しく説明されています。

レプリケーションでは、コンシューマーサーバー (レプリカサーバー) がサプライヤーサーバーまたはハブサーバーから更新を受信します。


[1] レプリケーションでは、コンシューマーサーバー (レプリカサーバー) がサプライヤーサーバーまたはハブサーバーから更新を受信します。

2.4. サイト調査の文書化
リンクのコピー

データ設計の複雑性により、サイト調査の結果を文書化します。サイト調査のすべてのステップで、シンプルなテーブルを使用してデータを追跡できます。決定事項と未解決の懸念事項を概説したサプライヤーテーブルを作成できます。可能ならば、コンテンツを簡単に並べ替えたり検索したりできるスプレッドシートを使用してください。

以下の表は、サイト調査で特定された各データのデータ所有権とデータアクセスを示しています。

Expand
表2.1 例: データ所有者およびアクセスのリスト
データ名所有者サプライヤーサーバー/アプリケーション自己読み取り/書き込みグローバルな読み取り人事部門による書き込み情報システム部門による書き込み

従業員名

HR

PeopleSoft

読み取り専用

はい (匿名)

はい

はい

ユーザーパスワード

IS

Directory US-1

読み取り/書き込み

いいえ

いいえ

はい

自宅電話番号

HR

PeopleSoft

読み取り/書き込み

いいえ

はい

いいえ

従業員のロケーション

IS

Directory US-1

読み取り専用

はい (ログインが必要)

いいえ

はい

オフィスの電話番号

ファシリティー

Phone switch

読み取り専用

はい (匿名)

いいえ

いいえ

表の各行には、評価対象の情報の種類、その情報に関心のある部門、その情報の使用方法とアクセス方法が示されています。たとえば、1 行目では、従業員名 データには以下のような管理上の考慮事項があります。

  • 所有者:この情報は人事部門が所有するため、その更新と変更の責任は人事部門にあります。
  • サプライヤーサーバー/アプリケーション:PeopleSoft アプリケーションは従業員名の情報を管理します。
  • 自己読み取り/書き込み:自分の名前は読むことはできますが、書く (または変更する) ことはできません。
  • グローバルな読み取り:従業員名は、ディレクトリーにアクセスできるすべてのユーザーが匿名で読むことができます。
  • 人事部門による書き込み:人事グループのメンバーは、ディレクトリー内の従業員名を変更、追加、削除できます。
  • 情報システム部門による書き込み:情報サービス (IS) グループのメンバーは、ディレクトリー内の従業員名を変更、追加、削除できます。

2.5. サイト調査の繰り返し
リンクのコピー

特に企業が複数の都市や国にオフィスを構えている場合は、複数のサイト調査が必要になることがあります。情報に対するニーズが非常に複雑なので、複数の異なる組織では、1 つの集中型サイトではなくローカルのオフィスで情報を維持する必要があるかもしれません。

この場合、情報のメインコピーを維持する各オフィスでは、独自のサイト調査を実行する必要があります。サイト調査が完了したら、各調査の結果を中心となるチーム (おそらく各オフィスの代表者で構成) に返して、企業全体のデータスキーマモデルとディレクトリーツリーの設計に使用する必要があります。

第3章 ディレクトリースキーマの設計
リンクのコピー

ディレクトリースキーマは、ディレクトリー内のデータの種類を記述します。ディレクトリーに保存されているデータの表現がわかっている場合は、使用するスキーマを決定できます。スキーマ設計プロセス中に、各データ要素は LDAP 属性にマップされ、関連する要素は LDAP オブジェクトクラスに集められます。適切に設計されたスキーマは、ディレクトリーデータの整合性を維持するのに役立ちます。

3.1. スキーマ設計プロセスの概要
リンクのコピー

スキーマ設計プロセス中に、Directory Server によって保存されるエントリーを表すオブジェクトクラスと属性を選択して定義できます。スキーマ設計プロセスでは、次の手順が実行されます。

  • データ要件を満たすために事前定義されたスキーマ要素を選択します。
  • 標準の Directory Server スキーマを拡張して、要件を満たす新しい要素を定義します。
  • スキーマのメンテナンスを計画します。

Directory Server が提供する標準スキーマで定義されている既存のスキーマ要素を使用できます。標準スキーマ要素は、ディレクトリー対応アプリケーションとの互換性を確保するのに役立ちます。スキーマは LDAP 標準をベースとしているため、、多数のディレクトリーユーザーによって確認され、同意されています。

3.2. 標準スキーマ
リンクのコピー

ディレクトリースキーマは、データ値のサイズ、範囲、および形式に制約を設定することにより、ディレクトリーに保存されているデータの整合性を維持します。スキーマは、ディレクトリーに含まれるさまざまな種類のエントリー (人、デバイス、組織など) と、各エントリーで使用可能な属性を識別します。

Directory Server の定義済みスキーマには、サーバーの機能をサポートするための標準 LDAP スキーマとアプリケーション固有のスキーマの両方が含まれています。ディレクトリーの固有のニーズに対応するために、新しいオブジェクトクラスと属性を追加してスキーマを拡張できます。

3.2.1. スキーマの形式
リンクのコピー

Directory Server のスキーマ形式は、LDAP プロトコルのバージョン 3 に基づいてビルドされています。このプロトコルでは、Directory Server は LDAP 自体によりそのスキーマを公開する必要があります。これにより、ディレクトリークライアントアプリケーションがプログラム的にスキーマを取得し、その動作を調整することができます。Directory Server のグローバルスキーマセットは、cn=schema エントリーにあります。

Directory Server スキーマは、プロプライエタリーオブジェクトクラスおよび属性を使用するため、LDAPv3 スキーマとは異なります。さらに、スキーマエントリーが元々どこで定義されたかを説明する、X-ORIGIN 389 Directory Server と呼ばれるスキーマエントリー内のプライベートフィールドを使用します。

標準 LDAPv3 スキーマでスキーマエントリーを定義する場合、X-ORIGIN 389 Directory Server フィールドは RFC 2252 を参照します。Directory Server の使用のためにエントリーが Red Hat によって定義されている場合、X-ORIGIN 389 Directory Server フィールドに 389 Directory Server 値が含まれます。たとえば、標準の person オブジェクトクラスは、以下のようにスキーマに表示されます。 

# objectclasses: ( 2.5.6.6 NAME 'person' DESC 'Standard Person Object Class' SUP top
MUST (objectclass $ sn $ cn) MAY (description $ seeAlso $ telephoneNumber $ userPassword)
X-ORIGIN 'RFC 2252' )
Copy to Clipboard Toggle word wrap

このスキーマエントリーには次のように記載されています。

  • クラスのオブジェクト識別子 (OID) (2.5.6.6)
  • オブジェクトクラスの名前 (person)
  • クラスの説明 (Standard Person)
  • 必須属性 (objectclass, sn, and cn)
  • オプション属性 (description、seeAlso、telephoneNumber、userPassword)

3.2.2. 標準属性
リンクのコピー

属性には、名前や fax 番号などの特定のデータ要素が含まれます。Directory Server は、特定の情報に関連付けられた説明的なスキーマ属性である属性とデータのペアとしてデータを表します。これらは、attribute-value assertions または AVAs とも呼ばれます。

たとえば、ディレクトリーには、標準属性を持つペアで人の名前などのデータを保存できます。Babs Jensen という名前の人物のエントリーには、属性とデータのペア cn: Babs Jensen があります。

エントリー全体は、一連の属性とデータのペアとして表されます。Babs Jensen のエントリー全体は以下のようになります。 

dn: uid=bjensen,ou=people,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Babs Jensen
sn: Jensen
givenName: Babs
givenName: Barbara
mail: bjensen@example.com
Copy to Clipboard Toggle word wrap

スキーマ内の各属性定義には、次の情報が含まれます。

  • 一意な名前
  • 属性のオブジェクト識別子 (OID)
  • 属性のテキストでの説明
  • 属性構文の OID

  • 以下を示す

    1. 属性が単一値か複数値
    2. この属性はディレクトリーでの使用を目的とする
    3. 属性の起点
    4. 属性に関連付けられた追加の一致ルール

cn 属性の定義は、スキーマ内で次のように表示されます。 

attributetypes: ( 2.5.4.3 NAME 'cn' DESC 'commonName Standard Attribute'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
Copy to Clipboard Toggle word wrap

属性の構文を使用して、属性に格納できる値の形式を定義できます。Directory Server は、すべての標準属性構文をサポートします。

3.2.3. 標準のオブジェクトクラス
リンクのコピー

オブジェクトクラスは、person や fax machine などの実際のオブジェクトを表します。関連する情報をグループ化するために使用されます。オブジェクトクラスを使用する前に、スキーマ内のオブジェクトクラスとその属性を識別する必要があります。ディレクトリーは、デフォルトでオブジェクトクラスの標準リストを認識します。

各ディレクトリーエントリーは、少なくとも 1 つのオブジェクトクラスに属します。スキーマで識別されるオブジェクトクラスをエントリーに配置すると、エントリーが特定の属性値セットを持つことができ、さらに別のより小さな必須属性値セットを持つ必要があることが Directory Server に通知されます。

オブジェクトクラス定義では次の情報が利用できます。

  • 一意な名前
  • オブジェクト識別子 (OID)
  • 必須属性のセット
  • 許可属性またはオプション属性のセット

スキーマ内の標準の person オブジェクトクラス: 

objectclasses: ( 2.5.6.6 NAME 'person' DESC 'Standard Person Object Class' SUP top
     MUST (objectclass $ sn $ cn) MAY (description $ seeAlso $ telephoneNumber $ userPassword)
     X-ORIGIN 'RFC 2252' )
Copy to Clipboard Toggle word wrap
注記

オブジェクトクラスは Directory Server で定義され、直接保存されるため、標準の LDAP 操作を使用してディレクトリースキーマをクエリーおよび変更できます。

3.3. データのデフォルトスキーマへのマッピング
リンクのコピー

サイト調査中に特定されたデータを既存のデフォルトのディレクトリースキーマにマップする必要があります。スキーマ内の要素が既存のデフォルトスキーマと一致しない場合は、カスタムオブジェクトクラスと属性を作成できます。

デフォルトのディレクトリースキーマは、Directory Server のすべての共通スキーマが含まれる /usr/share/dirsrv/schema/ ディレクトリーに保存されます。LDAPv3 標準のユーザーおよび組織スキーマは、00core.ldif ファイルにあります。ディレクトリーの以前のバージョンで使用されていた設定スキーマを、50ns-directory.ldif ファイルで見つけることもできます。

警告

デフォルトのディレクトリースキーマは変更しないでください。

3.3.1. スキーマ要素に一致するデータ
リンクのコピー

サイト調査で特定されたデータを既存のディレクトリースキーマにマップできます。このプロセスには、以下のステップが必要です。

  • データが記述するオブジェクトの種類を識別する必要があります。

データは、複数のオブジェクトを記述できる場合があります。ディレクトリースキーマで違い記述する必要があるかどうかを判断します。たとえば、電話番号は、従業員の電話番号と会議室の電話番号を記述できます。ディレクトリースキーマで、これらの異なるデータを異なるオブジェクトとして見なす必要があるかどうかを判断します。

  • デフォルトスキーマから類似のオブジェクトクラスを選択する必要がある。グループ、ユーザー、組織など、共通のオブジェクトクラスを使用すると良いでしょう。
  • 一致するオブジェクトクラスから類似の属性を選択する必要がある。
  • サイト調査から一致しないデータを特定する必要がある。デフォルトのディレクトリースキーマで定義されたオブジェクトクラスおよび属性と一致しないデータがある場合は、スキーマをカスタマイズします。
注記

Directory Server 設定、コマンド、およびファイルリファレンスは、データで利用可能な属性を判断するのに役に立ちます。各属性はそれを受け入れるオブジェクトクラスと共にリスト表示され、各オブジェクトクラスは必須属性および許可属性と共に相互リストされます。

3.4. スキーマのカスタマイズ
リンクのコピー

Directory Server の Web コンソールを使用して属性とオブジェクトクラスを追加することで、標準スキーマを拡張できます。LDIF ファイルを作成し、スキーマ要素を手動で追加することもできます。

スキーマをカスタマイズする際には、次のルールが適用できます。

  • スキーマはシンプルに保つ必要があります。
  • スキーマ要素を再利用する必要があります。
  • 各オブジェクトクラスに定義される必須属性の数を最小限に抑える必要があります。
  • 複数のオブジェクトクラスまたは属性を同じ目的 (データ) に定義しないでください。
  • 属性またはオブジェクトクラスの既存の定義は変更しないでください。
注記

スキーマをカスタマイズするときに、標準スキーマを削除または置き換えることはできません。これを行うと、他のディレクトリーまたは LDAP クライアントアプリケーションとの互換性の問題が発生する可能性があります。

カスタムオブジェクトクラスおよび属性は 99user.ldif ファイルで定義されます。各インスタンスは、/etc/dirsrv/slapd-instance_name/schema/ ディレクトリーに独自の 99user.ldif ファイルを維持します。カスタムスキーマファイルを作成し、スキーマをサーバーに動的に再ロードすることもできます。

特定のオブジェクトクラスが組織に関する特殊な情報を格納できない場合はスキーマを拡張できますが、Directory Server で提供されるオブジェクトクラスと属性は、最も一般的な企業のニーズを満たす必要があります。また、スキーマを拡張して、LDAP 対応アプリケーションの固有のデータニーズに必要なオブジェクトクラスと属性をサポートすることもできます。

3.4.1. オブジェクト識別子の割り当て
リンクのコピー

各 LDAP オブジェクトクラスまたは属性に一意の名前と object identifier (OID) を割り当てる必要があります。スキーマを定義する場合、要素には組織固有のベース OID が必要です。別の階層レベルを追加して、属性とオブジェクトクラスの新規ブランチを作成します。スキーマで OID を取得して割り当てるには、以下のステップが必要です。

  1. Internet Assigned Numbers Authority (IANA) または国家的な組織から OID を取得します。国によっては、企業に OID がすでに割り当てられています。
  2. OID 割り当てを追跡する OID レジストリーを作成します。OID レジストリーは、OID と、ディレクトリースキーマで使用される OID の説明のリストです。これにより、OID が複数の目的に使用されないようにします。次に、スキーマに OID レジストリーをパブリッシュします。
  3. スキーマ要素に対応するために OID ツリーでブランチを作成します。OID ブランチまたはディレクトリースキーマの下に、属性に OID. 1、オブジェクトクラスに OID. 2 を使用して、少なくとも 2 つのブランチを作成します。必要に応じて新しいブランチを追加し、カスタム一致ルールまたはコントロール (OID.`3 など) を定義します。

3.4.2. 新規オブジェクトクラスを定義するストラテジー
リンクのコピー

新しいオブジェクトクラスは次の 2 つの方法で作成できます。

  • 属性を追加できるオブジェクトクラス構造ごとに 1 つずつ、新しいオブジェクトクラスを作成します。
  • ディレクトリー用に作成されたすべてのカスタム属性をサポートする単一のオブジェクトクラスを作成します。このオブジェクトクラスは、補助オブジェクトクラスとして定義することで作成できます。

2 つの方法を組み合わせることもできます。たとえば、exampleDateOfBirth、examplePreferredOS、exampleBuildingFloor、および exampleVicePresident という属性を作成するとします。簡単なソリューションは、これらの属性のサブセットを許可する複数のオブジェクトクラスを作成することです。

  • examplePerson オブジェクトクラスでは、exampleDateOfBirth と examplePreferredOS が許可されます。examplePerson の親は inetOrgPerson です。
  • exampleOrganization オブジェクトクラスでは、exampleBuildingFloor と exampleVicePresident が許可されます。exampleOrganization の親は organization オブジェクトクラスです。

新しいオブジェクトクラスは、以下のように LDAPv3 スキーマ形式で表示されます。 

objectclasses: ( 2.16.840.1.117370.999.1.2.3 NAME 'examplePerson' DESC 'Example Person Object Class'
     SUP inetorgPerson MAY (exampleDateOfBirth $ examplePreferredOS) )

objectclasses: ( 2.16.840.1.117370.999.1.2.4 NAME 'exampleOrganization' DESC 'Organization Object Class'
     SUP organization MAY (exampleBuildingFloor $ exampleVicePresident) )
Copy to Clipboard Toggle word wrap

あるいは、これらすべての属性を許可する単一のオブジェクトクラスを作成し、それらを必要とするエントリーで使用することもできます。単一のオブジェクトクラスは以下のようになります。 

objectclasses: (2.16.840.1.117370.999.1.2.5 NAME 'exampleEntry' DESC 'Standard Entry Object Class' SUP top
     AUXILIARY MAY (exampleDateOfBirth $ examplePreferredOS $ exampleBuildingFloor $ exampleVicePresident) )
Copy to Clipboard Toggle word wrap

新しい exampleEntry オブジェクトクラスには AUXILIARY というマークが付き、構造的なオブジェクトクラスとは無関係に任意のエントリーと共に使用できることを意味します。

組織環境に応じて新しいオブジェクトクラスを編成できます。新しいオブジェクトクラスの実装を決定するときは、次の点を考慮してください。

  • スキーマに 2 つまたは 3 つ以上のオブジェクトクラスを追加する場合は、単一のオブジェクトクラスを使用する必要があります。
  • 複数のオブジェクトクラスには厳密なデータ設計が必要です。厳密なデータ設計により、すべてのデータが置かれるオブジェクトクラス構造に注意を払うことが強制されます。これには、便利な面と面倒な面があります。
  • データを人やアセットエントリーなどの複数のタイプのオブジェクトクラスに適用できる場合は、単一のオブジェクトクラスを使用してデータを使用できます。たとえば、person エントリーと group エントリーの両方にカスタムの preferredOS 属性を設定できます。単一のオブジェクトクラスは、両方のタイプのエントリーでこの属性を許可できます。
  • 新しいオブジェクトクラスでは必須属性を避ける必要があります。新しいオブジェクトクラスの属性に対して allow ではなく require を指定すると、スキーマが柔軟性を失う可能性があります。新しいオブジェクトクラスを定義したら、許可および必要な属性、ならびに属性を継承するオブジェクトクラスを決定します。

3.4.3. 新規属性を定義する際のストラテジー
リンクのコピー

アプリケーションの互換性と長期的なメンテナンスの両方のために、標準属性を使用する必要があります。デフォルトのディレクトリースキーマにすでに存在する属性を検索し、それを新しいオブジェクトクラスで使用するか、Directory Server スキーマガイドを確認する必要があります。ただし、標準スキーマに必要な情報がすべて含まれていない場合は、新しい属性と新しいオブジェクトクラスを追加します。

たとえば、person エントリーでは、デフォルトで person、organizationalPerson、または inetOrgPerson オブジェクトクラスがサポートするよりも多くの属性が必要になる可能性があります。標準の Directory Server スキーマ内には、生年月日を保存するための属性は存在しません。新しい補助オブジェクトクラス examplePerson 内の許可属性として、新しい属性 dateOfBirth を作成して設定できます。 

attributetypes: ( dateofbirth-oid NAME 'dateofbirth' DESC 'For employee birthdays'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Example defined')

objectclasses: ( 2.16.840.1.117370.999.1.2.3 NAME 'examplePerson' DESC 'Example Person Object Class'
     SUP inetorgPerson MAY (exampleDateOfBirth $ cn) X-ORIGIN 'Example defined')
Copy to Clipboard Toggle word wrap
注記

標準スキーマ要素にカスタム属性を追加または削除することはできません。ディレクトリーにカスタム属性が必要な場合は、カスタムオブジェクトクラスを追加してそれらを含めます。

3.4.4. スキーマ要素の削除
リンクのコピー

Directory Server にデフォルトで含まれているスキーマ要素を削除することはできません。未使用のスキーマ要素は、操作や管理のオーバーヘッドを表しません。標準の LDAP スキーマの一部を削除すると、Directory Server およびその他のディレクトリー対応アプリケーションの今後のインストールとの間で互換性の問題が発生する可能性があります。

ただし、使用されていないカスタムスキーマ要素は削除できます。スキーマからオブジェクトクラス定義を削除する前に、オブジェクトクラスを使用して各エントリーを変更します。最初に定義を削除すると、オブジェクトクラスを使用するエントリーが後で変更されなくなる可能性があります。不明なオブジェクトクラス値がエントリーから削除されない限り、変更されたエントリーのスキーマチェックも失敗します。

3.4.5. カスタムスキーマファイルの作成
リンクのコピー

Directory Server で提供される 99user.ldif ファイルに加えて、Directory Server 用のカスタムスキーマファイルを作成して使用することができます。これらのスキーマファイルには、組織固有の新しいカスタム属性とオブジェクトクラスが含まれます。新しいスキーマファイルは、スキーマディレクトリー /etc/dirsrv/slapd-instance_name/schema/ に配置されています。標準属性とオブジェクトクラスはすべて、カスタムスキーマ要素が読み込まれた後にのみロードされます。

注記

カスタムスキーマファイルは、数字順またはアルファベット順で 99user.ldif より大きくすることはできません。

カスタムスキーマファイルを作成したら、次の方法でスキーマの変更をすべてのサーバーに配布できます。

  • これらのカスタムスキーマファイルをインスタンスのスキーマディレクトリー /etc/dirsrv/slapd-instance/schema に手動でコピーしてスキーマをロードしたり、サーバーを再起動したり、schema-reload.pl スクリプトを実行してスキーマを動的に再ロードしたりすることができます。
  • Web コンソールなどの LDAP クライアントまたは ldapmodify コマンドを使用して、サーバー上のスキーマを変更できます。
  • レプリケーションでは、レプリケートされたスキーマ要素はすべてコンシューマーサーバーの 99user.ldif ファイルにコピーされます。90example_schema.ldif などのカスタムスキーマファイルにスキーマを維持するには、このファイルを手動でコンシューマーサーバーにコピーする必要があります。レプリケーションは、スキーマファイルをコピーしません。

これらのカスタムスキーマファイルをすべてのサーバーにコピーしない場合は、サプライヤーサーバー上のスキーマに変更が加えられたときにのみ、スキーマ情報がコンシューマーサーバーにレプリケートされます。スキーマの定義がまだ存在しないコンシューマーサーバーにレプリケートされると、それらは 99user.ldif ファイルに保存されます。

注記

このディレクトリーは、スキーマ定義の保存場所を追跡しません。スキーマがサプライヤーサーバー上でのみ維持される場合は、コンシューマーの 99user.ldif ファイルにスキーマ要素を保存できます。

3.4.6. カスタムスキーマのベストプラクティス
リンクのコピー

次の提案は、互換性があり管理しやすいカスタムスキーマを定義するのに役立ちます。

スキーマファイルの命名

カスタムスキーマファイルには、数字順とアルファベット順で 99user.ldif より小さい名前を付けます。99user.ldif file には、X-ORIGIN 値が 'user defined' の属性が含まれています。Directory Server は、すべての 'ユーザー定義' スキーマ要素を、数字順、次にアルファベット順に、最も名前の大きいファイルに書き込みます。スキーマファイルの名前が 99zzz.ldif で、スキーマが更新されると、X-ORIGIN 値が 'user defined' であるすべての属性が 99zzz.ldif ファイルに書き込まれます。その結果、重複した情報を含む LDIF ファイルと、99zzz.ldif file 内の一部の情報が消去される可能性があります。

カスタムスキーマファイルに名前を付ける場合は、[00-99]yourName.ldif という命名形式を使用します。

Origin としての 'user defined' の使用

カスタムスキーマファイル (例: 60example.ldif) の X-ORIGIN フィールドでは 'user defined' を使用しないでください。これは、スキーマが LDAP 経由で追加されるときに、Directory Server によって 'user defined' が内部的に使用されるためです。

カスタムスキーマ要素を 99user.ldif に手動で直接追加する場合は、X-ORIGIN の値として 'user defined' を使用します。異なる X-ORIGIN 値が設定されている場合、サーバーはそれを上書きする可能性があります。

値が 'user defined' の X-ORIGIN を使用すると、Directory Server によって 99user.ldif ファイル内のスキーマ定義が削除されなくなります。

以下に例を示します。 

attributetypes: ( exampleContact-oid NAME 'exampleContact'
DESC 'Example Corporate contact'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
X-ORIGIN 'Example defined')
Copy to Clipboard Toggle word wrap

Directory Server がスキーマエントリーを読み込むと、以下のように表示されます。 

attributetypes: ( exampleContact-oid NAME 'exampleContact'
DESC 'Example Corporate contact'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
X-ORIGIN ('Example defined' 'user defined') )
Copy to Clipboard Toggle word wrap

オブジェクトクラスの前の属性の定義

新しいスキーマ要素を追加するときは、オブジェクトクラスで使用される前にすべての属性を定義します。属性とオブジェクトクラスを同じスキーマファイルに定義できます。

単一ファイルでのスキーマの定義

各カスタム属性またはオブジェクトクラスを 1 つのスキーマファイルに定義して、サーバーが最後に作成されたスキーマをロードするときに以前の定義がオーバーライドされるのを阻止します。サーバーは、まず数値順に、次にアルファベット順にスキーマをロードします。重複するファイルにスキーマを確保しない方法を決定します。

  • 各スキーマファイルにどのスキーマ要素が含まれているかに注意してください。
  • スキーマファイルの命名および更新には注意が必要です。スキーマ要素が LDAP ツールを使用して編集されると、変更は最後のファイルにアルファベット順に自動的に書き込まれます。ほとんどのスキーマ変更は、60example.ldif などのカスタムスキーマファイルではなく、デフォルトの 99user.ldif ファイルに書き込まれます。99user.ldif ファイル内のスキーマ要素は、他のスキーマファイル内の重複する要素をオーバーライドします。
  • Web コンソールを使用してスキーマを管理する場合は、すべてのスキーマ定義を 99user.ldif ファイルに追加します。

3.5. 一貫性のあるスキーマの概要
リンクのコピー

LDAP クライアントアプリケーションは、Directory Server 内の一貫したスキーマを使用してディレクトリーエントリーを検索します。一貫性のないスキーマでは、同じ情報を格納するために異なる属性または形式が使用されるため、ディレクトリーツリー内の情報を見つけることはできません。

スキーマの一貫性は、次の方法で維持できます。

  • スキーマチェックを使用して、属性とオブジェクトクラスがスキーマルールに準拠していることを確認します。
  • 構文検証を使用して、属性値が必要な属性構文と一致するようにします。
  • 一貫したデータ形式を選択して適用できます。

3.5.1. スキーマチェック
リンクのコピー

スキーマチェックにより、すべての新規または変更されたディレクトリーエントリーがスキーマルールに準拠していることが検証されます。デフォルトでは、ディレクトリーはスキーマチェックを有効にします。ルールに違反すると、ディレクトリーは要求された変更を拒否します。

注記

スキーマチェックは、適切な属性が存在することを検証します。構文検証を使用すると、属性値が正しい構文にあることを確認できます。この機能を無効にしないでください。

スキーマチェックが有効になっている場合は、オブジェクトクラスによって定義されている必須属性と許可属性に注意する必要があります。エントリーのオブジェクトクラス定義に従って必須でもなく許可もされていない属性をエントリーに追加すると、Directory Server はオブジェクトクラス違反メッセージを返すことがあります。

たとえば、organizationalPerson オブジェクトクラスを使用するようにエントリーが定義されている場合には、エントリーに共通名 (cn) および姓 (sn) 属性が必要になります。これらの属性の値は、エントリーの作成時に設定する必要があります。さらに、エントリーでオプションとして使用できる属性の長いリストがあります (例: telephoneNumber、uid、streetAddress、userPassword などの記述的な属性)。

3.5.2. 構文の検証の概要
リンクのコピー

構文検証とは、Directory Server が属性の値がその属性に必要な構文と一致することを検証することを意味します。たとえば、構文検証では、新しい telephoneNumber 属性の値に有効な電話番号が含まれていることを確認できます。これは、デフォルトで有効になっています。

オプションで、構文検証の追加の設定を行い、構文違反に関する警告メッセージをログに記録してから、変更を拒否するか、変更プロセスを正常に実行できるようにします。

構文検証では、新しい属性値が追加された場合に LDAP 操作をチェックします。既存の属性や、レプリケーションなどのデータベース操作を通じて追加された属性は処理されません。既存の属性は、dsconf schema validate-syntax コマンドを使用して検証できます。

この機能は、必要な形式が定義されていないバイナリー構文と非標準構文を除くすべての属性構文を検証します。構文は RFC 4514 に対して検証されますが、DN はそれほど厳格ではない RFC 1779 または RFC 2253 に対して検証されます

注記

厳密な DN 検証を設定できます。

3.5.2.1. Directory Server 操作の構文検証
リンクのコピー

構文検証は、エントリーの作成 (追加) または属性の編集 (変更) などの標準の LDAP 操作に適用できます。属性構文を検証すると、他の Directory Server 操作に影響する可能性があります。

データベース暗号化

LDAP 操作用に値がデータベースに書き込まれる前に属性を暗号化できます。つまり、属性構文が検証された後に暗号化が実行されます。暗号化されたデータベースをインポートおよびエクスポートできます。

注記

エクスポートおよびインポート操作は、インポート操作の構文検証の実行を許可する --encrypted(dsctl) フラグを使用して実行する必要があります。

--encrypted flag (サポート対象外) を使用せずに暗号化されたデータベースをエクスポートすると、暗号化された値を含む LDIF が作成されます。この LDIF がインポートされると、暗号化された属性を検証できず、警告がログに記録され、インポートされたエントリーの属性検証がスキップされます。

同期

Windows Active Directory エントリーと Directory Server エントリーの属性に対して許可または強制される構文には違いがある場合があります。構文検証により、Directory Server エントリーに RFC 標準が適用されるため、Active Directory の値を同期することはできません。

レプリケーション

Directory Server 11.0 インスタンスが、変更をコンシューマーにレプリケートするサプライヤーである場合は、構文検証を使用できます。ただし、レプリケーションのサプライヤーが Directory Server の古いバージョンであるか、構文検証が無効になっているとします。その場合、Directory Server 11.0 コンシューマーはサプライヤーが許可する属性値を拒否できるため、11.0 コンシューマーでは構文検証を使用できません。

3.5.3. 一貫したデータ形式
リンクのコピー

LDAP スキーマを使用して、属性値を持つデータを配置できます。ただし、LDAP クライアントアプリケーションおよびディレクトリーユーザーに適した形式を選択して、一貫性を維持してディレクトリーツリーでデータを保存することが重要になります。

LDAP プロトコルと Directory Server を使用すると、RFC 2252 で指定されたデータ形式でデータを表現できます。たとえば、電話番号の正しい LDAP 形式は、2 つの ITU-T 推奨ドキュメントで定義されます。

  • ITU-T Recommendation E.123国内およびおよび国際電話番号の記法
  • ITU-T Recommendation E.163 国際的な電話サービスの番号付けプラン(たとえば、米国の電話番号は +1 555 222 1717 の形式になります。)

別の例として、postalAddress 属性には、行区切り文字としてドル記号 ($) を使用する複数行の文字列形式の属性値があります。適切にフォーマットされたディレクトリーエントリーは以下のように表示されます。 

postalAddress: 1206 Directory Drive$Pleasant View, MN$34200
Copy to Clipboard Toggle word wrap
注記

属性には、文字列、バイナリー入力、整数、その他の形式が必要です。属性のスキーマ定義で形式を設定できます。

3.5.4. レプリケートされたスキーマでの一貫性の維持について
リンクのコピー

ディレクトリースキーマを編集すると、変更内容が changelog に記録されます。レプリケーション中に changelog をスキャンして、変更の有無と、変更がレプリケートされているかを確認します。レプリケートされたスキーマの一貫性を維持することで、エラーなしでレプリケーションを続行できます。

レプリケートされた環境で一貫したスキーマを維持するために、以下のポイントを考慮してください。

  • 読み取り専用レプリカでスキーマを変更しないでください。

    読み取り専用レプリカのスキーマを変更すると、スキーマに不整合が生じ、レプリケーションが失敗します。

  • 異なる構文を使用する同じ名前の属性を 2 つ作成しないでください。

    読み取り/書き込みレプリカに、サプライヤーレプリカの属性と同じ名前で、サプライヤーの属性とは異なる構文を持つ属性を作成すると、レプリケーションは失敗します。

第4章 ディレクトリーツリーの設計
リンクのコピー

ディレクトリーツリーを使用して、Directory Server に保存されているデータを表示できます。ディレクトリーツリーの設計は、ディレクトリーに保存される情報の種類、企業の物理的な性質、ディレクトリーで使用されるアプリケーション、および実装されるレプリケーションの種類に基づいて行われます。

4.1. ディレクトリーツリーの概要
リンクのコピー

ディレクトリーデータに名前を付け、ディレクトリーツリーを使用してクライアントアプリケーションを参照できます。ディレクトリーツリーは、ディレクトリーのデータの分散、レプリケート、またはアクセス制御で利用可能な選択肢など、他の設計上の決定と対話できます。デプロイメント前にディレクトリーツリーを設計できるため、ディレクトリーサービスの運用中のデプロイメントフェーズとその後の両方で時間と労力を節約できます。

適切に設計されたディレクトリーツリーを使用すると、次のことが可能になります。

  • ディレクトリーデータを簡単に維持します。
  • レプリケーションポリシーとアクセス制御を柔軟に作成します。
  • ディレクトリーサービスを使用するアプリケーションをサポートします。
  • ユーザーのディレクトリーナビゲーションを簡素化します。

ディレクトリーツリーの構造は、階層 LDAP モデルに従います。ディレクトリーツリーは、グループ、人、または場所など、さまざまな論理方法でデータを整理する方法を提供します。ディレクトリーツリーを使用して、複数のサーバー間でデータを分割する方法を決定することもできます。たとえば、各データベースは接尾辞レベルでデータをパーティション化する必要があります。適切なディレクトリーツリー構造がないと、データを複数のサーバーに効率的に分散することはできません。

さらに、レプリケーションは、使用されるディレクトリーツリー構造のタイプによって制限されます。ディレクトリーツリーの一部のみをレプリケートするには、設計プロセス中にそのことを考慮してください。

4.2. ディレクトリーツリーの設計
リンクのコピー

ディレクトリーツリーを計画するときには、次の主要な決定を行います。

  • データを格納する接尾辞を選択します。
  • ディレクトリーツリー構造を作成することによって、データエントリー間の階層関係を決定します。
  • ディレクトリーツリー階層内のエントリーに名前を付けます。

4.2.1. 接尾辞の選択
リンクのコピー

接尾辞は、ディレクトリーツリーの root にあるエントリーの名前で、ディレクトリーデータはその下に保存されます。ディレクトリーには、複数の接尾辞を含めることができます。自然共通の root を持たない情報のディレクトリーツリーが 2 つ以上ある場合には、複数の接尾辞を使用できます。デフォルトでは、標準の Directory Server のデプロイメントには複数の接尾辞が含まれています。1 つはデータの保管用で、残りは内部ディレクトリー操作に必要なデータ (例: 設定情報、ディレクトリースキーマなど) 用です。

接尾辞の命名規則

ディレクトリー内のすべてのエントリーを、共通のベースエントリー (root 接尾辞) に配置する必要があります。root ディレクトリー接尾辞の名前を選択する場合、その名前を有効にするには次の条件を満たす必要があります。

  • グローバルに一意であること
  • 静的であること
  • 短いこと (その下のエントリーを簡単に読めるようにするため)
  • 簡単なこと (入力したり記憶したりしやすいこと)

単一のエンタープライズ環境では、エンタープライズの DNS 名またはインターネットドメイン名と対応するディレクトリー接尾辞を選択できます。たとえば、企業が example.com のドメイン名を所有する場合は、ディレクトリーの接尾辞は dc=example,dc=com になります。dc 属性は、ドメイン名をコンポーネント部分に分割することで、接尾辞を表します。通常、root 接尾辞に名前を付けるには任意の属性を使用できます。ただし、ホスト組織では、root 接尾辞を以下の属性に制限する必要があります。

dc
ドメイン名のコンポーネントを定義します。
c
ISO で定義される、国名を表す 2 桁のコードが含まれます。
l
エントリーが置かれる、またはエントリーに関連付けられる国、都市、または他の地理的エリアを識別します。
st
エントリーが所在する州または地方を識別します。
o
エントリーが属する組織の名前を識別します。

これらの属性は、サブスクライバーアプリケーションとの相互運用性を実現します。たとえば、ホスト組織はこれらの属性を使用して、クライアントの 1 つ example_a に対して root 接尾辞 o=example_a, st=Washington,c=US を作成できます。

X.500 の接尾辞命名規則では、組織名の後に国名を使用するのが一般的です。

複数接尾辞の命名

ディレクトリー内の各接尾辞は一意のディレクトリーツリーです。Directory Server が提供する個別のデータベースに保存される複数のディレクトリーツリーを作成できます。

たとえば、example_a と example_b の個別の接尾辞を作成し、それらを別々のデータベースに保存します。

dg ディレクトリー内の複数の dit
View larger image
dg ディレクトリー内の複数の dit

リソースの制限に応じて、データベースを単一のサーバーまたは複数のサーバーに保存できます。

4.2.2. ディレクトリーツリー構造の作成
リンクのコピー

フラットなツリー構造または階層ツリー構造を使用するかどうかを決定します。ディレクトリーツリーをできるだけフラットにするようにしてください。ただし、情報を複数のデータベース間でパーティション化する場合、レプリケーションを準備する場合、またはアクセス制御を設定する場合に、ある程度の階層化が重要になります。

ツリーの構造では、以下の手順および考慮事項が必要です。

  • ディレクトリーの分岐
  • ブランチポイントの特定
  • レプリケーションに関する考慮事項
  • アクセス制御に関する考慮事項
4.2.2.1. ディレクトリーの分岐
リンクのコピー

問題のある名前の変更を避けるために、namespace は可能な限りフラットにする必要があります。ディレクトリーツリーが階層的であるほど、名前のコンポーネントが多くなり、名前が変更される可能性が高くなります。

ディレクトリーツリー階層を設計する場合は、次のガイドラインに従ってください。

  • ツリーを分岐して、企業内の最大下部組織部門のみを表します。ブランチポイントは、企業情報サービス、カスタマーサポート、営業、エンジニアリングなどの部門に限定する必要があります。ディレクトリーツリーを分岐するために使用される部門が安定していることを確認します。企業が頻繁に再編成を行う場合は、この種のブランチングを実行しないでください。
  • ブランチポイントには、実際の組織名ではなく、機能名または汎用名を使用します。サブツリーの名前を変更するときに、接尾辞に多くの子がある場合、名前変更プロセスはリソースを大量に消費し、時間がかかります。たとえば、Widget Research and Development の代わりに Engineering を使用します。
  • 同様の機能を実行する組織が複数ある場合は、その機能に対して単一のブランチポイントを作成してみてください。たとえば、複数のマーケティング組織があり、それぞれが特定の製品ラインを担当している場合でも、単一の ou=Marketing サブツリーを作成します。すべてのマーケティングエントリーはそのツリーに属します。

エンタープライズ環境における分岐

変更される可能性が低い情報に基づいてディレクトリーツリー構造を計画すると、名前の変更を回避できます。たとえば、組織ではなくツリー内のオブジェクトのタイプを構造のベースとします。

構造を定義するには、次の共通オブジェクトを使用します。

  • ou=people
  • ou=groups
  • ou=contracts
  • ou=services

次の図は、これらのオブジェクトを使用して編成されたディレクトリーツリーを示しています。

dg enterprise environment dit

ホスト環境での分岐

ホスティング環境の場合は、root 接尾辞の下に、オブジェクトクラス organization (o) のエントリー 2 つと、オブジェクトクラス organizationalUnit (ou) のエントリー 1 つを含むツリーを作成します。たとえば、Example ISP というインターネットサービスプロバイダーは、次のようにディレクトリーを分岐します。

dg hosting environment

4.2.2.2. ブランチポイントの特定
リンクのコピー

ディレクトリーツリー内のブランチをプランニングする際に、ブランチポイントの特定に使用する属性を決定します。ブランチポイントは、ou=people、l=Japan、cn=Barbara Jansen などの属性とデータのペアになります。DN はこれらの属性とデータのペアで構成される一意の文字列であることを覚えておいてください。たとえば、Example Company の従業員である Barbara Jensen のエントリーの DN は次のようになります。

uid=bjensen,ou=people,dc=example,dc=com

次の図に、ou=people、ou=groups、cn=Barbara Jensen、cn=Billie Holiday のブランチポイントを持つ Example Company のディレクトリーツリーの例を示します。

dg example copr dit

次の図に、インターネットプロバイダー Example ISP のディレクトリーツリーの例を示します。

dg example isp dit

root 接尾辞エントリー o=example,c=US の下で、ツリーは 3 つのブランチに分割されます。o=ISP ブランチには、Example ISP の顧客データと内部情報が含まれています。o=internet ブランチはドメインツリーです。ou=groups ブランチには、管理グループに関する情報が含まれています。

ブランチポイントの属性を選択するときは、次の推奨事項を考慮してください。

  • 一貫性を持たせる必要があります。

    ディレクトリーツリー全体で DN 形式が一貫していない場合、一部の LDAP クライアントアプリケーションでは識別名 (DN) が見つからないことがあります。ディレクトリーツリーの一部で ou が o の下にある場合は、ディレクトリーサービスの他のすべての部分でも ou が o の下にあることを確認してください。

  • 従来の属性のみを使用するようにしてください。

    従来の属性を使用すると、Directory Server がサードパーティーの LDAP クライアントアプリケーションと互換性を持つ可能性が高まります。従来の属性を使用するということは、デフォルトのディレクトリースキーマがそれらを認識していることも意味します。

Expand
従来の属性説明

dc

dc=example などのドメイン名の要素。多くの場合、dc=example,dc=com または dc=mtv,dc=example,dc=com のように、ドメインに応じてペアで指定されるか、さらに長い名前で指定されます。ドメイン名の命名の詳細は、接尾辞の命名規則 セクションを参照してください。

c

国名。

o

組織名。この属性は、企業部門、学問分野 (人文科学、科学)、子会社、または企業内のその他の主要なブランチなどの大規模な部門のブランチを表すために使用します。この属性を使用してドメイン名を表すことができます。

ou

組織単位。この属性は、組織ではなく企業の小さな部門のブランチを表すために使用されます。通常、組織単位は前述の組織に従属します。

st

州または地区名。

l または locality

都市、国、オフィス、またはファシリティー名などのローカリティー。

注記

一般的な間違いは、識別名で使用される属性に基づいてディレクトリーを検索することを仮定することです。識別名はディレクトリーエントリーの一意の識別子であり、検索キーとして使用できません。代わりに、エントリー自体に保存されている属性とデータのペアに基づいてエントリーを検索します。したがって、エントリーの識別名が uid=bjensen,ou=People,dc=example,dc=com の場合、dc=example の検索は、そのエントリーの属性として dc:example が明示的に追加されない限り、そのエントリーと一致しません。

4.2.2.3. レプリケーションに関する考慮事項
リンクのコピー

レプリケートするエントリーを計画します。サブツリーの最上位の DN を指定して、その下のすべてのエントリーをレプリケートできます。このサブツリーは、ディレクトリーデータの一部を含むディレクトリー部分であるデータベースにも対応します。

たとえば、エンタープライズ環境では、ディレクトリーツリーをエンタープライズ内のネットワーク名に対応するように編成できます。ネットワーク名は 変更されない傾向 があるため、ディレクトリーツリー構造は安定しています。

たとえば、Example Company には、flightdeck.example.com、tickets.example.com、hangar.example.com という 3 つのプライマリーネットワークがあります。同社は最初に、主要な組織部門ごとにディレクトリーツリーを 3 つの主要グループに分岐します。次の図でディレクトリーツリーの最初の分岐を確認してください。

dg initial branching of dit corp

ツリーの初期構造を作成した後、同社は追加のブランチを作成します。次の図で拡張されたブランチを参照してください。

dg extended branching of dit corp

別の例では、インターネットプロバイダーの Example ISP には、プロバイダーのニーズを満たすために次の初期分岐があります。

dg initial isp dit

その後、Example ISP は論理サブグループ用の追加のブランチを作成します。次の図で拡張されたブランチを参照してください。

dg extended isp dit

企業の Example Company とホスティング組織の Example ISP はどちらも、頻繁に変更されない情報に基づいてデータ階層を設計します。

4.2.2.4. アクセス制御に関する考慮事項
リンクのコピー

ディレクトリーツリー内の階層を使用して、特定の種類のアクセス制御を有効にすることができます。レプリケーションと同様に、類似したエントリーをグループ化して、1 つのブランチから管理するのが簡単になります。

階層的なディレクトリーツリーを通じて管理できます。たとえば、マーケティング部門の管理者にマーケティングエントリーへのアクセス権を付与し、営業部門の管理者に営業のエントリーへのアクセス権を付与するには、これらの部門に従ってディレクトリーツリーを設計します。

さらに、ディレクトリーツリーではなくディレクトリーの内容に基づいてアクセス制御を設定することもできます。アクセス制御命令 (ACI) メカニズムを使用すると、特定のエントリーが特定の属性値を含むすべてのエントリーにアクセスできるようにすることができます。たとえば、営業管理者に属性値 ou=Sales を含むすべてのエントリーへのアクセス権を付与する ACI を設定します。

ただし、ACI の管理は難しい場合があります。アクセス制御の最適な方法 (ディレクトリーツリー階層の組織分岐、ACI、またはその 2 つの組み合わせ) を決定します。

4.2.3. エントリーの命名
リンクのコピー

ディレクトリーツリーの階層を設計した後、構造内のエントリーに名前を付けるときに使用する属性を決定する必要があります。1 つまたは複数の属性値を選択すると、相対識別名 (RDN) が形成されます。RDN は DN の一番左の部分であり、その部分に選択する属性は 命名属性 です。命名属性は、エントリーに一意の名前を設定します。たとえば、DN uid=bjensen,ou=people,dc=example,dc=com には RDN uid=bjensen があります。

選択する属性は、名前を付けるエントリーのタイプによって異なります。

エントリーに名前を付けるときは、次の点を考慮してください。

  • 命名に選択した属性を変更しないでください。
  • この名前は、ディレクトリー全体で一意でなければなりません。一意の名前により、DN はディレクトリー内の 1 つのエントリーのみを参照するようになります。

エントリーを作成するときは、エントリー内で RDN を定義します。エントリー内に定義された RDN を使用すると、エントリーをより簡単に見つけることができます。これは、実際の DN ではなく、エントリー自体に格納されている属性値に基づいてエントリーが検索されるためです。

属性名には意味があるため、表しているエントリーのタイプと一致する属性名を使用するようにしてください。たとえば、組織を表すのに l (location) を使用したり、組織単位を表すのに c (country) を使用したりしないでください。

4.2.3.1. ディレクトリーツリー内の person エントリーに名前を付ける
リンクのコピー

person エントリー名は一意である必要があります。通常、個人エントリーに名前を付けるには、commonName または cn 属性を使用して相対識別名 (RDN) を作成します。たとえば、Babs Jensen という名前の人物のエントリーの識別名 (DN) は cn=Babs Jensen,dc=example,dc=com になります。

RDN で共通名のみを使用すると、エントリー名を一意にする際に十分ではなく、複数の同一エントリーが作成され、DN 名の衝突が発生する可能性があることに注意してください。

共通名に一意の識別子を追加して、共通名の衝突を回避します (例: cn=Babs Jensen+employeeNumber=23,dc=example,dc=com)。ただし、これにより、大規模なディレクトリーでは共通名が不便になり、管理が困難になる可能性があります。

より適切な方法は、cn 以外の属性で個人エントリーを特定することです。以下の属性のいずれかを使用することを検討してください。

uid
uid 属性を使用して、ユーザーログイン ID や従業員番号など、個人の一意の値を指定します。ホスティング環境内のサブスクライバーを uid 属性で識別します。
mail
mail 属性には、常に一意である個人のメールアドレスが含まれます。この属性により、mail=bjensen@example.com,dc=example,dc=com などの重複した属性値を含む扱いにくい DN が発生する可能性があります。uid 属性の一意の値が見つからない場合にのみ、このオプションを使用します。たとえば、企業が臨時従業員または契約従業員に従業員番号やユーザー ID を割り当てない場合は、uid 属性ではなく mail 属性を使用します。
employeeNumber
inetOrgPerson オブジェクトクラスの従業員の場合は、employeeNumber 属性を使用します。

person エントリー RDN に使用される属性/データのペアに関係なく、それらが一意の永続的値であることを確認してください。person エントリー RDN も読み取り可能でなければなりません。たとえば、DN uid=bjensen,dc=example,dc=com は、uid=b12r56A,dc=example,dc=com よりも推奨され、識別名に基づいてディレクトリーエントリーを変更するなど、一部のディレクトリータスクが簡素化されます。また、一部のディレクトリークライアントアプリケーションでは、uid 属性と cn 属性に人間が判読できる名前が使用されていると想定しています。

ホストされる環境の person エントリーに関する考慮事項

person がサービスへのサブスクライバーである場合、エントリーには inetUser オブジェクトクラスが含まれ、uid 属性が含まれている必要があります。属性は、顧客サブツリー内で一意である必要があります。

個人がホスティング組織の一部である場合は、nsManagedPerson オブジェクトクラスで inetOrgPerson 属性を使用します。

ディレクトリーツリーに person エントリーを配置する

ディレクトリーツリーに person エントリーを配置する場合は、次のガイドラインに従ってください。

  • ディレクトリーツリーの組織エントリーの下にある企業内の人物を見つけます。
  • ホストされている組織の ou=people ブランチの下で、ホストしている組織のサブスクライバーを見つけます。
4.2.3.2. ディレクトリーツリー内のグループエントリーの命名
リンクのコピー

グループを表すには、次の方法を使用できます。

  • 静的グループ は、明示的にメンバーを定義します。groupOfNames または groupOfUniqueNames オブジェクトクラスには、グループのメンバーを命名する値が含まれます。静的グループは、ディレクトリー管理者のグループなど、メンバー数が少ないグループに適していますが、メンバー数が数千人のグループには適していません。

    uniqueMember は groupOfUniqueNames オブジェクトの必須属性であるため、静的グループエントリーには uniqueMember 属性値が含まれている必要があります。このオブジェクトクラスには cn 属性が必要です。これを使用して、グループエントリーの DN を形成できます。

  • 動的グループ はフィルターを指定し、フィルターに一致するすべてのエントリーがこのグループのメンバーになります。
  • ロール は、静的グループおよび動的グループの概念を統一します。

ホスト環境では、ディレクトリー管理で使用されるグループのメンバーに名前を付ける値を格納するために、groupOfUniqueNames オブジェクトクラスの使用を検討してください。

また、ディレクトリー管理に使用するグループエントリーを ou=Groups ブランチの下に配置します。

4.2.3.3. 組織エントリーの命名
リンクのコピー

組織エントリー名は一意である必要があります。組織の正式名称を他の属性値と一緒に使用すると、確実に一意な名前にする場合に役立ちます (例 : o=example_a+st=Washington,o=ISP,c=US)。

商標を使用することもできますが、一意ではない可能性があります。

ホスティング環境では、組織エントリーに次の属性を含めます。

  • o (organizationName)
  • top、organization、および nsManagedDomain の値を持つ objectClass
4.2.3.4. その他のエントリーの命名
リンクのコピー

ディレクトリーには、地域、州、国、デバイス、サーバー、ネットワーク情報、その他のデータタイプなど、さまざまな情報を表すエントリーが含まれています。これらのエントリーのタイプには、RDN の cn 属性を使用します。グループエントリーに cn=administrators,dc=example,dc=com という名前を付けることもできます。

エントリーオブジェクトクラスが commonName 属性をサポートしない場合があります。代わりに、エントリーオブジェクトクラスがサポートする属性を使用します。命名属性は、エントリーで実際に使用する属性に対応する必要はありません。ただし、DN 属性とエントリーで使用される属性の間に何らかの相関関係があれば、ディレクトリーツリーの管理が容易になります。

4.2.4. エントリーおよびサブツリーの名前変更
リンクのコピー

エントリー名はディレクトリーツリー構造を定義します。各ブランチポイントは階層内に新しいリンクを作成します。 

                                                                  dc=example,dc=com  =>  root suffix
                                                        ou=People,dc=example,dc=com  =>  org unit
                                          st=California,ou=People,dc=example,dc=com  =>  state/province
                          l=Mountain View,st=California,ou=People,dc=example,dc=com  =>  city
           ou=Engineering,l=Mountain View,st=California,ou=People,dc=example,dc=com  =>  org unit
uid=jsmith,ou=Engineering,l=Mountain View,st=California,ou=People,dc=example,dc=com  =>  leaf entry
Copy to Clipboard Toggle word wrap

エントリーの命名属性 (エントリー RDN) を変更する場合は、modrdn 操作を実行します。この変更操作により、ディレクトリーツリー内のエントリーが移動されます。リーフエントリー (子のないエントリー) の場合、modrdn 操作によって RDN 部分のみが変更され、親エントリーは変更されません。

dg modrdn leaf
View larger image
dg modrdn leaf

サブツリーエントリーの場合、modrdn 操作はサブツリーエントリー自体の名前を変更し、サブツリーの下にあるすべての子エントリーの DN コンポーネントも変更します。

dg modrdn subtree
View larger image
dg modrdn subtree
重要

サブツリー modrdn 操作では、サブツリーエントリーの下にあるすべての子エントリーも移動され、名前が変更されます。サブツリーが大きい場合、これは時間とリソースを必要とするプロセスになります。ディレクトリーツリー階層の命名構造を計画し、サブツリーの名前変更操作が頻繁に要求されないようにします。

サブツリーの名前を変更する同様のアクションは、エントリーをあるサブツリーから別のサブツリーに移動することです。この modrdn 操作の拡張タイプのものは、同じ名前であってもエントリーの名前を同時に変更し、エントリーをある親から別の親に移動する newsuperior 属性を設定します。

dg modrdn newsuperior
View larger image
dg modrdn newsuperior

Directory Server は、entryrdn.db インデックスを使用して、新しい上位およびサブツリーの名前変更操作を実行します。Directory Server は、各エントリーを自己リンク、親リンク、および子リンクによって識別します。entryrdn.db インデックスは、親と子をエントリーの属性として提示し、完全な DN ではなく、一意の ID とその RDN で各エントリーを記述します。

entryrdn.db インデックスの形式は次のとおりです。 

numeric_id:RDN => self link
     ID: ; RDN: "rdn"; NRDN: normalized_rdn P:RDN => parent link
     ID: ; RDN: "rdn"; NRDN: normalized_rdn C:RDN => child link
     ID: #; RDN: "rdn"; NRDN: normalized_rdn
Copy to Clipboard Toggle word wrap

たとえば、ou=people サブツリーには dc=example,dc=com 親エントリーと uid=jsmith 子エントリーがあります。entryrdn.db インデックスには次のコンテンツが含まれます。 

4:ou=people
   ID: 4; RDN: "ou=people"; NRDN: "ou=people"
P4:ou=people
   ID: 1; RDN: "dc=example,dc=com"; NRDN: "dc=example,dc=com"
C4:ou=people
   ID: 10; RDN: "uid=jsmith"; NRDN: "uid=jsmith"
Copy to Clipboard Toggle word wrap

名前変更操作を実行するときは、次の点を考慮してください。

  • ルート接尾辞の名前を変更することはできません。
  • レプリカ合意を再設定する必要はありません。Directory Server は、データベース内のサブツリーではなく、データベース全体にレプリカ合意を適用します。
  • サブツリーの名前変更操作の後、すべての同期合意を再設定することを推奨します。同期合意は、接尾辞またはサブツリーレベルで設定されるため、サブツリーの名前を変更すると、同期が破損してしまう可能性があります。
  • サブツリーに設定されているすべてのサブツリーレベルの ACI と、サブツリーの子エントリーに設定されているすべてのエントリーレベルの ACI を手動で再設定する必要があります。
  • 子を持つサブツリーの名前を変更できますが、子を持つサブツリーを削除できません。
  • ou から dc に移動するなど、サブツリーのコンポーネントを変更しようとすると、スキーマ違反で失敗する可能性があります。たとえば、organizationalUnit オブジェクトクラスには ou 属性が必要です。操作が organizationalUnit オブジェクトクラスから ou 属性を削除しようとすると、サブツリー操作は失敗します。

4.3. ディレクトリーエントリーのグループ化
リンクのコピー

ディレクトリー管理を簡素化するために、作成したエントリーをグループ化します。Directory Server は、エントリーをグループ化する次の方法をサポートしています。

  • グループ
  • ロール

4.3.1. Directory Server のグループについて
リンクのコピー

グループはユーザーのコレクションです。Directory Server には、証明書グループ、URL グループ、一意のメンバーのみを持つ一意のグループなど、許可されるメンバーシップのタイプを反映するいくつかのグループタイプがあります。それぞれのグループタイプは、groupOfUniqueNames などのオブジェクトクラスと、uniqueMember などの対応するメンバー属性によって定義します。

グループのタイプは、メンバーのタイプを識別します。グループ設定は、Directory Server がグループにメンバーを追加する方法によって異なります。Directory Server には 2 つのグループタイプがあります。

静的グループ
静的グループには、有限かつ定義されたメンバーのリストがあります。グループエントリーにメンバーを手動で追加します。
動的グループ
動的グループでは、フィルターを使用してグループにメンバーを追加します。したがって、グループフィルターに一致するエントリーの数が変更されるため、メンバーの数は常に変更されます。

グループはエントリーに対して操作を実行しませんが、LDAP クライアントはグループを管理して操作を実行できます。

4.3.1.1. ユーザーエントリーにおけるグループメンバーシップのリスト表示
リンクのコピー

グループはユーザー DN のリストです。デフォルトでは、グループエントリーにのみメンバーシップ情報が含まれ、ユーザーエントリーにはこの情報は含まれません。

MemberOf プラグインは、グループメンバーエントリーを使用してユーザーエントリーを動的に更新し、ユーザーが属するグループを反映させます。プラグインは、指定されたメンバー属性を持つグループエントリーを自動的にスキャンし、すべてのユーザー DN をトレースバックして、グループの名前を持つユーザーエントリーに対応する memberOf 属性を作成します。

ユーザーが所属するすべてのグループの名前は memberOf 属性としてリストされ、memberOf 属性の値を管理できます。

注記

デフォルトでは、MemberOf プラグインは、Directory Server がグループと同じデータベースに保存するユーザー内の潜在的なメンバーのみを検索します。Directory Server がユーザーとグループを異なるデータベースに保存する場合、MemberOf プラグインはユーザーとグループの関係を定義できないため、ユーザーエントリーを更新しません。

memberOfAllBackends 属性を有効にして、設定されたすべてのデータベースを検索するように MemberOf プラグインを設定します。

プラグインエントリーに複数値 memberofgroupattr を設定することにより、MemberOf プラグインの単一インスタンスを設定して複数のタイプのグループを管理できます。

4.3.1.2. グループに新しいエントリーを自動的に追加する
リンクのコピー

グループメンバーシップに基づいて、パスワードポリシー、アクセス制御リスト、その他のルールを適用できます。グループを使用すると、ディレクトリー全体で一貫して確実にポリシーを適用できます。

新しいエントリーが作成されたときに新しいエントリーをグループに自動的に割り当てることで、管理者のアクションなしで、Directory Server が適切なポリシーと機能をそれらのエントリーに即座に適用できるようになります。

Automembership プラグインを使用すると、静的グループは動的グループのように動作できます。Automembership プラグインは、エントリー属性、ディレクトリーのロケーション、および正規表現に基づく一連のルールを使用して、ユーザーを指定されたグループに自動的に割り当てます。

他の属性の値によっては、LDAP 検索フィルターに一致するエントリーを異なるグループに追加する必要がある場合があります。たとえば、IP アドレスや物理的ロケーションに応じて、マシンを異なるグループに追加する必要があります。または、従業員 ID 番号に応じてユーザーを異なるグループに配置する必要があります。

自動メンバー定義は、自動メンバーシッププラグインコンテナー、自動メンバー定義、およびその定義の正規表現条件を含むネストされたエントリーのセットです。

dg automember plugin
View larger image
dg automember plugin
注記

Directory Server は、エントリーが Directory Server に新しく追加された場合にのみ、エントリーをグループに自動的に割り当てます。既存のエントリー、または自動メンバールールを満たすように変更したエントリーの場合は、修正タスクを実行して適切なグループメンバーシップを割り当てます。

4.3.2. Directory Server のロールについて
リンクのコピー

ロールは、静的グループと動的グループの両方として動作します。グループを使用すると、Directory Server はグループエントリーにメンバーとしてエントリーを追加します。ロールを使用すると、Directory Server はエントリーにロール属性を追加し、その属性を使用してロールエントリー内のメンバーを自動的に識別します。

ロールを使用すると、次の方法でユーザーを整理できます。

  • ロールメンバーを明示的にリストします。ロールを表示すると、このロールのメンバーの完全なリストが表示されます。ロールをクエリーしてメンバーシップを確認することができますが、これは動的グループでは不可能です。
  • エントリーがどのロールに属しているかを表示します。エントリーを表示すると、エントリーが属するロールを確認できます。これは、Directory Server がエントリー内の属性によってロールのメンバーシップを決定するためです。これはグループの memberOf 属性に似ていますが、唯一の違いは、この機能が動作するためにプラグインインスタンスを有効にしたり設定したりする必要がないことです。
  • 適切なロールを割り当てます。Directory Server は、ロールではなくエントリーを通じてロールメンバーシップを割り当てます。したがって、エントリーを編集するだけで、ユーザーが属するロールを 1 つの手順で簡単に割り当てたり削除したりできます。

管理対象ロールでは、静的グループで実行できるすべての操作を実行できます。動的グループによるフィルタリングと同様に、フィルタリングされたロールを使用してロールメンバーをフィルタリングできます。ロールは実装の柔軟性が高く、クライアントの複雑さが軽減されるため、グループよりも使いやすくなっています。

ロールタイプを使用して、メンバーを明示的または動的に指定できます。Directory Server は、以下のタイプのロールをサポートします。

管理対象ロール
管理対象ロールにはメンバーの明示的なリストがあります。
フィルター設定ロール
エントリーにロールで定義された特定の属性がある場合、Directory Server はエントリーをフィルタリングされたロールに割り当てます。ロール定義は、ターゲット属性の LDAP フィルターを指定します。フィルターに一致するエントリーは、ロールを持ちます (ロールのメンバーです)。
ネストされたロール
ネストされたロールは、他のロールが含まれるロールです。

1 回の操作でエントリーのグループ全体をアクティブ化または非アクティブ化できます。ロールのメンバーが属するロールを非アクティブ化することで、そのメンバーを一時的に無効にすることができます。

ロールを非アクティブ化しても、ユーザーはロールエントリーを使用してサーバーにバインドできます。ただし、ユーザーはこのロールに属するエントリーのいずれかを使用してサーバーにバインドすることはできません。非アクティブ化されたロールに属するエントリーでは、nsAccountLock 属性が true に設定されています。

ネストされたロールを非アクティブ化すると、ネストされたロール内のいずれかのロールのメンバーであるユーザーは、サーバーにバインドできなくなります。ネストされたロールの直接または間接のメンバーであるロールに属するすべてのエントリーでは、nsAccountLock が true に設定されています。ネストされたロールをネスト内の任意の時点で非アクティブ化すると、その下のすべてのロールとユーザーが非アクティブ化されます。

4.3.3. ロールとグループの使い分け
リンクのコピー

ロールとグループは同じ目標を達成することができます。管理対象ロールは、静的グループができることをすべて行うことができ、フィルタリングされたロールは、動的グループのようにメンバーをフィルタリングして識別することができます。ロールとグループの両方に、メリットとデメリットがあります。ロールを使用するか、グループを使用するか、あるいはその両方を使用するかは、要件とサーバーリソースのバランスによって決まります。

ロールによりクライアント側の複雑さが軽減されます。ロールを使用すると、クライアントアプリケーションはエントリー内の nsRole 操作属性を検索することでロールのメンバーシップを確認できます。この複数値属性は、エントリーが属するすべてのロールを識別します。クライアントアプリケーションの観点からは、メンバーシップを確認する方法は統一されており、サーバー側で実行されます。

ただし、ロールによってサーバーの複雑さが増します。サーバーがクライアントアプリケーションに対して機能するため、Directory Server ではロールの評価がグループを評価するよりもリソース集約されます。

グループを効果的に使用するには、よりスマートで複雑なクライアントが必要です。たとえば、ダイナミックグループは、アプリケーションの観点から見ると、グループメンバーのリストを提供するサーバーからのサポートを提供しません。代わりに、アプリケーションはグループ定義を取得してから、フィルターを実行します。適切なプラグインを設定する場合にのみ、ユーザーエントリーにグループメンバーシップ情報が含まれます。

注記

MemberOf プラグインを使用して、グループメンバーシップをバランスよく管理できます。MemberOf プラグインは、ユーザーがグループに追加されるたびに、ユーザーエントリーに memberOf 属性を動的に作成します。クライアントは、グループエントリーを 1 回検索することで、そのグループのすべてのメンバーのリストを取得できます。ユーザーエントリーを 1 回検索することで、そのユーザーが属するすべてのグループの完全なリストを取得できます。

サーバーには、メンバーシップが変更されたときにのみメンテナンスのオーバーヘッドが発生します。Directory Server は指定された member (グループ) 属性と memberOf (ユーザー) 属性の両方をデータベースに保存するため、検索に追加の処理は必要なく、クライアントからの検索が非常に効率的になります。

4.4. 仮想ディレクトリー情報ツリービュー
リンクのコピー

Directory Server は、仮想ディレクトリー情報ツリービュー をサポートします。仮想ビューは、エントリーを分類および検索するための標準のディレクトリーツリーに追加されるオプションの構造レイヤーです。

注記

仮想ビューは、複数のバックエンドと完全に互換性があるわけではありません。検索は 1 つのバックエンドに制限されるため、仮想ビューが返すエントリーは同じバックエンドに存在する必要があります。

仮想 DIT ビューの詳細は、ビューを使用した仮想ディレクトリー階層の作成 を参照してください。

4.4.1. 仮想 DIT ビューの例
リンクのコピー

以下の LDIF エントリーは、ロケーションに基づいた仮想ビュー階層を示しています。dc=example,dc=com の下に存在し、ビューの説明に適合するエントリーはすべて、場所ごとに整理されてこのビューに表示されます。 

dn: ou=Location Views,dc=example,dc=com
objectclass: top
objectclass: organizationalUnit
objectclass: nsView
ou: Location Views
description: views categorized by location


dn: ou=Sunnyvale,ou=Location Views,dc=example,dc=com
objectclass: top
objectclass: organizationalUnit
objectclass: nsView
ou: Sunnyvale
nsViewFilter: (l=Sunnyvale)
description: views categorized by location


dn: ou=Santa Clara,ou=Location Views,dc=example,dc=com
objectclass: top
objectclass: organizationalUnit
objectclass: nsView
ou: Santa Clara
nsViewFilter: (l=Santa Clara)
description: views categorized by location


dn: ou=Cupertino,ou=Location Views,dc=example,dc=com
objectclass: top
objectclass: organizationalUnit
objectclass: nsView
ou: Cupertino
nsViewFilter: (l=Cupertino)
description: views categorized by location
Copy to Clipboard Toggle word wrap

ou=Location Views,dc=example,dc=com に基づくサブツリー検索では、フィルター (l=Sunnyvale)、(l=Santa Clara)、または (l=Cupertino) に一致する dc=example,dc=com の下のすべてのエントリーが返されます。ただし、1 レベルの検索では、条件を満たすすべてのエントリーが 3 つの子孫ビューに存在するため、子ビューエントリー以外のエントリーは返されません。

ou=Location Views,dc=example,dc=com ビューエントリーそのものには、フィルターが含まれていません。この機能は、ビューに含まれるエントリーをさらに制限する必要なしに、階層組織を容易にします。すべてのビューがフィルターを省略できます。

サンプルフィルターは非常に単純ですが、使用するフィルターは必要に応じて複雑にすることができます。ビューに含めるエントリーのタイプを制限できます。たとえば、この階層を people エントリーだけに限定するには、(objectclass=organizationalperson) にフィルター値を指定して、nsfilter 属性を ou=Location Views,dc=example,dc=com に追加します。

フィルターを含む各ビューは、すべての子孫のビューのコンテンツを制限し、フィルターが含まれる子孫のビューも祖先の内容を制限します。たとえば、前述の新しいフィルターと共に最上位ビュー ou=Location Views を最初に作成すると、organization オブジェクトクラスを持つすべてのエントリーが含まれるビューが作成されます。さらにエントリーを制限する子孫のビューが追加されると、子孫のビューに表示されているエントリーは、先祖のビューから削除されます。これは、仮想 DIT ビューが従来の DIT の動作をエミュレートする方法を示しています。

仮想 DIT ビューは従来の DIT の動作をエミュレートしますが、ビューは従来の DIT ができなかったことを実行できます。つまり、エントリーを複数のロケーションに表示できます。たとえば、Entry B を Mountain View および Sunnyvale の両方に関連付けるには、ロケーション属性に Sunnyvale 値を追加すると、エントリーが両方のビューに表示されます。

dg 仮想階層を持つ dit
View larger image
dg 仮想階層を持つ dit

4.5. ディレクトリーツリーの設計例
リンクのコピー

グローバル企業および ISP のディレクトリーツリーの例を見つけます。

グローバル企業のディレクトリーツリー

ディレクトリーツリーのルートエントリーとして、インターネットドメイン名を使用します。次に、企業が事業を展開している国ごとに、そのルートエントリーの下のツリーを分岐します。

異なる国を表すには、l (location) 属性を使用します。

dg l 属性の使用
View larger image
dg l 属性の使用

ただし、c (country) 属性も、各国のブランチを表すことができます。

dg c 属性の使用
View larger image
dg c 属性の使用

LDAP では、DN 内の属性の順序に制限はありません。

ISP のディレクトリーツリー

インターネットサービスプロバイダー (ISP) は、ディレクトリーを使用して複数の企業をサポートできます。ISP はそれぞれのお客様を独自の企業として扱い、それに応じてディレクトリーツリーを設計する必要があります。セキュリティー上の理由から、お客様ごとに一意の接尾辞と独立したセキュリティーポリシーを持つ一意のディレクトリーツリーを提供します。

それぞれのお客様に個別のデータベースを割り当て、これらのデータベースを個別のサーバーに保存します。各ディレクトリーツリーを独自のデータベースに配置すると、他のお客様に影響を与えることなく、各ディレクトリーツリーのデータをバックアップおよび復元できます。

さらに、パーティション分割により、ディスク競合によって発生するパフォーマンスの問題や、ディスク障害の影響を受ける可能性のあるお客様の数が低減されます。

dg ISP サンプルの dit
View larger image
dg ISP サンプルの dit

第5章 ディレクトリートポロジーの設計
リンクのコピー

Red Hat Directory Server は多数のエントリーを保存できるため、複数のサーバーにエントリーを分散することを推奨します。ディレクトリートポロジーは、ディレクトリーツリーを複数の物理 Directory Server 間で分割する方法と、これらのサーバーが相互にリンクする方法を説明します。

5.1. トポロジーの概要
リンクのコピー

Directory Server は、ディレクトリーツリーの設計 で設計したディレクトリーツリーを複数の物理 Directory Server に分散する 分散ディレクトリー をサポートします。これらのサーバー間でディレクトリーを分割する方法は、次のパフォーマンス関連のポイントに影響します。

  • ディレクトリー対応アプリケーションのパフォーマンス。
  • ディレクトリーサービスの可用性。
  • ディレクトリーサービスの管理。

ディレクトリートポロジーには、次の重要な意味があります。

データベース

データベース は、レプリケーション、バックアップ、データ復元などのジョブの基本単位です。単一のディレクトリーを複数の部分に分割し、それらを個別のデータベースに割り当てることができます。その後、これらのデータベースをサーバー間で分散して、各サーバーの作業負荷を軽減できます。1 台のサーバーに複数のデータベースを保存できます。たとえば、1 台のサーバーには 3 つの異なるデータベースが含まれる場合があります。

複数のデータベースの詳細は、複数のデータベースの使用について を参照してください。

Suffix

ディレクトリーツリーを複数のデータベースに分割すると、各データベースには 接尾辞 と呼ばれるディレクトリーツリーの一部が含まれます。たとえば、1 つのデータベースを使用して、ディレクトリーツリーの ou=people,dc=example,dc=com 接尾辞 (ブランチ) 内のエントリーのみを保存できます。

接尾辞の詳細は、接尾辞について を参照してください。

ナレッジ参照 (リファラルとチェイニング)

Directory Server は、異なるデータベースに保存されているディレクトリーデータをリンクするための、リファラルおよびチェイニングなどのナレッジ参照メカニズムを提供します。

リファラルおよびチェイニングの詳細は、リファラルの使用 および チェイニングの使用 を参照してください。

5.2. ディレクトリーデータの分散
リンクのコピー

ディレクトリーデータを分散することで、企業内の各サーバーに物理的にディレクトリーエントリーを含めることなく、複数のサーバーにわたってディレクトリーをスケーリングできます。したがって、分散ディレクトリーでは、1 台のサーバーよりもはるかに多くのエントリーを保持することができます。

さらに、分散の詳細をユーザーに非表示にするようにディレクトリーを設定することもできます。

5.2.1. Directory Server での複数のデータベースの使用
リンクのコピー

ディレクトリーサーバーは、データを LDAP Database Manager (LDBM) に保存します。各データベースは、割り当てられたすべてのデータが含まれる大規模なファイルのセットで構成されます。

ディレクトリーツリーのさまざまな部分をさまざまなデータベースに保存できます。たとえば、ディレクトリーツリーは次のように表示されます。

図5.1 ディレクトリーツリーの例

dg ディレクトリートポロジーの設計 1
View larger image
dg ディレクトリートポロジーの設計 1

例に示されるディレクトリーは、次の 3 つのサブ接尾辞で構成されています。

  • ou=people,dc=example,dc=com
  • ou=groups,dc=example,dc=com
  • ou=services,dc=example,dc=com

3 つのサブ接尾辞のデータを次の方法で 3 つの個別のデータベースに保存できます。

図5.2 別のデータベースでの接尾辞データの保存

dg ディレクトリートポロジーの設計 2
View larger image
dg ディレクトリートポロジーの設計 2
  • ou=people,dc=example,dc=com の DB1
  • ou=groups,dc=example,dc=com の DB2
  • ou=services,dc=example,dc=com の DB3

ディレクトリーツリーを複数のデータベースに分割すると、これらのデータベースを複数のサーバーに分散して、各サーバーの負荷を軽減できます。たとえば、3 つのデータベース (DB1、DB2、DB3) を 2 つのサーバー (Server A と Server B) に保存できます。

図5.3 個別のサーバー間での接尾辞データベースの分割

dg ディレクトリートポロジーの設計 3
View larger image
dg ディレクトリートポロジーの設計 3

Server A には DB1 および DB2 が含まれ、Server B には DB3 が含まれます。

Directory Server は、ディレクトリーサービス全体を停止することなく、データベースを動的に追加することをサポートします。

5.2.2. Directory Server の接尾辞
リンクのコピー

データベースには、特定の接尾辞 (ディレクトリーツリーの一部) のデータが含まれています。Directory Server では、root 接尾辞またはサブ接尾辞を作成できます。

root 接尾辞
root 接尾辞は、ツリーの最上部のエントリーです。これは、ディレクトリーツリーのルート、または Directory Server 用に設計したより大きなツリーの一部にすることができます。
サブ接尾辞
サブ接尾辞は root 接尾辞の下のブランチです。

たとえば、ExampleCom は、次の方法でディレクトリーデータの分散を表す接尾辞を作成します。

図5.4 ExampleCom のディレクトリーツリー

dg ディレクトリートポロジーの設計 4
View larger image
dg ディレクトリートポロジーの設計 4

ExampleCom は、次の方法でディレクトリーツリーを 4 つの異なるデータベースに分散します。

図5.5 複数のデータベースにまたがるディレクトリーツリー

dg ディレクトリートポロジーの設計 5
View larger image
dg ディレクトリートポロジーの設計 5

4 つのデータベースには、次の接尾辞のデータが含まれています。

  • dc=example,dc=com root 接尾辞このデータベースには、dc=example,dc=com データとともに、元のディレクトリーツリーの ou=marketing,dc=example,dc=com ブランチのデータも含まれています。
  • ou=testing,dc=example,dc=com サブ接尾辞
  • ou=development,dc=example,dc=com サブ接尾辞
  • ou=partners,ou=development,dc=example,dc=com サブ接尾辞

複数の root 接尾辞の使用

ディレクトリーサービスには複数の root 接尾辞を含めることができます。たとえば、ISP は、example_a.com 用と example_b.com 用に複数の Web サイトをホストします。ExampleISP のディレクトリー構造は次のとおりです。

図5.6 複数の root 接尾辞を含むディレクトリーツリー

dg ディレクトリートポロジーの設計 6
View larger image
dg ディレクトリートポロジーの設計 6

ISP は次の root 接尾辞を作成します。

  • dc=exampleISP,dc=com には、以下のエントリーのデータが含まれます。

    • dc=exampleISP,dc=com
    • o=ISP,dc=exampleISP,dc=com
    • o=internet,dc=exampleISP,dc=com
    • ou=groups,dc=exampleISP,dc=com

  • o=example_a.com には、以下のエントリーのデータが含まれます。

    • o=example_a.com,o=ISP,dc=exampleISP,dc=com
    • ou=people,o=example_a.com,o=ISP,dc=exampleISP,dc=com
    • ou=groups,o=example_a.com,o=ISP,dc=exampleISP,dc=com

  • o=example_b.com には、以下のエントリーのデータが含まれます。

    • o=example_b.com,o=ISP,dc=exampleISP,dc=com
    • ou=people,o=example_b.com,o=ISP,dc=exampleISP,dc=com
    • ou=groups,o=example_b.com,o=ISP,dc=exampleISP,dc=com

5.3. Directory Server のナレッジ参照
リンクのコピー

ナレッジ参照は、分散データ間の関係を定義します。ナレッジ参照は、さまざまなデータベースに保持されているディレクトリー情報へのポインターです。Directory Server は、分散データを 1 つのディレクトリーツリーにリンクする以下のタイプのナレッジ参照を提供します。

リファラル
Directory Server は、クライアントアプリケーションが要求を満たすために別のサーバーに接続する必要があることを示す情報をクライアントアプリケーションに返します。
チェイニング
Directory Server は、クライアントアプリケーションの代わりに他のサーバーに問い合わせ、操作の完了時にクライアントアプリケーションに結果をまとめて返します。

5.4. Directory Server でのリファラルの使用
リンクのコピー

リファラル とは、Directory Server によって返される情報で、要求を続行するためにどのサーバーに接続するかをクライアントアプリケーションに通知します。このリダイレクトメカニズムは、クライアントアプリケーションがローカルサーバーに含まれていないディレクトリーエントリーを要求したときに発生します。

Directory Server は以下のタイプのリファラルをサポートしています。

デフォルトのリファラル
クライアントアプリケーションがローカルツリーに属していないエントリーを要求すると、ディレクトリーはデフォルトのリファラルを返します。デフォルトのリファラルは、サーバーレベルと接尾辞レベルで設定できます。
スマートリファラル
Directory Server は、ディレクトリー内のエントリーにスマートリファラルを保存します。スマートリファラルは、スマートリファラルを含むエントリーの DN と一致する DN を持つサブツリーに関する情報を含むサーバーを指します。

Directory Server は、すべてのリファラルを LDAP ユニフォームリソースロケーター (LDAP URL) の形式で返します。

5.4.1. LDAP リファラルの構造
リンクのコピー

Directory Server は、すべてのリファラルを LDAP URL の形式で返します。LDAP URL には以下の情報が含まれています。

  • 問い合わせるサーバーのホスト名。
  • LDAP 要求をリッスンするように設定されたサーバーのポート番号。
  • ベース DN (検索操作用) またはターゲット DN (操作の追加、削除、および変更用)。

たとえば、クライアントアプリケーションは、dc=example,dc=com ブランチで姓が Jensen のエントリーを検索します。ただし、ディレクトリーツリーの一部はヨーロッパのサーバーに保存されます。リファラルは、以下の LDAP URL をクライアントアプリケーションに返します。 

ldap://europe.example.com:389/ou=people,l=europe,dc=example,dc=com
Copy to Clipboard Toggle word wrap

このリファラルは、クライアントアプリケーションに、ポート 389 でホスト europe.example.com に接続し、ヨーロッパブランチ ou=people,l=europe,dc=example,dc=com を通じて新しい検索を送信するように指示します。

使用する LDAP クライアントアプリケーションによって、リファラルの処理方法が決まります。クライアントアプリケーションの中には、参照されたサーバーで、操作を自動的に再試行するものがあります。他のクライアントアプリケーションは、リファラル情報をユーザーに返します。Red Hat Directory Server が提供するほとんどの LDAP クライアントアプリケーション (コマンドラインユーティリティーなど) は、自動的にリファラルに従います。Directory Server は、サーバーにアクセスするために、最初のディレクトリー要求で提供されたのと同じバインド認証情報を使用します。

ほとんどのクライアントアプリケーションは、限られた数のリファラル (hops) に従います。リファラル数を制限することで、クライアントアプリケーションがディレクトリールックアップ要求を完了しようとして費やす時間を短縮し、循環リファラルパターンが原因で発生するハングプロセスを排除する際に役立ちます。

5.4.2. Directory Server のデフォルトのリファラル
リンクのコピー

Directory Server は、接続されたサーバーまたはデータベースに要求されたデータが含まれていない場合、クライアントに デフォルトのリファラル を返します。

たとえば、クライアントが次のディレクトリーエントリーを要求します: uid=bjensen,ou=people,dc=example,dc=com

ただし、サーバーは dc=europe,dc=example,dc=com 接尾辞に保存されているエントリーのみを管理します。ディレクトリーは、dc=example,dc=com 接尾辞の下に保存されているエントリーに関して、どのサーバーに接続するかという情報を含むリファラルをクライアントに返します。その後、クライアントは該当するサーバーに問い合わせ、元の要求を再提出します。

デフォルトのリファラルは、サーバーレベルと接尾辞レベルで設定できます。

  • サーバーレベルのリファラルを設定するには、サーバーレベルの設定属性 nsslapd-referral を使用します。Directory Server は、その属性値を dse.ldif 設定ファイルに保存します。サーバーが利用できない場合、またはクライアントにローカルサーバー上のデータにアクセスするパーミッションがない場合は、Directory Server はデフォルトのリファラルを返します。
  • 接尾辞レベルのリファラルを設定するには、接尾辞設定属性 nsslapd-referral と nsslapd-state を使用します。接尾辞全体がオフラインになると、Directory Server はその接尾辞に対して行われたクライアント要求へのリファラルを返します。

5.4.3. Directory Server のスマートリファーラル
リンクのコピー

デフォルトのリファラルに加えて、Directory Server は、ディレクトリーエントリーまたはディレクトリーツリーを特定の LDAP URL に関連付ける スマートリファラル もサポートします。したがって、Directory Server はクライアント要求を次のいずれかに転送できます。

  • 別のサーバーに含まれる同じ namespace。
  • 異なるサーバー上の異なる namespace。
  • 同じサーバー上の異なる namespace。

デフォルトのリファラルとは異なり、Directory Server はスマートリファラルを設定ファイルではなくディレクトリー内に保存します。

たとえば、ExampleCom のアメリカオフィスのディレクトリーには、ou=people,dc=example,dc=com ディレクトリーブランチポイントが含まれます。

このブランチの要求を ExampleCom のヨーロッパオフィスの ou=people ブランチにリダイレクトするには、ou=people エントリー自体にスマートリファラルを指定できます。スマートリファーラルには次の値があります。

ldap://europe.example.com:389/ou=people,dc=example,dc=com

アメリカディレクトリーの ou=people ブランチへの要求は、以下の方法でヨーロッパディレクトリーにリダイレクトされます。

図5.7 スマートリファラルを使用した要求のリダイレクト

dg ディレクトリートポロジーの設計 7
View larger image
dg ディレクトリートポロジーの設計 7

同じメカニズムを使用して、異なる namespace を使用する別のサーバーにクエリーをリダイレクトすることもできます。たとえば、ExampleCom のイタリアのオフィスで働く従業員が、ExampleCom のアメリカの従業員の電話番号をヨーロッパのディレクトリーサービスに要求するとします。Directory Server は次のリファーラルを返します。

ldap://america.example.com:389/ou=people,dc=example,dc=com

次の図は、別の namespace へのリファラルがどのように機能するかを示しています。

図5.8 異なるサーバーと namespace へのクエリーのリダイレクト

dg ディレクトリートポロジーの設計 8
View larger image
dg ディレクトリートポロジーの設計 8

最後に、同じサーバー上で複数の接尾辞を提供する場合、ある namespace から同じサーバー上で提供される別の namespace にクエリーをリダイレクトできます。たとえば、ローカルサーバー上の o=example,c=us のすべてのクエリーを dc=example,dc=com にリダイレクトするには、o=example,c=us エントリーにスマートリファラル ldap:///dc=example,dc=com を設定します。LDAP URL の 3 番目のスラッシュは、URL が同じサーバーを指していることを示します。

注記

ある namespace から他の namespace へのリファラルは、その識別名に基づいて検索が行われるクライアントに対してのみ機能します。ou=people,o=example,c=US 以下の検索などのその他のタイプの操作は、正しく実行されません。

5.4.4. スマートリファラルを使用する際の考慮事項
リンクのコピー

スマートリファラルを使用する前に、次の点を考慮してください。

  • 設計はシンプルにします。

    複雑なリファラル Web では管理が困難になります。スマートリファラルを過度に使用すると、循環リファラルパターンにつながる可能性もあります。たとえば、あるリファラルが LDAP URL を指し、その URL がまた別の LDAP URL を指し、といった具合に、チェーンのどこかでリファラルが元のサーバーを指すまで続きます。次の図は循環リファラルパターンを示しています。

図5.9 循環リファラルパターン

dg ディレクトリートポロジーの設計 9
View larger image
dg ディレクトリートポロジーの設計 9

  • 主要なブランチポイントでリダイレクトします。

    セキュリティーを強化し、メンテナンスコストを削減するには、接尾辞と主要なブランチポイントレベルでリダイレクトを処理するようにリファラルの使用を制限します。スマートリファラルをエイリス作成メカニズムとして使用しないでください。

  • セキュリティーへの影響を考慮します。

    アクセス制御はリファラルの境界を越えません。要求が最初に送信されたサーバーがエントリーへのアクセスを許可している場合でも、スマートリファラルがクライアント要求を別のサーバーに送信すると、クライアントアプリケーションはアクセスを拒否される可能性があります。

    さらに、クライアントアプリケーションには、クライアントが参照されるサーバーに対して認証するための認証情報が必要です。

5.5. チェイニングの使用
リンクのコピー

チェイニングは、クライアントアプリケーションに代わって要求を別のサーバーにリダイレクトする方法です。チェイニングはプラグインとしてサーバーに実装されます。プラグインはデフォルトで有効です。このプラグインを使用すると、リモートに保存されたデータを指す特別なエントリーであるデータベースリンクを作成できます。クライアントアプリケーションがデータベースリンクからデータを要求すると、データベースリンクはリモートデータベースからデータを取得し、クライアントに返します。

図5.10 チェイニングを使用したクライアント要求のサーバーへの送信

dg ディレクトリートポロジーの設計 10
View larger image
dg ディレクトリートポロジーの設計 10

各データベースリンクは、データを保持するリモートサーバーに関連付けられます。障害が発生したときにデータベースリンクが使用するデータのレプリカを含む代替リモートサーバーを設定することもできます。

データベースリンクの設定の詳細は、データベースリンクの作成と管理 を参照してください。

データベースリンクは以下の機能を提供します。

  • リモートデータへの非表示のアクセス

    データベースリンクはクライアント要求を解決し、データディストリビューションをクライアントから完全に隠します。

  • 動的管理

    システム全体をクライアントアプリケーションで利用できる状態で、ディレクトリーの一部をシステムに追加したり、システムから削除したりできます。データベースリンクを使用すると、ディレクトリー全体にエントリーを再分散するまで、一時的にリファラルをアプリケーションに戻すことができます。

    クライアントアプリケーションをデータベースに転送する代わりに、リファラルを返す接尾辞を使用してこれを実装することもできます。

  • アクセス制御

    データベースリンクは、クライアントアプリケーションになりすまし、適切な認証 ID をリモートサーバーに提供します。アクセス制御の評価が不要な場合は、リモートサーバー上でユーザーのなりすましを無効にすることができます。

    データベースリンクとアクセス制御の評価の詳細は、データベースリンクとアクセス制御の評価 を参照してください。

5.6. リファラルとチェイニングの使い分け
リンクのコピー

ディレクトリーの特定のニーズに基づいて、リファラルとチェイニングのどちらかを選択します。

  • チェイニングにより、クライアントの複雑さが軽減されますが、その代償としてサーバーの複雑さが増します。ただし、チェイニングを使用すると、クライアントアプリケーションは単一のサーバーと対話しながら、複数のサーバーに保存されているデータに引き続きアクセスできます。クライアントは、要求がチェーンされているサーバーに対して認証を行う必要はありません。

  • リファラルの場合、クライアントアプリケーションはリファラルを見つけて検索結果を再送信する必要があります。クライアントは、参照先のサーバーに対して正しく認証できる必要もあります。

    さらに、ある会社のネットワークがプロキシーを使用している場合、リファラルが失敗することがあります。たとえば、クライアントアプリケーションは、ファイアウォール内の 1 つのサーバーのみと通信するパーミッションを持っている場合があります。そのアプリケーションが別のサーバーに参照されている場合、アプリケーションは正常に接続できない可能性があります。

    ただし、リファラルにより、クライアントアプリケーションの作成者にはより柔軟性が提供され、開発者は分散ディレクトリー操作の進行状況についてユーザーに優れたフィードバックを提供できます。

5.6.1. アクセス制御の評価
リンクのコピー

チェイニングは、リファラルとは異なる方法でアクセス制御を評価します。リファラルを使用する場合、クライアントエントリー (バインド DN) がすべてのターゲットサーバー上に存在している必要があります。チェイニングでは、クライアントエントリーはすべてのターゲットサーバー上にある必要はありません。

5.6.1.1. リファラルを使用した検索要求の実行
リンクのコピー

次の図は、リファラルを使用するサーバーへのクライアント要求を示しています。

図5.11 リファラルを使用したクライアント要求のサーバーへの送信

dg ディレクトリートポロジーの設計 11
View larger image
dg ディレクトリートポロジーの設計 11

検索要求は次のように発生します。

  1. クライアントアプリケーションは、最初に Server A にバインドします。
  2. Server A にはユーザー名とパスワードを提供するクライアントのエントリーが含まれるため、バインドの受け入れメッセージを返します。リファラルを機能させるためには、クライアントエントリーが Server A に存在する必要があります。
  3. クライアントアプリケーションは操作要求を Server A に送信します。
  4. ただし、Server A には要求された情報が含まれていません。代わりに、Server A はクライアントアプリケーションにリファラルを返し、Server B に接続するように指示します。
  5. 次に、クライアントアプリケーションは Server B にバインド要求を送信します。バインドを正常に実行するには、Server B にクライアントアプリケーションのエントリーも含まれている必要があります。
  6. バインドに成功し、クライアントアプリケーションは検索操作を Server B に再送信できるようになりました。

この方法では、Server B が、Server A からのクライアントエントリーのレプリケートされたコピーを持つ必要があります。

5.6.1.2. チェイニングを使用した検索要求の実行
リンクのコピー

サーバー全体でクライアントエントリーをレプリケートする問題は、チェイニングを使用して解決できます。

図5.12 チェイニングを使用したクライアント要求のサーバーへの送信

dg ディレクトリートポロジーの設計 12
View larger image
dg ディレクトリートポロジーの設計 12

検索要求は次のように発生します。

  1. クライアントアプリケーションが Server A にバインドすると、Server A はユーザー名とパスワードが正しいか確認しようとします。
  2. Server A にはクライアントアプリケーションに対応するエントリーが含まれません。代わりに、クライアントの実際のエントリーが含まれる Server B へのデータベースリンクが含まれます。Server A はバインド要求を Server B に送信します。
  3. Server B は Server A に受け入れ応答を送信します。
  4. 次に、Server A はデータベースリンクを使用して、クライアントアプリケーションの要求を処理します。データベースリンクは、Server B にあるリモートデータストアに問い合わせ、検索操作を処理します。

チェーンシステムでは、クライアントアプリケーションに対応するエントリーは、クライアントが要求するデータと同じサーバーに置く必要はありません。次の図は、2 つのチェーンサーバーを使用してクライアントの検索要求を完了する方法を示しています。

図5.13 2 つの異なるサーバーを使用してクライアントを認証し、データを取得する

dg ディレクトリートポロジーの設計 13
View larger image
dg ディレクトリートポロジーの設計 13

検索要求は次のように発生します。

  1. クライアントアプリケーションは Server A にバインドし、Server A はユーザー名とパスワードが正しいことを確定します。
  2. Server A にはクライアントアプリケーションに対応するエントリーが含まれません。代わりに、クライアントの実際のエントリーが含まれる Server B へのデータベースリンクが含まれます。Server A はバインド要求を Server B に送信します。
  3. Server B は Server A に受け入れ応答を送信します。
  4. 次に、Server A は別のデータベースリンクを使用して、クライアント要求を処理します。データベースリンクは、Server C にあるリモートデータストアに問い合わせ、検索操作を処理します。
5.6.1.3. サポートされないアクセス制御
リンクのコピー

データベースリンクは、以下のアクセス制御をサポートしません。

  • ユーザーエントリーが別のサーバー上にある場合に、ユーザーエントリーのコンテンツにアクセスする必要があるコントロール。これには、グループ、フィルター、およびロールに基づくアクセス制御が含まれます。
  • クライアント IP アドレスまたは DNS ドメインに基づいた制御は拒否される可能性があります。これは、データベースリンクがリモートサーバーに問い合わせする際に、クライアントになりすますためです。リモートデータベースに IP ベースのアクセス制御が含まれている場合は、元のクライアントドメインではなく、データベースリンクドメインを使用してそれらを評価します。

5.7. データベースパフォーマンスを改善するためのインデックスの使用
リンクのコピー

データベースのサイズによっては、クライアントアプリケーションによる検索に多くの時間とリソースがかかる場合があります。したがって、検索パフォーマンスを向上させるには、インデックスを使用できます。

インデックスは、ディレクトリーデータベースに保存されるファイルです。ディレクトリー内のデータベースごとに個別のインデックスファイルが保持されます。各ファイルには、インデックスを付ける属性に従って名前が付けられます。特定の属性のインデックスファイルには、複数のタイプのインデックスを含めることができます。たとえば、cn.db というファイルには、共通名 (cn) の属性のすべてのインデックスが含まれます。

ディレクトリーを使用するアプリケーションのタイプに応じて、さまざまなタイプのインデックスを使用します。アプリケーションによっては、頻繁に特定の属性を検索するか、別の言語でディレクトリーを検索するか、あるいは特定の形式でデータが必要な場合があります。

5.7.1. ディレクトリーインデックスタイプの概要
リンクのコピー

Directory Server は以下のインデックスタイプをサポートしています。

存在インデックス
uid などの特定の属性を持つエントリーをリスト表示します。
等価インデックス
cn=Babs Jensen などの特定の属性値を含むエントリーをリスト表示します。
概算インデックス
近似 (または "類似") 検索を可能にします。たとえば、エントリーには cn=Babs L. Jensen の属性値が含まれる場合があります。概算検索では、cn~=Babs Jensen、cn~=Babs、および cn~=Jensen に対する検索でこの値が返されます。
注記

近似インデックスでは、ASCII 文字を使用して名前を英語で表記する必要があります。

部分文字列インデックス
エントリー内の部分文字列を検索できます。たとえば、cn=*derson を検索すると、この文字列を含む Bill Anderson、Norma Henderson、Steve Sanderson などの一般的な名前が一致します。
国際インデックス
国際ディレクトリー内の情報の検索パフォーマンスが向上します。インデックスを作成する属性にロケール (国際化 OID) を関連付けることで、一致ルールを適用するようにインデックスを設定できます。
ブラウジングインデックスまたは仮想リストビュー (VLV) インデックス
Web コンソールのエントリーの表示パフォーマンスが向上します。任意のディレクトリーツリーブランチに ブラウジングインデックス を作成して、表示パフォーマンスを向上させることができます。

5.7.2. インデックス化のコストの評価
リンクのコピー

インデックスを使用して検索パフォーマンスを向上させる場合は、次の点を考慮してください。

  • インデックスを使用すると、エントリーの修正にかかる時間が長くなります。

    維持するインデックスの数が増えるほど、ディレクトリーによるデータベースの更新時間が長くなります。

  • インデックスファイルはディスク領域を使用します。

    インデックスする属性が増えるほど、作成されるファイルも多くなります。さらに、長い文字列を含む属性に対して近似インデックスと部分文字列インデックスを作成すると、インデックスファイルが急速に大きくなる可能性があります。

  • インデックスファイルはメモリーを使用します。

    より効率的に実行するために、Directory Server は可能な限り多くのインデックスファイルをメモリーに格納します。インデックスファイルは、データベースキャッシュのサイズに応じて利用可能なプールのメモリーを使用します。インデックスファイルの数が多いと、データベースキャッシュも大きくなります。

  • インデックスファイルの作成には時間がかかります。

    インデックスファイルは検索時の時間を短縮しますが、不要なインデックスを維持することは時間の浪費につながります。ディレクトリーを使用する際は、クライアントアプリケーションが必要とするファイルのみを維持します。

第6章 レプリケーションプロセスの設計
リンクのコピー

ディレクトリー情報をレプリケートすると、ディレクトリーの可用性とパフォーマンスが向上します。必要なときに必要な場所でデータが利用できるようにレプリケーションプロセスを設計します。

6.1. レプリケーションの概要
リンクのコピー

レプリケーションは、ディレクトリーデータを Directory Server から別の Directory Server に自動的にコピーするメカニズムです。レプリケーションを使用すると、独自のデータベース (レプリカ) に保存されている任意のディレクトリーツリーまたはサブツリーをサーバー間でコピーできます。情報のメインコピーを保持しているサーバーは、更新内容をすべてのレプリカに自動的にコピーします。

レプリケーションは高可用性ディレクトリーサービスを提供し、データを地理的に分散できます。以下は、レプリケーションの利点のリストです。

  • フォールトトレランスとフェイルオーバー

    ディレクトリーツリーを複数のサーバーにレプリケートすると、ハードウェア、ソフトウェア、またはネットワークの問題により、クライアントアプリケーションが特定の Directory Server にアクセスできない場合でも、ディレクトリーを利用できます。クライアントは、読み取りと書き込み操作のために、別の Directory Server を参照します。

    注記

    追加、変更、削除 操作のフェイルオーバーは、マルチサプライヤーレプリケーション でのみ可能です。

  • 負荷分散

    ディレクトリーツリーをサーバー全体でレプリケートすると、特定のサーバーへのアクセス負荷が軽減され、サーバーの応答時間が改善されます。

  • より高いパフォーマンス

    ディレクトリーエントリーをユーザーに近いロケーションにレプリケートすると、Directory Server のパフォーマンスが向上します。

  • ローカルデータ管理

    レプリケーションを使用すると、企業全体の他の Directory Server と情報を共有しながら、情報をローカルで所有および管理できます。

6.1.1. レプリケーションの概念
リンクのコピー

レプリケーションの実装を検討するときは、次の基本的な質問に答えてください。

  • レプリケートする必要がある情報は何ですか?
  • その情報のメインコピー、またはサプライヤーレプリカはどのサーバーに保存されていますか?
  • その情報の読み取り専用コピー、つまりコンシューマーレプリカはどのサーバーに保存されていますか?
  • コンシューマーレプリカがクライアントアプリケーションから 変更 要求を受信すると何が起こりますか?どのサーバーに要求をリダイレクトする必要がありますか?

Directory Server がレプリケーションを実装する方法を理解するための概念を説明します。

6.1.1.1. レプリカ
リンクのコピー

レプリカ はレプリケーションに参加するデータベースです。Directory Server は、以下のタイプのレプリカをサポートしています。

サプライヤーレプリカ (読み取り/書き込み)
ディレクトリーデータのメインコピーを含む読み取り/書き込みデータベース。ディレクトリークライアントからの 変更 要求を処理するのは、サプライヤーレプリカのみです。
コンシューマーレプリカ (読み取り専用)
サプライヤーレプリカに保持されている情報の別のコピーを含む読み取り専用データベース。コンシューマーレプリカはディレクトリークライアントからの 検索 要求を処理できますが、変更 要求はサプライヤーレプリカを参照します。

Directory Server は、レプリケーションにおいて異なるロールを持つ複数のデータベースを管理できます。たとえば、サプライヤーレプリカに dc=accounting,dc=example,dc=com 接尾辞を保存し、コンシューマーレプリカに dc=sales,dc=example,dc=com 接尾辞を保存することができます。

6.1.1.2. レプリケーションユニット
リンクのコピー

レプリケーションの最小単位は接尾辞 (namespace) です。レプリケーションメカニズムでは、1 つの接尾辞が 1 つのデータベースに対応している必要があります。Directory Server は、カスタム分散ロジックを使用して 2 つ以上のデータベースに分散された接尾辞をレプリケートできません。

6.1.1.3. サプライヤーとコンシューマー
リンクのコピー
サプライヤーサーバー
サプライヤーサーバーは、更新を他のサーバーにレプリケートするサーバーです。サプライヤーサーバーは、各更新操作の記録を含む changelog を保持します。
コンシューマーサーバー
コンシューマーサーバーは、他のサーバーから更新を受信するサーバーです。

次の状況では、サーバーはサプライヤーとコンシューマーのロールを同時に果たすことができます。

  • カスケードレプリケーションで、一部のサーバーが ハブサーバー のロールを果たす場合。詳細は、カスケードレプリケーション を参照してください。
  • マルチサプライヤーレプリケーションで、複数のサーバーがサプライヤーの読み取り/書き込みレプリカを管理する場合。各サーバーは他のサーバーから更新を送受信します。詳細は、マルチサプライヤーレプリケーション を参照してください。
注記

Red Hat Directory Server では、コンシューマーではなく、サプライヤーサーバーが常にレプリケーションを開始します。

サプライヤーサーバーは次のアクションを実行する必要があります。

  • ディレクトリークライアントからの 読み取り 要求や 更新 要求に対応します。
  • レプリカの状態情報と changelog を維持します。サプライヤーサーバーは、管理する読み取り/書き込みレプリカに加えられた変更を常に記録する必要があります。これにより、すべての変更がコンシューマーサーバーにレプリケートされるようになります。
  • コンシューマーサーバーへのレプリケーションを開始します。

コンシューマーサーバーは次のアクションを実行する必要があります。

  • 読み取り 要求に対応します。
  • レプリカのサプライヤーサーバーへの 更新 要求を参照します。コンシューマーサーバーがエントリーの追加、削除、または変更の要求を受信すると、その要求はサプライヤーサーバーに転送されます。サプライヤーサーバーは要求を実行し、これらの変更をレプリケートします。

カスケードレプリケーションの特殊なケースでは、ハブサーバーは次のアクションを実行します。

  • 読み取り 要求に対応します。
  • 更新 要求をサプライヤーサーバーに参照します。
  • コンシューマーサーバーへのレプリケーションを開始します。
6.1.1.4. Changelog
リンクのコピー

すべてのサプライヤーサーバーは changelog を維持します。changelog は、サプライヤーレプリカで発生した変更の記録です。サプライヤーサーバーは、これらの変更を他のサーバーに保存されているレプリカにプッシュします。

エントリーが追加、変更、または削除されると、Directory Server は実行された LDAP 操作を changelog ファイルに記録します。

changelog はサーバーの内部使用のみを目的としています。changelog を読み取る必要があるアプリケーションがある場合は、下位互換性のために Retro Changelog プラグインを使用する必要があります。

changelog 属性の詳細は、cn=changelog,cn=database_name,cn=ldbm database,cn=plugins,cn=config の下のデータベース属性 を参照してください。

6.1.1.5. レプリカ合意
リンクのコピー

サーバーはレプリカ合意を使用して、2 つのサーバー間でレプリケーションを実行する方法を定義します。レプリカ合意は、1 つ のサプライヤーと 1 つ のコンシューマーとの間のレプリケーションを説明します。合意はサプライヤーサーバー上で設定され、次の情報を識別します。

  • レプリケートするデータベース。
  • データがプッシュされるコンシューマーサーバー。
  • レプリケーションを実行できる時間。
  • サプライヤーサーバーが、コンシューマーでバインドを実行するために使用する必要がある DN と認証情報 (レプリケーションマネージャー エントリーまたは サプライヤーバインド DN と呼ばれる)。
  • 接続の保護方法 (TLS、StartTLS、クライアント認証、SASL、簡易認証など)。
  • レプリケートする属性。部分レプリケーションの詳細は、部分レプリケーション を参照してください。

6.1.2. データの整合性
リンクのコピー

データの一貫性とは、レプリケートされたデータベースの内容が特定の時点で互いにどれだけ一致しているかを指します。サプライヤーは、コンシューマーをいつ更新する必要があるかを決定し、レプリケーションを開始します。レプリケーションは、コンシューマーが初期化された後にのみ開始できます。

Directory Server は、レプリカを常に同期させたり、特定の時間や曜日に更新をスケジュールしたりできます。

常に同期されたレプリカ

常に同期されたレプリカはデータの一貫性を向上させますが、頻繁な更新によりネットワークトラフィックが増加します。

次の場合には、常に同期されたレプリカを使用します。

  • サーバー間に、信頼できる高速接続がある場合。
  • クライアントアプリケーションは主に 検索、読み取り、比較 を Directory Server に送信し、更新 操作はごくわずかしか送信しません。

コンシューマーの更新をスケジュールする場合。

ディレクトリーのデータ一貫性のレベルを低くすることができ、ネットワークトラフィックへの影響を軽減したい場合は、更新をスケジュールすることを選択します。

次の場合にスケジュールされた更新を使用します。

  • ネットワーク接続が信頼できないか、定期的にしか利用できない場合。
  • クライアントアプリケーションが主に、追加 操作と 変更 操作を Directory Server に送信する場合。
  • 接続コストを削減する必要がある場合。

マルチサプライヤーレプリケーションにおけるデータの一貫性

マルチサプライヤーレプリケーションがある場合、レプリカが常に同期されている場合でも、サプライヤーの保存データには常に違いがある可能性があるため、各サプライヤーのレプリカの一貫性は低くなります。

一貫性が低くなる主な理由は次のとおりです。

  • サプライヤー間の 変更 操作の伝播に遅延が発生する。
  • 変更 操作を処理したサプライヤーは、2 番目のサプライヤーがそれを検証するまで待たずに、クライアントに "operation successful" というメッセージを返します。

6.2. 一般的なレプリケーションシナリオ
リンクのコピー

次の一般的なシナリオを使用して、ニーズに最適なレプリケーショントポロジーをビルドできます。

6.2.1. 単一サプライヤーレプリケーション
リンクのコピー

単一サプライヤーレプリケーションシナリオでは、サプライヤーサーバーがディレクトリーデータのメインコピー (読み取り/書き込みレプリカ) を維持し、このデータの更新を 1 つ以上のコンシューマーサーバーに送信します。すべてのディレクトリーの変更は、サプライヤーサーバー上の読み取り/書き込みレプリカで行われ、コンシューマーサーバーにはデータの読み取り専用レプリカが含まれます。

サプライヤーサーバーは、サプライヤーレプリカに加えられたすべての変更を記録する changelog を保持します。

次の図は、単一サプライヤーのレプリケーションシナリオを示しています。

図6.1 単一サプライヤーレプリケーション

dg レプリケーションの設計 1
View larger image
dg レプリケーションの設計 1

1 つのサプライヤーサーバーが管理できるコンシューマーサーバーの合計数は、ネットワークの速度と毎日変更されるエントリーの合計数によって異なります。

6.2.2. マルチサプライヤーレプリケーション
リンクのコピー

マルチサプライヤーレプリケーション環境では、同じ情報のメインコピーが複数のサーバーに存在し、ディレクトリーデータを異なるロケーションで同時に更新できます。各サーバーで発生した変更は他のサーバーにレプリケートされるため、各サーバーはサプライヤーとコンシューマーの両方として機能します。

複数のサーバーで同じデータが変更されると、レプリケーションの競合が発生します。競合解決手順を使用して、Directory Server は最新の変更を有効な変更として使用します。

マルチサプライヤーが存在する環境では、各サプライヤーにはコンシューマーと他のサプライヤーを指すレプリカ合意が必要です。たとえば、2 つのサプライヤー (Supplier A と Supplier B) および 2 つのコンシューマー (Consumer C と Consumer D) を使用してレプリケーションを設定します。さらに、1 つのサプライヤーが 1 つのコンシューマーのみを更新することを決定します。Supplier A で、Supplier B および Consumer C を指すレプリカ合意を作成します。Supplier B で、Supplier A および Consumer D を指すレプリカ合意を作成します。次の図はレプリカ合意を示しています。

図6.2 2 つのサプライヤーを持つマルチサプライヤーレプリケーション

dg レプリケーションの設計 2
View larger image
dg レプリケーションの設計 2
注記

Red Hat Directory Server は、任意のレプリケーション環境で最大 20 台のサプライヤーサーバーと、数量無制限のハブサーバーおよびコンシューマーサーバーをサポートします。

多くのサプライヤーを使用する場合は、さまざまなレプリカ合意を作成する必要があります。さらに、各サプライヤーは異なるトポロジーで設定できるため、Directory Server 環境では 20 の異なるディレクトリーツリーがあるだけでなく、さまざまなスキーマもあります。他の多くの変数がトポロジーの選択に直接影響を与える可能性があります。

サプライヤーは、他のすべてのサプライヤーまたは一部のサプライヤーのサブセットに更新を送信できます。更新がすべてのサプライヤーに送信されると、変更がより速く伝播され、全体的なシナリオの障害許容度が向上します。ただし、サプライヤーの設定が複雑になり、ネットワークとサーバーの需要が高まります。サプライヤーのサブセットに更新を送信すると、設定がはるかに簡単になり、ネットワークとサーバーの負荷が軽減されますが、複数のサーバーに障害が発生した場合にデータが失われるリスクが高まります。

完全に接続されたメッシュトポロジー

次の図は、4 つのサプライヤーサーバーが他のすべてのサプライヤーサーバーにデータをレプリケートする、完全に接続されたメッシュトポロジーを示しています。1 つのレプリカ合意は 1 つのサプライヤーと 1 つのコンシューマー間の関係のみを記述するため、4 つのサプライヤーサーバー間に合計で 12 のレプリカ合意が存在します。

dg レプリケーションの設計 3
View larger image
dg レプリケーションの設計 3

サプライヤーが 20 ある場合は、合計 380 件のレプリカ合意 (サプライヤーが 20 で、各 19 件の合意) を作成する必要があります。

2 台以上のサーバーが同時に障害を起こす可能性が低い場合、または特定のサプライヤー間の接続の方が適している場合は、部分的に接続されたトポロジーの使用を検討してください。

部分的に接続されたトポロジー

次の図は、各サプライヤーサーバーが 2 つのサプライヤーサーバーにデータをレプリケートするトポロジーを示しています。前のトポロジーの例と比較すると、4 つのサプライヤーサーバー間に存在するレプリカ合意は 8 つだけです。

dg レプリケーションの設計 4
View larger image
dg レプリケーションの設計 4

6.2.3. カスケードレプリケーション
リンクのコピー

カスケードレプリケーションシナリオでは、ハブサーバーがサプライヤーサーバーから更新を受信し、その更新をコンシューマーサーバーに送信します。ハブサーバーは、一般的なコンシューマーサーバーのように読み取り専用のレプリカを保持し、一般的なサプライヤーサーバーのように changelog も維持するため、ハイブリッドになります。

ハブサーバーはサプライヤーデータをコンシューマーに転送し、ディレクトリークライアントからの更新要求をサプライヤーに参照します。

次の図は、カスケードレプリケーションのシナリオを示しています。

図6.3 カスケードレプリケーションのシナリオ

dg レプリケーションの設計 5
View larger image
dg レプリケーションの設計 5

次の図は、各サーバー上でレプリカがどのように設定されているか (読み取り/書き込みまたは読み取り専用)、およびどのサーバーが changelog を維持しているかを示しています。

図6.4 カスケードレプリケーションにおけるレプリケーショントラフィックと changelog

dg レプリケーションの設計 6
View larger image
dg レプリケーションの設計 6

カスケードレプリケーションは、次の場合に役立ちます。

  • 大量のトラフィック負荷を分散する場合。レプリケーショントポロジー内のサプライヤーはすべての更新トラフィックを管理するため、コンシューマーへのレプリケーショントラフィックもサポートすると、サプライヤーに大きな負荷がかかる可能性があります。多数のコンシューマーにレプリケーション更新を処理できるハブにレプリケーショントラフィックをリダイレクトできます。
  • 地理的に分散した環境でローカルハブサプライヤーを使用することで接続コストを削減する場合。
  • ディレクトリーサービスのパフォーマンスを向上する場合。すべての読み取り操作をコンシューマーに送信し、すべての更新操作をサプライヤーに送信すると、ハブサーバーからすべてのインデックス (システムインデックスを除く) を削除できます。これにより、サプライヤーとハブサーバー間のレプリケーション速度が大幅に向上します。

6.2.4. さまざまなシナリオ
リンクのコピー

ネットワークやディレクトリー環境のニーズに合わせて、いずれのレプリケーションシナリオも組み合わせることができます。一般的な組み合わせの 1 つとして、マルチサプライヤー設定をカスケード設定と使用する組み合わせがあります。

次の図は、混合シナリオのトポロジーの例を示しています。

図6.5 マルチサプライヤーとカスケードレプリケーションの組み合わせ

dg レプリケーションの設計 7
View larger image
dg レプリケーションの設計 7

6.3. レプリケーションストラテジーの定義
リンクのコピー

提供したいサービスに基づいてレプリケーションストラテジーを決定できます。実装できる一般的なレプリケーションストラテジーは次のとおりです。

  • 高可用性が主な懸念である場合は、1 つのサイトに複数の Directory Server を持つデータセンターを作成します。単一サプライヤーレプリケーションは、read-failover を提供しますが、マルチサプライヤーレプリケーションは write-failover を提供します。

    詳細は、高可用性のためのレプリケーションの使用 を参照してください。

  • ローカル可用性が主要な懸念事項である場合は、レプリケーションを使用して、世界中の現地事務所の Directory Server にデータを地理的に分散します。すべての情報のメインコピーを会社の本社などの 1 つのロケーションに保持することも、各ローカルサイトがそれぞれに関連するディレクトリー部分を管理することもできます。

    詳細は、ローカル可用性のためのレプリケーションの使用 を参照してください。

  • Directory Server が管理する要求の負荷を分散し、ネットワークの輻輳を回避するには、負荷分散用のレプリケーション設定を使用します。

    詳細は、負荷分散のためのレプリケーションの使用 を参照してください。

  • 会社のさまざまなロケーションやセクションで複数のコンシューマーを使用する場合、または一部のサーバーが安全でない場合は、部分 レプリケーションを使用して機密情報やほとんど変更されない情報を除外し、機密情報を危険にさらすことなくデータの整合性を維持します。

    詳細は、部分レプリケーション を参照してください。

  • ネットワークが地理的に広い地域に広がっている場合、複数のサイトに複数の Directory Server があり、ローカルデータサプライヤーがマルチサプライヤーレプリケーションによって接続されている場合、ワイドエリアネットワークのレプリケーション設定を使用します。

    詳細は、ワイドエリアネットワーク全体でのレプリケーション を参照してください。

レプリケーションストラテジーを確認するには、ネットワーク、ユーザー、アプリケーション、ディレクトリーサービスの使用方法などの調査から始めます。

6.3.1. レプリケーション調査の実施
リンクのコピー

レプリケーションストラテジーを定義するために、ネットワークの品質と使用状況に関する情報を収集します。

  • さまざまな建物やリモートサイトを接続する LAN と WAN の品質、および使用可能な帯域幅の量。

  • ユーザーの物理的なロケーション、各サイトのユーザー数、およびディレクトリーサービスをどのように使用する予定かを理解するための使用パターン。

    通常、人事データベースや財務情報を管理するサイトでは、電話帳の目的でのみディレクトリーを使用するエンジニアリングスタッフを含むサイトよりも、ディレクトリーにかかる負荷が大きくなります。

  • ディレクトリーサービスにアクセスするアプリケーションの数と、読み取り、検索、および 比較 操作と 書き込み 操作の相対的な割合。

    メッセージングサーバーがディレクトリーを使用する場合は、処理する電子メールメッセージごと実行する操作の数を調べます。ディレクトリーを使用するその他の製品としては、通常、認証アプリケーションやメタディレクトリーアプリケーションなどの製品があります。アプリケーションごとに、ディレクトリーで実行される操作の種類と頻度を決定します。

  • ディレクトリーに保存されたエントリーの数およびサイズ。

6.3.2. レプリケーションリソース要件
リンクのコピー

レプリケーションにはリソースが必要です。レプリケーションストラテジーを定義する際に、以下のリソース要件を検討してください。

ディスク使用量
サプライヤーサーバーでは、Directory Server は更新操作ごとに changelog を書き込みます。したがって、多くの更新操作を受信するサプライヤーサーバーではディスク使用量が高くなります。
サーバースレッド
各レプリカ合意は専用のスレッドを作成し、CPU 負荷はレプリケーションスループットに依存します。
ファイル記述子
サーバーは、changelog に 1 つのファイル記述子を使用し、レプリケーション契約ごとに 1 つのファイル記述子を使用します。

6.3.3. マルチサプライヤーレプリケーションに必要なディスク領域の管理
リンクのコピー

マルチサプライヤートポロジーでは、サプライヤーは、ディレクトリー編集の changelog、更新エントリーの状態情報、削除されたエントリーの tombstone エントリーなど、レプリケーションに必要な追加のログを保持します。これらのログファイルは非常に大きくなる可能性があるため、ディスク領域の不要な使用を避けるために、これらのファイルを定期的にクリーンアップする必要があります。

各サーバーでは、次の属性を使用して、レプリケートされた環境でのレプリケーションログのメンテナンスを設定できます。

  • nsslapd-changelogmaxage 属性は、changelog のエントリーの最大有効期間を設定します。エントリーが最大経過時間値よりも古くなると、Directory Server はそのエントリーを削除します。エントリーの最大有効期間を設定すると、changelog が無制限に大きくなることを阻止できます。
  • nsslapd-changelogmaxentries 属性は、changelog に含めることができるエントリーの最大数を設定します。nsslapd-changelogmaxentries の値は、ディレクトリー情報の完全なセットを格納するのに十分な大きさである必要があることに注意してください。そうしないと、マルチサプライヤーのレプリケーションが機能する際に問題が発生する可能性があります。
  • nsDS5ReplicaPurgeDelay は、changelog の tombstone (削除) エントリーと状態情報の最大有効期間を設定します。tombstone 情報または状態情報のエントリーがその期間を過ぎると、Directory Server はそのエントリーを削除します。nsDS5ReplicaPurgeDelay 値は、tombstone および状態情報エントリーにのみ適用されますが、nsslapd-changelogmaxage は、ディレクトリーの変更を含む、changelog のすべてのエントリーに適用されます。
  • nsDS5ReplicaTombstonePurgeInterval 属性は、changelog から tombstone と状態エントリーを消去するためにサーバーがパージ操作を実行する頻度を設定します。最大経過時間が、最も長いレプリケーション更新スケジュールよりも長いことを確認します。そうしないと、レプリカの更新時にマルチサプライヤーレプリケーションで問題が発生する可能性があります。

6.3.4. 高可用性でのレプリケーションの使用
リンクのコピー

単一のサーバーに障害が発生した場合にディレクトリーが使用できなくなるのを防ぐには、レプリケーションを使用します。少なくとも、ローカルディレクトリーツリーを 1 つ以上のバックアップサーバーにレプリケートします。フォールトトレランス用にどのくらいの頻度でレプリケートするかは、要件によって異なります。ただし、この決定は、ディレクトリーで使用されるハードウェアとネットワークの品質に基づいて行ってください。信頼性の低いハードウェアには、より多くのバックアップサーバーが必要です。

重要

レプリケーションとバックアップの目的が異なるため、通常のデータバックアップポリシーの代わりにレプリケーションを使用しないでください。ディレクトリーデータのバックアップに関する詳細は、Red Hat Directory Server のバックアップと復元 を参照してください。

次のストラテジーを選択すると、ディレクトリーが使用できなくなるのを阻止できます。

LDAP クライアントアプリケーションは通常、1 つの LDAP サーバーのみを検索するように設定されます。異なる DNS ホスト名にある LDAP サーバーをローテーションするカスタムクライアントアプリケーションがない場合は、LDAP クライアントアプリケーションは、Directory Server の単一の DNS ホスト名のみを参照するように設定できます。したがって、バックアップ Directory Server へのフェイルオーバーを提供するには、DNS ラウンドロビンまたはネットワークソートのいずれかを使用することを推奨します。

6.3.5. ローカル可用性でのレプリケーションの使用
リンクのコピー

ネットワークの品質やデータがミッションクリティカルであるかどうかに応じて、ローカル可用性のためにレプリケーションを使用することを推奨します。

以下の理由により、ローカル可用性のレプリケーションを使用します。

  • データのローカルメインコピーが必要です。

    大規模な多国籍企業では、特定の国の従業員にのみ関係するディレクトリー情報を維持する必要がある場合があります。さらに、社内ポリシーにより部門レベルまたは組織レベルでデータを管理するよう指示されている企業にとって、データのローカルメインコピーを保持することは重要です。

  • 信頼できないネットワーク接続、または断続的にしか利用できないネットワーク接続があります。

    国際ネットワークには信頼性の低い WAN があり、ネットワーク接続が断続的になります。

  • 定期的に非常に大きなネットワーク負荷が発生し、Directory Server のパフォーマンスに影響を及ぼします。

    老朽化したネットワークを持つ企業では、通常の営業時間中にネットワーク負荷が大きくなる可能性があります。

  • ネットワーク負荷とサプライヤーの作業負荷を軽減したいと考えています。

    ネットワークの信頼性が高く、利用可能であっても、ネットワークコストを削減することを推奨します。

6.3.6. ロードバランシングでのレプリケーションの使用
リンクのコピー

ディレクトリーデータをレプリケートする主な理由の 1 つは、ネットワークのワークロードのバランスを取り、ディレクトリーのパフォーマンスを向上させることです。

ディレクトリーエントリーのサイズは通常 1 KB なので、ディレクトリー検索ごとにネットワーク負荷が約 1 KB 増加します。ディレクトリーユーザーが 1 日に 10 回のディレクトリー検索を実行する場合、ディレクトリーユーザー 1 人あたりのネットワーク負荷の増加は 1 日あたり約 10 KB になります。WAN の速度が遅い、負荷が高い、または信頼性が低い場合は、ディレクトリーツリーをローカルサーバーにレプリケートすることを推奨します。

ただし、ローカルで利用可能なデータが、レプリケーションによって増加するネットワーク負荷のコストに見合う価値があるかどうかを判断します。ディレクトリーツリー全体をリモートサイトにレプリケートすると、ユーザーの検索によって発生するトラフィックに比べて、ネットワークにかかる負荷が大きくなる可能性があります。これは、ディレクトリーが頻繁に変更されるものの、リモートサイトで 1 日に数回のディレクトリー検索を実行するユーザーが少数である場合に特に当てはまります。

次の表は、100,000 件のエントリーが毎日変更される 100 万件のエントリーを持つディレクトリーをレプリケートした場合の負荷の影響と、1 日に 10 回ずつ検索を実行する 100 人の従業員がいる小規模なリモートサイトがある場合の負荷の影響を比較したものです。

Expand
表6.1 レプリケーションとリモート検索がネットワークに与える影響
負荷タイプアクセス数/日平均エントリーサイズLoad

レプリケーション

100,000

1KB

100Mb/日

リモート検索

1,000

1KB

1Mb/日

ネットワークに過負荷をかけずにローカルサイトでデータを利用できるようにする妥協策は、スケジュールされたレプリケーションを使用することです。データの一貫性とレプリケーションスケジュールの詳細は、データの一貫性 を参照してください。

6.3.6.1. ネットワーク負荷分散の例
リンクのコピー

この例では、ニューヨーク (NY) とロサンゼルス (LA) にオフィスがあり、各オフィスが個別のサブツリーを管理している企業を説明します。

次の図は、企業がサブツリーを管理する方法を示しています。

図6.6 エンタープライズ NY および LA サブツリー

dg レプリケーションの設計 8
View larger image
dg レプリケーションの設計 8

各オフィスには高速ネットワークがありますが、2 つの都市間の接続は不安定です。ネットワーク負荷を分散するには、次のストラテジーを使用します。

  • ローカルで管理されているデータのサプライヤーサーバーとして、各オフィスで 1 台ずつサーバーを選択します。

    ローカルに管理されているデータを、そのサプライヤーからリモートオフィスの対応するサプライヤーサーバーにレプリケートします。各ロケーションにデータのメインコピーがある場合、ユーザーは信頼性の低い接続を介して更新および検索操作を実行しません。その結果、パフォーマンスが最適化されます。

  • 各サプライヤーサーバーのディレクトリーツリー (リモートオフィスから提供されるデータを含む) を少なくとも 1 つのローカルの Directory Server にレプリケートして、ディレクトリーデータの可用性を確保します。

  • ローカルデータの検索専用のコンシューマーの数を増やして、各ロケーションでカスケードレプリケーションを設定し、さらなる負荷分散を実現します。

    NY オフィスでは、LA 固有の検索よりも NY 固有の検索が多く生成されます。この例では、NY オフィスに 3 つの NY データコンシューマーと 1 つの LA コンシューマーが存在します。LA オフィスには、3 つの LA データコンシューマーと 1 つの NY データコンシューマーがあります。

図6.7 企業向け負荷分散の例

dg レプリケーションの設計 9
View larger image
dg レプリケーションの設計 9
6.3.6.2. パフォーマンス向上のための負荷分散の例
リンクのコピー

この例では、次の特性を持つ企業を説明します。

  • ディレクトリーには 1,000,000 人のユーザーをサポートする 1,500,000 件のエントリーが含まれています。
  • 各ユーザーは 1 日に 10 回のディレクトリー検索を実行します。
  • メッセージングサーバーは 1 日あたり 25,000,000 件のメールメッセージを処理し、メールメッセージごとに 5 回のディレクトリー検索を実行します。
  • ユーザーは 4 つのタイムゾーンに分散しています。

これは合計で 1 日あたり 135,000,000 件のディレクトリー検索に相当します。

1,000,000 ユーザー x 10 回の検索 = 1 日あたり 10,000,000 回のユーザー検索

25,000,000 通のメール x 5 回の検索 = 1 日あたり 125,000,000 件のメール検索

1 日あたりの全検索数 10,000,000 + 125,000,000 = 135,000,000

1 日の営業時間が 8 時間で、ユーザーが 4 つのタイムゾーンに分散している場合、4 つのタイムゾーンでのピーク使用時間は 12 時間に達します。したがって、Directory Server は 1 日 12 時間で 135,000,000 件のディレクトリー検索をサポートする必要があります。これは、1 秒あたり 3,125 回の検索 (135,000,000/(60*60*12)) に相当します。

Directory Server を実行するハードウェアが 1 秒あたり 500 回の読み取りをサポートする場合、この負荷をサポートするには少なくとも 6 台または 7 台の Directory Server を使用する必要があります。ディレクトリーユーザーが 100 万人いる企業の場合は、ローカルでの可用性を確保するために Directory Server を追加します。

このようなシナリオでは、次のレプリケーションストラテジーを使用できます。

  • すべての書き込みトラフィックを処理するために、1 つの都市のマルチサプライヤー設定に 2 つの Directory Server を配置します。

    この設定では、すべてのディレクトリーデータを単一の制御ポイントで管理することを前提としています。

  • サプライヤーサーバーを使用して、1 つ以上のハブにレプリケートします。

    読み取り、検索、比較 の要求をコンシューマーに向けることで、サプライヤーは 書き込み 要求のみを処理できるようになります。ハブの詳細は、カスケードレプリケーション を参照してください。

  • ハブを使用して、企業全体のローカルサイトにレプリケートします。

    ローカルサイトにレプリケートすると、サーバーとネットワークの負荷が分散され、ディレクトリーデータの高可用性が確保されます。

  • 各サイトで、少なくとも 読み取り 操作用に、最低 1 回レプリケートして高可用性を確保します。

    DNS ソートを使用すると、ローカルユーザーがディレクトリー検索に使用できるローカル Directory Server を常に見つけられるようになります。

6.3.6.3. 小規模サイトのレプリケーションストラテジーの例
リンクのコピー

例に挙げる企業には以下の特性があります。

  • 企業全体が 1 つのビルに入っています。
  • ビルには、非常に高速 (毎秒 100 Mb) で、使用量の少ないネットワークがあります。
  • ネットワークは非常に安定しており、サーバーハードウェアと OS プラットフォームは信頼できます。
  • 単一のサーバーで負荷を簡単に処理できます。

このような状況では、メンテナンスやハードウェアのアップグレードのためにプライマリーサーバーをシャットダウンするときに可用性を確保するために、少なくとも 1 回はレプリケートする必要があります。また、Directory Server の 1 つが使用できなくなった場合に LDAP 接続のパフォーマンスを向上させるために、DNS ラウンドロビンをセットアップします。

6.3.6.4. 大規模サイトのレプリケーションストラテジーの例
リンクのコピー

小規模サイトのレプリケーションストラテジーの例 の例にある企業は、より大きな企業に成長し、現在では次の特性を備えています。

  • この会社は、Building A と Building B という 2 つの別々の建物に入っています。
  • 通常の営業時間中は、建物間の接続が遅く、非常に混雑します。
  • 各建物には非常に高速 (100 Mb/秒) で使用頻度の低いネットワークがあります。
  • 各建物内のネットワークは非常に安定しており、サーバーのハードウェアと OS プラットフォームは信頼性があります。
  • 1 台のサーバーで 1 つの建物内の負荷を簡単に処理できます。

このような条件では、レプリケーションストラテジーには次の手順が含まれます。

  • ディレクトリーデータのメインコピーを格納するために、2 つの建物のうちの 1 つにある単一のサーバーを選択します。

    ディレクトリーデータのメインコピーを管理する担当者が最も多くいる建物 (たとえば、Building A) にサーバーを配置します。

  • ディレクトリーデータの高可用性のために、Building A 内で最低 1 回レプリケートします。

    マルチサプライヤーレプリケーション 設定を使用して、書き込みフェイルオーバーを確実に実行します。

  • 2 つ目の Building B に 2 つのレプリカを作成します。
  • サプライヤーサーバーとコンシューマーサーバーの間で厳密な一貫性が必要ない場合は、レプリケーションがオフピーク時間帯にのみ実行されるようにスケジュールします。

6.3.7. 部分レプリケーション
リンクのコピー

部分レプリケーションを使用すると、Directory Server がサプライヤーからコンシューマーまたは別のサプライヤーにレプリケートしない属性のセットを選択できます。したがって、データベースに含まれるすべての情報をレプリケートしなくても、データベースをレプリケートできます。

部分レプリケーションは、レプリカ合意ごとに有効になり、設定されます。Directory Server は、属性の除外をすべてのエントリーに均等に適用します。除外された属性は、コンシューマーに対して常に値を持ちません。したがって、検索フィルターでこれらの属性が明示的に指定されている場合でも、コンシューマーサーバーに対して検索を実行するクライアントには除外された属性は表示されません。

次の状況では部分レプリケーションを使用します。

  • コンシューマーサーバーは低速ネットワークを使用して接続されています。ほとんど変更されない属性や jpegPhoto などの大きな属性を除外すると、ネットワークトラフィックが減少します。
  • コンシューマーサーバーは、パブリックインターネットなどの信頼できないネットワーク上に配置されます。電話番号などの機密属性を除外すると、サーバーのアクセス制御手段が無効化されたり、マシンが攻撃者によって悪用されたりした場合でも、機密属性にアクセスできないようにする追加の保護レベルが提供されます。

詳細は、部分レプリケーション内の属性の管理 を参照してください。

6.3.8. ワイドエリアネットワーク全体でのレプリケーション
リンクのコピー

ワイドエリアネットワーク (WAN) は通常、ローカルエリアネットワークよりも遅延や帯域幅遅延積が大きく、速度が遅くなります。Directory Server は、サプライヤーとコンシューマーがワイドエリアネットワークを使用して接続されている場合に効率的なレプリケーションをサポートします。

以前は、Directory Server が使用していたレプリケーションプロトコルは、サプライヤーが更新操作を 1 つだけ送信し、コンシューマーからの応答を待機していたため、遅延の影響を受けやすかったです。これにより、スループットが低下し、レイテンシーが長くなりました。

現在、サプライヤーは応答を待たずに多くの更新とエントリーをコンシューマーに送信しており、レプリケーションのスループットはローカルエリアネットワークのスループットと類似します。

WAN を使用する場合は、次のパフォーマンスとセキュリティーの問題を考慮してください。

  • インターネットなどのパブリックネットワーク経由で実行されるレプリケーションを保護するには、Transport Layer Security (TLS) プロトコルを使用します。
  • ネットワークには T1 以上のインターネット接続を使用してください。
  • WAN 経由のレプリケーション合意を作成するときは、サーバー間の継続的な同期を避けてください。レプリケーショントラフィックは帯域幅を大量に消費し、ネットワークとインターネット接続全体の速度を低下させる可能性があります。

6.4. 他の Directory Server 機能でのレプリケーションの使用
リンクのコピー

レプリケーションストラテジーをより適切に設計するために、レプリケーションとその他の Directory Server 機能との相互作用を説明します。

6.4.1. レプリケーションおよびアクセス制御
リンクのコピー

ディレクトリーはアクセス制御命令 (ACI) をエントリーの属性として保存し、Directory Server はこれらの ACI を他のディレクトリーコンテンツとともにレプリケートします。たとえば、特定のホストからのディレクトリーへのアクセスを制限するには、ACI でホスト固有の設定のみを使用します。そうしないと、ACI が他のサーバーにレプリケートされると、Directory Server が ACI をローカルで評価するため、すべてのサーバーでディレクトリーへのアクセスが拒否されます。

ディレクトリーのアクセス制御の設計に関する詳細は、アクセス制御の設計 を参照してください。

6.4.2. レプリケーションおよび Directory Server プラグイン
リンクのコピー

レプリケーションは、Directory Server に同梱されるほとんどのプラグインと連携します。ただし、次のプラグインには、複数のサプライヤー環境での制限と例外があります。

  • Attribute Uniqueness プラグイン

    Attribute Uniqueness プラグインは、ローカルサーバー上のみのエントリーに追加された属性値の一意性を検証します。たとえば、ある会社では、ユーザーエントリーの mail 属性が一意である必要があります。2 つの異なるサプライヤーサーバーで、mail 属性に同じ値を持つ 2 人の異なるユーザーが同時に追加されると、名前の競合が発生せず、結果としてレプリケーションの競合も発生しないため、Directory Server はこれらのユーザーをディレクトリーに追加します。Attribute Uniqueness プラグインは、レプリケートされた変更をチェックしないため、結果として、mail 属性値はディレクトリー内で一意ではなくなります。

  • Referential Integrity プラグイン

    リファラル整合性は、マルチサプライヤーセット内の 1 つ のサプライヤーでのみ有効になっている場合に、マルチサプライヤーレプリケーションで機能します。これにより、リファラル整合性の更新がサプライヤーサーバーの 1 つでのみ行われ、他のサーバーに伝播されます。

  • 自動メンバーシップと MemberOf プラグイン

    これら 2 つのプラグインがレプリケーション環境で正しく機能するには、各サーバー上でローカルに更新を実行するようにプラグインを設定します。

注記

デフォルトではプラグインは無効になっているため、手動で有効にする必要があります。

6.4.4. スキーマレプリケーション
リンクのコピー

レプリケートされた環境では、レプリケーションに参加するすべてのサーバー間でスキーマが一貫している必要があります。スキーマの一貫性を確保するには、単一のサプライヤーサーバーでのみスキーマの変更を行ってください。

サーバー間のレプリケーションを設定した場合、スキーマのレプリケーションはデフォルトで実行されます。

標準スキーマ

Directory Server は、標準スキーマのレプリケーションに次のシナリオを使用します。

  1. データをコンシューマーサーバーにプッシュする前に、サプライヤーサーバーは、そのスキーマのバージョンがコンシューマーサーバーに保持されているスキーマのバージョンと同じかどうかを確認します。
  2. サプライヤーとコンシューマーの両方のスキーマエントリーが同じである場合、レプリケーション操作が続行されます。
  3. サプライヤースキーマのバージョンがコンシューマースキーマのバージョンよりも新しい場合、サプライヤーサーバーはデータレプリケーションを続行する前に、そのスキーマをコンシューマーにレプリケートします。
  4. サプライヤースキーマのバージョンがコンシューマースキーマのバージョンよりも古い場合、コンシューマーのスキーマが新しいデータをサポートできないため、レプリケーションが失敗したり、レプリケーション中にサーバーがエラーを返すことがあります。したがって、コンシューマーサーバー上のスキーマは 更新しないでください。レプリケートされたトポロジー内のサプライヤーサーバー上でのみスキーマを維持する必要があります。

Directory Server は、dsconf コマンド、Web コンソール、LDAP 変更操作を使用して行われたスキーマの変更、または 99user.ldif ファイルに直接行われた変更をレプリケートします。

2 つのサプライヤーサーバーでスキーマを変更すると、コンシューマーは 2 つのサプライヤーからそれぞれ異なるスキーマを持つデータを受信します。コンシューマーは、より新しいスキーマバージョンを持つサプライヤーの変更を適用します。このような状況では、コンシューマーのスキーマは常にサプライヤーの 1 つと異なります。これを回避するには、必ず 1 つのサプライヤーに対してのみスキーマの変更を行うようにしてください。

スキーマをレプリケートするために特別なレプリカ合意を作成する必要はありません。ただし、同じ Directory Server にサプライヤーレプリカとコンシューマーレプリカを保持できます。そのため、スキーマのサプライヤーとして機能するサーバーを常に特定してから、このサプライヤーと、スキーマ情報のコンシューマーとして機能するレプリケーション環境の他のすべてのサーバーとの間にレプリカ合意をセットアップします。

標準スキーマファイルの詳細は、標準スキーマ を参照してください。

カスタムスキーマ

標準の 99user.ldif ファイルをカスタムスキーマとして使用する場合、Directory Server はカスタムスキーマのみをすべてのコンシューマーにレプリケートします。Directory Server は、Web コンソールまたは dsconf コマンドを使用して変更を加えた場合でも、他のカスタムスキーマファイルやこれらのファイルへの変更をレプリケートしません。

他のカスタムファイルを使用する場合は、サプライヤーで変更を加えた後に、これらのファイルをトポロジー内のすべてのサーバーに手動でコピーする必要があります。

第7章 セキュアなディレクトリーの設計
リンクのコピー

Red Hat Directory Server がデータを保護する方法は、これまでのすべての設計領域に影響します。あらゆるセキュリティー設計では、ディレクトリー内のデータを保護し、ユーザーとアプリケーションの両方のセキュリティーとプライバシーのニーズを満たす必要があります。

セキュリティーのニーズを分析し、そのニーズを満たすディレクトリーを設計する方法を説明します。

7.1. セキュリティーの脅威について
リンクのコピー

ディレクトリーは潜在的なセキュリティー上の脅威にさらされている可能性があります。最も一般的な脅威を理解すると、セキュリティー設計全体の概要を把握するのに役立ちます。ディレクトリーのセキュリティーの脅威は、以下の 3 つの主要カテゴリーに分類されます。

  • 不正アクセス
  • 不正な改ざん
  • サービス拒否

7.1.1. 不正アクセス
リンクのコピー

不正アクセスからディレクトリーを保護することは簡単に見えるかもしれませんが、安全なソリューションの実装は、最初の印象よりも複雑になる可能性があります。ディレクトリー情報配信パスには、権限のないクライアントがデータにアクセスできる可能性のあるアクセスポイントが多数あります。

以下のシナリオは、承認されていないクライアントがディレクトリーデータにアクセスする可能性のある方法の例をいくつか説明しています。

  • 権限のないクライアントは別のクライアントの認証情報を使用してデータにアクセスできます。これは、ディレクトリーが保護されていないパスワードを使用している場合に特に発生する可能性があります。未承認のクライアントは、承認されたクライアントと Directory Server の間で交換される情報を盗聴する可能性もあります。
  • 不正アクセスは会社内部から行われる可能性があります。また、エクストラネットやインターネットに接続している場合は会社外部から行われる可能性があります。

Directory Server が提供する認証方法、パスワードポリシー、およびアクセス制御メカニズムは、不正アクセスを阻止する効率的な方法を提供します。

7.1.2. 不正な改ざん
リンクのコピー

侵入者がディレクトリーにアクセスしたり、Directory Server とクライアントアプリケーション間の通信を傍受したりすると、ディレクトリーデータを変更または改ざんする可能性があります。クライアントがデータを信頼していない場合、またはディレクトリー自体がクライアントから受信した変更やクエリーを信頼できない場合、ディレクトリーサービスは役に立ちません。

たとえば、ディレクトリーが改ざんを検出できない場合、攻撃者はサーバーへのクライアント要求を変更したり、転送しなかったり、クライアントへのサーバー応答を変更したりする可能性があります。TLS および同様のテクノロジーは、接続の両側で情報に署名することで、この問題を解決できます。

7.1.3. サービス拒否
リンクのコピー

サービス拒否攻撃では、攻撃者の目的はディレクトリーがクライアントにサービスを提供できないようにすることです。たとえば、攻撃者がすべてのシステムリソースを使用し、他のユーザーがこれらのリソースを使用できないようにする可能性があります。Directory Server では、特定のバインド DN に割り当てられるリソースの制限を設定すると、サービス拒否攻撃を防ぐことができます。ユーザーのバインド DN に基づいてリソース制限を設定する方法の詳細は、ユーザー管理および認証 ガイドを参照してください。

7.2. セキュリティーニーズの分析
リンクのコピー

環境およびユーザーを分析し、セキュリティーニーズを特定します。安全なディレクトリーの設計 の章のサイト調査では、ディレクトリー内の個々のデータを誰が読み書きできるかに関する基本的な決定事項が明確にされています。この情報は、セキュリティー設計の基盤となります。

ディレクトリーサービスがビジネスをサポートするためにどのように使用されるかによって、セキュリティーの実装方法が決まります。イントラネットを提供するディレクトリーは、インターネットに公開されているエクストラネットまたは e コマースアプリケーションをサポートするディレクトリーと同じセキュリティー対策を必要としません。

ディレクトリーがイントラネットのみを提供する場合は、情報に必要なアクセスレベルを検討してください。

  • ユーザーおよびアプリケーションに、ジョブの実行に必要な情報へのアクセスを提供する方法。
  • 社員またはビジネスに関する機密データを一般アクセスから保護する方法。

ディレクトリーがエクストラネットを提供している場合、またはインターネット経由の電子商取引アプリケーションをサポートしている場合は、次の点も考慮してください。

  • 顧客にプライバシーの保証を提供する方法。
  • 情報の整合性を保証する方法。

7.2.1. アクセス権限の決定
リンクのコピー

データ分析により、ユーザー、グループ、パートナー、顧客、およびアプリケーションがディレクトリーサービスにアクセスするのに必要な情報が特定されます。アクセス権は、以下の 2 つの方法のいずれかで付与できます。

  • 機密データを保護しながら、すべてのカテゴリーのユーザーにできるだけ多くの権限を付与します。

    オープンな方法では、どのデータがビジネスにとって機密性が高いか、または重要であるかを正確に判断する必要があります。

  • 各カテゴリーのユーザーに、業務の遂行に必要な最小限のアクセス権を付与します。

    制限的な方法では、組織の内部、場合によっては外部のユーザーの各カテゴリーの情報ニーズを詳細に理解する必要があります。

アクセス権を決定するために使用される方法に関係なく、組織内のユーザーのカテゴリーとそれぞれに付与されたアクセス権をリスト表示する簡単な表を作成します。ディレクトリーに保持される機密データと、データごとにそれを保護するために実行する手順が記載された表の作成を検討してください。

7.2.2. データのプライバシーと整合性の確保
リンクのコピー

ディレクトリーを使用して、エクストラネットを介したビジネスパートナーとの交流をサポートしたり、インターネット上のお客様との e コマースアプリケーションをサポートしたりする場合は、交換されるデータのプライバシーと整合性を確保してください。

データのプライバシーと整合性を確保するには、次の方法を使用します。

  • データ転送を暗号化します。
  • 証明書を使用してデータ転送に署名します。

7.2.3. 定期的な監査の実施
リンクのコピー

追加のセキュリティー対策として、定期的な監査を実施して、SNMP エージェントによって記録されたログファイルと情報を調べ、セキュリティーポリシー全体の効率性を検証します。

7.2.4. セキュリティーニーズ分析の例
リンクのコピー

これらの例は、架空の ISP 会社 example.com がセキュリティーニーズを分析する方法を示しています。example.com は、Web ホスティングとインターネットアクセスを提供します。example.com の活動の一部は、クライアント会社のディレクトリーをホストすることです。また、多くの個人加入者へのインターネットアクセスも提供します。そのため、example.com のディレクトリーには、3 つの主要な情報カテゴリーがあります。

  • example.com の内部情報
  • 法人のお客様の情報
  • 個人加入者に関する情報

example.com には次のアクセス制御が必要です。

  • example_a や example_b などのホストされている会社のディレクトリー管理者に、各自のディレクトリー情報へのアクセスを提供します。
  • ホストされている会社のディレクトリー情報にアクセス制御ポリシーを実装します。
  • 自宅からのインターネットアクセスに example.com を使用するすべての個々のクライアント標準のアクセス制御ポリシーを実装します。
  • すべての部外者に対して example.com の企業ディレクトリーへのアクセスを拒否します。
  • 世界中のサブスクライバーの example.com ディレクトリーへの読み取りアクセス権を付与します。

7.3. セキュリティーメソッドの概要
リンクのコピー

Directory Server には、特定のニーズに適合する全体的なセキュリティーポリシーを設計する方法が複数あります。セキュリティーポリシーは、権限のないユーザーが機密情報を変更または取得できないようにするのに十分な強度が必要ですが、簡単に管理できるようにシンプルである必要もあります。複雑なセキュリティーポリシーは、アクセスが必要な情報へのアクセスを妨げるミスや、ひどい場合はアクセスを許可してはならないディレクトリー情報の変更や取得を許可するミスにつながる可能性があります。

Expand
表7.1 Directory Server で利用可能なセキュリティー方法
セキュリティーメソッド説明

認証

相手のアイデンティティーを確認します。たとえば、クライアントは LDAP バインド操作時に Directory Server にパスワードを提供します。

パスワードポリシー

このパスワードが有効であると判断するためにパスワードが満たす必要のある基準を定義します。たとえば、年齢、長さ、構文などです。

暗号化

情報のプライバシーを保護します。データが暗号化されると、受信者だけがデータを理解できます。

アクセス制御

さまざまなディレクトリーユーザーに付与されるアクセス権をカスタマイズし、必要な認証情報やバインド属性を指定する方法を提供します。

アカウントの非アクティブ化

ユーザーアカウント、アカウントグループ、またはドメイン全体を無効にして、Directory Server がすべての認証試行を自動的に拒否するようにします。

セキュアな接続

TLS、StartTLS、または SASL での接続を暗号化することで、情報の整合性を維持します。送信中に情報が暗号化されていれば、受信者は送信中に情報が変更されていないと判断できます。最小限のセキュリティー強度係数を設定することにより、セキュアな接続が必要になる場合があります。

監査

ディレクトリーのセキュリティーが侵害されているか判断します。簡単な監査方法の 1 つは、ディレクトリーが保持するログファイルを確認することです。

SELinux

Red Hat Directory Server マシン上のセキュリティーポリシーを使用して、Directory Server のファイルとプロセスへのアクセスを制限および制御します。

セキュリティー設計においてセキュリティーを維持するこれらのツールをいくつか組み合わせ、レプリケーションやデータディストリビューションなどのディレクトリーサービスのその他の機能を組み込んで、セキュリティー設計をサポートします。

7.4. 適切な認証方法の選択
リンクのコピー

セキュリティーポリシーに関する基本的な決定は、ユーザーがディレクトリーにアクセスする方法です。匿名ユーザーはディレクトリーにアクセスできますか? それとも、すべてのユーザーがユーザー名とパスワードを使用してディレクトリーにログイン (認証) する必要がありますか?

Directory Server が提供する認証方法を説明します。このディレクトリーは、ユーザーまたは LDAP 対応のアプリケーションに関係なく、すべてのユーザーに同じ認証メカニズムを使用します。

7.4.1. 匿名および認証されていないアクセス
リンクのコピー

匿名でのアクセスは、ディレクトリーへの最も簡単なアクセス方法です。匿名アクセスでは、ディレクトリーに接続するユーザーは誰でもデータにアクセスできます。

匿名アクセスを設定すると、誰がどのような検索を実行したかを追跡することはできず、誰かが検索を実行したことのみを追跡できます。特定のユーザーまたはユーザーグループが一部のディレクトリーデータにアクセスできないようにブロックすることもできますが、そのデータへの匿名アクセスが許可されている場合は、それらのユーザーはディレクトリーに匿名でバインドするだけでデータにアクセスできます。

匿名アクセスを制限することができます。通常、ディレクトリー管理者は、読み取り、検索、比較の権限に対してのみ匿名アクセスを許可し、書き込み、追加、削除、または自己書き込みの権限に対しては許可しません。管理者は多くの場合、名前、電話番号、メールアドレスなどの一般的な情報を含む属性のサブセットへのアクセスを制限します。政府が管理する ID 番号 (米国の社会保障番号など)、自宅の電話番号と住所、給与情報など、より機密性の高いデータへの匿名アクセスは絶対に許可しないでください。

ディレクトリーデータにアクセスするユーザーに関するルールを厳しくする必要がある場合は、匿名アクセスを完全に無効にすることができます。

認証されていないバインド は、ユーザーがユーザー名でバインドしようとするが、ユーザーのパスワード属性を持たない場合です。以下に例を示します。 

ldapsearch -x -D "cn=jsmith,ou=people,dc=example,dc=com" -b "dc=example,dc=com" "(cn=joe)"
Copy to Clipboard Toggle word wrap

Directory Server は、ユーザーがパスワードを入力しようとしない場合、匿名アクセスを付与します。認証されていないバインドでは、バインド DN が既存のエントリーである必要はありません。

匿名バインドと同様に、認証されていないバインドを無効にして、データベースへのアクセスを制限することでセキュリティーを強化できます。さらに、認証されていないバインドを無効にして、クライアントのサイレントバインド障害を防ぐこともできます。一部のアプリケーションでは、実際にはパスワードを渡すことに失敗し、認証されていないバインドで接続しただけなのに、バインド成功メッセージを受信したため、ディレクトリーへの認証が成功したと認識する場合があります。

7.4.2. シンプルバインドとセキュアなバインド
リンクのコピー

匿名アクセスが許可されない場合、ユーザーはディレクトリーの内容にアクセスする前にディレクトリーに対して認証する必要があります。シンプルパスワード認証では、クライアントは再利用可能なパスワードを送信してサーバーに対して認証します。

たとえば、クライアントは、識別名と認証情報のセットを提供するバインド操作を使用して、ディレクトリーに対して認証を行います。サーバーは、クライアント DN に対応するディレクトリーのエントリーを特定し、クライアントによって指定されるパスワードがエントリーに保存されている値と一致するかどうかを確認します。一致する場合、サーバーはクライアントを認証します。そうでない場合は、認証操作は失敗し、クライアントはエラーメッセージを受信します。

バインド DN は多くの場合、person エントリーに対応しています。ただし、一部のディレクトリー管理者は、person ではなく組織エントリーとしてバインドすることを好みます。ディレクトリーでは、バインドに使用されるエントリーに、userPassword 属性を許可するオブジェクトクラスが必要です。これにより、ディレクトリーはバインド DN およびパスワードを確実に認識します。

ほとんどの LDAP クライアントはバインド DN をユーザーに対して非表示にします。これは、長い文字列の DN を覚えるのは難しい可能性があるからです。クライアントがユーザーに対してバインド DN を非表示にする場合、以下のようなバインドアルゴリズムを使用します。

  1. ユーザーは、ユーザー ID などの一意の識別子を入力します。たとえば、fchen などです。
  2. LDAP クライアントアプリケーションは、ディレクトリー内でその識別子を検索し、関連付けられた識別名を返します。たとえば、uid=fchen,ou=people,dc=example,dc=com などです。
  3. LDAP クライアントアプリケーションは、取得した識別名と、ユーザーが指定したパスワードを使用して、ディレクトリーにバインドします。

シンプルなパスワード認証は、ユーザーを認証する簡単な方法を提供しますが、追加のセキュリティー方法が必要になります。使用する場合は、組織のイントラネットに限定することを検討してください。エクストラネットを介したビジネスパートナー間の接続、またはインターネット上の顧客との送信に使用するには、安全な (暗号化された) 接続を要求するのが最良である場合があります。

注記

シンプルパスワード認証の欠点は、パスワードがプレーンテキストで送信されることです。不正ユーザーがリッスンしている場合、そのユーザーが許可されたユーザーになりすます可能性があるため、ディレクトリーのセキュリティーが悪用される可能性があります。nsslapd-require-secure-binds 設定属性では、TLS または Start TLS を使用して、セキュアな接続を介して単純なパスワード認証を実行する必要があります。これにより、プレーンテキストのパスワードが効果的に暗号化され、悪意のある人物が盗聴できなくなります。

nsslapd-require-secure-binds 設定属性を使用して、TLS または Start TLS を使用してセキュアな接続をオンにします。SASL 認証または証明書ベースの認証も可能です。Directory Server とクライアントアプリケーションが相互に安全な接続を確立すると、クライアントはパスワードをプレーンテキストで送信しないことで、追加の保護レベルを備えた単純なバインドを実行します。

7.4.3. 証明書ベースの認証
リンクのコピー

ディレクトリー認証の代替形式は、デジタル証明書を使用してディレクトリーにバインドします。ディレクトリーは、ユーザーの初回アクセス時にパスワードを要求します。ただし、パスワードは、ディレクトリーに保存されているパスワードと一致するのではなく、ユーザー証明書データベースを開きます。

ユーザーが正しいパスワードを入力すると、ディレクトリークライアントアプリケーションは証明書データベースから認証情報を取得します。続いて、クライアントアプリケーションとディレクトリーは、この情報を使用して、ユーザー証明書をディレクトリー DN にマッピングすることでユーザーを識別します。ディレクトリーはこの認証プロセス中に特定されたディレクトリー DN に基づいて、アクセスを許可または拒否します。

7.4.4. プロキシー認証
リンクのコピー

ディレクトリーへのアクセスを要求するユーザーは、自身の DN ではなく プロキシー DN にバインドするため、プロキシー認証は特殊な形式の認証です。

プロキシー DN は、ユーザーが要求する操作を実行するための適切なパーミッションを持つエンティティーです。ユーザーまたはアプリケーションがプロキシーパーミッションを受け取ると、Directory Manager DN を除く任意の DN をプロキシー DN として指定できます。

プロキシーパーミッションの主な利点の 1 つは、LDAP アプリケーションが単一のバインドで単一のスレッドを使用して、Directory Server に対して要求を行う複数のユーザーにサービスを提供できることです。クライアントアプリケーションは、ユーザーごとにバインドおよび認証する代わりに、プロキシー DN を使用して Directory Server にバインドします。

プロキシー DN は、クライアントアプリケーションによって送信される LDAP 操作で指定されます。以下に例を示します。 

ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -X "dn:cn=joe,dc=example,dc=com" -f mods.ldif
Copy to Clipboard Toggle word wrap

このコマンドにより、マネージャーエントリー cn=Directory Manager は、ユーザー cn=joe から mods.ldif ファイルに変更を適用するパーミッションを受け取ります。この変更を行うために、管理者はユーザーパスワードを提供する必要はありません。

注記

プロキシーメカニズムは非常に強力なので、慎重に使用する必要があります。プロキシーパーミッションはアクセス制御リスト (ACL) の範囲内で付与され、ユーザーにプロキシーパーミッションを付与すると、このユーザーはターゲットの下にある任意のユーザーのプロキシーとして機能します。プロキシーパーミッションを特定のユーザーのみに制限することはできません。

たとえば、エントリーに dc=example,dc=com ツリーへのプロキシーパーミッションがある場合、このエントリーは何でも実行できます。したがって、プロキシーアクセス制御命令 (ACI) をディレクトリーの可能な限り低いレベルに設定するようにしてください。

7.4.5. パススルー認証 (PTA)
リンクのコピー

パススルー認証 (PTA) とは、Directory Server が認証要求を 1 つのサーバーから別のサーバーに転送することです。

たとえば、Directory Server がインスタンスのすべての設定情報を別のディレクトリーインスタンスに保存する場合、Directory Server は User Directory Server が Configuration Directory Server に接続するためにパススルー認証を使用します。PTA プラグインは、Directory Server 間のパススルー認証を処理します。

簡単なパススルー認証プロセス
View larger image
簡単なパススルー認証プロセス

多くのシステムには、Pluggable Authentication Modules (PAM) などの Unix および Linux ユーザー向けの認証メカニズムがすでに備わっています。PAM モジュールを設定して、Directory Server に LDAP クライアントの既存の認証ストアを使用するように指示できます。Directory Server は PAM サービスと対話し、PAM パススルー認証プラグインを使用して LDAP クライアントを認証します。

dg auth 経由の pam パス
View larger image
dg auth 経由の pam パス

PAM パススルー認証では、ユーザーが Directory Server にバインドしようとすると、Directory Server は認証情報を PAM サービスに転送します。認証情報が PAM サービスの情報と一致する場合、ユーザーは Directory Server アクセス制御の制限とアカウント設定がすべてある状態で、Directory Server に正常にバインドできます。

注記

PAM を使用するように Directory Server を設定することはできますが、認証に Directory Server を使用するように PAM を設定することはできません。

System Security Services Daemon (SSSD) を使用して PAM サービスを設定できます。PAM パススルー認証プラグインを、デフォルトで /etc/pam.d/system-auth などの SSSD が使用する PAM ファイルにポイントします。SSSD は、Active Directory、Red Hat Directory Server、OpenLDAP などのその他のディレクトリー、またはローカルシステム設定などのさまざまなアイデンティティープロバイダーを使用できます。

7.4.6. パスワードレス認証
リンクのコピー

認証の試行では、まずユーザーアカウントが認証できるかどうかが評価されます。アカウントは以下の基準を満たす必要があります。

  • アクティブである必要がある。
  • ロックされていない。
  • 適用されるパスワードポリシーに従って有効なパスワードを設定している。

場合によっては、ユーザーが実際に Directory Server にバインドすべきではない、またはバインドできない場合に、クライアントアプリケーションでユーザーアカウントの認証を実行する必要があります。たとえば、システムでシステムアカウントを管理するために PAM が使用されていて、LDAP ディレクトリーをアイデンティティーストアとして使用するように PAM を設定したとします。ただし、システムは SSH キーや RSA トークンなどのパスワードなしの認証情報を使用しており、これらの認証情報を渡して Directory Server に認証することはできません。

Red Hat Directory Server は、LDAP 検索用の Account Usability Extension Control エクステンションをサポートしています。このエクステンションは、返されたエントリーごとに、アカウントのステータスとそのアカウントのパスワードポリシーに関する情報を示す追加行を返します。次に、クライアントまたはアプリケーションはそのステータスを使用して、そのユーザーアカウントの Directory Server 外で行われた認証の試行を評価できます。基本的に、この制御では、認証操作なしにユーザーが認証を許可するかどうかを制御します。

さらに、このエクステンションを PAM などのシステムレベルのサービスと併用して、引き続き Directory Server を使用してアイデンティティーを保存し、アカウントステータスを制御するパスワードなしのログインを許可することもできます。

注記

デフォルトでは、Directory Manager のみが Account Usability Extension Control を使用できます。他のユーザーが制御を使用できるようにするには、サポートされるコントロールエントリーに適切な ACI を設定します (oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config)。

7.5. アカウントロックアウトポリシーの設計
リンクのコピー

アカウントロックアウトポリシーは、ディレクトリーへの不正なアクセスや危険なアクセスを防ぐことで、ディレクトリーデータとユーザーパスワードの両方を保護することができます。Directory Server がアカウントをロックまたは 非アクティブ化 すると、そのユーザーはディレクトリーにバインドできなくなり、認証操作は失敗します。

アカウントの非アクティブ化を実装するには、nsAccountLock 操作属性を使用します。エントリーに true の値を持つ nsAccountLock 属性が含まれている場合、サーバーはそのアカウントによるバインド試行を拒否します。

Directory Server は、特定の自動基準に基づいてアカウントロックアウトポリシーを定義できます。

  • Directory Server は、アカウントロックアウトポリシーをパスワードポリシーに関連付けることができます。ユーザーが適切な認証情報を使用して指定された回数までのログインに失敗すると、管理者が手動でロックを解除するまで、Directory Server はアカウントをロックします。

    このようなポリシーは、ユーザーパスワードを繰り返し推測してディレクトリーに侵入しようとする悪意のあるアクターから保護します。

  • Directory Server は、一定の時間が経過するとアカウントをロックできます。このポリシーを使用すると、アカウントが作成された時間に基づいて時間制限付きのアクセス権を持つ、インターン、学生、季節労働者などの一時ユーザーのアクセスを制御できます。あるいは、前回のログイン時から一定時間アカウントが非アクティブ化されている場合に、ユーザーアカウントを非アクティブ化するアカウントポリシーを作成することもできます。

    アカウントポリシープラグインを使用して、時間ベースのアカウントロックアウトポリシーを実装し、ディレクトリーのグローバル設定を行います。有効期限とタイプが異なる複数のアカウントポリシーサブエントリーを作成し、サービスクラスを通じてこれらのポリシーをエントリーに適用できます。

7.6. パスワードポリシーの設計
リンクのコピー

パスワードポリシーとは、特定のシステムでパスワードがどのように使用されるかを管理する一連のルールのことです。Directory Server のパスワードポリシーは、期間、長さ、ユーザーがパスワードを再利用できるかどうかなど、パスワードが有効であると見なされるために満たす必要のある基準を指定します。

7.6.1. パスワードポリシーの仕組み
リンクのコピー

Directory Server はきめ細かなパスワードポリシーをサポートしています。つまり、Directory Server はディレクトリーツリーの任意のポイントでパスワードポリシーを定義します。Directory Server は、次のレベルでパスワードポリシーを定義します。

ディレクトリー全体

このようなポリシーは グローバル パスワードポリシーと呼ばれます。このポリシーを設定して有効にすると、Directory Server は、Directory Manager エントリーとローカルパスワードポリシーが有効になっているユーザーエントリーを除く、ディレクトリー内のすべてのユーザーにこのポリシーを適用します。

このポリシータイプでは、すべてのディレクトリーユーザーに対して共通の単一のパスワードポリシーを定義できます。

ディレクトリーの特定のサブツリー

このようなポリシーは サブツリーレベル または ローカル パスワードポリシーと呼ばれます。このポリシーを設定して有効にすると、Directory Server は指定されたサブツリーの下にあるすべてのユーザーにこのポリシーを適用します。

このポリシータイプは、すべてのホスト会社に単一のポリシーを適用するのではなく、ホスト会社ごとに異なるパスワードポリシーをサポートするホスティング環境に適しています。

ディレクトリーの特定ユーザー

このようなポリシーは ユーザーレベル または ローカル パスワードポリシーと呼ばれます。このポリシーを設定して有効にすると、Directory Server は指定されたユーザーにのみこのポリシーを適用します。

このポリシータイプでは、ディレクトリーユーザーごとに異なるパスワードポリシーを定義できます。たとえば、一部のユーザーがパスワードを毎日変更し、一部のユーザーが毎月パスワードを変更し、他のすべてのユーザーが 6 か月ごとにパスワードを変更するように指定します。

デフォルトでは、Directory Server にはグローバルパスワードポリシーに関連するエントリーおよび属性が含まれます。つまり、同じポリシーがすべてのユーザーに適用されます。サブツリーまたはユーザーのパスワードポリシーを設定するには、サブツリーまたはユーザーレベルで追加のエントリーを追加し、cn=config エントリーの nsslapd-pwpolicy-local 属性を有効にします。この属性はスイッチとして機能し、粒度の細かいパスワードポリシーをオンおよびオフに切り替えます。

コマンドラインまたは Web コンソールを使用して、パスワードポリシーを変更できます。コマンドラインでは、dsconf pwpolicy コマンドはグローバルポリシーを変更し、dsconf localpwp コマンドはローカルポリシーを変更します。パスワードポリシーを設定する手順は、パスワードポリシーの設定 セクションを参照してください。

パスワードポリシーの確認プロセス

ディレクトリーに追加するパスワードポリシーエントリーによって、Directory Server が適用するパスワードポリシーのタイプ (グローバルまたはローカル) が決まります。

ユーザーがディレクトリーにバインドしようとすると、Directory Server は、ローカルポリシーが定義され、ユーザーのエントリーに対して有効になっているか判断します。Directory Server は、次の順序でポリシー設定をチェックします。

  1. Directory Server は、きめ細かいパスワードポリシーが有効になっているか判断します。サーバーは、cn=config エントリーの nsslapd-pwpolicy-local 属性の値 (on または off) をチェックします。値が off に設定されている場合、サーバーはサブツリーおよびユーザーレベルで定義されたポリシーを無視し、グローバルパスワードポリシーを適用します。

  2. Directory Server は、サブツリーまたはユーザーに対してローカルポリシーが定義されているか判断します。サーバーは、対応するユーザーエントリー内の pwdPolicysubentry 属性をチェックします。

    1. 属性が存在する場合は、サーバーは、ユーザーに設定されたローカルパスワードポリシーを適用します。エントリーに属性があっても、値が空または無効 (たとえば、存在しないエントリーを指している) の場合、サーバーはエラーメッセージをログに記録します。
    2. pwdPolicysubentry 属性がユーザーエントリーに見つからない場合、サーバーは最上位に到達するまで親エントリー、祖父母エントリー、およびその他の上位レベルのエントリーをチェックします。
    3. pwdPolicysubentry 属性が上位レベルのエントリーに見つからない場合、サーバーはグローバルポリシーを適用します。
  3. サーバーはユーザーが指定したパスワードを、ユーザーのディレクトリーエントリーで指定された値と比較して、それらが一致することを確認します。サーバーは、パスワードポリシーが定義するルールも使用して、ユーザーがディレクトリーにバインドできるようになる前にパスワードが有効であることを確認します。

バインド要求に加えて、要求に userPassword 属性が存在する場合、追加および変更操作中にパスワードポリシーのチェックも行われます。

userPassword の値を変更すると、次の 2 つのパスワードポリシー設定がチェックされます。

  • パスワードの最低期間ポリシーがアクティブになります。最小年齢要件が満たされていない場合、サーバーは constraintViolation エラーを返します。パスワード更新操作は失敗します。
  • パスワード履歴ポリシーがアクティブになります。userPassword 属性の新しい値がパスワード履歴に存在する場合、または現在のパスワードと同じ場合、サーバーは constraintViolation エラーを返します。パスワード更新操作は失敗します。

userPassword の値を追加および変更すると、パスワード構文に設定されているパスワードポリシーがチェックされます。

  • パスワードの最小長ポリシーがアクティブになります。userPassword 属性の新しい値が必要な最小長より短い場合、サーバーは constraintViolation エラーを返します。パスワード更新操作は失敗します。
  • パスワード構文の確認ポリシーがアクティブになります。userPassword の新しい値がエントリーの別の属性と同じ場合、サーバーは constraintViolation エラーを返します。パスワード更新操作は失敗します。

7.6.2. パスワードポリシーの属性
リンクのコピー

サーバーのパスワードポリシーを作成するために使用できる属性を説明します。Directory Server はパスワードポリシー属性を cn=config エントリーに保存しますが、dsconf ユーティリティーを使用してこれらの設定を変更できます。

失敗の最大回数

この設定により、パスワードポリシーでパスワードベースのアカウントロックアウトが有効になります。ユーザーが一定回数ログインを試行して失敗した場合、Directory Server はそのアカウントをロックします。このアカウントは、管理者がロックを解除するか、一定時間が経過するまで (オプション) ロックされます。失敗の最大回数を設定するには、passwordMaxFailure 設定パラメーターを使用します。

Directory Server には、ログイン試行回数をカウントし、ログイン試行回数が制限に達したときにアカウントをロックする方法が 2 つあります。

  • Directory Server は、カウントが (n) に達するとアカウントをロックします。
  • Directory Server は、カウントが (n+1) を超えた場合にのみアカウントをロックします。

たとえば、失敗回数が 3 回に制限されている場合、アカウントは 3 回目の失敗 (n) または 4 回目の失敗 (n+1) でロックされる可能性があります。n+1 の動作は LDAP サーバーの過去の動作であるため、レガシー動作とみなされます。新しい LDAP クライアントでは、より厳しいハード制限が想定されます。デフォルトでは、Directory Server は厳密な制限 (n) を使用しますが、passwordLegacyPolicy 設定パラメーターでレガシー動作を変更できます。

リセット後のパスワード変更

Directory Server パスワードポリシーでは、初回のログイン後、または管理者がパスワードをリセットした後にユーザーがパスワードを変更する必要があるかどうかを指定できます。管理者が設定するデフォルトのパスワードは通常、ユーザーのイニシャル、ユーザー ID、会社名などの会社の規則に従います。この規則が検出された場合、それは通常、悪意のある攻撃者がシステムに侵入しようとする際に使用する最初の値になります。したがって、管理者がパスワードをリセットした後は、ユーザーにパスワードの変更を要求することを推奨します。

パスワードポリシーにこの設定を行うと、ユーザー定義のパスワードが無効になっている場合でも、ユーザーはパスワードを変更する必要があります。パスワードポリシーにより、ユーザーが自分のパスワードを変更する必要がないまたは変更を許可されていない場合、管理者が割り当てるパスワードは、明白な規則に従わないもので、検出されにくいものにする必要があります。

デフォルト設定では、リセット後にユーザーがパスワードを変更する必要はありません。

ユーザー定義のパスワード

ユーザーが自分のパスワードを変更できるかできないかは、パスワードポリシーで設定できます。強固なパスワードポリシーには、適切なパスワードが必要です。適切なパスワードには、辞書に載っている単語、ペットや子供の名前、誕生日、ユーザー ID、または簡単に発見できる (またはディレクトリー自体に保存されている) ユーザーに関するその他の情報など、簡単に推測できるような単語は使用しないでください。適切なパスワードには、文字、数字、および特殊文字の組み合わせが含まれる必要があります。ただし、便宜上、ユーザーは覚えやすいパスワードを使用することがよくあります。そのため、企業によっては、強固なパスワード基準を満たすユーザーにパスワードを設定し、ユーザーがパスワードを変更できないようにすることがあります。

管理者がユーザーのパスワードを設定することには、次のような欠点があります。

  • 管理者の時間をかなり費やす必要があります。
  • 管理者が指定したパスワードは通常、覚えるのが難しいため、ユーザーはパスワードを書き留める可能性が高く、発見されるリスクが高くなります。

デフォルトでは、ユーザー定義のパスワードが許可されます。

パスワードの有効期限

パスワードポリシーを使用すると、同じパスワードを無期限に使用することを許可したり、一定期間後にパスワードの有効期限が切れるように設定することが可能です。一般的に、パスワードの使用期間が長いほど、パスワードが検出される可能性が高くなります。ただし、パスワードの期限切れが頻繁に発生すると、ユーザーはパスワードを覚えるのに苦労し、パスワードを書き留めてしまう可能性があります。一般的なポリシーでは、パスワードは 30 - 90 日ごとに失効します。サーバーは、パスワードの有効期限が無効であっても、パスワード失効の仕様を記憶します。パスワードの有効期限が再度有効になると、パスワードは最後に無効になった前に設定された期間のみ有効になります。たとえば、パスワードの有効期限が 90 日ごとに切れるように設定し、その後パスワードの有効期限を無効にしてから再度有効にした場合、デフォルトのパスワードの有効期限は 90 日間のままになります。

デフォルトでは、ユーザーパスワードは期限切れになりません。

有効期限の警告

パスワードの有効期限が設定されている場合、パスワードの期限が切れる前に警告をユーザーに送信することが推奨されます。

ユーザーがサーバーにバインドすると、Directory Server は警告を表示します。パスワードの有効期限が設定されている場合、Directory Server はデフォルトで、ユーザーパスワードの有効期限が切れる 1 日前に、LDAP メッセージを使用してユーザーに警告を送信します。ユーザークライアントアプリケーションはこの機能をサポートする必要があります。

パスワード有効期限警告の有効範囲は 1 日から 24,855 日です。

注記

Directory Server が有効期限の警告を送信するまで、パスワードは期限切れに なりません。

猶予ログイン制限

期限切れパスワードの 猶予期間 とは、パスワードが期限切れであっても、ユーザーがシステムにログインできることを意味します。一部のユーザーが期限切れのパスワードを使用してログインできるようにするには、パスワードの有効期限が切れた後にユーザーに許可される猶予ログインの試行回数を指定します。

デフォルトでは、Directory Server は猶予ログインを許可しません。

パスワードの構文チェック

パスワード構文チェックでは、パスワード文字列のルールが適用され、すべてのパスワードが特定の基準を満たすか、それを超える必要があります。すべてのパスワード構文チェックは、グローバルに、サブツリーごとに、またはユーザーごとに適用できます。passwordCheckSyntax 属性は、パスワード構文チェックを管理します。

デフォルトのパスワード構文には、最低 8 文字が必要で、パスワードに普通の言葉を使用できません。簡単に推測できる単語とは、ユーザーエントリーの uid、cn、sn、givenName、ou、または mailattributes に格納されている任意の値のことです。

さらに、他の形式のパスワード構文を強制でき、パスワード構文にさまざまなオプションのカテゴリーを提供します。

  • パスワードに必要な最小文字数 (passwordMinLength)。
  • 数字の最小桁数、つまり 0 から 9 までの数字 (passwordMinDigits)。
  • 大文字と小文字の両方を含む ASCII アルファベット文字の最小数 (passwordMinAlphas)。
  • 大文字の ASCII アルファベット文字の最小数 (passwordMinUppers)。
  • 小文字の ASCII アルファベット文字の最小数 (passwordMinLowers)。
  • !@#$ などの ASCII 特殊文字の最小数 (passwordMinSpecials)。
  • 8 ビット文字の最小数 (passwordMin8bit)。
  • aaabbb など、同じ文字をすぐに繰り返すことができる最大回数 (passwordMaxRepeats)。
  • パスワードに必要な文字カテゴリーの最小数。カテゴリーには、大文字または小文字、特殊文字、数字、または 8 ビット文字を使用できます (passwordMinCategories)。
  • Directory Server は、パスワードを CrackLib 辞書と照合します (passwordDictCheck)。
  • Directory Server は、パスワードに回文が含まれているか確認します (passwordPalindrome)。
  • Directory Server では、同じカテゴリーからの連続する文字が複数含まれるパスワードの設定を阻止します (passwordMaxClassChars)。
  • Directory Server は、特定の文字列を含むパスワードの設定を阻止します (passwordBadWords)。
  • Directory Server では、管理者定義の属性に設定された文字列を含むパスワードの設定が阻止されます (passwordUserAttributes)。

必要な構文のカテゴリーが多いほど、パスワードは強力になります。

デフォルトでは、パスワード構文のチェックは無効になっています。

パスワードの長さ

パスワードポリシーでは、ユーザーパスワードの最小の長さを要求できます。一般的に、パスワードが短いほど解読されやすくなります。パスワードの推奨最小文字数は 8 文字です。これは、解読が難しく、ユーザーがパスワードを書き留めなくても覚えられる長さです。この属性に有効な値の範囲は、2 - 512 文字です。

デフォルトでは、サーバーにはパスワードの最小文字数はありません。

パスワードの最小有効期間

パスワードポリシーにより、ユーザーが指定された期間はパスワードを変更できないようにすることができます。passwordMinAge 属性を passwordHistory 属性と組み合わせて設定すると、ユーザーは古いパスワードを再利用できなくなります。たとえば、パスワードの最小期間 (passwordMinAge) 属性が 2 日間の場合、ユーザーは単一のセッション中にパスワードを繰り返し変更できません。これにより、パスワード履歴を循環して、古いパスワードを再利用できるようになります。

passwordMinAge 属性の有効な値の範囲は 0 日から 24,855 日です。0 (0) の値は、ユーザーがすぐにパスワードを変更できることを示しています。

パスワード履歴

Directory Server は、パスワード履歴に 2 - 24 個のパスワードを保存できます。パスワードが履歴にある場合、ユーザーは自分のパスワードをその古いパスワードにリセットすることはできません。これにより、ユーザーは覚えやすいいくつかのパスワードを再利用できなくなります。あるいは、パスワード履歴を無効にして、ユーザーがパスワードを再利用できるようにすることもできます。

パスワード履歴をオフにしても、パスワードは履歴に残ります。パスワード履歴を再度オンにすると、パスワード履歴を無効にする前に履歴にあったパスワードをユーザーは再利用できなくなります。

サーバーはデフォルトではパスワード履歴を維持しません。

パスワードストレージスキーム

パスワードストレージスキームは、ディレクトリー内に Directory Server パスワードを保存するために使用される暗号化のタイプを指定します。Directory Server は、さまざまなパスワードストレージスキームをサポートします。

Password-Based Key Derivation Function 2 (PBKDF2_SHA256, PBKDF2-SHA1, PBKDF2-SHA256, PBKDF2-SHA512)
これは最も安全なパスワード保存方式です。デフォルトのストレージスキームは PBKDF2-SHA512 です。
Salted Secure Hash Algorithm (SSHA、SSHA-256、SSHA-384、および SSHA-512)
推奨される SSHA スキームは SSHA-256 以上です。
CLEAR
これは暗号化がないことを意味し、SASL Digest-MD5 で使用できる唯一のオプションであるため、SASL を使用するには CLEAR パスワード保存スキームが必要です。ディレクトリーに保存されるパスワードはアクセス制御情報 (ACI) 命令を使用して保護できますが、ディレクトリーにプレーンテキストのパスワードを保存することは推奨できません。
Secure Hash Algorithm (SHA、SHA-256、SHA-384、および SHA-512)
これは SSHA よりも安全性が低いです。
UNIX 暗号
このアルゴリズムは、UNIX パスワードとの互換性を提供します。
MD5
このストレージスキームは SSHA よりも安全性が低くなりますが、MD5 を必要とするレガシーアプリケーション用に含まれています。
Salted MD5
このストレージスキームは、プレーンな MD5 ハッシュよりも安全ですが、SSHA よりも安全性が低くなります。このストレージスキームは、新しいパスワードと併用するために含まれていませんが、salted MD5 に対応するディレクトリーからユーザーアカウントを移行する場合に役立ちます。

パスワードの最終変更時刻

passwordTrackUpdateTime 設定属性は、Directory Server がエントリーのパスワードを最後に更新した時刻のタイムスタンプを記録するようにサーバーに指示します。Directory Server は、パスワード変更時間を、modifyTimestamp または lastModified 操作属性とは別の操作属性 pwdUpdateTime としてユーザーエントリーに保存します。

デフォルトでは、サーバーはパスワードの最終変更時刻を保存しません。

7.6.3. レプリケートされた環境でのパスワードポリシーの設計
リンクのコピー

Directory Server は、レプリケートされた環境でパスワードとアカウントのロックアウトポリシーを次のように適用します。

  • パスワードポリシーはデータサプライヤーで実施されます。
  • アカウントのロックアウトは、レプリケーション設定のすべてのサーバーに適用されます。

Directory Server は、パスワードの有効期間、アカウントロックアウトカウンター、有効期限警告カウンターなどのパスワードポリシー情報をディレクトリーにレプリケートします。ただし、Directory Server は、パスワード構文やパスワード変更履歴などの設定情報をレプリケートしません。Directory Server はこの情報をローカルに保存します。

レプリケートされた環境でパスワードポリシーを設定する場合は、以下の点を考慮してください。

  • すべてのレプリカは、パスワードの期限切れが近いことを警告します。Directory Server は各サーバー上でこの情報をローカルに保存するため、ユーザーが複数のレプリカに順番にバインドすると、同じ警告が複数回表示されます。さらに、ユーザーがパスワードを変更する場合、レプリカがこの情報を受信するまでに時間がかかることがあります。ユーザーがパスワードを変更してからすぐに再バインドすると、レプリカが変更を登録するまでバインドに失敗する可能性があります。
  • サプライヤーやレプリカなど、すべてのサーバーで同じバインド動作が発生する必要があります。各サーバーに常に同じパスワードポリシー設定情報を作成します。
  • アカウントロックアウトカウンターは、マルチサプライヤー環境で想定どおりに機能しない場合があります。

7.7. アクセス制御の設計
リンクのコピー

認証スキームを決定したら、それらのスキームを使用してディレクトリーに含まれる情報を保護する方法を決定します。アクセス制御では、特定のクライアントが特定の情報にアクセスでき、その他のクライアントはアクセスできないように指定できます。

アクセス制御を定義するには、1 つ以上の アクセス制御リスト (ACL) を使用します。ディレクトリーの ACL は、指定されたエントリーとその属性へのパーミッション (読み取り、書き込み、検索、比較など) を許可または拒否する一連の 1 つ以上の アクセス制御情報 (ACI) ステートメントで構成されます。

ACL を使用すると、ディレクトリーツリーの任意のレベルでパーミッションを設定できます。

  • ディレクトリー全体
  • ディレクトリーの特定のサブツリー
  • ディレクトリーの特定のエントリー
  • エントリー属性の特定セット
  • 指定の LDAP 検索フィルターと一致するエントリー

さらに、特定のユーザー、特定のグループに属するすべてのユーザー、またはディレクトリーのすべてのユーザーに対してパーミッションを設定することもできます。IP アドレス (IPv4 または IPv6) や DNS 名などのネットワークの場所へのアクセスを定義できます。

7.7.1. ACI 形式について
リンクのコピー

セキュリティーポリシーを設計するときは、ディレクトリー内で ACI が表現される方法と、設定できるパーミッションを理解する必要があります。

ディレクトリー ACI は次の一般的な形式を使用します。 

target permission bind_rule
Copy to Clipboard Toggle word wrap

ACI 変数の説明は次のとおりです。

Target
ACI が対象とするエントリー (通常はサブツリー)、対象とする属性、またはその両方を指定します。ターゲットは ACI が適用されるディレクトリー要素を識別します。ACI はエントリーを 1 つだけターゲットにできますが、複数の属性をターゲットにできます。さらに、ターゲットには LDAP 検索フィルターを含めることができます。共通の属性値を含む、広範囲に分散したエントリーに対してパーミッションを設定できます。
Permission
ACI が設定する実際のパーミッションを識別します。パーミッション変数は、ACI が指定されたターゲットへの読み取りや検索などの特定のタイプのディレクトリーアクセスを許可または拒否することを示します。
Bind rule
パーミッションが適用されるバインド DN またはネットワークの場所を特定します。バインドルールは LDAP フィルターを指定する場合もあり、そのフィルターがバインドクライアントアプリケーションに対して true であると評価された場合、ACI はクライアントアプリケーションに適用されます。

したがって、ディレクトリーオブジェクトターゲットの場合、バインドルールが true の場合、ACI はパーミッションを許可または拒否します。

パーミッションとバインドルールはペアで設定され、すべてのターゲットには複数のパーミッションとバインドルールのペアを設定できます。特定のターゲットに対して複数のアクセス制御を効果的に設定できます。以下に例を示します。 

target (permission bind_rule)(permission bind_rule) ...
Copy to Clipboard Toggle word wrap
7.7.1.1. ターゲット
リンクのコピー

ACI は、ディレクトリーエントリーとそのエントリーの属性をターゲットにすることができます。

ディレクトリーエントリーをターゲットにすると、そのエントリーとそのすべての子エントリーがパーミッションの範囲に含まれます。ACI のターゲットエントリーを明示的に定義しない場合、ACI は ACI ステートメントを含むディレクトリーエントリーをターゲットにします。ACI は、1 つのエントリーのみ、または単一の LDAP 検索フィルターに一致するエントリーのみを対象にすることができます。

属性をターゲットにすると、属性値のサブセットにのみパーミッションが適用されます。属性セットをターゲットにする場合は、ACI がターゲットとする属性、または ACI がターゲットとしない属性を明示的に指定します。ターゲット内の属性を除外すると、オブジェクトクラス構造で許可される一部の属性を除くすべての属性に対するパーミッションが設定されます。

7.7.1.2. パーミッション
リンクのコピー

パーミッションによってアクセスを許可または拒否できます。パーミッションを拒否しないでください。詳細は、アクセスの許可または拒否 を参照してください。

パーミッションは、ディレクトリーサービスに対して実行される操作のいずれかです。

Expand
パーミッション説明

Read

ユーザーがディレクトリーデータを読み取ることができるかを示します。

Write

ユーザーがディレクトリーを変更または作成できるかを示します。さらに、このパーミッションにより、ユーザーはディレクトリーデータを削除することはできますが、エントリー自体は削除できません。ただし、エントリー全体を削除するには、ユーザーに delete パーミッションが必要です。

Search

ユーザーがディレクトリーデータを検索できるかを示します。これは、read パーミッションとは異なります。read パーミッションの場合は、検索操作の一部として返される場合に、ユーザーがディレクトリーデータを表示することを許可します。

たとえば、共通名 (cn) の検索とある人物の部屋番号の読み取りを許可すると、Directory Server は共通名検索の一部として部屋番号を返すことができます。ただし、部屋番号を検索対象として使用することはできません。この組み合わせを使用すると、特定の部屋に誰が座っているかを検索されるのを防ぐことができます。

Compare

ユーザーがデータを比較できるかどうかを示します。compare パーミッションには検索機能が含まれますが、Directory Server は検索の結果として実際のディレクトリー情報を返しません。代わりに、Directory Server は、比較された値が一致するかどうかを示す単純なブール値を返します。ディレクトリーの認証中に比較操作を使用して、userPassword 属性値を一致させます。

Self-write

self-write パーミッションはグループ管理にのみ使用してください。このパーミッションにより、ユーザーは自分自身をグループに追加したり、グループから削除したりできます。

追加

ユーザーが対象エントリーの下に子エントリーを作成できるか示します。

Delete

ユーザーが対象エントリーを削除できるか示します。

プロキシー

ユーザーが Directory Manager 以外の他の DN を使用して、この DN の権限でディレクトリーにアクセスできることを示します。

7.7.1.3. バインドルール
リンクのコピー

バインドルールは、ACI が適用されるバインド DN (ユーザー) を定義します。また、時刻や IP アドレスなどのバインド属性を指定することもできます。

さらに、バインドルールでは、ACI がユーザー自身のエントリーにのみ適用されることを簡単に定義できます。ユーザーは、他のユーザーのエントリーを更新するリスクを負うことなく、自分のエントリーを更新できます。

バインドルールは、ACI が適用される次の状況を示します。

  • バインド操作が特定の IP アドレス (IPv4 または IPv6) または DNS ホスト名から到着した場合。これを使用すると、特定のマシンまたはネットワークドメインからのすべてのディレクトリー更新を強制的に実行できます。
  • ユーザーが匿名でバインドする場合。匿名バインドのパーミッションを設定すると、そのパーミッションはディレクトリーにバインドするすべてのユーザーに適用されることになります。
  • ディレクトリーに正常にバインドされるユーザーの場合。これを使用すると、匿名アクセスを阻止する一方で、一般アクセスを許可することができます。
  • ユーザーがエントリーの直接の親としてバインドされている場合。
  • ユーザーが特定の LDAP 検索条件を満たしている場合。

Directory Server は、バインドルールに次のキーワードを提供します。

Parent
バインド DN が直接の親エントリーである場合、バインドルールは true になります。ディレクトリーエントリーがその直下の子エントリーを管理できるようにする特定のパーミッションを付与できます。
Self
バインド DN がアクセスを要求するエントリーと同じである場合、バインドルールは true になります。特定のパーミッションを付与して、各ユーザーが自分のエントリーを更新できるようにすることができます。
すべて
ディレクトリーに正常にバインドされたユーザーは、バインドルールは true になります。
全ユーザー
bind ルールは、すべてのユーザーで true になります。このキーワードを使用して、匿名アクセスを許可または拒否します。

7.7.2. パーミッションの設定
リンクのコピー

デフォルトでは、Directory Server は、Directory Manager を除くすべてのユーザーに対してあらゆる種類のアクセスを拒否します。したがって、ユーザーがディレクトリーにアクセスできるようにするには、ACI を設定する必要があります。

7.7.2.1. 優先度ルール
リンクのコピー

ユーザーがディレクトリーエントリーに対して何らかのアクセスを試みると、Directory Server はディレクトリーに設定されているアクセス制御をチェックします。アクセスを決定するため、Directory Server は 優先度ルール を適用します。このルールは、競合する 2 つのパーミッションが存在する場合に、アクセスを拒否するパーミッションが、アクセスを許可するパーミッションよりも常に優先されることを示しています。

たとえば、Directory Server がディレクトリーのルートレベルでの書き込みパーミッションを拒否し、そのパーミッションがディレクトリーにアクセスするすべてのユーザーに適用される場合、書き込みアクセスを許可するその他のパーミッションに関係なく、どのユーザーもディレクトリーに書き込むことはできません。特定のユーザーにディレクトリーへの書き込みパーミッションを許可するには、元の書き込み拒否の範囲を設定して、そのユーザーが含まれないようにする必要があります。次に、ユーザーに対して追加の書き込み許可パーミッションを設定する必要があります。

7.7.2.2. アクセスの許可または不許可
リンクのコピー

ディレクトリーツリーへのアクセスを許可または拒否できますが、アクセスを明示的に拒否する場合は注意してください。優先ルールにより、Directory Server は、ディレクトリーの上位レベルでアクセスを拒否するルールを見つけた場合、アクセスを許可する可能性のある競合するパーミッションに関係なく、下位レベルでのアクセスを拒否します。

ユーザーまたはクライアントアプリケーションの可能な限り小さなサブセットのみが含まれるように、アクセスルールのスコープを制限します。たとえば、ユーザーが自分のディレクトリーエントリーの任意の属性に書き込めるようにパーミッションを設定しても、Directory Administrator グループのメンバーを除くすべてのユーザーに uid 属性への書き込み権限を拒否することができます。

または、以下の方法で書き込みアクセスを許可する 2 つのアクセス制御ルールを作成します。

  • uid 属性を除くすべての属性への書き込み権限を許可するルールを 1 つ作成します。このルールはすべてのユーザーに適用される必要があります。
  • uid 属性への書き込み権限を許可するルールを 1 つ作成します。このルールは、Directory Administrators グループのメンバーにのみ適用する必要があります。

許可特権のみを提供すると、明示的な拒否特権を設定する必要がなくなります。

7.7.2.3. アクセスを拒否する場合
リンクのコピー

明示的に拒否権限を設定する必要はほとんどありませんが、次の場合には役立ちます。

  • 複雑な ACL が分散している大きなディレクトリーツリーがある場合。

    セキュリティー上の理由により、Directory Server は特定のユーザー、グループ、または物理的なロケーションへのアクセスを突然拒否する必要がある場合があります。時間をかけて既存の ACL を注意深く調べ、許可パーミッションを制限する方法を理解する代わりに、分析を行う時間ができるまで、明示的な拒否特権を一時的に設定します。ACL がこのように複雑になると、拒否 ACI は将来的には管理オーバーヘッドにコストのみを追加します。できるだけ早く ACL を作り直して、明示的な拒否特権を回避し、アクセス制御スキーム全体を簡素化します。

  • アクセス制御は、曜日または時間に基づいて設定します。

    たとえば、Directory Server はすべての書き込みアクティビティーを拒否することができます。時間は、日曜日午後 11 時 (2300) から月曜日午前 1 時 (0100) までになります。管理の観点からは、ディレクトリー全体ですべての allow-for-write ACI を検索し、その範囲をこの時間枠内で制限するよりも、このタイプの時間ベースのアクセスを明示的に制限する ACI を管理する方が簡単な場合があります。

  • ディレクトリー管理権限を複数のユーザーに委任する場合は、権限を制限します。

    個人またはユーザーのグループに、ツリーの一部を変更を許可せずに、ディレクトリーツリーの一部の管理を許可するには、明示的な拒否特権を使用します。

    たとえば、メール管理者が共通名 (cn) 属性への書き込みアクセスを許可しないようにするには、共通名属性への書き込みアクセスを明示的に拒否する ACI を設定します。

7.7.2.4. アクセス制御ルールの配置場所
リンクのコピー

ディレクトリー内の任意のエントリーにアクセス制御ルールを追加できます。多くの場合、管理者はオブジェクトクラス domainComponent、country、organization、organizationalUnit、inetOrgPerson、または group. を持つエントリーにアクセス制御ルールを適用します。ACL 管理を簡素化するために、ルールを可能な限りグループに整理します。ルールは、ターゲットエントリーとそのエントリーのすべての子に適用されます。したがって、アクセス制御ルールは、個々のリーフ (個人など) のエントリーに分散させるのではなく、ディレクトリーのルートポイントまたはディレクトリーブランチポイントに配置するのが最適です。

7.7.2.5. フィルターされたアクセス制御ルールの使用
リンクのコピー

LDAP 検索フィルターを使用して、定義された基準セットに一致するディレクトリーエントリーへのアクセスを設定できます。たとえば、Marketing に設定された organizationalUnit 属性を含むすべてのエントリーに対して読み取りアクセスを許可します。

フィルターされたアクセス制御ルールにより、事前定義のアクセスレベルが許可されます。たとえば、ディレクトリーには自宅住所や電話番号の情報が含まれています。この情報を公開したい人もいれば、非公開にしたい人もいます。

アクセスを設定するには、次の方法を使用できます。

  1. すべてのユーザーディレクトリーエントリーに publishHomeContactInfo という属性を追加します。
  2. publishHomeContactInfo 属性が true (有効) に設定されているエントリーに対してのみ、homePhone 属性と homePostalAddress 属性への読み取りアクセスを許可するアクセス制御ルールを設定します。LDAP 検索フィルターを使用して、このルールのターゲットを表します。
  3. ディレクトリーユーザーが独自の publishHomeContactInfo 属性の値を true または false に変更できるようにします。これにより、ディレクトリーユーザーは、この情報が公開されているかどうかを判断できます。

7.7.3. ACI の表示: Get effective rights
リンクのコピー

Get effective rights (GER) は、エントリー内の各属性に設定されているアクセス制御パーミッションを返す拡張 ldapsearch コマンドです。この検索により、LDAP クライアントは、サーバーのアクセス制御設定によってユーザーが実行できる操作を判別できます。

アクセス制御情報は、エントリー権限と属性権限の 2 つのアクセスグループに分かれています。エントリー権限は、変更や削除など、特定のエントリーに限定された権限です。属性権限は、ディレクトリー全体のその属性のすべてのインスタンスへのアクセス権です。

このような詳細なアクセス制御は、以下のような状況で必要になることがあります。

  • GER コマンドを使用して、ディレクトリーのアクセス制御命令をより適切に編成できます。あるユーザーグループが閲覧または編集できる内容を、別のユーザーグループと比較して制限しなければならない状況は頻繁に発生します。たとえば、QA Managers グループのメンバーは、manager や salary などの属性を検索して読み取る権限を持っていますが、それを変更または削除する権限を持っているのは HR Group のメンバーだけです。他にも方法はありますが、ユーザーまたはグループの実効権限を確認することで、管理者が適切なアクセス制御を設定しているか確認できます。
  • GER コマンドを使用して、個人のエントリーで表示または変更できる属性を確認できます。たとえば、ユーザーは homePostalAddress や cn などの属性にアクセスできるはずですが、manager 属性や salary 属性に対しては読み取り権限しか持っていない場合があります。

7.7.4. ACI の使用: いくつかのヒントとコツ
リンクのコピー

次のヒントは、ディレクトリーセキュリティーモデルの管理にかかる管理上の負担を軽減し、ディレクトリーのパフォーマンス特性を向上させるのに役立ちます。

  • ディレクトリー内の ACI の数を最小限に抑えます。

    Directory Server は 50,000 を超える ACI を評価できますが、多数の ACI ステートメントを管理するのは困難です。ACI の数が多いと、人間の管理者が特定のクライアントが使用できるディレクトリーオブジェクトをすぐに判断することが難しくなります。

    Directory Server は、マクロを使用してディレクトリー内の ACI の数を最小限に抑えます。マクロを使用して、ACI ターゲットまたはバインドルール、あるいはその両方で DN またはその一部を表します。

  • アクセス許可の許可と拒否のバランスを取ります。

    デフォルトのルールでは、明確にアクセスを許可されていないユーザーへのアクセスは拒否されますが、ツリーのルートに近いアクセスを許可する ACI を 1 つ使用し、リーフエントリーに近いアクセスを拒否する ACI を少数使用して、ACI の数を減らす方がよい場合があります。このシナリオでは、リーフエントリーの近くで複数の許可 ACI が使用されることを回避します。

  • ACI 内の最小の属性セットを識別します。

    属性のサブセットへのアクセスを許可または拒否する場合、最小のリストが許可される属性のセットであるか、拒否される属性のセットであるかを選択します。次に、最小のリストの管理のみが必要になるように ACI を設定します。

    たとえば、person オブジェクトクラスには多数の属性が含まれています。ユーザーが少数の属性のみを更新できるようにするには、それらの属性のみへの書き込みアクセスを許可する ACI を記述します。ただし、少数の属性を除くすべての属性をユーザーが更新できるようにするには、これらの少数の名前付き属性を除くすべての属性への書き込みアクセスを許可する ACI を作成します。

  • LDAP 検索フィルターの使用には注意が必要です。

    検索フィルターでは、アクセスを管理するオブジェクトの名前は直接指定されません。したがって、それらを使用すると、予期しない結果が生じる可能性があります。特に、ディレクトリーが複雑になった場合に予期しない結果が生じる可能性があります。ACI で検索フィルターを使用する前に、同じフィルターを使用して ldapsearch 操作を実行し、結果を明確にします。

  • ディレクトリーツリーの異なる部分で ACI を複製しないでください。

    ACI の重複を防ぎます。たとえば、ディレクトリールートポイントに、commonName 属性と givenName 属性へのグループ書き込みアクセスを許可する ACI があり、同じグループに commonName 属性のみへの書き込みアクセスを許可する別の ACI がある場合、1 つのコントロールのみがグループへの書き込みアクセスを許可するように ACI を更新することを検討してください。

    ディレクトリーがより複雑になると、誤って ACI が重複するリスクが急速に高まります。ACI の重複を回避することで、ディレクトリーに含まれる ACI の総数が減り、セキュリティー管理が容易になります。

  • ACI に名前を付けます。

    ACI の命名は任意ですが、各 ACI に短くて意味のある名前を付けることは、セキュリティーモデルの管理に役立ちます。

  • ディレクトリー内で ACI をできるだけ密接にグループ化します。

    ACI の場所をディレクトリーのルートポイントと主要なディレクトリーのブランチポイントに制限するようにします。ACI をグループ化すると、ディレクトリー内の ACI の総数を最小限に抑えるだけでなく、ACI の合計リストを管理するのにも役立ちます。

  • バインド DN が cn=Joe と等しくない場合に書き込みを拒否するなど、二重否定の使用は避けてください。

    この構文はサーバーにとっては完全に受け入れられますが、人間が読めるものではありません。

7.7.5. ルート DN (Directory Manager) への ACI の適用
リンクのコピー

通常のアクセス制御ルールは、Directory Manager ユーザーには適用されません。Directory Manager は、通常のユーザーデータベースではなく dse.ldif ファイルで定義されるため、ACI ターゲットにはそのユーザーが含まれません。

Directory Manager では、メンテナンスタスクを実行し、インシデントへの対応に高いレベルのアクセスが必要です。ただし、Directory Manager に一定レベルのアクセス制御を付与して、ルートユーザーとして不正アクセスや攻撃が行われるのを阻止することができます。

RootDN Access Control プラグインを使用して、Directory Manager ユーザーに固有の特定のアクセス制御ルールを設定します。

  • 特定の日および特定の時間範囲でアクセスを許可または拒否する時間ベースのアクセス制御
  • 定義された IP アドレス、サブネット、およびドメインからのアクセスを許可または拒否するための IP アドレスルール
  • 特定のホスト、ドメイン、およびサブドメインからのアクセスを許可または拒否するホストアクセスルール

Directory Manager にはアクセス制御ルールを 1 つだけ設定できます。これはプラグインエントリーにあり、ディレクトリー全体に適用されます。

重要

Directory Manager アカウントに適切なレベルのアクセス権があることを確認してください。この管理ユーザーは、時間外に保守操作を実行したり、障害に対応したりする必要がある場合があります。この場合、時間または曜日のルールを厳しく設定しすぎると、Directory Manager ユーザーがディレクトリーを効果的に管理できなくなる可能性があります。

7.8. データベースの暗号化
リンクのコピー

データベースは情報をプレーンテキストで保存します。その結果、アクセス制御手段では、政府の識別番号やパスワードなどの極めて機密性の高い情報を十分に保護できない可能性があります。ファイルシステムを介して直接、または廃棄されたディスクドライブやアーカイブメディアにアクセスすることによって、サーバーの永続ストレージファイルにアクセスできる可能性があります。

データベース暗号化を使用すると、個々の属性をデータベースに保存するときに暗号化できます。設定すると、特定の属性のすべてのインスタンス (インデックスデータも含む) が暗号化され、TLS などの安全なチャネルを使用してのみアクセスできます。

7.9. サーバー接続の保護
リンクのコピー

識別されたユーザーの認証スキームと、ディレクトリー内の情報を保護するためのアクセス制御スキームを設計したら、次のステップは、サーバーとクライアントアプリケーションの間を通過する情報の整合性を保護する方法を設計することです。

サーバーからクライアントへの接続とサーバーからサーバーへの接続の両方において、Directory Server はさまざまなセキュアな接続タイプをサポートしています。

トランスポートレイヤーセキュリティー (Transport Layer Security, TLS)
Directory Server は、TLS 経由の LDAP を使用して、ネットワーク上でセキュアな通信を提供できます。特定の接続に対して選択される暗号化方式は、クライアントアプリケーションと Directory Server 間のネゴシエーションの結果です。
Start TLS
Directory Server は、通常の暗号化されていない LDAP ポートを介して Transport Layer Security (TLS) 接続を開始する方法である Start TLS もサポートしています。
Simple Authentication and Security Layer (SASL)
SASL は、クライアントアプリケーションとサーバーアプリケーションの両方で有効にするメカニズムに応じて、サーバーに対してユーザーを認証するためのさまざまなメカニズムを設定するために使用できるセキュリティーフレームワークです。さらに、SASL はクライアントとサーバーの間で暗号化されたセッションを確立できます。Directory Server では、SASL を GSS-API とともに使用して Kerberos ログインを有効にし、レプリケーション、チェイニング、パススルー認証を含むほぼすべてのサーバー間接続を実現します。Directory Server は Windows 同期で SASL を使用できません。

セキュアな接続は、レプリケーションなどの機密情報を扱う操作で推奨され、Windows パスワード同期などの一部の操作では必須となっています。Directory Server は、TLS 接続、SASL、および非セキュア接続を同時にサポートできます。

Directory Server は、SASL 認証と TLS 接続の両方を同時にサポートできます。たとえば、サーバーへの TLS 接続を要求し、レプリケーション接続の SASL 認証もサポートするように Directory Server インスタンスを設定したとします。これは、ネットワーク環境で TLS を使用するか SASL を使用するかを選択する必要がないことを意味します。

さらに、サーバーへの接続に対して最低限のセキュリティーレベルを設定できます。セキュリティー強度係数は、キーの強度で、セキュアな接続の強度を測定します。接続が特定の強度以上の場合にのみ、パスワードの変更などの特定の操作を実行することを要求する ACI を設定できます。また、基本的に標準接続を無効にし、すべての接続に TLS、Start TLS、または SASL を要求する最小の SSF を設定することもできます。Directory Server は TLS と SASL を同時にサポートし、サーバーは利用可能なすべての接続タイプの SSF を計算し、最も強力なものを選択します。

7.10. SELinux ポリシーの使用
リンクのコピー

SELinux は、システム上のアプリケーション、プロセス、およびファイルへのアクセス制御を定義するセキュリティーポリシーのコレクションです。セキュリティーポリシーは、不正アクセスや改ざんを防ぐために、SELinux にアクセスを許可する対象と許可しない対象を指示する一連のルールです。

SELinux は、サーバー上のファイル、ディレクトリー、ポート、プロセス、ユーザー、およびその他のオブジェクトを分類します。SELinux は、各オブジェクトを適切なセキュリティーコンテキストに配置し、そのオブジェクトのロール、ユーザー、セキュリティーレベルを通じて、サーバー上でオブジェクトがどのように動作できるかを定義します。SELinux はオブジェクトのこれらのロールをドメインにグループ化し、SELinux ルールは、あるドメイン内のオブジェクトが別のドメイン内のオブジェクトと対話できる方法を定義します。

Directory Server には次のドメインがあります。

  • dirsrv_t (Directory Server)
  • dirsrv_snmp_t (SNMP)
  • ldap_port_t (LDAP ポート)

これらのドメインは、Directory Server のすべてのプロセス、ファイル、ディレクトリー、ポート、ソケット、およびユーザーのセキュリティーコンテキストを提供します。

  • SELinux は、特定のセキュリティーコンテキストを使用して、各インスタンスのファイルとディレクトリーにラベルを付けます。Directory Server が使用するメインディレクトリーのほとんどには、ローカルインスタンスの数に関係なく、すべてのローカルインスタンス用のサブディレクトリーがあるため、SELinux は新しいインスタンスに単一のポリシーを簡単に適用できます。
  • SELinux は、特定のセキュリティーコンテキストを使用して各インスタンスのポートにラベルを付けます。
  • SELinux は、すべての Directory Server プロセスを適切なドメイン内に制限します。
  • 各ドメインには、ドメインに承認されたアクションを定義する特定のルールがあります。
  • SELinux ポリシーで指定されていない場合、SELinux はインスタンスへのアクセスを拒否します。

SELinux には 3 つの異なるレベルの適用があります。

disabled
SELinux なし
permissive
SELinux プロセスルールは処理されますが、適用されるわけではありません。
enforcing
SELinux はすべてのルールを厳密に適用します。

Red Hat Directory Server は、厳密な SELinux enforcing モードで通常どおり実行できるようにする SELinux ポリシーを定義しています。Directory Server は、通常の操作用とインポートなどのデータベース操作用 (ldif2db モード) の 2 つの異なるモードで実行できます。Directory Server の SELinux ポリシーは、通常モードにのみ適用されます。

デフォルトでは、Directory Server は SELinux ポリシーを使用して通常モードで実行されます。

第8章 ディレクトリー設計の例
リンクのコピー

ディレクトリーサービスの設計は、企業の規模と性質によって異なります。これらの例は、実際のディレクトリーサービスのデプロイメント計画を作成するための出発点となります。

8.1. ローカルエンタープライズの設計例
リンクのコピー

ExampleCom は自動車部品メーカーの小規模な会社で、従業員数は 500 人です。ExampleCom は、自社で使用するディレクトリー対応アプリケーションをサポートするために、Red Hat Directory Server のデプロイを決定しました。

8.1.1. ローカルエンタープライズのデータ設計
リンクのコピー

ディレクトリーに保存するデータのタイプを決定するために、ExampleCom はサイト調査を実行するデプロイメントチームを結成します。デプロイメントチームは、次の重要なポイントを決定します。

  • メッセージングサーバー、Web サーバー、カレンダーサーバー、人事アプリケーション、およびホワイトページアプリケーションがディレクトリーを使用します。

  • メッセージングサーバーは、uid、mailServerName、mailAddress などの属性に対して 正確な 検索を実行します。データベースのパフォーマンスを向上させるために、ExampleCom はこれらの属性のインデックスを維持します。

    インデックスの使用に関する詳細は、インデックスを使用してデータベースのパフォーマンスを向上させる を参照してください。

  • ホワイトページアプリケーションは、ユーザー名と電話番号を検索します。したがって、ディレクトリーは、大量の結果セットを返す頻繁な部分文字列、ワイルドカード、およびあいまい検索を処理する必要があります。ExampleCom 社は、以下のインデックスを維持することにしました。

    • cn、sn、givenName 属性の 存在、等価性、近似値、および 部分文字列 インデックス。
    • telephoneNumber 属性の 存在、等価性、および 部分文字列 のインデックス。
  • 組織内にデプロイされた LDAP サーバーベースのイントラネットをサポートするには、ディレクトリーでユーザーとグループの情報を維持する必要があります。ディレクトリー管理者グループは、ExampleCom のユーザーおよびグループ情報のほとんどを管理します。ただし、ExampleCom では、メール情報を管理するために別のメール管理者グループを必要としています。
  • ディレクトリーには、S/MIME メールなどの公開鍵基盤 (PKI) アプリケーションをサポートするために、ユーザーの公開鍵証明書を保存する必要があります。

8.1.2. ローカルエンタープライズのスキーマ設計
リンクのコピー

ExampleCom ディレクトリーがサポートするアプリケーションには、userCertificate および uid (userID) 属性が必要です。したがって、ExampleCom デプロイメントチームは、両方の属性が許可されるため、inetOrgPerson オブジェクトクラスを使用してディレクトリー内のエントリーを表すことにしました。

さらに、ExampleCom は、従業員を表す examplePerson オブジェクトクラスを作成して、デフォルトのディレクトリースキーマをカスタマイズしたいと考えています。このオブジェクトクラスは、inetOrgPerson オブジェクトクラスから派生しています。examplePerson では、1 つの exampleID 属性が許可されます。この属性には、各従業員に割り当てられた特別な従業員番号が含まれます。ExampleCom は今後、examplePerson オブジェクトクラスに新しい属性を追加できます。

8.1.3. ローカルエンタープライズのディレクトリーツリー設計
リンクのコピー

準備されたデータとスキーマ設計に基づいて、ExampleCom は次のディレクトリーツリーを作成します。

図8.1 ExampleCom のディレクトリーツリー

dg ローカル企業の例 1
View larger image
dg ローカル企業の例 1
  • ディレクトリーツリーの root は dc=example,dc=com で、これは会社のインターネットドメイン名です。

  • ディレクトリーツリーには 4 つのブランチポイントがあります。

    • ou=people
    • ou=groups
    • ou=resources
    • ou=roles

  • すべての ExampleCom の people エントリーは、ou=people ブランチの下に作成されます。

    people エントリーはすべて、person、organizationalPerson、inetOrgPerson、および examplePerson オブジェクトクラスのメンバーです。uid 属性は、各エントリーの識別名 (DN) を一意に識別します。たとえば、会社には Babs Jensen (uid=bjensen) と Emily Stanton (uid=estanton) のエントリーが含まれています。

  • ExampleCom の各部門には、sales、marketing、および accounting ロールが作成されます。

    person エントリーにはそれぞれ、その人が所属する部門を識別するロール属性が含まれます。この会社は、これらのロールに基づいてアクセス制御命令 (ACI) を作成できるようになりました。

    ロールの詳細は、「Directory Server のロールについて」 を参照してください。

  • ou=groups ブランチの下に、以下のグループブランチが作成されます。

    • cn=administrators グループには、ディレクトリーの内容を管理するディレクトリー管理者のエントリーが含まれています。
    • cn=messaging admins グループには、メールアカウントのみを管理するメール管理者のエントリーが含まれています。このグループは、メッセージングサーバーが使用する管理者グループに対応します。

  • ou=resources ブランチの下に次のブランチが作成されます。

    • 会議室用の ou=conference rooms ブランチ。
    • オフィス用の ou=offices ブランチ。
  • エントリーが管理グループに属しているかどうかに応じて、mailquota 属性の値を提供する Class of Service (CoS) が作成されます。この CoS では、管理者には 100GB のメールクォータが提供され、一般の ExampleCom の従業員には 5GB のメールクォータが与えられます。

8.1.4. ローカルエンタープライズのトポロジー設計
リンクのコピー

ExampleCom デプロイメントチームは、ディレクトリーデータベースとサーバートポロジーの設計を開始します。

ExampleCom は次のデータベーストポロジーを設計します。

図8.2 ローカルエンタープライズのデータベーストポロジー

dg ローカル企業の例 2
View larger image
dg ローカル企業の例 2
  • Database 1 には ou=people ブランチが格納されます。
  • Database 2 には ou=groups ブランチが格納されます。
  • Database 3 には、ou=resources および ou=roles ブランチと dc=example,dc=com root 接尾辞が格納されます。

ExampleCom は次のサーバートポロジーを設計します。

図8.3 ローカル企業のサーバートポロジー

dg ローカル企業の例 3
View larger image
dg ローカル企業の例 3

ExampleCom は、2 つのサプライヤーサーバーと 3 つのコンシューマーサーバーを含むサーバートポロジーを作成することにしました。2 つのサプライヤーはそれぞれ、Directory Server のデプロイメント内の 3 つのコンシューマーをすべて更新します。

コンシューマーは、1 つのメッセージングサーバーと他のサーバーにデータを提供します。互換性のあるサーバーからの変更要求は、適切なコンシューマーサーバーにルーティングされます。コンシューマーサーバーは、スマートリファラルを使用して、変更されるデータのメインコピーを担当するサプライヤーサーバーへの要求をルーティングします。

8.1.5. ローカルエンタープライズのレプリケーション設計
リンクのコピー

ExampleCom は、ディレクトリーデータの高可用性を確保するために、マルチサプライヤーのレプリケーション設計を使用することを決定します。マルチサプライヤーレプリケーションの詳細は、マルチサプライヤーレプリケーション を参照してください。

マルチサプライヤーアーキテクチャー

ExampleCom は、マルチサプライヤーレプリケーションアーキテクチャーで 2 つのサプライヤーサーバーを使用します。サプライヤーが相互に更新することで、ディレクトリーデータの整合性が保たれます。次の図は、ExampleCom のサプライヤー - サプライヤーアーキテクチャーを示しています。

図8.4 ExampleCom マルチサプライヤーアーキテクチャー

dg ローカル企業の例 4
View larger image
dg ローカル企業の例 4

サプライヤーコンシューマーアーキテクチャー

以下の図は、ExampleCom のディレクトリーのデプロイメントで、サプライヤーサーバーが各コンシューマーにレプリケートする方法を示しています。

図8.5 ExampleCom サプライヤー - コンシューマーアーキテクチャー

dg ローカル企業の例 5
View larger image
dg ローカル企業の例 5

両方のサプライヤーサーバーが 3 つのコンシューマーサーバーを更新します。これにより、サプライヤーサーバーの 1 つに障害が発生しても、コンシューマーが影響を受けることはありません。

8.1.6. ローカル企業のセキュリティー設計
リンクのコピー

ディレクトリーデータを保護するために、ExampleCom は次のアクセス制御命令 (ACI) を作成します。

  • 従業員がエントリーを変更できるようにする ACI。ユーザーは、uid、manager、department 属性を除くすべての属性を変更できます。
  • 従業員データのプライバシーを保護するために、従業員と従業員のマネージャーのみが従業員の自宅住所と電話番号を確認できる ACI。

  • ディレクトリーツリーのルートにある ACI は、2 つの管理者グループに適切なディレクトリーパーミッションを付与します。

    • ディレクトリー管理者グループは、ディレクトリーへのフルアクセスが必要です。
    • メッセージング管理者グループには、mailRecipient および mailGroup オブジェクトクラス、およびこれらのオブジェクトクラスで許可される属性 (mail 属性を含む) への write および delete アクセス権が必要です。ExampleCom は、メッセージング管理者グループに、メールグループを作成するためのグループサブディレクトリーへの write、delete、および add パーミッションも付与します。
  • ディレクトリーツリーのルートにある一般的な ACI で、read、search、および compare アクセスに対する匿名アクセスを許可します。さらに、この ACI は匿名ユーザーによるパスワード情報へのアクセスを拒否します。
  • アカウンティングロールのメンバーにすべての給与情報へのアクセス権を与える ACI。

さらに、ExampleCom は次のセキュリティー対策を決定します。

  • サービス拒否攻撃や不適切な使用からサーバーを保護するために、ExampleCom は、ディレクトリークライアントがバインドに使用する DN に基づいてリソース制限を設定します。

    • 匿名ユーザーは、検索要求に応じて一度に 100 件のエントリーを受け取ることができます。
    • メッセージング管理者は 1,000 件のエントリーを受信できます。
    • ディレクトリー管理者は、無制限の数のエントリーを受け取ることができます。

  • ExampleCom は、長さが少なくとも 8 文字で、90 日後に期限切れになるパスワードのパスワードポリシーを作成します。

    パスワードポリシーの詳細は、パスワードポリシーの設計 を参照してください。

8.1.7. ローカルエンタープライズの運営上の決定
リンクのコピー

会社は、ディレクトリーの日常業務に関して次の決定を下します。

  • 毎晩、データベースをバックアップします。
  • SNMP を使用してサーバーの状態を監視します。
  • アクセスログとエラーログを自動でローテーションします。
  • エラーログを監視し、サーバーが想定どおりに実行されていることを確認します。
  • アクセスログを監視して、インデックスを作成できる検索を示します。

8.2. 多国籍企業の設計例
リンクのコピー

ExampleCom は、以前は ローカル企業のデザイン例 の小さな会社でしたが、米国、ヨーロッパ、アジアの 3 つの地理的場所に分散する大規模な組織に成長しました。現在、同社には 20,000 人を超える従業員がおり、すべての従業員は ExampleCom オフィスがある国に住み、働いています。

ExampleCom は、社内コミュニケーションを改善し、Web アプリケーションの開発とデプロイを容易にし、セキュリティーとプライバシーを強化するために、全社的な LDAP ディレクトリーを開始することを決定しました。

グローバル企業向けのディレクトリーツリーを設計する場合、ExampleCom は次の質問に対する解決策を見つける必要があります。

  • ディレクトリーエントリーを論理的に収集するにはどうすればよいですか?
  • データ管理をサポートするにはどうすればよいですか?
  • グローバル規模でレプリケーションをサポートするにはどうすればよいでしょうか?

さらに、ExampleCom は、サプライヤーや取引先が使用できるエクストラネットを作成し、このエクストラネットを会社のイントラネットの拡張として外部クライアントに実装したいと考えています。

8.2.1. 多国籍企業向けのデータ設計
リンクのコピー

ExampleCom International は、サイト調査を実行するためのデプロイメントチームを作成します。デプロイメントチームは、サイト調査から次の重要なポイントを決定します。

  • メッセージングサーバーは、ほとんどの ExampleCom サイトでメールのルーティング、配信、および読み取りサービスを提供するために使用されます。企業サーバーは、ドキュメント公開サービスを提供します。すべてのサーバーは Red Hat Directory Server 12 上で実行されます。
  • ExampleCom International では、管理者がデータをローカルで管理できるようにする必要があります。たとえば、ヨーロッパのサイトは、ディレクトリーのヨーロッパブランチの管理と、このブランチデータのメインコピーを行います。
  • ExampleCom International のオフィスは地理的に分散しているため、ユーザーとアプリケーションは 24 時間ディレクトリーにアクセスする必要があります。

  • 特定のデータ要素のデータ値は複数の言語で指定する必要があります。

    注記

    すべてのデータは UTF-8 文字セットを使用します。その他の文字セットは LDAP 標準に違反します。

さらに、エクストラネットのデータ設計では、次の条件が満たされていることを確認する必要があります。

  • 部品サプライヤーは、ExampleCom International ディレクトリーにログインして、同社との契約を管理する必要があります。パーツのサプライヤーは、名前やユーザーパスワードなどの、認証に使用するデータ要素に依存します。
  • 取引先は、ディレクトリーを使用して、メールアドレスや電話番号など、パートナーネットワーク内の人々の連絡先の詳細を検索します。

8.2.2. 多国籍企業向けスキーマ設計
リンクのコピー

ExampleCom International は、オリジナルのスキーマ設計を使用し、エクストラネットをサポートするために 2 つの新しいオブジェクトクラスを追加します。

  • exampleSupplier オブジェクトクラスでは、exampleSupplierID 属性が許可されます。この属性には、ExampleCom International が各自動車部品サプライヤーに割り当てる一意の ID が含まれます。
  • examplePartner オブジェクトクラスでは、examplePartnerID 属性が許可されます。この属性には、ExampleCom International が各取引パートナーに割り当てる一意の ID が含まれます。

デフォルトのディレクトリースキーマのカスタマイズに関する詳細は、スキーマのカスタマイズ を参照してください。

8.2.3. 多国籍企業向けディレクトリーツリー設計
リンクのコピー

ExampleCom International は次のディレクトリーツリーを作成します。

図8.6 ExampleCom International の基本ディレクトリーツリー

dg 多国籍企業の例 1
View larger image
dg 多国籍企業の例 1

dc=com 接尾辞はディレクトリーツリーのルートです。この接尾辞の下で、同社は次のブランチを作成します。

  • ExampleCom International の内部データが含まれる dc=exampleCom,dc=com ブランチ。
  • エクストラネットのデータが含まれる dc=exampleNet,dc=com ブランチ。

dc=exampleCom,dc=com の下のイントラネットのディレクトリーツリーには、3 つのメインブランチがあります。各ブランチは、ExampleCom International がオフィスを構えるリージョンの 1 つに対応しています。これらのブランチは、l (locality) 属性を使用して識別されます。

ExampleCom International は、dc=exampleNet,dc=com ブランチの下に次のブランチを作成します。

  • 会社が取引しているサプライヤーの o=suppliers ブランチ。
  • 取引先用の o=partners ブランチ。
  • ou=groups ブランチには、エクストラネットの管理者のエントリーと、自動車部品製造に関する最新情報を得るためにパートナーがサブスクライブするメーリングリストのエントリーが含まれています。
8.2.3.1. ExampleCom International のイントラネット設計
リンクのコピー

dc=exampleCom,dc=com の下の各ブランチは、ローカルエンタープライズ例のディレクトリーツリー設計 からの ExampleCom の元のディレクトリーツリー設計を繰り返します。

図8.7 イントラネットのディレクトリーツリーの例

dg 多国籍企業の例 2
View larger image
dg 多国籍企業の例 2

ExampleCom International は、各地域に次のブランチポイントを作成します。

  • ou=people
  • ou=groups
  • ou=roles
  • ou=resources

l=Asia 地域のエントリーは、LDIF では次のように表示されます。 

dn: l=Asia,dc=exampleCom,dc=com
objectclass: top
objectclass: locality
l: Asia
description: includes all sites in Asia
Copy to Clipboard Toggle word wrap
8.2.3.2. ExampleCom International のエクストラネット設計
リンクのコピー

次の図は、ExampleCom エクストラネットのディレクトリーツリーを示しています。

図8.8 エクストラネットのディレクトリーツリーの例

dg 多国籍企業の例 3
View larger image
dg 多国籍企業の例 3

8.2.4. 多国籍企業向けのトポロジー設計
リンクのコピー

ExampleCom International のデプロイメントチームは、ディレクトリーデータベースとサーバートポロジーの設計を開始します。

8.2.4.1. ExampleCom International のデータベーストポロジー
リンクのコピー

ExampleCom International は、すべての地域で同じトポロジー設計を使用しています。ただし、ヨーロッパ地域には、次のブランチのデータのメインコピーが保存されます。

  • dc=com ルートエントリー
  • dc=exampleCom,dc=com の下のイントラネット
  • dc=exampleNet,dc=com の下のエクストラネット

次の図は、ヨーロッパ地域のデータベーストポロジーを示しています。

図8.9 ExampleCom Europe のデータベーストポロジー

dg 多国籍企業の例 4
View larger image
dg 多国籍企業の例 4

l=Europe データベースには、dc=exampleCom,dc=com および dc=com エントリーのメインコピーが保存されます。

Database link 1 および Database link 2 は、各国にローカルに保存されているデータベースを指します。たとえば、ExampleCom Europe サーバーが l=USA ブランチの下のデータに対して受信する操作要求は、データベースリンクによって米国のサーバー上のデータベースにチェーンされます。データベースリンクとチェイニングの詳細は、チェイニングの使用 を参照してください。

ヨーロッパのサーバーには、エクストラネットのデータのメインコピーが含まれています。エクストラネットデータは、次の方法で 3 つのデータベースに保存されます。

  • Database 1 には、o=suppliers ブランチのメインコピーが保存されます。
  • Database 2 には、o=partners ブランチのメインコピーが保存されます。
  • Database 3 には、ou=groups ブランチのメインコピーが保存されます。

以下の図は、エクストラネットのデータベーストポロジーを示しています。

図8.10 ExampleCom International エクストラネットのデータベーストポロジー

dg 多国籍企業の例 5
View larger image
dg 多国籍企業の例 5
8.2.4.2. ExampleCom International のサーバートポロジー
リンクのコピー

ExampleCom International は、以下のタイプのサーバートポロジーを開発しています。

  • 企業イントラネットのトポロジー。ExampleCom は、ヨーロッパ、米国、アジアの各主要地域に 1 つずつ、合計 3 つのデータセンターを設置することを決定しました。各データセンターには次のサーバーが含まれます。

    • 2 つのサプライヤーサーバー。
    • 2 つのハブサーバー。
    • 3 つのコンシューマーサーバー。
  • パートナーエクストラネットのトポロジー。

以下の図は、ExampleCom Europe データセンターのアーキテクチャーを示しています。

図8.11 ExampleCom Europe のサーバートポロジー

dg 多国籍企業の例 6
View larger image
dg 多国籍企業の例 6

ヨーロッパのデータセンターには、ExampleCom エクストラネットのメインコピーが含まれています。このデータは、米国のデータセンターにある 2 つのコンシューマーサーバーと、アジアのデータセンターにある 2 つのコンシューマーサーバーにレプリケートされます。全体として、ExampleCom ではエクストラネットをサポートするために 10 台のサーバーが必要です。

以下の図は、ヨーロッパデータセンターの ExampleCom エクストラネットのサーバーアーキテクチャーを示しています。

図8.12 ExampleCom International エクストラネットのサーバートポロジー

dg 多国籍企業の例 7
View larger image
dg 多国籍企業の例 7

ハブサーバーは、ヨーロッパ、米国、アジアの各データセンターの 2 つのコンシューマーサーバーにデータをレプリケートします。

8.2.5. 多国籍企業向けのレプリケーション設計
リンクのコピー

ExampleCom International は、ディレクトリーのレプリケーションを設計する際に以下の点を考慮します。

  • データはローカルで管理されます。
  • ネットワーク接続の品質は、サイトごとに異なります。
  • データベースリンクは、リモートサーバー上のデータを接続するために使用されます。
  • データの読み取り専用コピーを含むハブサーバーは、コンシューマーサーバーにデータをレプリケートするために使用されます。

ハブサーバーは、メールサーバーや Web サーバーなどの重要なディレクトリー対応アプリケーションの近くに配置されます。

サプライヤーサーバーが書き込み操作に集中できるように、ハブサーバーのみがレプリケーションを実行します。

将来的に ExampleCom が拡張し、より多くのコンシューマーサーバーを追加する必要がある場合でも、追加のコンシューマーはサプライヤーサーバーのパフォーマンスに影響を与えません。

マルチサプライヤーアーキテクチャー

ExampleCom イントラネットでは、各地域がそのデータのメインコピーを保存し、データベースリンクを使用して他の地域のデータに転送します。

データのメインコピーには、各地域でマルチサプライヤーレプリケーションアーキテクチャーが使用されています。

以下の図は、dc=exampleCom,dc=com および dc=com ブランチを含むヨーロッパ地域のマルチサプライヤーアーキテクチャーを示しています。

図8.13 ExampleCom Europe 向けマルチサプライヤーアーキテクチャー

dg 多国籍企業の例 8
View larger image
dg 多国籍企業の例 8

各地域には 2 つのサプライヤーが含まれており、そのサイトのデータのメインコピーを共有しています。各地域は、その地域のデータのメインコピーに対して責任を負います。

マルチサプライヤーアーキテクチャーを使用すると、データの可用性が確保され、各サプライヤーサーバーによって管理されるワークロードのバランスを取ることができます。

全面的な障害のリスクを軽減するために、ExampleCom は各サイトで複数の読み取り/書き込みサプライヤー Directory Servers を使用しています。

次の図は、ヨーロッパの 2 つのサプライヤーサーバーと米国の 2 つのサプライヤーサーバー間の相互作用を示しています。

図8.14 ExampleCom Europe および ExampleCom USA のマルチサプライヤーアーキテクチャー

dg 多国籍企業の例 9
View larger image
dg 多国籍企業の例 9

ExampleCom USA と ExampleCom Asia の間、および ExampleCom Europe と ExampleCom Asia の間に、同様の関係が存在します。

8.2.6. 多国籍企業向けのセキュリティー設計
リンクのコピー

ExampleCom International は、以前のセキュリティー設計を使用して次のアクセス制御を追加し、新しい多国籍イントラネットをサポートしています。

  • ExampleCom は、一般的な ACI をイントラネットのルートに追加し、各国および各国の下の支社により制限の厳しい ACI を作成します。

  • ExampleCom は、ディレクトリー内の ACI の数を最小限に抑えるために、マクロ ACI を使用することを決定します。

    ExampleCom はマクロを使用して、ACI のターゲットまたはバインドルール部分で DN を表します。ディレクトリーが着信 LDAP 操作を取得すると、ACI マクロは LDAP 操作の対象となるリソースと照合されます。一致した場合、Directory Server はマクロを対象リソースの DN の値に置き換えます。

マクロ ACI の詳細は、マクロアクセス制御命令の使用 を参照してください。

ExampleCom は、エクストラネットをサポートするために次のアクセス制御を追加します。

  • ExampleCom は、すべてのエクストラネットアクティビティーに証明書ベースの認証を使用することを決定します。エクストラネットにログインする場合、ユーザーはデジタル証明書が必要です。ディレクトリーには証明書が保存されます。したがって、ユーザーはディレクトリーに保存されている公開鍵を検索することで、暗号化されたメールを送信できます。
  • ExampleCom は、エクストラネットへの匿名アクセスを禁止する ACI を作成します。これにより、サービス拒否攻撃からエクストラネットを守ることができます。
  • ExampleCom では、ディレクトリーデータの更新が ExampleCom がホストするアプリケーションからのみ行われるようにしたいと考えています。つまり、エクストラネットを使用するパートナーとサプライヤーは、ExampleCom が提供するツールのみを使用できます。エクストラネットユーザーを ExampleCom 推奨ツールに制限することで、ExampleCom 管理者は監査ログを使用してディレクトリーの使用状況を追跡し、ExampleCom International 外部のエクストラネットユーザーによって発生する可能性のある問題の種類を制限できます。

第9章 Directory Server の RFC サポート
リンクのコピー

サポートされている注目すべき LDAP 関連の RFC のリストを見つけます。これは Directory Server がサポートする RFC の完全なリストではないことに注意してください。

9.1. LDAPv3 の機能
リンクのコピー

Technical Specification Road Map (RFC 4510)
これは追跡ドキュメントであり、要件は含まれていません。
The Protocol (RFC 4511)

以下の例外を除いてサポートされます。

Directory Information Models (RFC 4512)

以下の例外を除いてサポートされます。

Authentication Methods and Security Mechanisms (RFC 4513)
サポート対象。
String Representation of Distinguished Names (RFC 4514)
サポート対象。
String Representation of Search Filters (RFC 4515)
サポート対象。
Uniform Resource Locator (RFC 4516)
サポート対象。ただし、この RFC は主に LDAP クライアントに焦点を当てています。
Syntaxes and Matching Rules (RFC 4517)

サポート対象。以下は例外:

  • directoryStringFirstComponentMatch
  • integerFirstComponentMatch
  • objectIdentifierFirstComponentMatch
  • objectIdentifierFirstComponentMatch
  • keywordMatch
  • wordMatch
Internationalized String Preparation (RFC 4518)
サポート対象。
Schema for User Applications (RFC 4519)
サポート対象。
entryUUID Operational Attribute (RFC 4530)
サポート対象。
Content Synchronization Operation (RFC 4533)
サポート対象。

9.2. 認証方法
リンクのコピー

Anonymous SASL Mechanism (RFC 4505)
サポート対象外。RFC 4512 は、ANONYMOUS SASL メカニズムを必要としない点に留意してください。ただし、Directory Server は LDAP 匿名バインドをサポートします。
External SASL Mechanism (RFC 4422)
サポート対象。
Plain SASL Mechanism (RFC 4616)
サポート対象外。RFC 4512 は、PLAIN SASL メカニズムを必要としない点に留意してください。ただし、Directory Server は LDAP 匿名バインドをサポートします。
SecurID SASL Mechanism (RFC 2808)
サポート対象外。ただし、Cyrus SASL プラグインが存在する場合、Directory Server はそれを使用できます。
Kerberos V5 (GSSAPI) SASL Mechanism (RFC 4752)
サポート対象。
CRAM-MD5 SASL Mechanism (RFC 2195)
サポート対象。
Digest-MD5 SASL Mechanism (RFC 2831)
サポート対象。
One-time Password SASL Mechanism (RFC 2444)
サポート対象外。ただし、Cyrus SASL プラグインが存在する場合、Directory Server はそれを使用できます。

9.3. X.509 証明書のスキーマおよび属性サポート
リンクのコピー

LDAP Schema Definitions for X.509 Certificates (RFC 4523)

  • 属性タイプとオブジェクトクラス: サポート対象
  • 構文: サポート対象外(Directory Server はバイナリーおよび octet 構文を使用)
  • 一致規則: サポート対象外

法律上の通知
リンクのコピー

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat