Skip to content

MS_LDAPDirectorySearch

Jump to bottom
nishi_74322014 edited this page Aug 4, 2026 · 1 revision

LDAPプロトコルでのディレクトリ・エントリ検索処理

概要

Lightweight Directory Access Protocol（以下、LDAPと略す）は、
X.500に基づいたディレクトリ サービス上のデータを
参照・操作（追加・更新・削除）するためのプロトコルであるが、
LDAPを使用するには、ディレクトリ サービス、LDAPの構文の知識が必要になる。

そこで本ページでは、LDAPを使用して、ディレクトリ・サーバへアクセスするプログラムを
作成する上で最低限必要となるディレクトリ サービス、LDAP、LDAPの構文について説明した上で、
.NET Frameworkから利用可能なAPIライブラリであるADSI（Active Directory Services Interfaces）
を使用するプログラムについて説明する。

  • ADSI
    • ADSIは、Active Directoryを初めとするLDAPサーバにアクセスする
      Microsoft提供のCOMインターフェイスのセット。
    • ADSIを使用すると、ネットワークの規模にかかわらず、管理者は、
      比較的簡単にネットワーク上のリソースを検索および管理できる。
  • System.DirectoryServices
    .NET Frameworkでは、System.DirectoryServices名前空間が追加され、より使い易くなっている。
    • .NET Framework 2.0では、以下の名前空間が追加されている。
      • Active Directory 関連のプログラミングを容易にする、System.DirectoryServices.ActiveDirectory
      • LDAP関連のプログラミングを容易にする、System.DirectoryServices.Protocols
    • .NET Framework 3.5では、以下の名前空間が追加されている。
      • セキュリティ プリンシパルの管理のプログラミングを容易にする、System.DirectoryServices.AccountManagement

補足（最新化）: 現行の .NET では、System.DirectoryServices と System.DirectoryServices.AccountManagement は Windows 専用 のパッケージとして提供される。 クロスプラットフォームで LDAP を扱う場合は System.DirectoryServices.Protocols（Linux / macOS 対応）を使う。

LDAPの基本事項

LDAPとは？

  • LDAPとはRFC 2251〜2256で定義されている、
    X.500に基づいたディレクトリ サービスを利用するために定められたクライアント・サーバ型のプロトコルであり、
    インターネットやイントラネットなどのTCP/IPネットワーク上で利用することができる。
  • X.500ディレクトリ サービスで定義されるDAP（Directory Access Protocol）は複雑であったため、
    現在、DAPをベースにして軽量化したLDAPがディレクトリ サービス プロトコルの標準となっている。

補足（最新化）: RFC 2251〜2256（LDAPv3 の第1版）は、 現在 RFC 4510〜4519 のシリーズに置き換えられている（RFC 4510 がロードマップ）。 ポートは 389/tcp、LDAPS は 636/tcp。 なお平文 LDAP のシンプル バインドは非推奨で、 Windows Server では LDAP 署名 / チャネル バインディングの強制が既定方向。

LDAPの動作

LDAPを実装した、ディレクトリ サービス（LDAPサーバ）は、
『DIB（Directory Information Base）』と呼ばれるデータベースを保有している。

  • LDAPクライアントは、LDAPプロトコルを使用してLDAPサーバに接続〜質問をする。
  • この質問に対してサーバは回答を返すか、クライアントがさらに情報を探し出せる場所へのポインタを返す。

LDAPシステムの概要図

LDAPの機能

  • 情報の統合管理
    • 組織内で利用する多様な情報（ネットワークを利用するユーザ名やマシン名、
      メールアドレスや環境に関する情報）をディレクトリ サービスに統合できる。
    • 組織内のユーザはネットワーク上のどこからでもアクセスできる。
  • 通信経路暗号化
    通信にSSL/TLSをサポートし、機密データを外部の侵入から保護する。
  • アクセス制御
    PAM/Kerberosなどの認証機構を用いて、ユーザ認証する。
  • ローミングサービス
    どこからでもブックマーク・設定・メールフィルタなどを取り出せるようにできる。

LDAPのAPIライブラリ

元々LDAPはAPI定義も含めた標準仕様であるため、環境を用意しやすく、さまざまなAPIライブラリが存在している。
これらのAPIを利用すれば、LDAPのプロトコルレベルの仕様を知らなくとも簡単に情報の検索や変更処理が実装できる。

  • Microsoft ADSI（Active Directory Service Interface）
    • Active Directoryへアクセスするための、Microsoft提供のCOMインターフェイスのセット。
    • Active Directoryは標準のネットワーク・プロトコルとしてLDAPを使用しているため、
      NDS（Novell社のディレクトリ・サービス）など、他のLDAPサーバにも対応している。
    • また、NTディレクトリ サービスなどを操作するLDAP以外のプロトコルにも対応している。
  • Sun MicroSystems JNDI（Java Naming and Directory Interface）
    • Java 1.2よりJavaの標準ライブラリとして含まれるようになった。
    • JNDIはサービス プロバイダという独自の概念を持っており、
      サービス プロバイダを選択することで、対応するディレクトリが追加可能になっている。
    • LDAPのほかに、DNS、RMI、NDS、NIS のサービス プロバイダが用意されている。
  • Netscape Directory SDK 4.0
    • Netscape CorporationがJavaとC言語で提供するAPI。
    • 本来はNetscape Directory ServerのためのAPI、LDAPにのみ対応する。

LDAPを実装したディレクトリ サービス

  • LDAPを実装した、ディレクトリ サービス（LDAPサーバ）は、
    • ネットワーク環境でネーム サービスを提供するために開発されたDNS、NISなどとは異なり、
      多様な情報を扱う汎用的な情報検索を目的としている。
    • 最近では、単純なユーザ管理だけでなく、プリンタなどの、
      ネットワーク上の共有資源の管理に応用する動きも活発になっている。
  • このように、LDAPサーバでは、何を検索するのか？どういうことが可能になるのか？ということが厳密に決まっていない。
    • LDAPサーバはいくつかのベンダから提供されているが、何を検索できるかは製品ごとに異なる。
    • しかし「登録した情報を検索する」という基本機能は変わらない。

LDAPサーバ ソフトウェア

Active Directory、NTディレクトリ サービス

  • Windows Server に搭載されているディレクトリ サービス（LDAPサーバ）。
    （ライトウェイト ディレクトリ サービス (AD LDS)）
  • Windows OSの機能の多くはActive Directoryを前提に設計されており、重要な機能である。
  • Active Directoryは、Exchange 5.5で使用されていたディレクトリ サービスが原型である。
  • データベース エンジンは、Microsoft Accessなどでも使われているJET（Joint Engine Technology）の拡張版であり、
    現在はESE（Extensible Storage Engine）と呼ばれている。

Red Hat Directory Server

無償である「Fedora Directory Server」の商用版。
「Netscape Directory Server」のテクノロジをベースとしている。

補足（最新化）: Fedora Directory Server は 389 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」に至る。

補足（最新化）: Oracle による Sun 買収後は 「Oracle Directory Server Enterprise Edition」となり、既にサポート終了。

OpenLDAP

  • 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 (Directory Information Tree)

DIT（Directory Information Tree）

本章では、LDAPにおける『DIT』形式でデータの

  • 『エントリ』の特定方法
  • 『エントリ』のデータ構造
  • LDAPで利用される『属性型』
  • エントリのテキスト表現（LDIF）

などについて説明する。

DIT上のエントリを特定する

相対識別名

  • LDAPにおける『エントリ』への名前付けの方法について簡単に説明する。
  • 『エントリ』にはそれぞれ固有の名前を付けることができる。
  • 例えば、下記のような『DIT』の場合、各『エントリ』の名前「A,B,C,D」を、
    『相対識別名』（Relative DN：RDN）と呼ぶ。

エントリと相対識別名

識別名

  • 下記のような『DIT』の場合、同一の『相対識別名』の『エントリ』を名前だけで区別することはできない。
  • こうなると、『相対識別名』だけでは特定の『エントリ』を識別できないので、
    確実に『エントリ』を特定するための手段として、『識別名』（Distinguished Name：DN）を使用する。

エントリと識別名

『識別名』は、上位の『エントリ』の『相対識別名』を「,」を使って全て並べて作成する。
例えば、図の3つの『Ａ』エントリの『識別名』はそれぞれ次のようになる。

  • （※１）の『Ａ』の『識別名』：x,y,A
  • （※２）の『Ａ』の『識別名』：x,z,A
  • （※３）の『Ａ』の『識別名』：x,z,A,E,A

これにより、『DIT』上の『エントリ』を特定することができる。
これで『エントリ』を特定できない場合は、エントリを区別するために、親エントリを追加する必要がある。
また、兄弟で同じ『相対識別名』にすると『エントリ』を区別できなくなるため
兄弟間では同じ『相対識別名』をつけてはいけない。

移行メモ（正誤）: 原文の「Distungnished Name」は Distinguished Name の誤記。
なお実際の LDAP の DN は 末端のエントリから根に向かって 並べ、 区切りは「,」で cn=A,ou=z,o=x のように書く（本文の例は根から末端の順に列挙している）。

エントリのデータ構造

ディレクトリという単語には「人名簿」・「住所録」という意味がある。
実際、ディレクトリ サービスは、「人名簿」・「住所録」などを基に案内をする。
通常、「人名簿」・「住所録」といえば、50音順で構成されている「個人情報」の一覧表を持っている。
各個人情報は「あ行」・「か行」のような行毎に分類され、各「個人情報」が『エントリ』になる。

LDAPに於ける『DIT』では、50音順の一覧ではなく、木構造によって「個人情報」を分類する。

木構造の名簿

LDAPに於ける『DIT』上の『エントリ』の各項目を『属性』と呼ぶ。
木構造では、共通の『属性』が親の『エントリ』に抜き出される特徴があり、
各『エントリ』に登録する情報を集約すると、階層構造をとれなくなる点に注意する。

属性と属性型・属性値

『エントリ』を構成する『属性』は『属性型』（属性の種類）と『属性値』（属性の内容）から構成される。
また、『属性』は、次のように記述する。

  • 属性型:属性値

例えば、『属性』「生年月日」は、「生年月日」という『属性型』と
「○○年○月○日」という『属性値』から構成され、以下のように記述する。

  • 生年月日:○○年○月○日

名前付け属性

『エントリ』の『相対識別名』を表の外に書いた場合、
『相対識別名』を保持するための概念が、『エントリ』の『属性』の他に新たに必要となってしまう。
このため、LDAPでは『相対識別名』を1つの『属性』として管理している。
この『相対識別名』を『属性値』として持つ『属性』を、『名前付け属性』という。

名前付け属性

属性と相対識別名の表記方法の違い

『相対識別名』から『識別名』を生成する場合、
『属性型』の「:」と『属性値』の「:」を区別するため、『相対識別名』は、次のように記述する。

  • 属性型=属性値

例えば、「太郎」の『識別名』を『属性』の表記方法で記述すると次のようになる。

  • 名前: 太郎, 姓: 田中, 情報単位: 家系

これに、『識別名』という『属性』を明記すると以下のようになる。

  • 識別名: 名前: 太郎, 姓: 田中, 情報単位: 家系

この表記では、『属性型』の「:」と、『属性値』の「:」を区別し難い。
このため、『識別名』の『属性値』の要素である『相対識別名』を規定の記述方法で記述する。

  • 識別名: 名前=太郎, 姓=田中, 情報単位=家系

これにより、『識別名』の『属性値』の要素である『相対識別名』の『属性型』が解かり易くなる。

objectClass

『エントリ』の中に自由に情報を書き込めれば、融通がきく側面もあるが、
あまり自由に使用されると、脈絡のない見づらい情報になる。
このため、『エントリ』が保持できる『属性型』の一覧を保持する『属性』を『エントリ』内に埋め込む。
これによって各『エントリ』が保持する『属性型』を定義できる。
なお、LDAPでは、この『属性』の『属性型』を『objectClass』という。

先に示した、個人情報『エントリ』の例では、『属性』として、
『属性型』＝「objectClass」、『属性値』＝「個人情報」を埋め込む。

個人情報エントリのobjectClass

同様に、姓情報『エントリ』の例では、『属性』として、
『属性型』＝「objectClass」、『属性値』＝「姓情報」を埋め込む。

姓情報エントリのobjectClass

MUST属性とMAY属性

『objectClass』は、その『エントリ』に格納する『属性型』を規定するものである。
例えば、「個人情報」という『objectClass』の場合、個人の「名前」・「生年月日」などの『属性』を格納する。

  • 「名前」・「生年月日」などの『属性』は「個人情報」の必要最低限の情報で、
    『エントリ』の中に必ず存在しなければならない。このような属性を『MUST属性』と呼ぶ。
  • 一方、「電話番号」・「備考欄」などの『属性』は「個人情報」の補足的な情報で、
    『エントリ』に必ず存在する必要はない。このような属性のことを『MAY属性』という。
objectClass: 個人情報 ─┬─ 『必須（MUST）属性』 ─→ 「名前」・「生年月日」
                       └─ 『補足（MAY）属性』  ─→ 「電話番号」・「備考欄」

エントリの追加

存在しなかった『属性』が後から必要になる場合がある。
そういう状況に柔軟に対応できるように、LDAPでは、1つの『エントリ』が複数の『objectClass』を保持できるようにしている。
このため、「個人情報」という『objectClass』を保持する『エントリ』に、別の『objectClass』を追加できる。

複数のobjectClass

2つのobjectClass

『objectClass』には2つの種類がある。
ひとつはエントリの大枠を決めるもの、もうひとつはそのエントリに存在する補足情報を決めるものである。

  • 『MUST属性』を決める『objectClass』を『structural objectClass』
  • 『MAY属性』を決める『objectClass』を『auxiliary objectClass』

と呼ぶ。

なお、『structural objectClass』は、エントリの中に必ず存在しなければいけない。
また、（実効的なものが）ふたつ以上あってもいけない。
逆に『auxiliary objectClass』は、エントリ中に何個指定しても良い。

structural objectClass と auxiliary objectClass

上記の例では、

  • 『structural objectClass』は、[objectClass：個人情報]
  • 『auxiliary objectClass』は、[objectClass：電子メール情報]

である。

移行メモ: 原文表記の「structual」は structural の綴り誤り。 また LDAP には第3の種類として abstract objectClass（top など）があり、 単独では使えず他クラスの継承元になる。

LDAPで利用される属性型

標準の属性型

LDAP では、各『エントリ』の『名前付け属性』として、「c」、「o」、「ou」など、
標準的な『名前付け属性』を使用する。
これらは「c」で国を、「o」で組織／会社を、「ou」で組織単位を、「cn」で固有の名称（氏名など）を示す。
この標準的な『名前付け属性』を使用することで、世の中のすべての存在が1つのツリー内で定義することができる。
これは、「組織ツリー」と呼ばれている。

代表的な『名前付け属性』と、対応する『objectClass』を以下に示す。

項番 名前付け属性／その他の属性 オブジェクトクラス 説明
1 objectClass top（共通） そのクラス自身および全ての親クラス
2 c (countryName) country（国） 国の名前
description 〃 国の説明
3 o (organizationName) organization（組織） 組織の名前
l (localityName) 〃 都市、地域
4 ou (organizationalUnitName) organizationalUnit（組織単位） 部署などの名前
l (localityName) 〃 都市、地域

※ 太字が『名前付け属性』（元 Wiki では黄色網掛け）。
※ LDAPで使用される『属性型』の文法と種類は、現在 RFC 4517 / RFC 4519 で定義されている。

移行メモ（正誤）: 原文は属性型の定義を「RFC2552で、種類はRFC2556で定義されている」と していたが、RFC 2252 / RFC 2256 の誤記（RFC 2552・2556 は別物）。 さらにこれらは現在 RFC 4517（構文）/ RFC 4519（スキーマ） に置き換えられている。 また organizationUnitName は正しくは organizationalUnitName、 オブジェクトクラス名も organizationalUnit。

組織ツリー

製品毎の属性型

  • ただし、ディレクトリ サービス（LDAPサーバ）製品毎に『属性』・『名前付け属性』に違いがある。
  • 例えば、LDAP と Active Directory の『名前付け属性』の対応は、以下のようになっている。
項番 LDAP Active Directory
1 c（国） (サポートされていない)
2 o（組織） dc（ドメイン構成要素）
3 ou（組織単位） ou（組織単位）
4 cn（一般名） cn（一般名）
  • Active Directoryの『名前付け属性』を見る限り、「c」（国）、「o」（組織／会社）ではなく、
    「dc」（ドメイン構成要素）で世の中のすべての存在を1つのツリー内で定義しようとしている。
    • 「dc」（ドメイン構成要素）を使用した組織ツリーは、
      別のディレクトリ サービス（LDAPサーバ）製品でも使われており、
      これは「ドメイン構成要素ツリー」と呼ばれている。
  • Active Directoryの『名前付け属性』と、対応する『objectClass』を以下に示す。
項番 名前付け属性 objectClass
1 dc（ドメイン構成要素） domainDNS
2 ou（組織単位） organizationalUnit
3 cn（一般名） user

ドメイン構成要素ツリー

移行メモ（正誤）: 原文は「『dc』という『属性型』はRFC2552でも定義されていない （Active Directoryのマニュアルでは、拡張仕様と表現されている）」としていたが、 dc（domainComponent）は RFC 2247 で標準化されており、 現在は RFC 4519 のスキーマにも含まれる標準属性である。AD 独自の拡張ではない。

LDIF（LDAPデータ交換フォーマット）

『LDIF（LDAPデータ交換フォーマット）』は、
LDAPの『エントリ』を簡単なテキスト形式で表現するために利用される。
LDAPツール（LDAPのAPIライブラリ）は、入出力に『LDIF』を使用する。

  • LDIF は RFC 2849 で定義されている。

LDAPで、ディレクトリを検索する

LDAPは、クライアントからの要求にサーバが応答する、クライアント・サーバ型のプロトコルである。
LDAPシステムは、以下の流れでディレクトリ内を検索する。

＜LDAPの検索オペレーション＞
・LDAPクライアントが、検索条件を指定し、検索要求を送信する。
・要求を受けたLDAPサーバは、その内容に対応する『エントリ』を探索する。
・『エントリ』が見つかったら、さらに指定された『属性』を探索する。
・問い合わせのあった『属性』をクライアントに返却する。

上記の一連の流れを『オペレーション』という。
『オペレーション』には、その内容に応じて複数のパターンが用意されている。
LDAPには、『検索オペレーション』以外に、代表的なものとして
『エントリ』の『追加、変更、削除を行う各オペレーション』、
LDAPサーバを不正に利用させないようにするための『認証オペレーション』がある。
LDAPの場合、認証をするための手続きを バインド という。

検索オペレーションの基本

LDAPには複数の『オペレーション』が存在するが、
ディレクトリ サービスにアクセスするためのプロトコルであることを考慮し、検索用に最適化されている。

『検索オペレーション』では、LDAPクライアントが、検索要求を送信する。
検索要求とは、SQLのSELECT文のような、LDAPサーバの理解できる言葉である。

例えば、以下は、電話番号が03から始まる病院の住所を検索する。
検索要求は、主に2つの引き数『フィルタ式』と『取得する属性』を指定する。

記述 意味
filter: (&(telNumber=03*)(businessCategory=病院))
attribute: cn address		 ⇒ 『フィルタ式』
⇒ 『取得する属性』

『フィルタ式』とはディレクトリの中から対象とする『エントリ』を識別するための条件のことである。
取得する『属性』は、条件に一致した『エントリ』のどの『属性値』を取り出すかを指定する。
※ LDAPで使用される『フィルタ式』の書式は、RFC 4515（旧 RFC 2254）に定義されている。

フィルタ式

filter: (&(telNumber=03*)(businessCategory=病院))

  • 条件１（『属性型』と比較演算子）

    (telNumber=03*)

    この条件は、「03で始まる」電話番号の『エントリ』を検索することを意味する。
    「03*」が「03で始まる」ことを表し、「*」がない場合は「03」そのものを意味する。

  • 条件２（『属性型』と比較演算子）

    (businessCategory=病院)

    「businessCategory」という『属性型』の『属性値』が「病院」である『エントリ』を検索することを意味する。

  • 論理演算子

    (&

    かっこで括られたその後に続くすべての条件がすべて成り立っていなければならないことを表す。
    (&(A)(B)) は A と B の両方の条件にマッチしていなければいけないことを表す。

フィルタ式の演算子

  • 比較演算子

    =   ：属性が指定した内容を持っている。
>=  ：属性値が指定した値より大きいか等しい
<=  ：属性値が指定した値より小さいか等しい
~=  ：属性値が指定した内容に似ている

  • 論理演算子

    &   ：指定した条件がすべて成り立っている
|   ：複数の条件のうち、ひとつが成り立っている
!   ：指定した条件が成り立っていない

取得する属性

必要のない情報まで取り出すと、ネットワークやサーバ、クライアントに余計な負荷をかけてしまう。
そのため、『検索オペレーション』には、『エントリ』を探すための『フィルタ式』に加え、
見つかった『エントリ』のどの『属性』を取得するかを指定できる。

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が複雑すぎるため、こちらが一般的。
  • ADSI (Active Directory Services Interfaces) — マイクロソフト社が提供するLDAPクライアントのAPIライブラリ

データ構造

  • DIB (Directory Information Base) — ディレクトリ サービスのデータ格納先
  • DIT (Directory Information Tree) — ディレクトリ サービスのデータ構造（木構造）
  • エントリ — ディレクトリ サービスのデータ。木構造のノードに当たる。Active Directoryでは、オブジェクトと呼ばれたりもする。
  • 属性 — 『エントリ』上の個々のデータ
    • 属性型：『属性』のデータ型
    • 属性値：『属性』のデータ値
  • 識別名 (Distinguished Name, DN) — 木構造のデータ上で『エントリ』を一意に特定するため、
    親エントリの『相対識別名』を列挙して作成したパス。
  • 相対識別名 (Relative DN, RDN) — 『エントリ』の名前。『名前付け属性』にて命名される。
  • 名前付け属性 — 『エントリ』の名前になる値を保持する属性。
    • 一般的には、cn（一般名）、ou（組織単位）、o（組織）、c（国）がある。
    • Active Directoryでは、cn（一般名）、ou（組織単位）、dc（ドメイン構成要素）がある。
  • objectClass — その『エントリ』に追加できる『属性型』を決定する『エントリ』の型。
  • MUST属性 — エントリに必須の『属性』。『objectClass』によって設定される。
  • MAY属性 — エントリの補足の『属性』。『objectClass』によって設定される。
  • structural objectClass — 上記の『MUST属性』を決める『objectClass』
  • auxiliary objectClass — 上記の『MAY属性』を決める『objectClass』
  • LDIF — LDAPデータ交換フォーマット。

ディレクトリ エントリの検索処理

  • 検索オペレーション — LDAPサーバに対する検索処理の要求。
    これ以外の代表的なオペレーションとして、
    • 『エントリ』の追加、変更、削除を行う各オペレーション
    • クライアントを認証する『認証オペレーション』がある。
  • フィルタ式 — 『検索オペレーション』でLDAPクライアントが使用する検索要求。
  • 検索要求 — SQLのSELECT文のような、LDAPサーバの理解できる言葉。

Active Directory

  • ドメイン — Active Directoryの『ドメイン』の範囲は、
    物理的なネットワーク構造に依存しない、同じ『DIB』を共有する範囲
  • ドメイン コントローラ (DC) — 『ドメイン』を管理するコンピュータ。
  • ドメイン ツリー — 『ドメイン』が階層構造を取った全体の構造。
  • フォレスト — 『ドメイン ツリー』同士で信頼関係を結んだ際の全体の構造。
  • コンテナ・オブジェクト — 『DC』でユーザやPCなどのオブジェクト（エントリ）情報を管理するための入れ物。
    ファイル・システムのフォルダのような役割を持つ。
  • 管理可能なオブジェクト — ユーザやPCなどのオブジェクト（エントリ）の実際の情報を保持するオブジェクトで、
    フォルダ内のファイルのような役割を持つ。

参考

Tags: IT国際標準, Active Directory, 認証基盤, ディレクトリ サービス

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally