LDAPとは？ わかりやすく10分で解説

LDAP（Lightweight Directory Access Protocol）の概要

LDAP（Lightweight Directory Access Protocol）は、ディレクトリサービスに格納された情報を検索・参照・更新するための通信プロトコルです。ユーザー、グループ、端末、組織、アプリケーション設定などの識別情報や属性情報をまとめて扱い、必要なときに取り出すための共通窓口として使われます。

先に整理すると、LDAPは「製品名」でも「認証方式そのもの」でもありません。LDAPはあくまでディレクトリへアクセスするためのプロトコルであり、実際に情報を保持するのはLDAPでアクセスできるディレクトリサーバーやディレクトリサービスです。ここを混同すると、Active Directoryとの違いや、認証での役割が分かりにくくなります。

LDAPとは何か？

LDAPは、ディレクトリサービスを問い合わせ・操作するためのプロトコルです。LDAPの技術仕様は、X.500のデータモデルやサービスモデルを前提に整理されており、現在のLDAP技術仕様はRFC 4510群で定義されています。

ディレクトリサービスは、情報を階層的に整理し、必要な属性を素早く引けるようにした仕組みです。たとえば、従業員の氏名、メールアドレス、所属部署、役職、グループ所属、端末情報などをまとめて管理し、アプリケーションや認証基盤が同じ情報を参照できるようにします。

LDAPが向くケースと、LDAPだけでは足りないケース

LDAPを理解するときは、できることだけでなく、LDAPだけでは完結しない範囲も押さえたほうが運用判断を誤りにくくなります。

要するに、LDAPは「情報の置き場と引き出し方」を整えるのが得意です。一方で、現代の認証連携で必要になるトークン連携、クラウドSSO、IDライフサイクル管理までをLDAPだけでまかなう設計は無理があります。

LDAPの仕組み

DIT（Directory Information Tree）とは

LDAPの情報は、DIT（Directory Information Tree）というツリー構造で表現されます。ツリー上の各ノードがエントリで、エントリは属性（attribute）と値（value）の集合で構成されます。

この構造により、「どの組織単位に属するか」「どの配下にある情報か」を階層として表しやすくなります。部署ごとの情報、拠点ごとの情報、グループ単位の情報を整理して持ちたい場面と相性が良いのはこのためです。

DN（Distinguished Name）とは

エントリはDN（Distinguished Name）という一意の名前で識別されます。DNはツリー上の位置関係を含むため、そのエントリがどこにあるかまで含めて表現できます。LDAPでは、このDNを手掛かりにバインドや検索、更新を行います。

属性（Attribute）と値（Value）

LDAPはエントリを属性と値で表現します。たとえばユーザーエントリなら、氏名、メールアドレス、所属、電話番号、役職などが属性として入ります。アプリケーション側は必要な属性だけを指定して取得できるため、ユーザー情報を個別のデータベースに重複して持たずに済む構成を取りやすくなります。

スキーマ（Schema）とは

スキーマは、どの種類のエントリが、どの属性を持てるかを定義するルールです。LDAPでは、属性を無秩序に足していくのではなく、どの属性を必須にするか、どのオブジェクトクラスで扱うかをスキーマで管理します。

拡張は可能ですが、独自属性を増やしすぎると、アプリケーション連携や移行時に扱いづらくなります。LDAPは拡張できるからこそ、設計段階で何を共通属性として持つかを先に整理しておく必要があります。

LDAP検索の考え方

LDAP検索では、一般に検索ベースと検索フィルタを指定します。検索ベースは「どの枝から探し始めるか」、検索フィルタは「どの条件で絞り込むか」です。ユーザーIDやメールアドレス、グループ所属を条件に検索し、必要な属性だけを取得する使い方がよく行われます。

LDAPでできること

代表的な操作

LDAPはクライアント／サーバー型のプロトコルで、検索（Search）、追加（Add）、更新（Modify）、削除（Delete）、名前変更や移動（Modify DN）などの操作を扱えます。通信は一般に389番ポートで行われ、TLSを前提としたLDAP over TLS/SSLは一般に636番ポートが使われます。

ただし、運用上よく使われるのは検索と参照だけとは限りません。管理側ではユーザー属性の更新やグループ所属の変更も日常的に発生するため、「LDAPは参照専用」と決めつけると実態を外します。正確には、LDAPは検索にも更新にも使えるプロトコルです。

認証での使われ方

LDAPは、認証方式そのものというより、認証のために参照する情報基盤として使われることが多いプロトコルです。アプリケーションはLDAPサーバーに対してユーザーの存在確認、属性取得、グループ所属の確認、バインドによる照合などを行い、アクセス可否の判断材料にします。

大規模環境では、LDAPのディレクトリ情報を基点にして、シングルサインオンや多要素認証と連携する設計も一般的です。ここでのポイントは、LDAPがトークン発行やフェデレーションの中心になるとは限らず、元になる利用者情報の参照元として機能するケースが多いということです。

アプリケーション開発での使い方

多くのプログラミング言語やミドルウェアにはLDAPクライアントライブラリやAPIが用意されています。これにより、アプリケーション内でユーザー属性の取得、グループ所属の参照、認証連携、権限制御のための属性参照などを実装できます。

アプリごとに個別のユーザーDBを持つ設計は、更新漏れや重複管理を招きやすくなります。LDAPを共通の参照元にすると、属性変更を一か所で反映しやすくなり、運用負荷を下げやすくなります。

LDAPと混同しやすい言葉の違い

特に混同されやすいのが、LDAPとActive Directoryの関係です。Active Directoryはディレクトリサービスの実装であり、LDAPはその情報にアクセスするためのプロトコルです。両者は同義ではありません。

また、「LDAP認証」という言い方は現場ではよく使われますが、技術的には「LDAPを使って認証に必要な情報を参照・照合する」という意味で使われていることが多く、LDAP単独で認証全体を説明しているわけではありません。

LDAPのセキュリティと運用上の注意

TLSと安全な接続

LDAPは平文のままでも通信できるため、認証情報や検索内容を保護するにはTLSを前提にした接続が必要です。代表的な方式として、389番ポートで接続してからTLSへ切り替えるStartTLSと、TLSを前提に接続するLDAPSがあります。

特にSimple Bindを暗号化なしで使う構成は避けるべきです。ユーザー名とパスワードを扱う以上、TLSなしでの運用は情報漏えいのリスクをそのまま抱えます。LDAPを基盤として使うなら、「TLS必須」を前提に設計したほうがよい、というより、そうしない構成を残す理由がありません。

認証方式と権限制御

LDAPでは、Simple Bindのほか、SASLを使う認証方式も扱えます。どの方式を使うかは製品や環境に左右されますが、重要なのは「安全な認証方式を選ぶこと」と「読める属性・書ける属性を分けること」です。

アクセス制御では、アクセス制御リスト（ACL）を用いて、誰が何を読めるか、何を書き換えられるかを細かく制御します。個人情報を含む属性は、全利用者が参照できる前提で設計せず、属性単位で公開範囲を切り分ける必要があります。

可用性と変更管理

LDAPは多くのシステムから参照される基盤になりやすいため、停止時の影響範囲が広くなります。冗長化、バックアップ、監視、変更手順の整備を後回しにすると、障害時の復旧だけでなく、日常の属性追加やスキーマ変更でも混乱しやすくなります。

運用で見落としやすいのは、スキーマ変更の影響です。属性を一つ追加するだけでも、連携先アプリケーションの前提が崩れることがあります。LDAPは基盤寄りの技術なので、変更管理を軽く扱うと後で連携側にしわ寄せが出ます。

クラウド時代のLDAP

クラウド利用が進んでも、LDAPの役割がすぐ消えるわけではありません。オンプレミスにある既存ディレクトリを基点にして運用している組織では、利用者情報の集約元として今も使われています。

一方で、クラウド側の認証・ID連携はLDAPだけで完結しないことが増えています。SAML、OIDC、SCIMなど別の方式が前提になる場面では、LDAPを直接見せるのではなく、LDAPの情報を橋渡しに使う設計が現実的です。

IoTやデバイス管理の文脈でも、識別情報の管理という考え方自体は役に立ちます。ただし、証明書、鍵管理、デバイス固有の認証方式まで含めて考える必要があるため、「主体情報を持てる」という理由だけでLDAPを中心に据えると設計が足りなくなります。

まとめ

LDAPは、ディレクトリサービスに格納されたユーザーやグループなどの情報を検索・参照・更新するためのプロトコルです。製品名ではなく、ディレクトリへアクセスするための共通手順だと捉えると、Active Directoryや認証基盤との関係が整理しやすくなります。

押さえるべき実務上の論点は、DITとDNで情報をどう表すか、スキーマで属性をどう管理するか、認証でどこまでLDAPを使うか、そしてTLSとACLを前提にどう安全に運用するか、の4点です。LDAPは古い技術だから不要なのではなく、役割を切り分けて使うべき基盤技術です。

利用者情報の共通参照元として使うなら今も有効です。ただし、SSOやクラウド連携まで一つで片付けようとせず、LDAPが担う範囲と、別の認証・連携方式が担う範囲を分けて設計する必要があります。

FAQ

Q. LDAPは「製品」ですか？

LDAPはプロトコルです。LDAPでアクセスできるディレクトリサーバー製品やディレクトリサービスは複数あり、LDAPはそれらに共通して使えるアクセス手段です。

Q. LDAPは何の情報を管理するのに向いていますか？

ユーザー、グループ、所属、連絡先、端末、権限判定に使う属性情報などの管理に向いています。複数のシステムから同じ属性を参照したい場面で使いやすい仕組みです。

Q. DITとは何ですか？

DIT（Directory Information Tree）は、LDAPの情報をツリー構造で表現したものです。各ノードがエントリで、階層構造によって所属関係や管理単位を表せます。

Q. エントリは何で構成されていますか？

エントリは属性（attribute）と値（value）の集合で構成されます。ユーザーなら、氏名、メールアドレス、所属、電話番号などが属性として格納されます。

Q. LDAPとActive Directoryは同じものですか？

同じではありません。LDAPはディレクトリにアクセスするためのプロトコルで、Active DirectoryはMicrosoftのディレクトリサービス実装です。Active DirectoryはLDAPを主要なアクセス手段の一つとして使います。

Q. LDAPは認証にどう使われますか？

LDAPは認証情報の参照先として使われることが多く、アプリケーションがユーザーの存在確認や属性取得、バインドによる照合などを行います。認証全体をLDAPだけで完結させるとは限りません。

Q. LDAP通信は暗号化しないと危険ですか？

はい。平文通信のままだと認証情報や検索内容が漏えいする可能性があります。通常はTLSを前提にし、StartTLSまたはLDAPSで保護して運用します。

Q. Simple Bindはそのまま使っても問題ありませんか？

TLSなしで使うのは避けるべきです。Simple Bindは資格情報を扱うため、暗号化されていない接続で使うとリスクが高くなります。

Q. ACLは何のために使いますか？

ACLは、誰がどの属性を読めるか、どこまで書き換えられるかを制御するために使います。個人情報や管理用属性を守るには、属性単位の最小権限設計が欠かせません。

Q. クラウド時代でもLDAPは必要ですか？

ケースによります。既存のオンプレミスのディレクトリを基点にしている組織では今も重要ですが、クラウド側ではSAML、OIDC、SCIMなど別の方式が前提になることも多いため、LDAPの役割を絞って使う設計が現実的です。