VPN装置やNAS、複合機の設定画面を開くと、よく「LDAPサーバ」という項目が出てきます。ADのことだろうと何となく入力して動いたものの、LDAPとADは何が違うのか、RADIUSやSAMLとはどう使い分けるのか、と聞かれると答えに詰まる人も多いのではないでしょうか。
この記事では、LDAP（エルダップ）を「社員名簿に問い合わせるための共通の言葉」としてとらえ、なぜ必要なのか、データをどう持っているのか、どんなやり取りでログインを確かめているのかを、図を使って順番に説明します。最後に、ADやRADIUS・SAML・OAuthとの違いと、LDAPを使う場面、安全に使うためのポイントを整理します。
- LDAPとは何か、なぜ必要なのか
- ツリーとDNによるデータの持ち方
- LDAPでログインを確かめる流れ（BindとSearch）
- Active Directory、RADIUS・SAML・OAuthとの違い
- LDAPを使う場面と、安全に使うためのポイント
LDAPを一言でいうと
LDAP（Lightweight Directory Access Protocol）は、「ディレクトリ」に問い合わせるためのプロトコルです。ディレクトリは、社員や部署、グループ、PCなどの情報をまとめた名簿のようなものだと考えてください。名簿そのものは、Active Directory（AD）やOpenLDAPといった製品が持っています。
会社の総務にある社員名簿でたとえると、名簿がディレクトリ、名簿を管理している総務の窓口がディレクトリサーバ、窓口に「営業部の山田さんのメールアドレスを教えて」「山田さんのパスワードはこれで合っていますか」と問い合わせるときの決まった言い方がLDAPです。問い合わせ方が決まっているので、複合機でもLinuxでもVPN装置でも、同じ名簿を同じ方法で使えます。
なぜLDAPが必要なのか
社員が使うシステムが、ファイルサーバ（NAS）、複合機、Linuxサーバ、VPN装置、社内アプリと5つあるとします。名簿を共有しなければ、それぞれの機器にユーザーを登録し、パスワードを設定することになります。
機器ごとにユーザーを持つと、次のような問題が起きます。
| 問題 | 起きること |
|---|---|
| 管理の手間 | 入社のたびに5か所で登録し、パスワードの変更も5か所で行うことになります。 |
| 退職者の消し忘れ | 1か所でも削除を忘れると、退職した人のアカウントが使える状態で残ります。 |
| パスワードの使い回し | 覚えきれないので、社員が同じパスワードを使い回したり、メモに書いたりしがちです。 |
| 異動への追従 | 「営業部だけ使える」といった権限を、異動のたびに機器ごとに直す必要があります。 |
名簿を1か所にまとめ、どの機器もLDAPでその名簿に問い合わせるようにすれば、登録も削除も1回で済みます。退職者をADで無効にすれば、LDAPで問い合わせているすべての機器で、その人はログインできなくなります。
LDAPのデータの持ち方：ツリーとDN
データはツリー（木構造）で並んでいる
LDAPのディレクトリは、Excelのような表ではなく、会社の組織図のようなツリーでデータを持っています。いちばん上が会社（ドメイン）、その下に部署、さらにその下に人やグループが並びます。ツリーの1つ1つの項目を「エントリ」と呼びます。
DNは「住所」、属性は「名簿の欄」
ツリーの中で1つのエントリを指し示す名前を、DN（Distinguished Name、識別名）と呼びます。図2の山田さんなら uid=yamada,ou=sales,dc=example,dc=com です。「example.com社の営業部の山田さん」を、自分の名前から上へ順に書いたもので、住所を番地から書いていくのに似ています。ADでは CN=Taro Yamada,OU=Sales,DC=example,DC=com のように、人の名前を CN で書く形がよく使われます。
エントリには、名簿の欄にあたる「属性」がいくつも入っています。よく見る属性は次のとおりです。
| 属性 | 意味 | 値の例 |
|---|---|---|
| dc | ドメイン名の一部（domainComponent） | example、com |
| ou | 部署などの組織単位（organizationalUnitName） | sales |
| cn | 名前（commonName） | Taro Yamada、vpn-users |
| uid | ログイン名（userid） | yamada |
| sn | 姓（surname） | Yamada |
| メールアドレス | yamada@example.com | |
| member | グループに入っているメンバーのDN | uid=yamada,ou=sales,dc=example,dc=com |
普通のデータベースとの違い
「名簿ならデータベース（RDB）でもよいのでは」と思うかもしれません。ディレクトリは、読むことが多く書くことが少ない情報を、組織の形のまま持つのが得意です。社員情報は、1日に何千回もログインのたびに読まれますが、書き換えは入社・異動・退職のときぐらいしか起きません。
| ディレクトリ（LDAP） | リレーショナルデータベース（SQL） | |
|---|---|---|
| データの形 | ツリー（組織図の形） | 表（行と列） |
| 得意なこと | 人・グループ・機器の情報を、たくさんのシステムから検索・参照する | 売上や在庫のように、頻繁に書き換わるデータを扱う |
| 代表的な製品 | Active Directory、OpenLDAP | MySQL、PostgreSQL、SQL Server |
LDAPでログインを確かめる流れ
LDAPのやり取りは、クライアントがサーバに「操作」を頼む形で進みます。主な操作は次のとおりです。
| 操作 | やること | たとえると |
|---|---|---|
| Bind | 自分が誰かを名乗り、パスワードなどで確かめてもらう | 窓口で社員証を見せる |
| Search | 条件に合うエントリを探して、属性を返してもらう | 名簿から探してもらう |
| Compare | エントリの属性が、ある値と一致するかを確かめる | 「この人は営業部？」と確認する |
| Add／Delete／Modify | エントリの追加・削除・属性の変更 | 名簿に書き足す・消す・直す |
| Unbind | やり取りを終える | 窓口を離れる |
VPN装置やNAS、社内アプリで「LDAP認証」を設定すると、多くの場合は次のように「探してから、本人として名乗る」流れで動きます。
利用者がIDとパスワードを入力する（①）
利用者がVPNのログイン画面などに yamada とパスワードを入力します。アプリや機器（LDAPクライアント）は、この時点ではまだ「yamada」が名簿のどこにいる誰なのかを知りません。
サービスアカウントで名乗る（②）
アプリは、名簿を検索するために用意した専用のアカウント（サービスアカウント、Bind用アカウントとも呼びます）でBindします。機器の設定画面にある「Bind DN」「Bindパスワード」の欄に入れるのが、このアカウントです。
ログイン名から本人を探す（③）
アプリは「ou=... から下で、uid が yamada の人」をSearchし、山田さんのDNを受け取ります。Searchでは、次の4つを指定します。
| 指定するもの | 意味 | 例 |
|---|---|---|
| ベースDN | どこから下を探すか | dc=example,dc=com |
| スコープ | 探す範囲。そのエントリだけ（base）、1段下だけ（one）、下すべて（sub） | sub |
| フィルタ | 探す条件 | (uid=yamada)、(&(objectClass=person)(sn=Yamada)) |
| 取得する属性 | 返してほしい欄 | mail、memberOf |
本人として名乗り直す（④）
アプリは、見つけたDNと、利用者が入力したパスワードでもう一度Bindします。Bindが成功すればパスワードは正しく、失敗（invalidCredentials）なら間違っています。パスワードの照合はLDAPサーバが行うので、アプリや機器はパスワードを保存しなくて済みます。
必要ならグループも確かめる（⑤）
「VPNは vpn-users グループの人だけ」のような条件があるときは、ユーザーの所属グループもLDAPで確認してから、ログインの可否を決めます。ADなら、ユーザーの memberOf 属性に所属グループのDNが入っています。
機器によっては、②③を省き、入力されたIDからDNを組み立てて（または yamada@example.com の形で）いきなり④のBindをするものもあります。設定画面に「Bind DN」の欄があるかどうかで、どちらの方式かの見当が付きます。
Active DirectoryとLDAPの違い
いちばん混同しやすいのが、ADとLDAPの関係です。LDAPは名簿に問い合わせるための「言葉（プロトコル）」で、ADはマイクロソフトの「製品」です。ADはディレクトリを持ち、その窓口の1つとしてLDAPを話します。ほかにも、Windowsのログオンに使うKerberos、名前解決のDNS、PCを一括で設定するグループポリシーなどを1つにまとめています。
ドメインに参加したWindows PCのログオンは、主にKerberosで行われます。一方で、複合機、Linuxサーバ、VPN装置、NAS、業務アプリなどWindows以外の機器やアプリは、LDAPでADの名簿を検索したり、ログインを確かめたりします。つまり、「LDAPかADか」を選ぶのではなく、「ADという名簿を、LDAPという言葉で使う」という関係です。
| LDAP | Active Directory | |
|---|---|---|
| 正体 | プロトコル（問い合わせの決まりごと） | マイクロソフトのディレクトリサービス製品 |
| できること | ディレクトリの検索、Bindによる本人確認、エントリの追加・変更 | ディレクトリに加えて、Kerberos、DNS、グループポリシーなどをまとめて提供 |
| ほかの例 | ― | OpenLDAP、389 Directory Server など（LDAPで使えるディレクトリ製品） |
ADでは、通常のLDAP（389）のほかに、フォレスト全体を検索するためのグローバルカタログ（3268、TLSでは3269）があります。複数ドメインの環境で「ユーザーが見つからない」ときは、問い合わせ先のポートを確認してみてください。
RADIUS・SAML・OAuthとの違い
LDAPと並んでよく出てくる認証まわりのプロトコルとの関係を、1枚の図にまとめます。ポイントは、LDAPが「名簿を引く」役で、ほかのプロトコルは「名簿を使って、何かを許可する」役だということです。
| プロトコル | 主な役割 | 誰と誰が話すか | LDAPとの関係 |
|---|---|---|---|
| LDAP | 名簿（ディレクトリ）の検索と、Bindによる本人確認 | アプリ・機器 ↔ ディレクトリサーバ | ― |
| RADIUS | Wi-Fi・VPNなどネットワークの入口でのAAA（認証・認可・アカウンティング） | AP・VPN装置 ↔ RADIUSサーバ | 社内のアカウントで認証するとき、RADIUSサーバがADなどに確認する。そのやり取りにLDAPが使われることが多い |
| SAML | Webアプリのシングルサインオン | ブラウザを介して IdP ↔ クラウドサービス | IdPのユーザー情報の元がADであることが多い（同期やLDAPなどで連携） |
| OAuth 2.0 OpenID Connect | OAuthはAPIを使う権限の受け渡し（認可）。OpenID Connectはその上でログイン（認証）を行う | アプリ ↔ 認可サーバ（IdP） | SAMLと同じく、IdPの裏側の名簿として使われる |
| Kerberos | Windowsドメインのログオン | Windows PC ↔ ドメインコントローラ | ADの中でLDAPと並んで動く |
もう1つ大きな違いがあります。SAMLやOpenID Connectが受け渡すのは「いまログインした本人」の情報です。一方LDAPは、名簿全体から条件に合う人やグループを探せます。「営業部の全員のメールアドレスを一覧したい」「このグループに誰が入っているか知りたい」といった用途は、LDAPの得意分野です。
こんなときはLDAP
ここまでの内容を、「やりたいこと」から逆に引けるようにまとめます。どれも、ブラウザでログイン画面を出せない機器や、名簿そのものを検索したい場面です。
| やりたいこと | LDAPを使う理由 |
|---|---|
| 複合機でスキャンした文書を、社員のメールアドレス宛てに送りたい | 複合機のアドレス帳がLDAPでADを検索し、宛先のメールアドレスを引けます。社員の登録を複合機ごとにやる必要がありません。 |
| VPNやNASを、ADのアカウントで、特定のグループの人だけに使わせたい | 機器がLDAPでパスワードを確かめ、所属グループも確認できます。退職者や異動者もADの変更だけで反映されます。 |
| Linuxサーバに、社員がADのアカウントでログインできるようにしたい | SSSDなどを使い、LDAPでユーザーやグループの情報を引きます（パスワードの確認にはKerberosを使う構成もあります）。 |
| 社内アプリやパッケージ製品のログインを、ADのアカウントでそろえたい | 多くの製品が「LDAP認証」の設定を持っており、図3の流れでADを使えます。 |
| 部署やグループのメンバー一覧を、システムから取りたい | LDAPのSearchで、条件に合うエントリをまとめて取得できます。 |
クラウドの時代にLDAPはどうなるのか
最近は、Microsoft Entra IDなどのクラウドのID基盤に移る会社も増えています。ただ、クラウドのID基盤はSAMLやOpenID Connectでログインさせることが中心で、Microsoft Entra IDには、機器がそのままLDAPで問い合わせる窓口はありません。一方で、複合機やNAS、VPN装置、Linuxサーバのように、LDAPでしか社内のアカウントを使えない機器はまだ多く残っています。
こうした機器を使い続ける場合は、次のような形がとられます。
- オンプレミスのADを残し、LDAPが必要な機器はADを見る。
- Microsoft Entra Domain Services のように、クラウド側でLDAP（TLSを使う636番も含む）を提供するサービスを使う。
- IDaaS製品が用意しているLDAPの窓口やエージェントを使う。
どの形にするかを考えるには、まず社内の機器やアプリのうち、どれがLDAPを使っているかを洗い出すのが近道です。設定画面に「LDAPサーバ」「Bind DN」の欄がある機器が、その候補です。
安全に使うためのポイント
389番のままでは、パスワードが読める
通常のLDAP（TCP 389）の通信は暗号化されていません。Bindでよく使われるシンプルBindでは、パスワードがそのまま送られるため、通信を盗み見られるとパスワードがわかってしまいます。パスワードを送る場合は、TLSで暗号化した通信を使います。
| 方式 | 内容 |
|---|---|
| LDAPS（TCP 636） | 最初からTLSで暗号化した通信でLDAPを話す方式です。 |
| StartTLS（TCP 389） | 389番でつないだ後、StartTLSという操作で暗号化に切り替える方式です。 |
ADではLDAP署名の要求に注意する
ADには、署名のないLDAPのやり取りを拒否する「LDAP署名」の設定があります。Windows Server 2025では、新しく作るADで、LDAP署名を必須にするのが既定になりました。暗号化していない389番でシンプルBindをしている古い機器やアプリは、つながらなくなる可能性があります。ADを新しくするときは、LDAPを使う機器をLDAPSかStartTLSに切り替えられるかを、先に確認しておくと安心です。
空のパスワードと、Bind用アカウントの権限
| 注意点 | 内容 |
|---|---|
| 空のパスワード | LDAPには、DNだけを送りパスワードを空にした「認証なしのBind」があります。アプリがこれを成功と扱ってしまうと、パスワードなしでログインできてしまいます。空のパスワードはアプリ側で受け付けず、サーバ側でも認証なしのBindを拒否する設定にします。 |
| 匿名のBind | DNもパスワードも空のBind（匿名）で名簿を読めると、社員の一覧が外から取れてしまいます。必要がなければ無効にします。 |
| Bind用アカウント | 図3の②で使うサービスアカウントは、検索に必要な読み取り権限だけにし、パスワードは長く推測しにくい値にします。 |
まとめ
LDAPは、ADなどのディレクトリ（名簿）に問い合わせるための共通の言葉です。名簿を1か所にまとめ、いろいろな機器やアプリが同じ名簿をLDAPで見ることで、アカウントの登録や削除が1回で済むようになります。RADIUSやSAMLが「入口」や「ログイン」を受け持つのに対し、LDAPはその下で名簿を引く役です。
| 項目 | ポイント |
|---|---|
| LDAPとは | ディレクトリ（名簿）に問い合わせるためのプロトコル |
| なぜ必要か | 機器ごとのアカウント管理をやめ、1つの名簿で登録・削除・権限を管理するため |
| データの持ち方 | 組織図のようなツリー。エントリの住所がDN（例：uid=yamada,ou=sales,dc=example,dc=com） |
| ログインの確認 | サービスアカウントでBind → Searchで本人のDNを探す → 本人のDNとパスワードでBind |
| ADとの違い | LDAPは言葉、ADは製品。ADはLDAPのほかKerberos・DNS・グループポリシーも提供する |
| ほかとの違い | RADIUSはネットワークの入口、SAML・OpenID ConnectはWebのログイン、LDAPはその裏の名簿の検索 |
| ポート | LDAP 389（StartTLSも389）、LDAPS 636、ADのグローバルカタログ 3268／3269 |
| セキュリティ | パスワードを送るならLDAPSかStartTLS。空のパスワードと匿名Bindに注意し、ADではLDAP署名の要求に備える |
コメント