「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
Lightweight Directory Access Protocol（以下、LDAPと略す）は、X.500に基づいたディレクトリ サービス上のデータを参照・操作（追加・更新・削除）するためのプロトコルであるが、LDAPを使用するには、ディレクトリ サービス、LDAPの構文の知識が必要になる。そこで本ページでは、LDAPを使用して、ディレクトリ サーバへアクセスするプログラムを作成する上で最低限必要となるディレクトリ サービス、LDAP、LDAPの構文について説明した上で、.NET Frameworkから利用可能なAPIライブラリであるADSI（Active Directory Services Interfaces） を使用し、LDAPを使用して、ディレクトリ・サーバへアクセスするプログラムについて説明する。
- ADSI
- ADSIは、Active Directoryを初めとするLDAPサーバにアクセスするMicrosoft提供のCOMインターフェイスのセット。
- ADSIを使用すると、ネットワークの規模にかかわらず、管理者は、比較的簡単にネットワーク上のリソースを検索および管理できる。
- System.DirectoryServices?
.NET Frameworkでは、System.DirectoryServices?名前空間が追加され、より使い易くなっている。
- .NET Framework 2.0では、以下の名前空間が追加されている。
- ActiveDirectory? 関連のプログラミングを容易にする、System.DirectoryServices?.ActiveDirectory?、
- LDAP関連のプログラミングを容易にする、System.DirectoryServices?.Protocols
- .NET Framework 3.5では、以下の名前空間が追加されている。
- セキュリティ プリンシパルの管理のプログラミングを容易にする、System.DirectoryServices?.AccountManagement?
LDAPの基本事項 †
LDAPとは？ †
- LDAPとはRFC2251～2256で定義されている、
X.500に基づいたディレクトリ サービスを利用するために定められたクライアント・サーバ型のプロトコルであり、
インターネットやイントラネットなどのTCP/IPネットワーク上で利用することができる。
- X.500ディレクトリ サービスで定義されるDAP（Directory Access Protocol）は複雑であったため、現在、
DAPをベースにして軽量化したLDAPがディレクトリ サービス プロトコルの標準となっている。
- RFC2251～2256については、以下のURLを参照のこと。
- RFC2251JP:Lightweight Directory Access Protocol (v3)
LDAPの動作 †
LDAPを実装した、ディレクトリ サービス（LDAPサーバ）は、
『DIB（Directory Information Base）』と呼ばれるデータベースを保有している。
- LDAPクライアントは、LDAPプロトコルを使用してLDAPサーバに接続～質問をする。
- この質問に対してサーバは回答を返すか、クライアントがさらに情報を探し出せる場所へのポインタを返す。
LDAPの機能 †
LDAPクライアント・サーバシステムの機能を簡単に説明する。
- 情報の統合管理
- 組織内で利用する多様な情報（ネットワークを利用するユーザ名やマシン名、メールアドレスや環境に関する情報）をディレクトリ サービスに統合できる。
- 組織内のユーザはネットワーク上のどこからでもアクセスできるディレクトリ サービスに統合でき、必要なユーザが使用できる。
- 通信経路暗号化
通信にSSL/TLSをサポートし、機密データを外部の侵入から保護する。
- アクセス制御
PAM/Kerberosなどの認証機構を用いて、ユーザ認証する。
- ローミングサービス
どこからでもブックマーク・設定・メールフィルタなどを取り出せるようにできる。
つまり、自分自身の設定をどのパソコンからでもできるようにする（Netscapeなど）。
LDAPのAPIライブラリ †
元々LDAPはAPI定義も含めた標準仕様であるため、環境を用意しやすく、さまざまなAPIライブラリが存在している。
これらのAPIを利用すれば、LDAPのプロトコルレベルの仕様を知らなくとも簡単に情報の検索や変更処理が実装できる。
以下は、その中の主なAPIである。
- Microsoft ADSI(Active Directory Service Interface)
- Active Directoryへアクセスするための、Microsoft提供のCOMインターフェイスのセット。
- Active Directoryは標準のネットワーク・プロトコルとしてLDAPを使用しているため、
NDS（Novel社のディレクトリ・サービス）など、他のLDAPサーバにも対応している。
- また、NTディレクトリ サービスなどを操作するLDAP以外のプロトコルにも対応している。
- Sun MicroSystems? JNDI(Java Naming and Directory Interface)
- Java1.2よりJavaの標準ライブラリとして含まれるようになった。
- JNDIはサービス プロバイダという独自の概念を持っており、
サービス プロバイダを選択することで、対応するディレクトリが追加可能になっている。
- 現在ではLDAPのほかに、以下のサービス プロバイダが用意されている。
- DNS
- RMI（Java環境の分散オブジェクト技術）、
- NDS（Novel社のディレクトリ サービス）、
- NIS（Sun Microsystems社の分散ネーミング サービス、ユーザ管理も可能）、
- Netscape Directory SDK 4.0
- Netscape CorporationがJavaとC言語で提供するAPI。
- 本来はNetscape Directory ServerのためのAPI、LDAPにのみ対応する。
- またJNDIのサービス プロバイダとしても対応している。
LDAPを実装したディレクトリ サービス †
- LDAPを実装した、ディレクトリ サービス（LDAPサーバ）は、
- ネットワーク環境でネーム サービスを提供するために開発されたDNS、NISなどとは異なり、
多様な情報（ネットワークを利用するユーザ名やマシン名、メールアドレスや環境に関する情報）を扱う汎用的な情報検索を目的としている。
- 最近では、単純なユーザ管理だけでなく、プリンタなどの、ネットワーク上の共有資源の管理に応用する動きも活発になっている。
- このように、LDAPサーバでは、何を検索するのか？どういうことが可能になるのか？ということが厳密に決まっていない。
- LDAPサーバはいくつかのベンダから提供されているが、何を検索できるかは製品ごとに異なる。
- しかし「登録した情報を検索する」という基本機能は変わらない。
LDAPサーバ ソフトウェア †
LDAPサーバ ソフトウェアには、以下のものがある。
- Windows 2000 Server、Windows Server 2003に搭載されているディレクトリ サービス（LDAPサーバ）。
- Windows OSの機能の多くはActive Directoryを前提に設計されており、重要な機能である。
- Active Directoryは、Exchange5.5で使用されていたディレクトリ サービス（LDAPサーバ）が原型である。
- データベース エンジンは、Microsoft Accessなどでも使われているJET（Joint Engine Technology）の拡張版であり、
現在はESE（Extensible Storage Engine）と呼ばれている。
Red Hat Directory Server †
無償である「Fedora Directory Server」の商用版。
「Netscape Directory Server」のテクノロジをベースとしている。
Sun Java System Directory Server †
- 「Netscape Directory Server」をベースに「iPlanet Directory Server」が作られ、
- Sunが製品群を「Sun ONE」ブランドとして統一した事で名称が変更され「Sun ONE Directory Server」となり、
- 現在の「Sun Java System Directory Server」に至る。
Open LDAP †
- LDAP部分のみの機能を提供する。
- ディレクトリ サービスの機能は、別のサーバと組み合わせる必要がある。
- もともとミシガン大学のSLAPDが原型であり、
オープンソースとしてソースコードが無償で公開されている。
Hitachi Directory Server †
- 日立も「Netscape Directory Server」を元にした、
「Hitachi Directory Server」を開発・販売していた。
- 後に、「iPlanet Directory Server」と技術提携、知識情報および実装技術を共有。
ディレクトリ サービス（LDAPサーバ）の特徴 †
- ディレクトリ サービス（LDAPサーバ）は主に、検索・認証システムなどに使用される。
- 格納されるデータは、ユーザ情報、コンピュータリソースなどが格納される。
- データ構造は木構造（階層型データベース構造）で、
大量の照会あるいは検索操作に即応できるように最適化されている。
- ディレクトリ サービス（LDAPサーバ）と、LDAPの関係は、RDBMSとSQLの関係に似ている。
しかし、ディレクトリ サービスとRDBMSでは、以下の点が異なる。
| 項番 | 項目 | ディレクトリ サービス（LDAPサーバ） | RDBMS |
| 1 | 使用システム | 検索・認証システム | 業務システム（例：流通・会計システム） |
| 2 | 用途 | 格納データの検索 | 格納データの参照・更新 |
| 3 | データ形式 | 木構造 | テーブル（表） |
| 4 | 格納データ | ユーザ情報、コンピュータリソース | 業務データ（例：商品情報、顧客情報） |
| 5 | スキーマ定義 | 標準が存在（スキーマ、プロトコル、API） | スキーマはユーザが決定 |
| 6 | トランザクション | 単純な書き換え | ACID機能を実装 |
ディレクトリ サービス（LDAPサーバ）のデータ構造 †
ディレクトリ サービス（LDAPサーバ）では、
- オブジェクトは『属性』から構成されている。
- オブジェクトは『DIT（Directory Information Tree）』形式の、木構造のデータのノードに配置され、
- 『DIB（Directory Information Base）』と呼ばれるデータベースに保存される。
- また、このオブジェクト（『DIT』のノード）は『エントリ』と呼ばれている。
『DIT』のデータ構造に関する詳細は、本ページ：「ディレクトリ・サービスの基本事項」で詳しく説明する。
DIT（Directory Information Tree） †
以下に、LDAPサーバの『DIT』の例を示す。
本章では、LDAPにおける『DIT』形式でデータの
- 『エントリ』の特定方法
- 『エントリ』のデータ構造
- LDAPで利用される『属性型』
- エントリのテキスト表現（LDIF）
などについて説明する。
DIT上のエントリを特定する †
相対識別名と識別名 †
- LDAPにおける『エントリ』への名前付けの方法について簡単に説明する。
- 『エントリ』にはそれぞれ固有の名前を付けることができる。
- 例えば、下記のような『DIT』の場合、各『エントリ』の名前「A,B,C,D」を、『相対識別名』（RelativeDN：RDN）と呼ぶ。
識別名 †
- 下記のような『DIT』の場合、同一の『相対識別名』の『エントリ』を名前だけで区別することはできない。
- こうなると、『相対識別名』だけでは特定の『エントリ』を識別できないので、
確実に『エントリ』を特定するための手段として、『識別名』（Distungnished Name：DN）を使用する。
『識別名』は、上位の『エントリ』の『相対識別名』を「,」を使って全て並べて作成する。
例えば、図の３つの『Ａ』エントリの『識別名』はそれぞれ次のようになる。
- （※１）の『Ａ』の『識別名』 ：x,y,A、
- （※２）の『Ａ』の『識別名』 ：x,z,A、
- （※３）の『Ａ』の『識別名』 ：x,z,A,E,A
これにより、『DIT』上の『エントリ』を特定することができる。
これで『エントリ』を特定できない場合は、エントリを区別するために、親エントリを追加する必要がある。
また、兄弟で同じ『相対識別名』にすると『エントリ』を区別できなくなるため兄弟間では同じ『相対識別名』をつけてはいけない。
エントリのデータ構造 †
ディレクトリという単語には「人名簿」・「住所録」という意味がある。実際、ディレクトリ サービスは、「人名簿」・「住所録」などを基に案内をする。通常、「人名簿」・「住所録」といえば、50音順で構成されている「個人情報」の一覧表を持っている。各個人情報は「あ行」・「か行」のような行毎に分類され、各「個人情報」が『エントリ』になる。
LDAPに於ける『DIT』では、50音順の一覧ではなく、木構造によって「個人情報」を分類する。
LDAPに於ける『DIT』上の『エントリ』の各項目を『属性』と呼ぶ。木構造では、共通の『属性』が親の『エントリ』に抜き出される特徴があり、各『エントリ』に登録する情報を集約すると、階層構造をとれなくなる点に注意する。例えば、上記のエントリに、「姓情報」という属性を追加すると、親のエントリに「姓情報」を抜き出した、階層構造が取れなくなる。
属性と属性型・属性値 †
『エントリ』を構成する『属性』は『属性型』（属性の種類）と『属性値』（属性の内容）から構成される。また、『属性』は、次のように記述する。
例えば、『属性』「生年月日」は、
- 「生年月日」という『属性型』
- 「○○年○月○日」という『属性値』
から構成され、以下のように記述する。
名前付け属性 †
『エントリ』の『相対識別名』を表の外に書いた場合、『相対識別名』を保持するための概念が、『エントリ』の『属性』の他に新たに必要となってしまう。このため、LDAPでは『相対識別名』を1つの『属性』として管理している。この『相対識別名』を『属性値』として持つ『属性』を、『名前付け属性』という。
属性と相対識別名の表記法方の違い †
『相対識別名』から『識別名』を生成する場合、『属性型』の「:」と『属性値』の「:」を区別するため、『相対識別名』は、次のように記述する。
例えば、「太郎」の『識別名』を『属性』の表記方法で記述すると次のようになる。
これに、『識別名』という『属性』を明記すると以下のようになる。
- 識別名: 名前: 太郎, 姓: 田中, 情報単位: 家系
属性型 属性値
この表記では、『属性型』の「:」と、『属性値』の「:」を区別し難い。
このため、『識別名』の『属性値』の要素である『相対識別名』を規定の記述方法で記述する。
- 識別名: 名前=太郎, 姓=田中, 情報単位=家系
属性型 属性値
これにより、『識別名』の『属性値』の要素である『相対識別名』の『属性型』が解かり易くなる。
objectclass †
『エントリ』の中に自由に情報を書き込めれば、融通がきく側面もあるが、あまり自由に使用されると、脈絡のない見づらい情報になる。このため、『エントリ』が保持できる『属性型』の一覧を保持する『属性』を『エントリ』内に埋め込む。これによって各『エントリ』が保持する『属性型』を定義できる。なお、LDAPでは、『エントリ』が保持できる『属性型』の一覧を保持する『属性』の『属性型』『objectClass』という。
先に示した、個人情報『エントリ』の例では、『属性』として、
『属性型』＝「objectClass」、『属性値』＝「個人情報」を埋め込む。
同様に、姓情報『エントリ』の例では、『属性』として、
『属性型』＝「objectClass」、『属性値』＝「姓情報」を埋め込む。
このように、『objectClass』という『エントリ』が保持できる『属性型』の一覧を保持する『属性』を追加することで、各『エントリ』が保持する『属性』を定義できる。標準的に使用される『属性型』と、それに対応する『objectClass』は既に用意されており、これについては、本ページ：「LDAPで利用される属性型」の「標準の属性型」で説明する。
MUST属性とMAY属性 †
『objectClass』は、その『エントリ』に格納する『属性型』を規定するものである。例えば、「個人情報」という『objectClass』の場合、個人の「名前」・「生年月日」などの『属性』を格納する。
- 「名前」・「生年月日」などの『属性』は「個人情報」の必要最低限の情報で、『エントリ』の中に必ず存在しなければならない。このような属性を『MUST属性』と呼ぶ。
- 一方、「電話番号」・「備考欄」などの『属性』は「個人情報」の補足的な情報で、『エントリ』に必ず存在する必要はない。このような属性のことを『MAY属性』という。
objectClass: 個人情報 ─ ┬ ─ 『必須（MUST）属性』 ─ → 「名前」・「生年月日」
└ ─ 『補足（MAY）属性』 ─ → 「電話番号」・「備考欄」
エントリの追加 †
存在しなかった『属性』が後から必要になる場合がある。そういう状況に柔軟に対応できるように、LDAPでは、１つの『エントリ』が複数の『objectClass』を保持できるようにしている。このため、「個人情報」という『objectClass』を保持する『エントリ』に、別の『objectClass』を追加できる。例えば、「電子メールアドレス情報」という『objectClass』を『エントリ』に追加できる。
２つのobjectclass †
『objectClass』には２つの種類がある。ひとつはエントリの大枠を決めるもの、もうひとつはそのエントリに存在する捕捉情報を決めるものである。
それぞれ、
- 『MUST属性』を決める『objectClass』を『structual objectClass』
- 『MAY属性』を決める『objectClass』を『auxiliary objectClass』
と呼ぶ。
なお、『structual objectClass』は、エントリの中に必ず存在しなければいけない。また、ふたつ以上あってもいけない。逆に『auxiliary objectClass』は、エントリ中に何個指定しても良い。
上記の例では、
- 『structual objectClass』は、[objectClass：個人情報]
- 『auxiliary objectClass』は、[objectClass：電子メール情報]
である。
LDAPで利用される属性型 †
標準の属性型 †
LDAP では、各『エントリ』の『名前付け属性』として、「c」、「o」、「ou」など、標準的な『名前付け属性』を使用する。これらは「c」で国を、「o」で組織／会社を、「ou」で組織単位を、「cn」で固有の名称（氏名など）を示す。この標準的な『名前付け属性』を使用することで、世の中のすべての存在が1つのツリー内で定義することができる。これは、「組織ツリー」と呼ばれている（これには、世界に存在するディレクトリのルートのエントリが1つである必要がある）。
代表的な『名前付け属性』と、対応する『objectClass』を以下に示す。
| 項番 | 名前付け属性
その他の属性 | オブジェクトクラス | 説明 |
| １ | objectClass | top(共通) | そのクラス自身および全ての親クラス |
| ２ | c (countryName) | country(国) | 国の名前 |
| description | 国の説明 |
| ３ | o (organizationName) | organization(組織) | 組織の名前 |
| l (localityName) | 都市、地域 |
| ４ | ou (organizationUnitName?) | organizationUnit(組織単位) | 部署などの名前 |
| l (localityName) | 都市、地域 |
※ 黄色網掛けは、『名前付け属性』
※ LDAPで使用される『属性型』の文法はRFC2552で、種類はRFC2556で定義されている。
- RFC2251JP:Lightweight Directory Access Protocol (v3)
組織ツリー
製品毎の属性型 †
- ただし、ディレクトリ サービス（LDAPサーバ）製品毎に『属性』・『名前付け属性』に違いがある。
- 例えば、LDAP とActive Directoryの『名前付け属性』の対応は、以下のようになっている。
LDAPとActive Directoryの『名前付け属性』の対応
| 項番 | 名前付け属性 |
| LDAP | Active Directory |
| 1 | c（国） | (サポートされていない) |
| 2 | o（組織） | dc（ドメイン構成要素） |
| 3 | ou（組織単位） | ou（組織単位） |
| 4 | cn（一般名） | cn（一般名） |
- Active Directoryの『名前付け属性』を見る限り、「c」（国）、「o」（組織／会社）ではなく、
｢dc｣（ドメイン構成要素）で世の中のすべての存在を1つのツリー内で定義しようとしている。
- ｢dc｣（ドメイン構成要素）という『属性型』はRFC2552でも定義されていない（Active Directoryのマニュアルでは、拡張仕様と表現されている）。
- 特に｢dc｣（ドメイン構成要素）を使用した組織ツリーは、別のディレクトリ サービス（LDAPサーバ）製品でも使われており、
これは「ドメイン構成要素ツリー」と呼ばれている。このように『属性型』は製品毎にある程度変更されている。
| 項番 | 名前付け属性 | objectClass |
| １ | dc（ドメイン構成要素） | domainDns |
| ２ | ou（組織単位） | organizationalUnit |
| ３ | cn（一般名） | user |
ドメイン構成要素ツリー
LDIF（LDAPデータ交換フォーマット） †
『LDIF （LDAPデータ交換フォーマット）』は、
LDAPの『エントリ』を簡単なテキスト形式で表現するために利用される。
LDAPツール（LDAPのAPIライブラリ）は、入出力に『LDIF』を使用する。
『LDIF』による『エントリ』の基本的なテキスト形式については下記URLのページが参考になる。
LDAPで、ディレクトリを検索する †
LDAPは、クライアントからの要求にサーバが応答する、クライアント・サーバ型のプロトコルである。
LDAPシステムは、以下の流れでディレクトリ内を検索する。
＜LDAPの検索オペレーション＞
・LDAPクライアントが、検索条件を指定し、検索要求を送信する。
・要求を受けたLDAPサーバは、その内容に対応する『エントリ』を探索する。
・『エントリ』が見つかったら、さらに指定された『属性』を探索する。
・問い合わせのあった『属性』をクライアントに返却する。
以上が、LDAPで『エントリ』を検索する実際の流れとなる。
上記の一連の流れを『オペレーション』という。『オペレーション』には、その内容に応じて複数のパターンが用意されている。例えば、前述の『オペレーション』は『検索オペレーション』という。LDAPには、『検索オペレーション』以外に、代表的なものとして『エントリ』の『追加、変更、削除を行う各オペレーション』、LDAPサーバを不正に利用させないようにするための『認証オペレーション』がある。LDAPの場合、認証をするための手続きをバインドという。
検索オペレーションの基本 †
LDAPには複数の『オペレーション』が存在するが、ディレクトリ サービスにアクセスするためのプロトコルであることを考慮し、検索用に最適化されている。
『検索オペレーション』では、LDAPクライアントが、検索要求を送信する。
検索要求とは、SQLのSELECT文のような、LDAPサーバの理解できる言葉である。
例えば、以下は、電話番号が03から始まる病院の住所を検索する。
検索要求は、主に2つの引き数『フィルタ式』と『取得する属性』を指定する。
filter: (&(telNumber=03*)(businessCategory=病院))
attribute: cn address | ⇒ 『フィルタ式』
⇒ 『取得する属性』 |
『フィルタ式』とはディレクトリの中から対象とする『エントリ』を識別するための条件のことである。
上記の例でいえば、「03から始まる病院」が『フィルタ式』になる。
取得する『属性』は、条件に一致した『エントリ』のどの『属性値』を取り出すかを指定する。
※ LDAPで使用される『フィルタ式』の書式は、RFC2254に定義されている。
フィルタ式 †
『フィルタ式』の記述方法について詳しく説明する。
filter: (&(telNumber=03*)(businessCategory=病院))
- 条件１（『属性型』と比較演算子）
(telNumber=03*)
この条件は、「03で始まる」電話番号の『エントリ』を検索することを意味する。
「telNumber」という『属性型』の『属性値』が「03で始まる」『エントリ』ということになる。
「03*」が「03で始まる」ことを表し、「*」がない場合は「03」そのものを意味する。
- 条件２（『属性型』と比較演算子）
(businessCategory=病院)
同様に、この条件も「businessCategory」という『属性型』の『属性値』が「病院」である『エントリ』を検索することを意味する。ここには「*」がないため、「病院」そのものを意味する。
これは、かっこで括られたその後に続くすべての条件がすべて成り立っていなければならないことを表す。例えば以下の『フィルタ』があった場合、
(&(A)(B))
これはAとBの両方の条件にマッチしていなければいけないことを表す。
フィルタ式の演算子 †
『フィルタ式』で使える主な演算子を示す。
取得する属性 †
前述の『フィルタ式』を用いて特定の『エントリ』を探し出すことができる。
次に、見つかった『エントリ』の情報を取り出す方法について説明する。
必要のない情報まで取り出すと、ネットワークやサーバ、クライアントに余計な負荷をかけてしまう。
そのため、『検索オペレーション』には、『エントリ』を探すための『フィルタ式』に加え、
見つかった『エントリ』のどの『属性』を取得するかを指定できる。
先程のディレクトリから電話番号が「03」で始まる「病院」で見つかった『エントリ』の、
「名前」と「住所」の『属性』を取り出す検索要求は以下のとおりになる。
filter: (&(telNumber=03*)(businessCategory=病院))
attribute: cn address
LDAPのログ出力 †
WindowsのActive Directoryには、以下の様なログがあるもよう。
サーバーのトレース †
クライアントのトレース †
用語集 †
ディレクトリ サービス（LDAPサーバ）関連 †
- X.500
CCITT（現在のITU－T）とISOにより標準化された仕様。
- LDAPサーバ
ディレクトリ サービスとほぼ同義だが、厳密には、フロントエンドの機能をLDAPサーバ、
バックエンドの機能をディレクトリ サービスと使い分けることもある。
- DAP(Directory Access Protocol)
X.500に基づいたディレクトリ サービス上のデータを参照～操作するためのプロトコル
- LDAP(Lightweight Directory Access Protocol)
DAPの簡易プロトコル。DAPが複雑すぎるため、こちらが一般的。
データ構造 †
- DIB(Directory Information Base)
ディレクトリ サービスのデータ格納先
- DIT(Directory Information Tree)
ディレクトリ サービスのデータ構造（木構造）
- 属性：『エントリ』上の個々のデータ
- 属性型：『属性』のデータ型
- 属性値：『属性』のデータ値
- 識別名(Distungnished Name(DN))
木構造のデータ上で『エントリ』を一意に特定するため、
親エントリの『相対識別名』を列挙して作成したパス。
- 相対識別名(RelativeDN(RDN))
『エントリ』の名前。『名前付け属性』にて命名される。
- 名前付け属性
『エントリ』の名前になる値を保持する属性。
- 一般的には、cn（一般名）、ou（組織単位）、o（組織）、c（国）、がある。
- Active Directoryでは、cn（一般名）、ou（組織単位）、dc（ドメイン構成要素）がある。
- objectClass
その『エントリ』に追加できる『属性型』を決定する『エントリ』の型。
『objectClass』のデータは、エントリの『属性』に保持される。
- MUST属性
エントリに必須の『属性』。『objectClass』によって設定される。
- MAY属性
エントリの補足の『属性』。『objectClass』によって設定される。
- structual objectClass
上記の『MUST属性』を決める『objectClass』
- auxiliary objectClass
上記の『MAY属性』を決める『objectClass』
- LDIF
LDAPデータ交換フォーマット。LDAPの『エントリ』を簡単なテキスト形式で表現する。
一般的にLDAPツール（LDAPのAPIライブラリ）の入出力には『LDIF』が使用される。
ディレクトリ エントリの検索処理 †
- 検索オペレーション
LDAPサーバに対する検索処理の要求。
これ以外の代表的なオペレーションとして、
- 『エントリ』の追加、変更、削除を行う各オペレーション
- クライアントを認証する『認証オペレーション』がある。
- フィルタ式
『検索オペレーション』でLDAPクライアントが使用する検索要求。
- 検索要求
SQLのSELECT文のような、LDAPサーバの理解できる言葉。
- ドメイン コントローラ(DC)
『ドメイン』を管理するコンピュータ。
- ドメイン ツリー
『ドメイン』が階層構造を取った全体の構造。
- フォレスト
『ドメイン ツリー』同士で信頼関係を結んだ際の全体の構造。
- コンテナ・オブジェクト
『DC』でユーザやPCなどのオブジェクト（エントリ）情報を管理するための入れ物。
ファイル・システムのフォルダのような役割を持つ。
- 管理可能なオブジェクト
ユーザやPCなどのオブジェクト（エントリ）の、
実際の情報を保持するオブジェクトで、フォルダ内のファイルのような役割を持つ。
参考 †
Tags: :IT国際標準, :Active Directory, :認証基盤, :ディレクトリ サービス
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
11_DomainComponentTree.png 1220件
[詳細]
10_structualObjClsandAuxiliaryObjCls.png 1059件
[詳細]
9_MultipleObjectClass.png 1108件
[詳細]
8_ObjectClassOfSurnameInformationEntry.png 1050件
[詳細]
7_ObjectClassOfPersonalInformationEntry.png 1193件
[詳細]
6_NamingAttribute.png 1073件
[詳細]
5_RosterOfTheTreeStructure.png 1259件
[詳細]
4_EntryandDN.png 1196件
[詳細]
3_EntryandRDN.png 1070件
[詳細]
2_DIT(DirectoryInformationTree).png 1213件
[詳細]
1_SchematicDiagramOfTheLDAPSystem.png 1090件
[詳細]
