LDAP（Lightweight Directory Access Protocol）は1993年、ミシガン大学のTim Howesらが提案したディレクトリサービス用の問い合わせプロトコルです。X.500ディレクトリの重厚なDAP（Directory Access Protocol）をTCP/IP上で軽量に使えるよう簡素化したもので、当初は「LightweightなDAP」という意味でこの名が付きました。ユーザー、グループ、組織単位（OU）、デバイスなどを階層的な木構造で管理し、Active DirectoryやOpenLDAP、FreeIPAなど企業内ディレクトリ基盤の共通インターフェースとして30年以上使われ続けています。
この記事の目次
- ツリー構造とDN・属性の世界
- X.500からLDAP、そしてActive Directory
- 認証連携・アドレス帳・SSOの基盤
- SCIMやIdP API、NoSQLとの比較
- まとめ
ツリー構造とDN・属性の世界
LDAPディレクトリは「ディレクトリ情報木（DIT）」と呼ばれる階層構造で、エントリの位置を識別名（DN：Distinguished Name）で表します。例えば「cn=John Smith,ou=Sales,dc=example,dc=com」のように、cn（共通名）、ou（組織単位）、dc（ドメイン構成要素）を右から左へ繋げて完全パスとし、コンマで区切ります。各エントリは複数の属性（attribute）を持ち、objectClassで「inetOrgPerson」などのスキーマを指定すると、mail、telephoneNumber、memberOfといった属性が使えるようになります。
問い合わせはASN.1のBERエンコードで行われ、ldapsearchコマンドなら「ldapsearch -x -b 'dc=example,dc=com' '(uid=jsmith)'」のようにフィルタ式を渡します。プロトコル自体は389/TCP（平文）または636/TCP（LDAPS、TLS）、もしくは389番でStartTLSを使って暗号化します。ベンダーごとに認証バインド方式（simple、SASL、GSSAPI、EXTERNALなど）が用意されており、Active DirectoryではKerberos GSSAPIバインドが、OpenLDAPではsimple + StartTLSが一般的に使われます。
X.500からLDAP、そしてActive Directory
前身となるX.500は1988年にITU-Tが勧告した壮大なディレクトリ標準で、OSIプロトコルスタック上で動くDAPを使う設計でした。しかしOSIスタックの普及が進まず、TCP/IPのインターネットが現実の主役となるにつれて、「X.500ディレクトリにTCP/IPから直接問い合わせたい」というニーズが高まりました。ミシガン大学のTim HowesがX.500のフロントエンドとして設計したLDAPv1がRFC 1487（1993年）として公開され、v2（RFC 1777）を経て1997年12月にLDAPv3（RFC 2251）として完成されたのが現行版です。
Microsoftは2000年2月リリースのWindows 2000 Serverで、それまでのNT4ドメインを置き換える次世代ディレクトリ「Active Directory」を投入し、その問い合わせインターフェースとしてLDAPv3を採用しました。Tim Howesは1996年にNetscapeへ移籍してNetscape Directory Serverを開発し、これが後にSun ONE Directory Server、Red Hat Directory Server、389 Directory Server、FreeIPAへと枝分かれします。オープンソースではミシガン大学発のOpenLDAPが1998年から開発され、Linux系サーバーの標準ディレクトリとして今も使われています。
認証連携・アドレス帳・SSOの基盤
LDAPの主用途はユーザー認証・認可の集中管理です。Linuxサーバーでは、PAM経由でLDAPバインドを行い、/etc/passwdに依らず社内ディレクトリの認証情報でログインを許可する構成が定番です。WebアプリではAtlassian Confluence/Jira、GitLab、Jenkins、Grafana、NextcloudなどがLDAP認証バックエンドを内蔵しており、「社員ID/パスワードで全社の業務ツールを使い回す」という体験を可能にしています。
メールクライアントのアドレス帳機能もLDAP参照が標準で、OutlookやThunderbird、Apple Mailから社内ディレクトリを検索して連絡先を引けます。802.1X認証のRADIUSサーバー（FreeRADIUSなど）もユーザーDBとしてLDAPを参照し、Wi-FiやVPN接続時の本人確認に使われます。管理者の悩みどころはスキーマ拡張で、社内独自の属性（社員番号、所属コード、入社日など）を追加するためにはobjectClassの定義変更が必要になり、運用が複雑化しがちです。とはいえ、「企業に1つは必ずある中央ディレクトリ」のクエリ言語として、LDAPの地位は揺らいでいません。
SCIMやIdP API、NoSQLとの比較
クラウド時代の対抗馬として、2011年にSCIM（System for Cross-domain Identity Management、RFC 7642〜7644）が登場しました。RESTful APIとJSONでユーザー・グループのプロビジョニングを行う仕組みで、Okta、Azure AD、Google WorkspaceなどのクラウドIdPが対応しています。LDAPがBERエンコードのバイナリプロトコルで、ファイアウォール越しに使いにくいのに対し、SCIMはHTTPS上で動くため、SaaS間のID同期に向きます。Microsoft Graph APIもクラウド版のAzure AD/Entra IDの現代的なクエリインターフェースとして広く使われるようになりました。
それでもLDAPが消えない理由は、オンプレミスでの実績と互換性です。社内の認証連携、Linuxサーバー認証、ネットワーク機器、プリンタなど、組織内のあらゆる機器がLDAPクライアントを内蔵しているため、入れ替えのコストが膨大です。Microsoft自身もEntra ID（旧Azure AD）でクラウドネイティブAPIへ重心を移しつつ、「Azure AD Domain Services」でクラウド上のLDAP/Kerberos互換を提供するなど、LDAP互換性を捨てきれていません。オンプレはLDAP、クラウドはSCIM/Graphという棲み分けが今後しばらく続くと見られています。
まとめ
LDAPはX.500の重厚さをTCP/IPで軽量化したディレクトリ問い合わせ標準として、30年にわたり企業の認証基盤を支えてきました。Active DirectoryやOpenLDAPの中核プロトコルとして、Linux認証からSSO連携まで実装は揺るぎなく、クラウド時代のSCIMやMicrosoft Graphと共存しながら、オンプレ世界の共通言語であり続けています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント