1. LDAPとは——ユーザー情報の「電話帳」にアクセスする仕組み
LDAP（Lightweight Directory Access Protocol／ライトウェイト・ディレクトリ・アクセス・プロトコル）は、組織内のユーザー情報やコンピュータ情報などを一元的に管理する「ディレクトリサービス」にアクセスするための標準プロトコルです。読み方は「エルダップ」が一般的です。
イメージとしては、組織の巨大な「電話帳（名簿）」を思い浮かべると分かりやすいでしょう。この電話帳には、社員の名前・所属・メールアドレス・所属グループといった情報が体系的に整理されて格納されています。LDAPは、その電話帳に「この人の情報を教えて」「この人はこのパスワードで合っている？」と問い合わせるための、共通の言葉（プロトコル）です。
LDAPの現在の中核仕様は、IETF（インターネット技術の標準化団体）が定めたRFC 4511（LDAPバージョン3のプロトコル）をはじめとする一連の標準で規定されています。特定のベンダーに縛られない標準プロトコルであるため、さまざまな製品・システムが共通してLDAPに対応しています。
「Lightweight（軽量）」の由来
LDAPの「L」はLightweight（軽量）を意味します。これは、かつて存在した「X.500」という重厚なディレクトリアクセスの仕組みを、より軽量・簡便にしたものとして生まれた経緯によります。「ディレクトリ（情報の整理された保管庫）に、軽量にアクセスするためのプロトコル」というのが、名前の成り立ちです。
2. ディレクトリサービスとLDAPの関係
LDAPを理解するには、「ディレクトリサービス」と「LDAP」の関係を分けて捉えることが大切です。
- ディレクトリサービス：ユーザー・グループ・コンピュータなどの情報を、階層構造で整理して保管するデータベースのような仕組みそのもの。情報の「保管庫」にあたる。
- LDAP：そのディレクトリサービスにアクセスするためのプロトコル（通信の約束事）。保管庫に問い合わせる「共通言語」にあたる。
ディレクトリサービスの情報は、木の枝のような階層構造（ツリー構造）で管理されます。組織を頂点として、その下に部門、さらにその下に個々のユーザー——というように、現実の組織構造を反映した形で情報が整理されます。各エントリは「識別名（DN：Distinguished Name）」という一意の名前で特定されます。
この構造のおかげで、「営業部に所属する全員」「特定のグループのメンバー」といった検索が効率的に行えます。ユーザー情報を各システムがバラバラに持つのではなく、ディレクトリサービスに一元化してLDAPで参照する——これが、ID管理の基本的な考え方の1つです。
3. LDAP認証の仕組み——バインドによる本人確認
LDAP認証とは、ディレクトリサービスに登録された情報を使って、ユーザーの本人確認（認証）を行うことです。多くのシステムが「ログイン時のパスワード確認」をLDAP経由でディレクトリサービスに問い合わせる形で実現しています。
その中心となる操作が「バインド（Bind）」です。バインドとは、LDAPでディレクトリサーバーに接続し、認証を行う操作を指します。典型的な流れは次のとおりです。
- ユーザーがシステムにIDとパスワードを入力する。
- システムは、そのIDに対応するエントリをディレクトリサービスから探す。
- 見つかったエントリの識別名（DN）と、入力されたパスワードを使って、ディレクトリサーバーにバインド（認証）を試みる。
- パスワードが正しければバインドが成功し、認証OKと判断される。誤っていれば失敗する。
この仕組みにより、各システムが個別にパスワードを保持しなくても、ディレクトリサービスに集約されたユーザー情報で認証を一元化できます。パスワードを1か所で管理できるため、変更やロックの管理も効率化されます。
ディレクトリ基盤の認証、見直しませんか？
LDAP・Active Directoryを土台にした認証を、より安全なパスワードレス認証へ。Net Peaceが、既存基盤を活かした認証強化を支援します。
4. Active DirectoryとLDAPの関係
LDAPを語るうえで欠かせないのが、MicrosoftのActive Directory（AD）との関係です。企業でLDAPが使われている場面の多くは、実はActive Directoryが関わっています。
Active Directoryは、Windows環境で広く使われているディレクトリサービスの製品です。そして、そのActive Directoryにアクセス・認証する際の主要なプロトコルの1つがLDAPです。つまり、「Active Directory＝ディレクトリサービスの実体」「LDAP＝それにアクセスするプロトコル」という関係になります。
- ADはLDAPに対応している：Active DirectoryはLDAPをサポートしており、多くのアプリケーションがLDAP経由でADのユーザー情報を使って認証している。
- AD独自の仕組みもある：Windowsのログイン認証などでは、LDAPだけでなくKerberosという別の認証プロトコルも使われる。ADはLDAPとKerberosを組み合わせて動いている。
- 非Windows環境との連携：LinuxサーバーやさまざまなSaaS・業務アプリが、LDAPを介してADのユーザー情報を参照することで、認証を一元化できる。
このように、LDAPは「ADと外部システムをつなぐ共通言語」として、企業のID基盤で重要な役割を果たしています。
5. セキュリティの要——LDAPSと暗号化
LDAP認証を扱ううえで、絶対に押さえておくべきなのが通信の暗号化です。LDAPは、使い方を誤ると認証情報が平文（暗号化されていない状態）でネットワークを流れてしまう危険があります。
| 方式 | ポート | 暗号化 |
|---|---|---|
| LDAP（標準） | 389 | 暗号化なし（平文）※STARTTLSで暗号化に切替可能 |
| LDAPS（LDAP over SSL/TLS） | 636 | 暗号化あり |
標準のLDAPが使うポート389は、そのままでは通信が平文です。パスワードを含むやり取りが平文で流れれば、ネットワーク上で盗聴された場合に認証情報が漏れてしまいます。これを防ぐのがLDAPS（ポート636）で、SSL/TLSによって通信全体を暗号化します。また、標準ポート389のまま通信を暗号化に切り替えるSTARTTLSという仕組みもあります。
「平文LDAP」は避ける
認証情報をやり取りするLDAP通信は、必ず暗号化（LDAPSまたはSTARTTLS）を用いるべきです。暗号化されていない平文のLDAP認証は、盗聴によって認証情報が漏れるリスクを抱えます。既存環境で平文LDAPが残っていないか、一度確認することを強くおすすめします。加えて、匿名でのアクセスや過剰な検索権限を許していないかなど、ディレクトリサーバー側の設定も点検が必要です。
6. LDAPの限界と、これからの認証
LDAPは、ユーザー情報を一元管理し認証を集約する仕組みとして、長年にわたり企業のID基盤を支えてきました。今も多くの組織で現役です。しかし、時代の変化とともに、LDAP認証だけでは十分でない場面も増えています。
- パスワード依存の限界：LDAP認証の多くは、結局のところ「IDとパスワード」による認証。パスワードは、フィッシングや使い回し、漏えいに弱いという根本的な課題を抱える。
- 社内前提の設計：LDAPやADは、もともと「社内ネットワークの中」で使うことを前提に設計されている。クラウドサービスやテレワークが広がった今、社外からの安全なアクセスをどう扱うかが課題になる。
- 多要素認証の必要性：パスワードだけでは不十分な時代になり、多要素認証やパスワードレス認証との組み合わせが求められている。
重要なのは、「LDAPやActive Directoryが古い・悪い」ということではありません。これらは今も価値ある基盤です。ポイントは、その基盤を活かしつつ、パスワードだけに依存しない、より安全な認証へと段階的に強化していくことです。既存のディレクトリ基盤を土台に、フィッシングに強い認証方式を重ねていくアプローチが、多くの企業にとって現実的な進化の道筋になります。
自社の認証がLDAP・ADのパスワード認証に留まっているなら、それを一足飛びに捨てる必要はありません。既存資産を活かしながら、どのように認証の安全性を引き上げていけるか——その道筋を描くことが、これからのID基盤づくりの鍵になります。