LDAPとは？ディレクトリサービスの仕組みとActive Directory・認証連携を実装視点で解説

LDAP（Lightweight Directory Access Protocol）は、ユーザーや端末の情報を階層構造で管理するディレクトリサービスへ、検索や認証のために問い合わせる標準プロトコルです。この記事では、DN・DIT・objectClassといったデータモデルの読み解き方から、bind・searchの操作と検索フィルタの構文、Active Directoryとの正確な関係、LDAPS／StartTLSによる暗号化、そして自前LDAPを採るべき場面とSAML／OIDCのフェデレーションへ寄せるべき場面の判断まで、認証基盤を設計する開発者が実装に落とせる粒度で整理します。社内システムのログインをディレクトリに束ねたい担当者や、既存ADと業務アプリを連携させる技術者が対象です。

まとめ：LDAPはディレクトリへ問い合わせる標準プロトコルという要点と実装勘所

LDAPは「ディレクトリという階層型データベースへアクセスする手順」を定めたプロトコルであり、ディレクトリそのものではありません。ここを分けて捉えると、Active Directoryとの関係もすっきり整理できます。ADはディレクトリサービスという製品で、その中身へLDAPという共通言語で問い合わせる、という主従関係になっています。情報はツリー（DIT）で保持し、各エントリは`cn=yamada,ou=Sales,dc=example,dc=com`のようなDN（識別名）で一意に指し示す形です。

実装の勘所は、認証と暗号化の2点に集約されます。アプリからのユーザー認証は「サービスアカウントでbindしてユーザーのDNを検索し、そのDNで再bindを試みる」流れが定石で、ここで検索フィルタへ入力値を素通しするとLDAPインジェクションを招きます。通信は平文の389番ではなくLDAPS（636番）かStartTLSでTLS化するのが前提です。新規に認証基盤を組むなら、社内アプリはLDAP／ADに束ね、社外向けやSaaS連携はSAML／OIDCのフェデレーションへ委ねる、という役割分担が現実的な設計になります。

LDAPの基本とディレクトリサービス・階層型データモデルの考え方

LDAPを扱う近道は、「プロトコル」と「ディレクトリのデータ構造」を別々に理解することです。この2つを押さえれば、AD連携も認証実装も同じ土台の上で考えられます。

LDAPの定義とディレクトリサービス・「Lightweight」が指す軽量化

LDAPは、ネットワーク上のディレクトリサービスへ問い合わせるためのプロトコルです。ディレクトリサービスとは、ユーザー・グループ・端末・プリンタといった組織内の情報を一元管理する、いわば電話帳のような仕組みを指します。読み取りが圧倒的に多く、更新が少ないという特性に合わせて設計されており、リレーショナルデータベースとは用途が分かれます。

名前の「Lightweight（軽量）」は、元となったX.500ディレクトリのアクセスプロトコルDAPが重厚だったことへの対比です。DAPがOSIの通信スタックを前提としたのに対し、LDAPはTCP/IP上で直接動く簡略版として設計されました。現在広く使われるのはLDAPv3（RFC 4510系）で、標準ポートは平文が389番、TLSで保護するLDAPSが636番と決まっています。

DIT・DN・エントリ・objectClassというLDAPのデータモデル

LDAPのデータは、DIT（Directory Information Tree）と呼ばれるツリー構造で保持されます。ツリーの各ノードが1件のエントリで、エントリはメールアドレスや所属といった属性（attribute）の集まりです。ツリーの頂点はドメインを表すdc（domain component）で始まり、組織単位のou（organizational unit）を挟み、末端に個々のユーザーcn（common name）が並びます。

各エントリを一意に指す住所がDN（Distinguished Name）です。末端の1階層だけを表すRDN（Relative Distinguished Name）を、根まで連結したものがDNにあたります。どんな属性を持てるかはobjectClassが定義し、たとえばinetOrgPersonクラスならmailやtelephoneNumberを持てる、という具合にスキーマで縛られます。

LDAPとActive Directoryの関係と、自前・クラウドのディレクトリ選択

実務で最も混同されるのが、LDAPとActive Directoryの関係です。ここを製品とプロトコルの主従で整理し、どのディレクトリ実装を選ぶかの判断につなげます。

Active DirectoryはLDAPを実装したディレクトリ製品という主従関係

「LDAPとADのどちらを使うか」という問いの立て方自体が、実は噛み合っていません。LDAPはディレクトリへ話しかけるための共通言語で、ADはその言語を話せるディレクトリサービス製品の一つ、という関係だからです。ADはLDAPインターフェースを備えつつ、Windows環境向けにKerberos認証やグループポリシー（GPO）を独自に足した統合基盤になっています。

そのため、業務アプリからADのユーザー情報を引く場合も、通信そのものはLDAP（既定で389／636番）で行います。OpenLDAPのような純粋なLDAPサーバはクロスプラットフォームで軽量な一方、ADはWindows端末の一元管理まで踏み込むぶん構成は重めです。「LDAP＝プロトコル、AD＝それを実装した製品」と押さえれば、両者は比較対象ではなく層が違うと分かります。

OpenLDAP・Active Directory・クラウドディレクトリを選び分ける基準

ディレクトリの実装は、運用主体と対象環境で選び分けます。Linux中心でシンプルな認証基盤を自前で持ちたいならOpenLDAPや389 Directory Server、Windows端末とファイルサーバまで統合管理するならAD、という切り分けが出発点です。クラウド前提なら、オンプレADの設計をそのまま持ち込まず、マネージドサービスへ寄せる選択肢が増えています。

Azure／Microsoft 365環境なら、クラウドのIDaaSであるMicrosoft Entra ID（旧Azure AD）が候補になります。ただしEntra IDは従来型LDAPを直接は話さない設計で、既存のLDAP依存アプリを載せるにはEntra Domain Servicesなどの別レイヤが要る点に注意が必要です。AWS上で従来のADをそのまま使いたい場合は、AWS Managed Microsoft ADのようなマネージドADが、パッチ適用や冗長化の運用負担を肩代わりします。自前運用かマネージドかは、可用性要件と運用工数の天秤で決めるのが妥当です。

LDAPの通信と認証の仕組みをbind・検索・暗号化から捉える実装ポイント

ディレクトリの構造がつかめたら、次はアプリからどう問い合わせ、どう認証するかです。ここは設計を誤るとセキュリティ事故に直結するため、操作と暗号化を具体的な手順で押さえます。

bind・searchとスコープ・LDAP検索フィルタの構文

LDAPの操作は、いくつかの基本コマンドで構成されます。接続後にまずbind（認証）を行い、search（検索）でエントリを引き、必要に応じてadd／modify／delete／compareで更新し、unbindで切断する流れです。中心はsearchで、検索の起点となるbase DN、探索範囲を決めるスコープ、絞り込み条件のフィルタの3点を指定します。

スコープはbase（起点エントリのみ）・one（直下の子のみ）・sub（配下すべて）の3種です。フィルタはRFC 4515で定義された前置記法で書き、属性と条件を丸括弧で囲みます。たとえば「Sales部門のyamada」を探すなら次のように組み立てます。

(&(objectClass=inetOrgPerson)(ou=Sales)(cn=yamada))

先頭の&はAND条件、|はOR、!はNOTを表します。この構文は文字列連結で組み立てるため、後述するインジェクション対策の対象になります。

simple bindとSASL・匿名バインドとLDAPインジェクションの注意点

認証にあたるbindには、大きく2方式があります。DNとパスワードを直接送るsimple bindと、Kerberosなどの外部認証機構と連携するSASL bindです。simple bindはパスワードを平文で送るため、TLSでの保護が前提になります。アプリのログイン実装では「サービスアカウントでbind→ユーザーDNをsearch→そのDNで再度simple bindを試行し、成功なら認証成立」という二段構えが定番のパターンです。

ここで2つの落とし穴を避けます。1つは匿名バインド（anonymous bind）で、認証情報なしの接続を許すと、ディレクトリの内部構造や属性を外部から列挙されかねません。用途がなければ無効化します。もう1つがLDAPインジェクションです。ユーザー入力を検索フィルタへそのまま連結すると、*や)を注入されて認証回避や情報漏えいを招きます。入力値は特殊文字をエスケープするか、パラメータ化に対応したライブラリ経由で組み立て、フィルタへ生の文字列を差し込まない実装にします。

LDAPS（636番）とStartTLS（389番）による通信の暗号化

LDAPは既定では平文で通信するため、認証情報や属性がそのまま流れます。これをTLSで保護する方法が2通りあります。1つはLDAPS（LDAP over TLS）で、636番ポートに接続した時点からTLSで暗号化する方式です。もう1つがStartTLSで、通常の389番へ平文で接続した後、コマンドで同一ポート上の通信をTLSへ昇格させます。

どちらを使う場合も、サーバ証明書の検証を省略しない設定が要点です。クライアント側で証明書チェックを無効にすると、TLSで暗号化していても中間者攻撃を許し、暗号化の意味が薄れます。ADでは特定の操作（パスワード変更など）がLDAPS必須になるため、業務アプリとADを連携させるなら636番でのTLS接続を初期設計に含めておくのが堅実です。ログイン後の権限をディレクトリのグループで制御する設計は、RBAC（ロールベースアクセス制御）の考え方と組み合わせると見通しがよくなります。

LDAPを採用する場面と、フェデレーションへ寄せるべき場面の判断

仕組みが出そろったところで、採用判断を条件で言い切ります。何でもLDAPに寄せる設計は、社外連携やSaaS時代の要件で破綻しやすく、役割で線を引くのが現実解です。新規に認証基盤を組む段階で、ここを設計判断の材料にしてください。

LDAP／ADを認証基盤に採用する条件と、向いているシステムの特徴

LDAPを中核に据えるのが妥当なのは、境界がはっきりした組織内システムです。社員向けの社内アプリ、ファイルサーバやプリンタ、社内のグループウェアなど、利用者が自組織のメンバーに閉じ、端末やアカウントを一元管理したいケースでは、LDAP／ADにアカウントを集約する価値が高くなります。1か所のディレクトリを更新すれば全システムへ反映され、退職者の無効化も一元的に回せます。

既存でADを運用している組織なら、新規の業務アプリもまずADのLDAPインターフェースで認証を通すのが自然です。多要素認証を足したい場合も、ディレクトリ認証の後段に多要素認証（MFA）を重ねる構成で無理なく拡張できます。要は「利用者が内部に閉じ、端末込みで統制したい」なら、LDAPは今も第一候補になります。

LDAPに閉じず、SAML／OIDCへ橋渡しすべき場面と失敗パターン

逆に、LDAPだけで押し切ると失敗する場面もはっきりしています。外部のSaaSや社外パートナーへのログインを、LDAPを社外公開して実現しようとする設計です。LDAPはもともと境界内での利用を想定したプロトコルで、インターネット越しに直接さらすとインジェクションや認証情報流出のリスク面が大きく、実務では採るべきではありません。ここはSAMLやOIDC（OpenID Connect）といったフェデレーション規格の領分です。

現実的な設計は、社内のLDAP／ADを唯一のアカウント源（信頼の起点）に置きつつ、外向きの認証はIdPを立ててSAML／OIDCで各SaaSへ渡す二段構えです。ディレクトリが「誰か」を管理し、フェデレーションが「そのアカウントで外部サービスへどう入るか」を担います。組織を横断する導入可否の判断は、二段階認証の観点も含めて整理しておくと迷いません。こうしたLDAP／ADと会員基盤・SaaS連携をまたぐ認証設計と実装は、会員管理システム開発としてディレクトリ連携ごと受託しています。既存ADをどこまで使うかの線引きから、ご相談ください。

よくある質問

LDAPの設計・実装でよく挙がる疑問を、開発者の視点で簡潔にまとめます。

LDAPとActive Directoryは何が違うのですか？

層が異なります。LDAPはディレクトリへ問い合わせるためのプロトコル（共通言語）で、Active Directoryはそのプロトコルを話せるディレクトリサービス製品の一つです。ADはLDAPに加えてKerberos認証やグループポリシーをWindows向けに統合しています。つまり「どちらか」ではなく、ADの中身へLDAPで問い合わせる、という主従の関係になります。

LDAPで使うポート389と636の違いは何ですか？

暗号化の有無です。389番は平文のLDAP、636番はTLSで暗号化するLDAPS（LDAP over TLS）の標準ポートです。389番のまま接続後にStartTLSコマンドでTLSへ昇格させる方法もあります。認証情報や属性が平文で流れるのを避けるため、本番環境では636番のLDAPSかStartTLSでの暗号化を前提にし、あわせてサーバ証明書の検証を有効にします。

LDAPでユーザー認証はどう実装するのですか？

bindという認証操作を使います。定番は「サービスアカウントで一度bindし、入力されたユーザー名からDNをsearchで特定、そのDNとパスワードで再度bindを試みて成功可否を判定する」二段構えです。入力値を検索フィルタへ直接連結するとLDAPインジェクションを招くため、特殊文字のエスケープやライブラリのパラメータ化を通し、通信はTLSで保護します。

OpenLDAPとActive Directoryはどちらを選ぶべきですか？

環境と管理対象で選び分けるのが基本です。Linux中心でユーザー認証のディレクトリを軽量に自前運用したいならOpenLDAP、Windows端末やファイルサーバまで含めて統合管理したいならActive Directoryが向きます。クラウド前提なら、運用負担を抑えるためAWS Managed Microsoft ADのようなマネージドADや、IDaaSのMicrosoft Entra IDへ寄せる選択肢も検討対象になります。

LDAPとSAML/OIDCはどう使い分けますか？

対象範囲で使い分けるのが基本です。LDAPは境界内のディレクトリ照会・認証に向き、社内システムのアカウント一元管理に使います。社外のSaaSやパートナー間のログインは、LDAPを外部公開せず、SAMLやOIDCのフェデレーションに任せます。社内LDAP／ADをアカウントの起点に置き、外向きはIdP経由でSAML/OIDCへ渡す二段構えが、実務での標準的な組み合わせです。

関連記事

• Microsoft Entra ID（旧Azure AD）とは？読み方・Azure AD/Active Directoryとの違い・機能・料金を解説：LDAP依存アプリをクラウドへ移す際の受け皿。Entra IDとLDAPの関係を整理しています。
• AWS Managed Microsoft ADとは：クラウド上でのディレクトリサービスの基本概念と機能：ADのLDAP環境をAWS上でマネージド運用する選択肢。自前運用との比較に使えます。
• SAMLとは？認証フロー・IdP/SPの仕組みとOAuth・OIDCとの使い分けを実装視点で解説：社外SaaS連携でLDAPの外に出す認証。フェデレーションの規格を解説しています。
• OIDC（OpenID Connect）とは？仕組み・OAuthとの違いをわかりやすく解説：LDAPを起点にIdPが発行するIDトークンの認証層。新規の外向き認証で選ばれます。
• RBACとは何か？基本概念とアクセス制御における役割：ディレクトリのグループを権限に結び付ける考え方。LDAP認証後の認可設計で使います。