LDAPプロトコル、データ階層、およびエントリコンポーネントについて

LDAPシステムのデータ自体は、主にattributesと呼ばれる要素に格納されます。 属性は基本的にキーと値のペアです。 他の一部のシステムとは異なり、キーには、エントリ用に選択されたobjectClassesによって決定される定義済みの名前があります（これについては後で説明します）。 さらに、属性のデータは、属性の初期定義で定義されたタイプと一致する必要があります。

属性の値の設定は、属性名と属性値をコロンとスペースで区切って行います。 電子メールアドレスを定義するmailという属性の例は、次のようになります。

属性とそのデータを参照する場合（設定しない場合）、代わりに等号で2つの側面が結合されます。

属性値には、LDAPシステムに保存してアクセスする実際のデータのほとんどが含まれています。 LDAP内の他の要素は、構造、組織などに使用されます。

属性自体はあまり有用ではありません。 意味を持たせるには、何かを含むassociatedである必要があります。 LDAP内では、entry内の属性を使用します。 エントリは、基本的に何かを記述するために使用される名前の下の属性のコレクションです。

たとえば、システム内のユーザーまたはインベントリ内の各アイテムに対してエントリを作成できます。 これは、リレーショナルデータベースシステムの行またはアドレス帳内の単一ページにほぼ類似しています（ここでの属性は、これらの各モデルのさまざまなフィールドを表します）。 属性は何かの品質または特性を定義しますが、エントリは単に名前の下でこれらの属性を収集することによってアイテム自体を説明します。

LDIF（LDAP Data Interchange Format）に表示されるエントリの例は次のようになります。

上記の例は、LDAPシステム内の有効なエントリです。

LDAPに慣れ始めると、属性によって定義されたデータがオブジェクトに関する利用可能な情報の一部のみを表していることを簡単に認識できます。 残りは、LDAPシステム内でのエントリの配置と、これが意味する関係にあります。

たとえば、ユーザーとインベントリアイテムの両方のエントリを作成できる場合、誰かがそれらを区別する方法を教えてください。 異なるタイプのエントリを区別する1つの方法は、関係とグループを確立することです。 これは主に、エントリが作成されたときに配置される場所の機能です。 エントリはすべて、Data Information TreesまたはDITsと呼ばれるツリー上のブランチとしてLDAPシステムに追加されます。

DITは、各エントリ（最上位エントリ以外）に1つの親エントリがあり、その下に任意の数の子エントリがあるファイルシステムに似た組織構造を表します。 LDAPツリーのエントリはほぼ何でも表すことができるため、ファイルシステム内のディレクトリと同様に、いくつかのエントリは主に組織的な目的で使用されます。

このようにして、「人」のエントリと「在庫アイテム」のエントリを作成できます。 実際のデータエントリをこれらの子として作成して、タイプをより適切に区別できます。 組織のエントリは、データを最もよく表すように任意に定義できます。

前のセクションのエントリ例では、dn行にDITの1つの表示があります。

この行はエントリの識別名と呼ばれ（詳細は後述）、エントリを識別するために使用されます。 これは、DITのルートに戻るフルパスのように機能します。 この例では、作成しているsn=Ellingwoodというエントリがあります。 直接の親はou=peopleと呼ばれるエントリであり、おそらく人を説明するエントリのコンテナとして使用されています。 このエントリの親は、DITのルートとして機能するdigitalocean.comドメイン名から派生しました。

属性は、かなり複雑な構文を使用して定義されます。 属性の名前、属性を参照するために使用できる他の名前、入力できるデータの種類、およびその他のさまざまなメタデータを示す必要があります。 このメタデータは、属性を説明し、LDAPに属性の値をソートまたは比較する方法を指示し、他の属性とどのように関連するかを伝えることができます。

たとえば、これはname属性の定義です。

'name'は属性の名前です。 最初の行の番号は、他のすべての属性と区別するために属性に割り当てられたグローバルに一意のOID（オブジェクトID）です。 エントリの残りの部分は、検索中にエントリを比較する方法を定義し、属性のデータ型要件に関する情報の場所を示すポインタがあります。

属性定義の重要な部分の1つは、エントリで属性を複数回定義できるかどうかです。 たとえば、姓はエントリごとに1回しか定義できないと定義できますが、「niece」の属性を使用すると、1つのエントリでその属性を複数回定義できます。 属性はデフォルトで複数値であり、エントリごとに1回しか設定できない場合は、SINGLE-VALUEフラグを含める必要があります。

属性の定義は、属性の使用と設定よりもはるかに複雑です。 幸いなことに、ほとんどのLDAP実装には最も一般的な属性が含まれており、他の属性は簡単にインポートできるため、ほとんどの場合、独自の属性を定義する必要はありません。

属性は、objectClassesと呼ばれるエンティティ内に収集されます。 ObjectClassesは、特定の事柄を記述するのに役立つ関連属性の単純なグループ化です。 たとえば、「person」はobjectClassです。

エントリは、objectClassと呼ばれる特別な属性を設定し、使用するobjectClassに名前を付けることで、objectClassの属性を使用できるようになります。 実際、objectClassは、追加のobjectClassを指定せずにエントリに設定できる唯一の属性です。

したがって、objectClass person（またはpersonから派生したより具体的なperson objectClassesのいずれか-これについては後で説明します）を含む、personを説明するエントリを作成する場合、そのobjectClass内のすべての属性を使用できます。

その後、エントリ内でこれらの属性を設定できます。

異なるobjectClassesの属性が必要な場合は、objectClass属性を複数回使用できますが、許容できるものを指定するルールがあります。 ObjectClassesは、いくつかの「タイプ」の1つとして定義されています。

ObjectClassの2つの主なタイプは、structuralまたはauxiliaryです。 エントリmustには、構造クラスが1つだけありますが、クラスで使用可能な属性を拡張するために使用される補助クラスが0個以上ある場合があります。 構造objectClassは、エントリの作成と定義に使用されますが、補助objectClassesは、追加の属性を通じて機能を追加します。

ObjectClass定義は、それらが提供する属性が必須（MUST仕様で示される）かオプション（MAY仕様で示される）かを決定します。 複数のobjectClassesが同じ属性を提供でき、属性のMAYまたはMUSTの分類はobjectClassごとに異なる場合があります。

例として、personobjectClassは次のように定義されます。

これは、構造的なobjectClassとして定義されます。つまり、エントリの作成に使用できることを意味します。 作成されたエントリmustは、surnameおよびcommonname属性を設定し、userPassword、telephoneNumber、seeAlso、またはdescription属性。

次に、ObjectClass定義と属性定義は、schemaと呼ばれる構造にグループ化されます。 従来のリレーショナルデータベースとは異なり、LDAPのスキーマは、関連するobjectClassesおよび属性の単なるコレクションです。 単一のDITは、必要なエントリと属性を作成できるように、多くの異なるスキーマを持つことができます。

スキーマには多くの場合、追加の属性定義が含まれ、他のスキーマで定義された属性が必要になる場合があります。 たとえば、上記で説明したperson objectClassでは、person objectClassを使用するすべてのエントリにsurnameまたはsn属性を設定する必要があります。 これらがLDAPサーバー自体で定義されていない場合、これらの定義を含むスキーマを使用して、これらの定義をサーバーの語彙に追加できます。

スキーマの形式は、基本的には次のように上記のエントリの単なる組み合わせです。

DITは、単に既存のエントリの関係を記述する階層です。 作成時に、各新しいエントリは、既存のエントリの子として自身を配置することにより、既存のDITに「フック」する必要があります。 これにより、関係の定義と意味の割り当てに使用されるツリーのような構造が作成されます。

DITの最上位は、後続の各ノードが何らかの形で子孫となる最も広いカテゴリです。 通常、一番上のエントリは、DITが使用される組織を示すラベルとして単に使用されます。 これらのエントリは、任意のobjectClassesにすることができますが、通常、ドメインコンポーネント（example.comに関連付けられた情報を管理するLDAPの場合はdc=example,dc=com）、場所（組織またはセグメントのl=new_york,c=us）を使用して構築されます。 NY）、または組織セグメント（ou=marketing,o=Example_Co）。

編成に使用される（フォルダーのように使用される）エントリーは、多くの場合、organizationalUnit objectClassを使用します。これにより、ou=と呼ばれる単純な説明属性ラベルを使用できます。 これらは、トップレベルのDITエントリの下の一般的なカテゴリによく使用されます（ou=people、ou=groups、ou=inventoryなどが一般的です）。 LDAPは、ツリー内の上下ではなく、ツリーに沿って横方向に情報を検索するために最適化されているため、一般的な組織の枝と特定の属性の割り当てによってさらに細分化されたDIT階層をやや浅くすることが最善です。

エントリはその属性によって参照されます。 つまり、各エントリには、DIT階層のレベルで明確な属性または属性のグループが必要です。 この属性または属性のグループは、エントリのrelative distinguished nameまたはRDNと呼ばれ、ファイル名のように機能します。

エントリを明確に参照するには、エントリのRDNをその親エントリのすべてのRDNと組み合わせて使用​​します。 このRDNのチェーンは、DIT階層の最上部に戻り、問題のエントリへの明確なパスを提供します。 このRDNのチェーンをエントリのdistinguished nameまたはDNと呼びます。 LDAPシステムが新しいエントリを配置する場所を認識し、エントリのRDNが別のエントリによって既に使用されていないことを確認できるように、作成中にエントリのDNを指定する必要があります。

類推として、ファイルシステムで見られるように、相対ファイル名またはディレクトリ名としてRDNを考えることができます。 一方、DNは絶対パスにより類似しています。 重要な違いは、LDAP DNにはleft-hand側に最も具体的な値が含まれ、ファイルパスにはright-hand側に最も具体的な情報が含まれることです。 DNは、コンマでRDN値を区切ります。

たとえば、John Smithという名前の人のエントリは、example.comの下の組織の「People」エントリの下に配置される場合があります。 組織には複数のJohn Smithが存在する可能性があるため、エントリのRDNにはユーザーIDの方が適している場合があります。 エントリは次のように指定できます。

このインスタンスのuid属性にアクセスするには、inetOrgPerson objectClassを使用する必要がありました（person objectClassで定義されているすべての属性には、引き続きアクセスできます。次のセクション）。

各objectClassは、そのタイプのオブジェクトの特性を記述するクラスです。

ただし、単純な継承とは異なり、LDAPのオブジェクトは複数のクラスのインスタンスになり得ます（多くの場合、プログラミング言語によっては、複数の継承を通じて同様の機能を提供します）。 これが可能になるのは、クラスのLDAPの概念が、MUSTまたはMAYを持つ属性の単なるコレクションであるためです。 これにより、エントリに複数のクラスを指定でき（ただし、1つのSTRUCTURAL objectClassのみが存在でき、存在する必要があります）、オブジェクトは、最も厳密なMUSTまたはMAY宣言が優先されるマージされた属性のコレクションにアクセスできます。

その定義では、objectClassは、属性を継承する親objectClassを識別できます。 これは、SUPとそれに続く継承元のobjectClassを使用して行われます。 たとえば、organizationalPersonobjectClassは次のように始まります。

SUP識別子に続くobjectClassは、親objectClassです。 親は、定義されているobjectClassのobjectClassタイプを共有する必要があります（たとえば、STRUCTURALまたはAUXILIARY）。 子objectClassは、親の属性と属性要件を自動的に継承します。

エントリでobjectClassを割り当てる場合、継承チェーンの最も具体的な子孫を指定するだけで、属性に完全にアクセスできます。 前のセクションでは、これを使用して、personおよびorganizationalPerson objectClassesで定義された属性にアクセスしながら、John Smithエントリの唯一のobjectClassとしてinetOrgPersonを指定しました。 inetOrgPersonの継承階層は次のようになります。

ほとんどすべてのobjectClass継承ツリーは、「top」と呼ばれる特別なobjectClassで終わります。 これは抽象objectClassであり、その唯一の目的は、objectClass自体の設定を要求することです。 継承チェーンのトップを示すために使用されます。

同様に、属性自体は定義中に親属性をリストできます。 属性は、親属性で設定されたプロパティを継承します。

これは、一般的な属性のより具体的なバージョンを作成するためによく使用されます。 たとえば、姓は名前の一種であり、同じメソッドをすべて使用して、等しいかどうかを比較およびチェックできます。 これらの品質を継承して、「名前」属性の一般的な形式を取得できます。 実際、実際の姓の定義には、親属性へのポインタ以外はほとんど含まれていません。

これは、一般的な形式が変更されていない場合でも、要素を解釈する人にとって役立つ特定の属性を作成できるため便利です。 ここで説明したsurname属性の継承は、人々が名前とより一般的な名前を区別するのに役立ちますが、値の意味を除いて、LDAPシステムの名前と名前の間にほとんど違いはありません。