LDAP (ライトウェイト・ディレクトリ・アクセス・プロトコル) 認証とは

LDAP (ライトウェイト・ディレクトリ・アクセス・プロトコル) は、ユーザーが組織、個人などに関するデータを検索するために役立つプロトコルです。LDAP には主に 2 つの目的があります。それは、LDAP ディレクトリにデータを格納すること、ディレクトリにアクセスするユーザーを認証することです。また、アプリケーションがディレクトリサービスとの間で情報を送受信するために必要な通信言語を提供します。ディレクトリサービスは、ネットワーク内の組織、個人、およびその他のデータに関する情報がある場所へのアクセスを提供します。

最も一般的な LDAP のユースケースは、ディレクトリサービスにアクセスし、それを管理するための中心的な場所を提供することです。組織は LDAP を使用することにより、組織、そのユーザー、および資産 (ユーザー名やパスワードなど) に関する情報を保存し、管理し、保護することができます。LDAP は情報を階層化するため、ストレージアクセスを単純化するために役立ちます。また、規模が拡大してユーザーデータや資産が増加している組織にとっては重要である可能性があります。

LDAP は、ユーザー認証を対象とした ID およびアクセス管理 (IAM) ソリューションとしても機能し、Kerberos とシングルサインオン (SSO)、Simple Authentication Security Layer (SASL)、および Secure Sockets Layer (SSL) をサポートしています。

何が LDAP 検索を促し、どのように機能するのでしょうか。

LDAP 認証プロセスは、クライアントとサーバー間の認証モデルであり、次の主要プレーヤーで構成されます。

• ディレクトリ・システム・エージェント (DSA)：ネットワーク上で LDAP を実行するサーバー
• ディレクトリ・ユーザー・エージェント (DUA)：クライアントとして DSA にアクセスする (ユーザーの PC など)
• DN：LDAP がナビゲートするディレクトリ情報ツリー (DIT) のパスを含む識別名 (例： cn=Susan, ou=users, o=Company)
• 相対識別名 (RDN)：DN 内のパスの各コンポーネント (例：cn=Susan)
• アプリケーション・プログラミング・インタフェース (API)：他の製品やサービスがどのように実装されているかを知らなくても、利用中の製品やサービスをそれらと通信させることができる

このプロセスは、ユーザーが自分の PC で、ビジネス E メール・アプリケーションのような LDAP 対応のクライアントプログラムにアクセスしようしたときに開始されます。LDAPv3 では、ユーザーは 2 つのユーザー認証方法、すなわち、ログイン認証情報を使用した SSO などの単純な認証、または LDAP サーバーを Kerberos などのプログラムにバインドする SASL 認証のいずれかを経由します。ログインの試行により、ユーザーに割り当てられた DN を認証するための要求が送信されます。DN は、DSA を起動するクライアント API またはサービスを通じて送信されます。

クライアントは自動的に DSA にバインドし、LDAP は DN を使用して、LDAP データベース内のレコードに対して一致するオブジェクトまたはオブジェクトのセットを検索します。DN の RDN は、LDAP が DIT を介して個人を検索するための手段となるものであり、この段階で非常に重要です。バックエンドでパスに接続している RDN がない場合、結果が無効になる可能性があります。この場合、LDAP が検索するオブジェクトは個々のユーザーアカウント (cn=Susan) であり、ディレクトリ内のアカウントに一致する uid と userPassword がある場合にのみユーザーを認証できます。ユーザーグループは、LDAP ディレクトリ内のオブジェクトとしても識別されます。

ユーザーが応答 (有効または無効) を受信すると、クライアントは LDAP サーバーとのバインドを解除します。認証されたユーザーは、システム管理者によって付与されたアクセス許可に基づいて、必要なファイル、ユーザー情報、その他のアプリケーションデータを含め、API とそのサービスにアクセスできます。

LDAP が軽量構造であること、DIT を使用することにより、LDAP 検索を迅速に実行し、結果を正しく提供できます。DIT を理解することは、LDAP サーバーを適切にナビゲートし、LDAP 検索の仕組みを理解するために不可欠です。

DIT を使用すると、LDAP ディレクトリのさまざまなレベルをすばやくナビゲートして、検索結果を絞り込み、クエリに応答することができます。DIT は root ディレクトリから始まり、次に国が続き、ドメインコンポーネント (dc) と組織名 (o) の 2 つのサブクラスに分岐します。

ドメイン・アクセス・コンポーネント  (dc)

dc (つまり、dc=com, dc=example) は、ドメインネームシステム (DNS) マッピングを使用して、インターネットドメイン名を検索し、それらを IP アドレスに変換します。

ほとんどのユーザーは、検索している個人のドメイン名や IP アドレスを知りません。この場合、LDAP はユーザーに割り当てられた識別名 (DN) をパスとして使用し、DIT をすばやくナビゲートして検索結果を見つけます。ここでサブクラス o が登場します。

組織名 (o)

サブクラス o (例：o-Company) は、DN にリストされている最も一般的なサブクラスの 1 つであり、通常、LDAP が検索を最初に開始する場所です。たとえば、単純なパスは通常サブクラス o で始まり、組織単位 (ou) に分岐し、その後にユーザーアカウントまたはグループが続きます。

組織単位 (ou)

前述のように、ou は o のサブクラスであり、多くの場合、ou=users または ou=group と見なされ、それぞれにユーザーアカウントまたはグループのリストが含まれます。これがディレクトリ内でどのように表示されるかを示します。

• o-Company

  • ou=groups

    • cn=developers

  • ou=users

    • cn=Susan 

共通名 (cn)

共通名 (cn) は、グループまたは個々のユーザーアカウントの名前を識別するために使用されます (例：cn=developers, cn=Susan)。ユーザーはグループに属することができるため、Susan が開発者の場合、cn=developers に属することもできます。

属性および値

LDAP DIT の各サブクラス (つまり、o、ou、cn) には、属性と値、または検索を絞り込むために役立つ LDAP ディレクトリの構造に関する情報を含むスキーマが含まれています。属性はアドレス帳の項目と似ており、名前、電話番号、住所などのラベルがあり、各属性に値が割り当てられています。たとえば、Susan は name 属性の値になります。

cn=Susan のアカウントでは、ユーザー ID (uid) と userPassword が属性で、ユーザーのログイン認証情報が値です。しかし、cn=developers のようなグループでは、Susan は uniqueMember 属性を持ちます (例： uniqueMember=Susan, ou-Users, o-Company)。これにより、Susan の個々のユーザーアカウントが存在する場所へのパスと、LDAP が検索している情報が関連付けられます。ユーザーアカウントは DIT の行末であり、LDAP が最終的に検索結果を抽出する場所です。

organizationalPerson (構造型) や personal (構造型) のような ObjectClasses など、検索を絞り込むために役立つ属性タイプや構文は他にも多数あります。しかし、軽量で使いやすくするために、LDAP の属性の数は制限されています。

組織のネットワーク管理者は通常、一度に数千のユーザーを管理しています。つまり、ユーザーのロールに基づくアクセス制御とポリシーの割り当てや、会社のイントラネットなどの日常業務用のファイルへのアクセス権の割り当てを行っています。

LDAP は、ユーザー管理プロセスを単純化し、ネットワーク管理者の貴重な時間を節約し、認証プロセスを一元化します。LDAP を組織の環境に組み入れる前に、次の点を考慮することが重要です。

• 容量：保存する必要があるユーザー管理データの量はどのくらいですか。LDAP ソリューションを実装する製品の容量で、必要なデータをすべて格納し、管理できるかを検討しましょう。

• 検索頻度：ユーザーが毎日アクセスする必要があるデータ (会社のイントラネット、E メールアプリケーション、またはサービスなど) はありますか。もしそうなら、LDAP を利用するべきかもしれません。

• 編成：LDAP の単純な DIT でデータを十分に編成できますか。それとも、より詳細なシステムが必要でしょうか。

LDAP は一般に AD で使用されますが、UNIX の Red Hat Directory Server や Windows のオープンソース・アプリケーションである OpenLDAP など、他のツールやクライアント環境のユーザー認証にも使用できます。また、API 管理、ロールベースのアクセス制御 (RBAC)、Docker や Kubernetes などの他のアプリケーションやサービスに対して、LDAP の認証機能とユーザー管理機能を利用することもできます。

Red Hat® Enterprise Linux® は一元化された ID 管理機能を備えており、データセンター全体にまたがる単一の拡張可能なインタフェースを使用して、ユーザー認証と RBAC の実装を行うことができます。

Red Hat Enterprise Linux による ID 管理には、次のようなさまざまな認証および認可機能が含まれています。

• Linux 用のドメインコントローラー：この信頼できる一元化された ID ストア内で、すべてのユーザー、サービス、ホストの ID、アクセス、およびポリシーを一元管理します。これにより、管理オーバーヘッドが削減され、信頼できるセキュリティ境界を作成するためのドメイン登録が単純化されます。ユーザーは、最適化されたユーザー認証エクスペリエンスを得られます。

• AD 統合：Active Directory と Red Hat Enterprise Linux のネイティブ統合により、Linux と Windows 間のユーザー ID のギャップを埋めます。Active Directory をユーザー ID の信頼できる唯一の情報源として使用し、調整されたアクセス制御ポリシーを Linux ドメインに直接適用して、管理効率を向上し、ポリシーの作成場所を一元化します。

• Kerberos SSO：ID 管理認証の中核である Kerberos を使用してユーザー認証プロセスを単純化し、インフラストラクチャの SSO をサポートします。パスワードなしで認証できるようにサービスに拡張し、SSO (Keycloak に基づく) を使用した Web 認証をサポートします。

• システムロール：一貫性のある繰り返し可能な構成ワークフローを利用することで、時間とリソースを節約します。自動化により、長期的にデプロイと ID 管理に関連する技術的負担と手動タスクが大幅に削減されます。

Red Hat は、より専門的なニーズを持つユーザー向けのアドオンとして、Red Hat Directory Server も提供しています。

Red Hat Directory Server は、大規模で多様な環境に合わせて拡張可能な LDAP ベースのディレクトリです。コストのかかる既存のサードパーティ製 LDAP ソリューションを簡単に置き換えることができ、さまざまなレプリケーション方法を使用して、分散型で複雑なディレクトリトポロジーを管理できます。このソリューションは、ディレクトリデータの属性とスキーマをカスタマイズできるようにすることで、柔軟性をもたらします。