LDAPとは何ですか？

LDAPは、1990年代初頭にX.500ディレクトリアクセスプロトコルのより軽量な代替手段として開発されて以来、アイデンティティプロトコルの基盤として機能してきました。現在でも、ほとんどの企業環境に組み込まれており、組織がクラウド型アイデンティティソリューションを導入する中でも、認証およびディレクトリサービスの基盤としての役割を果たし続けています。.

LDAPはクライアント・サーバーモデルに基づいて動作し、LDAPクライアントがディレクトリサーバーにリクエストを送信すると、ディレクトリサーバーは一元化されたディレクトリから情報を取得して返します。通信はTCP/IPを介して行われ、通常、標準接続ではポート389、LDAPS（SSL/TLS上のLDAP）ではポート636が使用されます。.

大まかに言えば、LDAPの通信は次の4つのステップで構成されます：

1. 接続：クライアントは、LDAPサーバーとTCPセッションを確立します。.
2. 製本： クライアントは、匿名または認証情報を使用して、サーバーに対して認証を行います。.
3. リクエスト：クライアントは、ディレクトリに対して検索や変更のリクエストなどの操作を発行します。.
4. 回答：サーバーは、リクエストされたデータまたはステータスコードを返し、クライアントは最終的に「unbind」を発行してセッションを終了します。.

サーバーはデータを階層的なツリー構造で整理し、バインド、検索、比較、追加、変更、削除、アンバインドといった定義済みの操作セットに応答します。この共有型のリアルタイムアクセスモデルこそが、多くのアプリケーションが同一の権威ある情報源に対してIDデータのクエリを実行する必要がある環境において、LDAPが適している理由です。.

LDAPのディレクトリ構造

LDAPディレクトリは、ディレクトリ情報ツリー（DIT）と呼ばれる階層的なツリー構造に情報を格納します。ツリー内の各エントリは、オブジェクト（ユーザー、グループ、デバイスなど）を表しており、階層内での位置を表す一意の識別名（DN）によって識別されます。.

DNは、最も具体的なものから最も一般的なものへと順に読み取られる一連の構成要素から成り立っています：

• cn（通称）、例えば本人のフルネームなど
• ou（組織単位）、例えば部署など
• dc（ドメイン構成要素）、例えばドメイン名の一部など

たとえば、DN「cn=John Smith,ou=Engineering,dc=example,dc=com」は、example.com ドメイン内の「Engineering」組織単位に所属する John Smith という名前のユーザーを識別します。.

LDAP操作

LDAPでは、認証から読み取り、書き込み、セッションの終了に至るまで、クライアントとディレクトリとのやり取りの全ライフサイクルを網羅する、少数の標準化された操作が定義されています。.

• Bind: ディレクトリサーバーに対してクライアントの認証を行い、認証済みセッションを確立します。バインド操作こそが、LDAPを認証メカニズムとして利用可能にするものです。なぜなら、バインドが成功すれば、送信された認証情報が有効なディレクトリエントリと一致していることが確認されるからです。.
• 検索: 特定の条件に一致するエントリをディレクトリから検索し、フィルタ構文を使用して、どの属性と値を返すかを定義します。検索は、LDAP操作の中で最も頻繁に使用されるものであり、ユーザーの検索、グループのメンバーシップ確認、ディレクトリの閲覧といったユースケースを支えています。.
• 比較する: 指定された属性値がエントリに格納されている値と一致するかどうかを確認し、格納されている値そのものを公開することなく、true または false を返します。Compare は、完全な検索が不要な軽微な検証タスクによく使用されます。.
• 追加: ディレクトリ内のツリー上の指定された場所に新しいエントリを作成します。追加操作は、ユーザーのプロビジョニング時、つまりディレクトリに新しいアカウント、グループ、またはデバイスを登録する必要がある場合に、よく使用されます。.
• 変更: 既存のエントリの属性を更新し、パスワードのリセット、グループメンバーシップの更新、プロフィールの編集などの変更を可能にします。「Modify」では、エントリ内の個々の属性値の追加、置換、削除を行うことができます。.
• DNの変更: エントリの名前を変更したり、ディレクトリツリー内の別の場所に移動したりします。「DNの変更」は、ユーザーが部署間を異動したり、組織単位の再編が行われたりするなど、組織構造に変更があった場合に使用されます。.
• 削除: ディレクトリからエントリを削除します。Delete は通常、アカウントやリソースが廃止され、そのディレクトリレコードをクリーンアップする必要があるプロビジョニング解除の際に使用されます。.
• 紐を解く: クライアントセッションを閉じ、サーバーへの接続を終了します。その名前からはバインドを元に戻すように思えますが、実際には、unbind はクライアントの処理が完了したことを通知し、関連するサーバーリソースを解放します。.
• 業務の拡大: これは、ベンダーや標準化団体が、コアセット以外の追加操作を定義できるようにするフレームワークです。標準のLDAP接続を暗号化された接続にアップグレードする「StartTLS」は、最も広く利用されている拡張操作の一つです。.

LDAPは、エンタープライズ環境全体で、IDデータを一元管理し、複数のアプリケーションやサービスからそのデータに一貫性を持ってアクセスできるようにするために利用されています。代表的な利用例としては、次のようなものがあります：

• 一元認証: 単一のディレクトリから多数のアプリケーションのユーザー認証情報を検証し、パスワードの乱立や管理上の負担を軽減する
• ユーザーおよびグループの管理: 従業員、契約業者、システムアカウントに関する記録、およびそれらに関連付けられたグループや権限の保存と整理
• アドレス帳と連絡先の検索: メールクライアントやコラボレーションツールが、企業のディレクトリから連絡先情報を取得できるようにすること
• デバイスおよびリソースの管理: プリンター、サーバー、共有ストレージなどのネットワークリソースの追跡
• シングルサインオンの基盤: SSOシステムがユーザーの認証やプロフィール属性の取得に利用する、基盤となるID情報源としての役割を果たす

LDAP認証とは、アプリケーションが、ユーザーから送信された認証情報を使用してLDAPディレクトリにバインドし、ユーザーの身元を確認するプロセスです。ディレクトリが、その認証情報が有効なエントリと一致することを確認した場合、ユーザーは認証され、リクエスト元のアプリケーションへのアクセスが許可されます。.

一般的なLDAP認証の流れは、以下の通りです：

1. ユーザーは、アプリケーションに認証情報（通常はユーザー名とパスワード）を入力します。.
2. このアプリケーションは、それらの認証情報を含むLDAPバインド要求をディレクトリサーバーに送信します。.
3. LDAPサーバーは、送信された識別子を使用して、ディレクトリツリー内からユーザーのエントリを検索します。.
4. サーバーは、送信されたパスワードと、そのエントリについて保存されている認証情報を照合します。.
5. サーバーは、アプリケーションに対して成功または失敗の応答を返します。.
6. 処理が成功した場合、アプリケーションはユーザーにリクエストされたリソースへのアクセス権を付与します。.

シンプルバインドとSASLバインドの比較

LDAP は 2 つの主要なバインド方式をサポートしており、どちらを選択するかは、認証時の認証情報の送信および検証方法に関して、セキュリティ上重要な意味を持ちます。.

A 単純なバインド ユーザー名とパスワードをサーバーに直接送信します。サーバーは、接続がTLS（LDAPSやStartTLSなど）によって保護されていない限り、認証情報を平文で送信します。.

A SASLのバインド (Simple Authentication and Security Layer) は、Kerberos、クライアント証明書、その他のプラグイン方式など、より強力な認証メカニズムをサポートしており、認証情報の漏洩が懸念される環境では、この方式が推奨されます。.

LDAPとActive Directoryはしばしば混同されますが、これらは競合する技術ではありません。LDAPはディレクトリ情報にアクセスするためのオープンプロトコルであるのに対し、Active Directoryは、LDAPをサポートするアクセス方法の一つとして採用しているMicrosoftディレクトリサービス製品です。.

簡単に言えば、Active DirectoryはLDAPに対応していますが、LDAPそのものがActive Directoryというわけではありません。OpenLDAP、389 Directory Server、Oracle Internet Directoryなど、Microsoft以外の多くのディレクトリサービスも、LDAPプロトコルを実装しています。.

LDAP、SAML、およびOAuthは、相互に関連しつつもそれぞれ異なるプロトコルであり、アイデンティティおよびアクセス管理という広範な分野において、それぞれ異なる課題を解決するものです。.

• LDAPディレクトリへのアクセスと認証を処理し、主にオンプレミスリソースや内部アプリケーションで使用されます。これは、ディレクトリに対する照会や変更を行うためのプロトコルであり、bind操作を通じて認証を行うことができます。.
• SAML （Security Assertion Markup Language）は、Webベースのシングルサインオンにおけるフェデレーテッド認証を可能にし、IDプロバイダーとサービスプロバイダーの間で認証および認可のアサーションを交換します。これは、クラウドやSaaSアプリケーションへのユーザーログインに広く利用されています。.
• OAuth これは、サードパーティ製アプリケーションが、認証情報を公開することなく、ユーザーのリソースへの限定的なアクセス権を取得できるようにする認証プロトコルです。このプロトコルは、ユーザーが誰であるかではなく、アプリケーションがユーザーに代わって何を行うことができるかを規定するものです。.

多くの現代的な環境では、これら3つすべてが活用されています。すなわち、ユーザーデータの基盤となるディレクトリとしてのLDAP、クラウドアプリケーションへのフェデレーテッドSSOのためのSAML、そしてAPIへの委任アクセスのためのOAuthです。認証層とガバナンス層がどのように連携しているかについてさらに詳しく知りたい場合は、RSAの記事「 アイデンティティ・ガバナンスおよびIAM .

組織がクラウドIDプロバイダーやSaaSアプリケーションを導入しているにもかかわらず、LDAPは依然として広く導入されており、全面的に置き換えられることはありません。ほとんどの企業環境では、ユーザーデータの信頼できる情報源として既存のLDAPディレクトリを引き続き利用しており、最新のIAMプラットフォームは、一般的に、それらを置き換えるのではなく、統合できるように設計されています。.

現在の主流は、LDAPディレクトリがクラウドIDプロバイダー、SSOプラットフォーム、多要素認証レイヤーと共存するハイブリッドアーキテクチャです。 組織では、単純なバインドを実行してアクセス権を付与するのではなく、多要素認証、パスワードレス認証、適応型認証、リスクベースのアクセス決定、継続的な検証といった追加の制御機能をLDAP認証に組み込むケースが増えています。この多層的なアプローチにより、既存のディレクトリへの投資を維持しつつ、単純なLDAPバインドだけでは軽減できない認証情報に基づくリスクに対処することができます。.

RSAの IDおよびアクセス管理ソリューション 既存のLDAPディレクトリと統合することで、レガシーインフラストラクチャの上に最新の認証およびアクセス制御機能を追加します。RSAは、LDAPベースの認証にMFA、パスワードレス認証、リスクベースのアクセス制御機能を拡張することで、組織がすでに依存しているディレクトリサービスを置き換えることなく、IDセキュリティを強化できるようにします。.