LDAPとは何ですか？

組織は、ほぼ三十年にわたってユーザー管理、属性、および認証のためにLDAPプロトコルを使用してきました。 その時代、プロトコルは変化するIT環境やビジネスニーズに対応するために拡張され、進化してきました。

このブログでは、LDAPの起源から今日のクラウド駆動型ビジネスの世界での場所まで、LDAPについて知る必要があるすべてをカバーし、LDAPの仕組み、使用方法、開始方法、およびどのLDAPサーバーソリューションがニーズに適しているかについて説明しています。

LDAPプロトコル

LDAP(Lightweight Directory Access Protocol)は、ディレクトリサービス(ユーザーとITリソースへのアクセス権を安全に管理するプロセス)のために開発されたコアプロトコルの一つであり、ほとんどのディレクトリサービスは今日でもLDAPを使用していますが、Kerberos、SAML、RADIUS、SMB、Oauthなどの追加プロトコルを使用することもあります。

一言で言えば、LDAPはディレクトリストレージの方法を指定し、サーバー、ファイル、ネットワーク機器、アプリケーション、その他のITリソースに対するユーザーの認証と承認を容易にします。 LDAPは、1993年にミシガン大学のTim Howesと彼の同僚によって開発され、DAP（directory access protocol）のように、当時使用されていたX.500ディレクトリサービスプロトコルの軽量で低オーバ

X.500は、システム（大きなフットプリント）とネットワーク（帯域幅を集中的に）の両方で困難でした。 実際には、1990年代初頭の人々の机の上のシステムの多くは、X.500ディレクトリサービスに接続できなかったので、それは特定のシステムに限定されていました（

LDAPは、エンドポイントのオーバーヘッド、帯域幅の使用、および需要を削減しながら、サーバー、ファイル、およびアプリケーションに対するユーザーの認証と承認を可

これらの効率の結果、LDAPは大きな成功を収め、しばらくの間、事実上のinternet directory services認証プロトコルになるでしょう。 実際、Ldapv3(LDAPの3番目のバージョン)が提案され、1997年にディレクトリサービスのインターネット標準として受け入れられました。 これは、今日のLDAPの最新かつ最も普及しているバージョンです。

このマイルストーンに続いて、Kurt ZeilengaはOpenLDAP1.0を1998年にリリースしてOpenLDAPプロジェクトを開始しました。

OpenLDAP1.0はLdapv3.3から派生した最初の完全オープンソースのクライアントおよびサーバーアプリケーションスイートであり、高度なセキュリティ機能、更新されたプラ OpenLDAPのオープンソースの性質により、IT管理者は組織のニーズに合わせてitを変更することができ、一般的なLDAPの選択肢となりました。 OpenLDAPはその後、Howard ChuとSymasチームによって推進されてきました。

一年後の1999年、マイクロソフトはLDAPとKerberosを使用したActive Directoryをリリースし、組織をMicrosoftエコシステムにロックし続けるための独自の拡張機能も作成しました。

LDAPはどのように機能しますか？

要するに、LDAPは、レコードの追加、削除、および変更を可能にするディレクトリストレージの方法を指定し、それらのレコードの検索を可能にして、リソースへのユー

LDAPの3つの主な機能は次のとおりです。

更新: これには、ディレクトリ情報の追加、削除、または変更が含まれます。

クエリ:ディレクトリ情報の検索と比較が含まれます。

Authenticate:主な認証機能にはbindingとunbindingが含まれます;第三の機能abandonは、サーバーが操作を完了するのを停止するために使用できます。

LDAPディレクトリコンポーネント

以下は、LDAPプロトコルとLDAPベースのディレクトリの主要な要素と概念の一部です。 Identity provider(IdP)を使用する場合、これの多くはGUIの背後で発生します。; しかし、それはあなたの理解を丸めると道の下のカスタマイズやトラブルシューティングを支援するために、両方を知っておくと便利です。

さらに、OpenLDAPは柔軟なカスタマイズを可能にしますが、プロトコルとそのユースケースについてのより複雑な知識が必要です。 一般的に、これらの変更は、コマンドライン、設定ファイルを使用して、または、時にはオープンソースのコードベースを変更することによって行われます。 LDAPの仕組みを理解することは、OpenLDAPを使用している人や、ニーズに合わせてldapをカスタマイズすることに興味がある人にとって特に重要です。

LDAPディレクトリ情報ツリー

LDAPは、ディレクトリ情報ツリー(DIT)と呼ばれる階層ツリー構造に情報を整理します。 LDAP DITは、使用するソフトウェアまたはディレクトリサービスによって異なる場合がありますが、LDAPディレクトリは一般にこのツリー構造に従います。

このルートは、ルートDSEと呼ばれるディレクトリサーバエージェント(DSA)固有のエントリ(DSE)であり、ディレクトリに関する情報を提供します。

エントリ

エントリは、ユーザーやマシンなど、ディレクトリに格納されている実際のアイテムを記述するために属性を使用します。 電話帳のように、またはより関連性の高い電話の連絡先リストのように、ユーザーはエントリとして存在し、ユーザーに関する追加情報を格納します。

LDAPでは、エントリは共通名(CN)で参照されることがよくあります。

属性

属性は、LDAPディレクトリに格納されているユーザー、サーバー、またはその他のアイテムを記述します。 たとえば、ユーザーの属性には、通常、フルネーム、電子メールアドレス、ユーザー名、およびパスワードが含まれます。 属性は型と値、すなわち mail(type)[email protected](value)で構成されています。

含めることができる属性は、ObjectClass属性によって事前定義されています; 組織は、複数のObjectClass属性を使用し、LDAPディレクトリに格納する情報を包含するカスタムObjectClass属性を作成することができますが、エントリごとに構造オブジェク (追加の補助オブジェクトクラスがあるかもしれませんが、構造オブジェクトクラスと呼ばれる1つのメインオブジェクトクラスは、各エントリを定義します)。

スキーマ

スキーマはディレクトリを定義します。 具体的には、スキーマは、構文、一致ルールを含むディレクトリのパラメータを定義します（つまり、入力パスワードはディレクトリデータと一致しますか？)、属性タイプ、およびオブジェクトクラス。

Ldapv3(LDAPの最新のイテレーション)は事前定義されたスキーマを提供し、他のLDAPオファリングはスキーマバリアントまたはイテレーションを提供するため、 カスタムスキーマを作成することは、より微妙でニッチなユースケースでも可能です。

DN:識別名

これはLDAPエントリの一意の識別子で、オブジェクトに割り当てられているすべての属性を指定します。 これには複数のデータポイントを含めることができ、カンマで区切られた文字列内の相対識別名(Rdn)で構成されます。

DN形式は地理座標のように機能し、逆の順序でのみ機能します。

地理座標は一般的に始まり、より具体的になりますが、DNはオブジェクトの名前で始まり、メインディレクトリコンポーネント(LDAPサーバーのドメインなど)まで機能し、LDAPツリー内のエントリの場所を指す完全なアドレスを形成します。

DNsは次のようにフォーマットされます。

RDN、RDN、RDN

InitechのIT部門のプログラマーであるPeter Gibbonsの場合、DNは次のようになります:

cn=Peter Gibbons,ou=IT,ou=People,dc=Initech,dc=com

RDN:Relative Distinguished Name

これらは、ユーザーに電子メールアドレスを割り当てるなど、属性に値を割 これらは、名前と値のペアで等号(=)で形成されます。 形式は次のようになります。

attribute=value

たとえば、ユーザー Peter Gibbonsの電子メールアドレスのRDNは[email protected]になります。

複数値RDNs

RDNsは、プラス記号を持つ包括的なRDNに組み合わせることができます。 複数値Rdnは2つの属性値を1つとして扱い、同じ値を持つ2つのRdnを区別するために使用できます（同じ名前の2人のユーザーのように、ディレクトリは電子メールアドレスのRDNをユーザー名に添付して、それぞれに一意のRdnを作成できます）。 複数値のRDNは、

RDN+RDNのようにフォーマットされます。

LDAPサーバー

LDAPディレクトリには1つ以上のサーバーを含めることができますが、ルートサーバー(上の図のルートDSE)が1つ存在する必要があります。 主なLDAPサーバーはslapdデーモン上で実行され、slurpdデーモンを介してサーバーレプリカに変更を送信します。

従来、LDAPサーバーは事前にホストされ、組織によって内部的に管理されていましたが、Microsoft ADは市場でLDAPのための最も人気のある商用ソリューションでした。 OpenLDAPは、今日利用可能な最も人気のあるオープンソースと純粋な再生LDAPサーバーです。

しかし今、組織は、内部サーバーのホスティング、セキュリティ、および管理の負担を軽減するクラウドホストディレクトリサービスを使用することがよ また、クラウドベースのLDAPサーバーを使用すると、組織はインフラストラクチャをクラウドに移行し、リモート作業の機会を活用し、コストを削減できます。 詳細については、この記事の”LDAPおよびActive Directory”セクションを参照してください。

LDAP認証と認可

LDAPプロトコルは、ユーザーのリソースに対する認証と認可の両方を行います。 このプロトコルは、ユーザーがLDAPディレクトリと通信できるようにするバインド操作でユーザーを認証し、入力されたログイン情報がデータベースに記載されて

LDAP認証

LDAP認証はクライアント/サーバーバインド操作に依存しており、これにより、ldap対応クライアント(dua)と呼ばれるLDAP対応クライアントと、directory system agent(DSA)と呼ばれるdirectory serverが、安全で暗号化されたセッション内で通信できるようになります。

データベースへのアクセスを取得しようとするLDAPサーバーに対して認証すると、ユーザー名とパスワードの入力を求められます。

ユーザーがクライアントに入力した値がLDAPデータベースにある値と一致する場合、ユーザーはLDAPサーバーによってITリソースが何であれアクセス権を付与されます。

LDAP承認

ユーザーが正常に認証されると、要求されたリソースに対して承認される必要があります。 LDAPインスタンスによって構造やエンコードが若干異なる場合がありますが、これは基本的にディレクトリ内のグループとロールでアクセス許可を割り当

たとえば、OpenLDAPでは、ユーザーは異なる権限を割り当てることができるグループに属しています。 認証ユーザーに特定のリソースにアクセスするための正しいアクセス許可が割り当てられている場合、LDAPプロトコルはそれらを許可します。

LDAPは何のために使用されますか？

LDAPプロトコルは、次のことができるディレクトリを定義します:

• ユーザーデータを一元的かつアクセス可能な場所に格納します。
• これらのユーザーを、アクセスが許可されているリソースに関連付けます。
• • 技術的なアプリケーション:Jenkins、Docker、OpenVPN、Atlassian suiteなど多くのアプリケーションがLDAPで最高の認証を行います。
  • サーバーインフラストラクチャ:オンプレミスとクラウドの両方のLinuxサーバー(AWSなど)は、LDAPを利用してユーザーを認証します。
  • ファイルサーバー:QNAP、Synology、FreeNASなどのファイルサーバーはLDAPをサポートしています。
  • ネットワーク機器:これはRADIUSプロトコルと重複する可能性がありますが、一部の組織では、Vpn、WiFiアクセスポイント、およびその他のネットワーク機器を介

LDAPが開始されたときには、上記の機能は他のユーザー管理オプションよりもはるかに洗練されていました。 プロトコルの普及に伴い、より多くのITリソースがLDAP互換になり、クラウドLDAP、その他の認証プロトコル、フルディレクトリサービスなどの新しい製品が、それらのITリソースへのアクセスをサポートするためにシーンに入りました。

IT管理者はLDAPを使用してマシンを認証し、オンプレミスとクラウドの両方でレガシーアプリケーション、ネットワーク、NAS、およびその他のコンポーネントへのア JumpCloudのような一部のクラウドディレクトリサービスでは、この機能を他のプロトコルと組み合わせて、ユーザーが事実上すべてのITリソースにアクセ

LDAPとActive Directory

LDAPがコアディレクトリサービスプロトコルになったため、Microsoft ADはLDAP上に多くの基盤を構築しましたが、ADは純粋なLDAPツールではありません。

ADはLDAPを使用できますが、認証にはKerberosに大きく依存しており、オープンソースのLDAPディレクトリよりも柔軟性がありません。 ADにはドメインコントローラが必要で、Microsoft Windowsベースのデバイスやアプリケーションに最適です。 ADとLDAPの比較で、これらの違いをさらに詳しく調べてください。

最近まで、ディレクトリツールは主にwindowsベースの環境内で機能し、オンプレミスの環境に対応していました。 ADの成功は、何十年もの間のビジネス標準であったWindows中心のオンプレム環境に焦点を当てたことから主に来ました。

しかし、2020年のパンデミック主導の遠隔作業への大量移行で加速したこの過去10年間のクラウドへの移行は、世界のディレクトリニーズを変えた。

企業は現在、ADやその他のオンプレミディレクトリモデルの代わりに、クラウドベースのMacとLinuxに優しいディレクトリサービスを選択しています。 これらの変更に対応するためにLDAPソリューションがどのように進化したかについての詳細は、”LDAPのクラウド内の場所”のセクションを参照してくださ

LDAPおよびAzure Active Directory

Azure active Directoryは、Azureユーザー管理およびwebアプリケーションシングルサインオン用のad(ADの代替ではない)のクラウド対応アドオンであり、LDAPをネイ 代わりに、他のプロトコルを使用し、Azure ADドメインサービス(DS)またはLDAPが必要なハイブリッドAD環境でのLDAP機能を容易にします。

Azure AD DSは、Azure内に展開された仮想マシンおよびWindowsレガシーアプリケーションのドメインコントローラとしてのサービスとして請求されます。 これは、時間のために課金され、価格はディレクトリオブジェクトの数に基づいています。

Azure ADでLDAPを使用したい場合、特にオンプレミスのアプリケーションやストレージシステムの認証には、非常に困難な場合があります。 多くのIT組織は、追加のLDAPサーバーを展開することを選択します。 多くの場合、このLDAPサーバーはJumpCloudのLDAP-as-a-Serviceソリューションを介してクラウドにデプロイされます。

最近のクラウドへの移行や異種の職場への移行により、クラウドリソースと連携し、異なるオペレーティングシステムに対応できるより柔軟なディレクトリソリュー ADのMicrosoft WindowsおよびAzure中心のアプローチは、OSが多様な環境を持つ多くの企業にとってはもはや実行可能ではなく、多くの企業は、成長、多様化、分散するインフ ADおよびon-premディレクトリに関するこれらの新たな課題は、企業がクラウドLDAP、最終的にはDirectory-as-a-Serviceに移行することを促しました。

クラウドLDAPは、コアディレクトリインフラストラクチャの設定と保守から、アプリケーションやシステムをLDAPベースのIdPに統合するまで、企業のディレ クラウドLDAPを使用すると、サーバーはすでにそこにあり、企業がLDAPに接続されたエンドポイントをそれらに向ける準備ができています。

クラウドディレクトリサービスは、他のプロトコルも使用する傾向があり、その範囲をさらに広げ、新しい技術に対応しながら、オンプレムのActive Directoryサーバーの必要性を排除します。

一部のクラウドLDAPサービスにはGUIとテクニカルサポートが含まれているため、プレーンテキストコードですべてを実行する必要がなくなります(一部のディレ

LDAPはまだ関連していますか？

ディレクトリがクラウドに向かって移動しており、LDAPがオンプレミス環境で動作するように構築されている場合、LDAPはまだ関連していますか？

クラウドアプリケーションがビジネス標準になり、ITネットワークがより分散化され、これらの進化するニーズを満たすための新しいプロトコルが開発

ディレクトリは、現代の分散型ビジネス環境に対処するためにマルチプロトコルアプローチを採用し始めています。 マルチプロトコルディレクトリは、特定の目的のために多くのプロトコルを活用します。

その結果、各プロトコルはあまり頻繁に使用されませんが、そのユースケースに非常に適しており、堅牢なマルチプロトコルディレクトリの重要なコンポー

LDAPも例外ではなく、古いディレクトリモデルに比べてディレクトリの機能の割合は小さくなりますが、現代のディレクトリの不可欠な部分です。

マルチプロトコルディレクトリサービスは、柔軟性、オープンソースの遺産、長年にわたる安定性のために、他のプロトコルと一緒にLDAPを使用し続けています。

たとえば、OpenVPN、Jenkins、MySQL、Jira、Confluenceなどの多くのレガシーアプリケーションは、何万もの他のアプリケーション、ストレージシステム、ネットワークデバイス、サーバーなどとともに、LDAPを引き続き使用しています。

LDAPの設定方法

LDAPの設定手順は、使用しているLDAPオファリングによって異なり、手順はクラウドLDAPサーバーを使用しているか、自分で立ち上げているかに

ただし、いずれかのパスを開始する前に、LDAP実装の最初のステップは計画する必要があります: ITチームは、何かを実装する前に、ディレクトリをどのように整理するかを慎重に検討する必要があります。

これには、ディレクトリに含めるリソース、ユーザーグループを分離してアクセス許可を割り当てる方法、対応する必要があるオペレーティングシステム、リモートワーカーを統合する方法、セキュリティパラメータ、ほぼ100%の可用性を確保するために行うこと、組織の成長計画などが含まれます。

最初の計画は、環境に適しており、成長と変化に対応するための適切な配置の組織化されたディレクトリを構築するために重要です。 たとえば、10人の組織であるが、大幅に拡大する予定がある場合は、各部門が1人または2人のユーザーだけで始まっていても、組織的な成長を可能にす

計画ステップは、組織が独自のディレクトリを構築するために特に重要です; ただし、どのLDAPソリューションがニーズに最も適しているかを組織が理解するのにも役立ちます。

ディレクトリレイアウトを計画し、LDAPプロバイダーを選択した後(またはオープンソースLDAPを選択した後)、LDAPサーバーを設定する必要があります。

ON-Prem LDAP設定:

独自のLDAPインスタンスをホストしている場合は、LDAPサーバーを立ち上げる必要があります。 LDAPディレクトリをインストールおよび構成する手順は、使用するLDAPインスタンスによって異なります。 OpenLDAPはおそらく市場で最も人気のあるLDAPインスタンスですが、いくつかのLDAPサーバーから選択できます。 OpenLDAPディレクトリを作成するためのMITの手順は次のとおりです。

クラウドLDAPの設定:前述したように、クラウドLDAPの設定とメンテナンスは最小限であるため、多くの企業が従来のon-premオプションよりもそれを選択した理由の一つである。 Cloud LDAPのサーバーステップでは、自分で立ち上げるのではなく、cloud LDAPサーバーにサブスクライブする必要があります。 LDAPソリューションを選択する前に慎重に計画する必要がありますが、ほとんどのプロバイダは、変更を容易にするユーザーフレンドリーなGUIを介してディレ

無料のLDAPサーバー(ハードウェアを含む)はあまりありませんが、いくつかの無料のLDAPソフトウェアオプションがあります。 次にそれらを探索します。

LDAPプロバイダー

LDAPがなければ、一般的にユーザーアカウントとアクティビティの可視性がなく、リソースアクセスを手動で管理するため、冗長性、摩擦、セキュリテ 組織は、ソリューションを実装するコストが、時間のかかる手動管理のコストとそれに関連するリスクよりも少ないことを認識すると、LDAPを見始めるこ ほとんどの企業が考慮する主なLDAPソリューションがいくつかあります:

Active Directory(AD)

ADは、LDAPとKerberosを使用してITリソースに対するユーザーを認証します。 Microsoft製品として、Windowsベースの環境に最適です。 ADを使用するには、IT管理者がADを含むWindows Serverのライセンス料を支払う必要があります。 これは、IT組織がMicrosoft製品でよく知っている従来のライセンスモデルを表しています。 最後に、ADでは、on-premリソースに対してリモートユーザーを認証するために、VPNやSD-WANなどの何らかの形式のリモートアクセスが必要です。 Azure Active Directoryは最近、ADの拡張機能として登場しましたが、真のネイティブLDAP機能はありません。

OpenLDAP

前述のように、OpenLDAPはダウンロードに何の費用もかかりません。 しかし、インフラストラクチャの設定と継続的な管理は、かなりのコストで囲まれています。 そのオープンソースのルーツのために、OpenLDAPはLinuxおよびUnixベースのOsで素晴らしい作品なので、あなたは多くのDevOps環境でそれを見つけることができます。 ADと同様に、on-premリソースを認証するにはVPNが必要です。

Cloud LDAP

クラウドベースのLDAPはベンダーに依存せず、さまざまなITリソースと連携します。 代わりに、ユーザーのデバイス上の軽量エージェントは、各セッションの開始時に安全なTLS接続を確立し、ユーザーがVPNなしでLDAPリソースに安全に接続できるよ クラウドLDAPサービスには、多くの場合、追加のプロトコルが提供されているため、一つのツールでユーザーに事実上すべてのリソー

LDAPの長所と短所

LDAPの利点は何ですか？

• オープンソース: それは多くの場合、ダウンロードしてすぐにOpenLDAPを試して何も費用はかかりません。
• 標準化:LDAPは、1997年にRFC2251でInternet Engineering Task Force(IETF)標準として批准されました。 このように、業界全体がLDAPをサポートしており、引き続きそうしていきます。
• 柔軟性:開発者とIT管理者は、アプリケーション認証やリモートサーバー認証など、さまざまなユースケースでLDAP認証を利用します。 そして、それは非常に多くの異なる方法で使用されているので、人々がそれを最大限に活用するのに役立つプロトコルを取り巻くコミュニティがあ
• デバイスに依存しない:本質的に、LDAPは異なるオペレーティングシステムとデバイスと互換性があります。 たとえば、ADはWindows中心であり、多くの場合、追加のオペレーティングシステムとシームレスに動作するためにアドオンが必要です。
• セキュア:元の例では、LDAPはクリアテキストで送信されましたが、SSL(LDAPS)またはTLS(STARTTLS)を介してLDAP通信を暗号化するオプションがあります。 STARTTLSは理想的なオプションであり、LDAPは第二に来ると、非常に安全です—クリアテキストを使用するのではなく、常に可能な限り（今、ほとんどどこでも）二つの LDAPとLDAPSの詳細については、ブログをご覧ください。

LDAPの欠点は何ですか？

• 年齢：LDAPは古いプロトコルです。 SAMLのような新しい認証プロトコルは、webアプリケーションを使用する最新のクラウド転送IT環境用に構築されています。
• On-Prem:LDAPは伝統的にOpenLDAPサーバーでon-premで設定されており、簡単な作業ではありません。 クラウドに移行する組織にとっては、クラウドITリソースにブリッジするオンプレム認証メカニズムを設定する必要は理想的ではありません。
• 専門知識:LDAPのセットアップとメンテナンスには一般的に専門家が必要です。 このレベルの技術的な知識を持つ人々は、見つけるのが難しく、高価になる可能性があります。 これは特にOpenLDAPに当てはまります。
• 重要な立ち上げ:組織が大きくなればなるほど、新しいディレクトリを開始することは困難になります。 ディレクトリは基本的に組織内のすべてのコンポーネントの統合であるため、新しいディレクトリをゼロから構築したり、あるディレクトリから別の 幸いなことに、JumpCloudのようないくつかのクラウドディレクトリプラットフォームは、セットアップガイダンスを持っており、ADのような既存のディレ

完全なクラウドディレクトリへのLDAPの拡張

Cloud LDAPは、クラウドホストサーバーを使用して、ユーザーがすべてのオンプレミスリソースへのアクセスを提供します。 クラウドディレクトリプラットフォームは、SAML、OAuth、RADIUS、SCIM、WebAuthnなどの他のプロトコルとLDAPを組み合わせて、webおよびクラウドベースのリソースへの安全な認証と承認を容易にするようになりました。

一部のLDAPインスタンスは、安全なWiFiおよびVPNアクセスを容易にするためのRADIUS、安全なファイル承認のためのSamba、自動化されたwebベースのidプロビジョニングのためのSAML、JITおよびSCIMなど、他のプロトコルと統合されています。

その結果、ユーザーを管理し、必要なすべてのITリソースへのアクセスを許可するコアディレクトリが作成されます。

JumpcloudによるクラウドLDAPおよびそれ以降

JumpCloud directory platformは、LDAPサービスおよびアプリケーションと直接統合した最初の包括的なクラウドディレクトリサービスでした。 さらに、JUMPCLOUDはLDAPとRADIUS、SAML、Samba、WebAuthn、SCIM、およびその他のプロトコルを組み合わせて、ユーザーを作業を実現するために必要なITに接続します。

JUMPCLOUDは、IAMとデバイス管理に加えて、multi-factor authentication(MFA)などのツールを使用してゼロ信頼セキュリティアプローチを適用し、クロスプラットフォームのデバイス管理を容易にして、すべてのデバイスを安全かつ正しく構成し、管理者とユーザーの両方にユーザーフレンドリーなGUIを提供します。

JumpCloudのクラウドLDAPオファリングについての詳細を学ぶか、無料でプラットフォームを試してみてください—それはあなたの最初の10人のユーザーとデバ