概要
LDAP (ライトウェイト・ディレクトリ・アクセス・プロトコル) は、組織や人物などに関するデータの検索を支援するプロトコルです。LDAP の主な目的は 2 つあります。1 つは LDAP ディレクトリにデータを保存すること、もう 1 つはディレクトリにアクセスするユーザーを認証することです。また、アプリケーションがディレクトリサービスと情報をやり取りする際に必要となる通信言語も提供します。ディレクトリサービスは、ネットワーク内で組織や個人の情報、その他のデータが保存されている場所へのアクセスを提供します。
LDAP の最も一般的なユースケースは、ディレクトリサービスへのアクセスと管理を一元的に行う場所を提供することです。LDAP により、組織とその人員、資産に関する情報 (ユーザー名やパスワードなど) を保存、管理、保護できます。情報を階層構造にすることでストレージへのアクセスが単純化され、企業が成長して取得するユーザーデータや資産が増えるにつれて、LDAP は不可欠なものになります。
また、LDAP は、Kerberos とシングルサインオン (SSO)、Simple Authentication Security Layer (SASL)、Secure Sockets Layer (SSL) をサポートするなど、ユーザー認証のための ID およびアクセス管理 (IAM) ソリューションとしても役立ちます。
LDAP とActive Directory
LDAP は、マイクロソフトの Active Directory (AD) ディレクトリサービス (ネットワーク内のあらゆるユーザーアカウントの情報を保管する大規模なディレクトリ・サービス・データベース) で使用されているコアプロトコルです (ただし、専用ではありません)。具体的には、LDAP はディレクトリ・アクセス・プロトコル (DAP) の軽量版であり、TCP/IP (伝送制御プロトコル/インターネット・プロトコル) で実行されるディレクトリサービスへのアクセスと管理を一元的に行う場所を提供します。最新バージョンは LDAPv3 です。
AD は、ユーザーおよびグループの認証と管理を行い、最終的にユーザーまたはコンピュータを認証します。データベースには、LDAP にプルされるものよりも多くの属性が含まれています。ただし、LDAP は情報の少ないディレクトリ・オブジェクトを見つけることに特化しているため、AD などのプル元のディレクトリサービスからすべての属性を抽出する必要はありません。
LDAP の主な目的は、AD と通信してオブジェクト (ドメイン、ユーザー、グループなど) を抽出し、LDAP サーバー上にある専用ディレクトリで使用可能な形式に変換して保存することです。
次のように考えてみましょう。AD は世界最大の図書館であり、あなたはタイトルに「ゾンビ」が含まれる本を探しているとします。LDAP の世界では、その本が米国で出版されたものか、1,000 ページを超えているか、ゾンビの世界を生き抜くためのハウツーガイドであるかといった詳細は、(選択肢を絞り込むのには役立ちますが) 重要ではありません。LDAP は経験豊富な司書です。あなたのリクエストを満たすものがどこにあるかを正確に把握しており、探しているものが見つかったことを確認します。
Red Hat を使用した Linux セキュリティの最適化
LDAP 認証プロセス
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 つのユーザー認証方法のいずれかを実行します。1 つはログイン認証情報を使用した SSO などの簡易認証、もう 1 つは LDAP サーバーを Kerberos などのプログラムにバインドする SASL 認証です。ログインを試行すると、ユーザーに割り当てられた DN を認証するための要求が送信されます。DN は、クライアント API (または DSA を起動するサービス) を介して送信されます。
クライアントは自動的に DSA にバインドされ、LDAP は DN を使用して LDAP データベース内のレコードと一致する オブジェクトまたはオブジェクトセットを検索します。この段階で、DN 内の RDN が非常に重要になります。LDAP が DIT をたどって個人を検索する際のステップになるからです。バックエンドで接続する RDN がパスにない場合、結果が無効になることがあります。この場合、オブジェクト LDAP で検索されるのは個々のユーザーアカウント (cn=Susan) です。ディレクトリ内のアカウントに一致する uid と userPassword がある場合にのみ、そのユーザーを検証できます。ユーザーグループは、LDAP ディレクトリ内のオブジェクトとしても識別されます。
ユーザーが応答 (有効または無効) を受信すると、クライアントは LDAP サーバーからバインド解除されます。認証されたユーザーは、システム管理者によって付与されたアクセス権に基づいて、必要なファイル、ユーザー情報、その他のアプリケーションデータを含めて、API とそのサービスにアクセスできます。
LDAP コンポーネントの説明
LDAP は、その軽量な構造と DIT の使用により、迅速に LDAP 検索を実行して結果を返すことができます。LDAP サーバーを適切に操作し、LDAP 検索の仕組みを理解するには、DIT を理解することが不可欠です。
DIT により、LDAP ディレクトリのさまざまなレベルをすばやく移動して、検索結果を絞り込み、クエリに応答することができます。DIT はルートディレクトリから始まり、次に国、さらにドメインコンポーネント (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 は名前属性の値になります。
cn=Susan アカウントでは、ユーザー ID (uid) と userPassword は属性であり、ユーザーのログイン認証情報は値です。ただし、cn=developers などのグループでは、Susan は uniqueMember 属性を持つことになります (例:uniqueMember=cn-Susan,ou-Users,o-Company)。これにより、Susan の個人ユーザーアカウントがある場所へのパスと、LDAP が検索している情報がマッピングされます。ユーザーアカウントは DIT の末端であり、LDAP が最終的に検索結果を抽出する場所です。
他にも、organizationalPerson (structural) や personal (structural) といった ObjectClass など、検索の絞り込みに役立つ属性タイプや構文は数多くあります。ただし、軽量で使いやすい状態に保つために、LDAP の属性の数は制限されています。
LDAP を使用する理由
エンタープライズ・ネットワークの管理者は通常、同時に数千人ものユーザーを管理しています。ユーザーのロールと、会社のイントラネットなどの日常業務で使用するファイルへのアクセス権に基づいて、アクセス制御とポリシーを割り当てる責任を負っています。
LDAP はユーザー管理プロセスを単純化し、ネットワーク管理者の貴重な時間を節約し、認証プロセスを一元化します。LDAP を環境に統合する前に、次の点を検討することが重要です。
容量:どの程度のユーザー管理データを保存する必要がありますか。LDAP ソリューションを実装する製品に、必要なすべてのデータを保存および管理できる容量があるかどうかを検討します。
検索の頻度:会社のイントラネット、E メールアプリケーションまたはサービスなど、ユーザーが毎日アクセスする必要のあるデータはありますか。ある場合は、LDAP が適しているかもしれません。
整理:LDAP のシンプルな DIT でデータを十分に整理できますか。それとも、より詳細なシステムが必要ですか。
LDAP は主に AD で使用されますが、UNIX 上の Red Hat Directory Server や、Windows 上のオープンソース・アプリケーションである OpenLDAP など、他のツールやクライアント環境のユーザー認証にも使用できます。また、LDAP の認証機能とユーザー管理機能は、API 管理、ロールベースのアクセス制御 (RBAC)、その他のアプリケーションやサービス (Docker や Kubernetes など) にも活用できます。
Red Hat Enterprise Linux の LDAP 認証
Red Hat® Enterprise Linux® は一元的な ID 管理機能を備えており、データセンター全体をカバーする単一のスケーラブルなインタフェースを使用してユーザーを認証し、ロールベースのアクセス制御を実装できます。
Red Hat Enterprise Linux の ID 管理には、次のような幅広い認証および認可機能が含まれています。
- 一元化された ID 管理:Red Hat Enterprise Linux は一元化された ID 管理を促進します。これによってセキュリティ制御の適用、コンプライアンス基準への適合、認証ポリシーの一元的な管理が可能になるため、プラットフォーム間の一貫性を確保し、ユーザーエクスペリエンスを向上させ、IT の負担を軽減することができます。
- 多要素認証 (MFA) およびパスワードレス機能:Red Hat Enterprise Linux は多要素認証 (MFA) に対応しており、ID 確認を二重化できます。Red Hat Enterprise Linux は、FIDO2/WebAuthn やパスキー派生 Kerberos チケットによる SSH や GDM へのログインなど、パスワードレス認証をサポートすることでゼロトラスト・アーキテクチャ (ZTA) の成熟度を向上させ、セキュリティを単純な MFA からフィッシング耐性のある適応型の認証へと進化させます。
- 外部 ID プロバイダーとの統合:Red Hat Enterprise Linux はユーザーが OAuth 2.0 を使用してクライアント経由で認証することを可能にするほか、Keycloak、Entra ID (Azure AD)、GitHub などの外部の ID プロバイダーと統合されています。これにより、認証と認可のプロセスを外部エンティティに委任することが可能になり、多様な IT 環境内での柔軟性と相互運用性が向上します。
- ポリシーと証明書の包括的な管理: Red Hat Enterprise Linux には、ID 管理 (IdM) サーバーの管理を委任するためのロールベースのアクセス制御や、特権昇格を制限するカスタム sudo ルールなど、カスタマイズされたセキュリティポリシー管理を行うための機能が備わっています。また、証明書のライフサイクル全体を自動化する堅牢な証明書管理ツールも提供されるため、有効期限の追跡やタイムリーな更新の確実な実施が可能であるのに加え、ZTA の主要コンポーネントである公開鍵基盤 (PKI) を使用して信頼できる ID の検証を行うこともできます。
- システムロールによる自動化とオーケストレーション:Red Hat Enterprise Linux では、(Ansible Automation Platform を活用した) Red Hat システムロールを使用して、セキュリティの構成と管理を自動化できます。クラウドからオンプレミスまですべての環境にわたって一貫性とコンプライアンスを大規模に確保し、手作業や潜在的な構成ミスを削減するためには、このような自動化が不可欠です。システムロールは、CISA ZTA フレームワークの自動化およびオーケストレーション・レイヤーに組み込まれています。
Red Hat では、より特殊なニーズを持つお客様のために、Red Hat Directory Server をアドオンとして提供しています。
Red Hat Directory Server は LDAP ベースのディレクトリであり、大規模で多様な環境に合わせて拡張できます。既存のコストの高いサードパーティの LDAP ソリューションから、ほぼそのまま置き換えることが可能で、さまざまなレプリケーション・オプションを利用して複雑な分散型ディレクトリトポロジーを管理できます。このソリューションにより、ディレクトリデータの属性とスキーマをカスタマイズできるようになり、柔軟性が向上します。
Red Hat 公式ブログ
Red Hat のお客様、パートナー、およびコミュニティのエコシステムに関する最新の情報を入手しましょう。