OpenLDAPを構成し、管理LDAPタスクを実行する方法

前書き

OpenLDAPシステムの管理は、システムの構成方法や必要な重要な情報の入手先がわからない場合、困難になる可能性があります。 このガイドでは、OpenLDAPサーバーに重要な情報を照会する方法と、実行中のシステムに変更を加える方法を示します。

前提条件

開始するには、OpenLDAPがインストールおよび構成されているシステムにアクセスできる必要があります。 OpenLDAPサーバーのセットアップ方法を学ぶことができますhttps://www.digitalocean.com/community/tutorials/how-to-install-and-configure-openldap-and-phpldapadmin-on-an-an-ubuntu-14-04-サーバー[こちら]。 LDAPディレクトリサービスを使用する際に使用される基本的な用語に精通している必要があります。 https://www.digitalocean.com/community/tutorials/understanding-the-ldap-protocol-data-hierarchy-and-entry-components [このガイド]を使用して、これらのトピックをさらに理解することができます。

OpenLDAPオンライン構成

LDAPシステムは、保存するデータを* Directory Information Trees または DITs *と呼ばれる階層構造に整理します。 バージョン2.3以降、OpenLDAPサーバーの実際の設定は特別なDIT内で管理され、通常は `+ cn = config +`と呼ばれるエントリをルートとしています。

この構成システムは、OpenLDAPオンライン構成、または* OLC *と呼ばれます。 サービスの開始時に構成ファイルの読み取りに依存していた非推奨の構成方法とは異なり、OLCに対する変更はすぐに実装され、多くの場合、サービスを再起動する必要はありません。

OLCシステムは、標準のLDAPメソッドを使用して認証および変更を行います。 このため、経験豊富なLDAP管理者の管理は、データDITの操作に使用するものと同じ知識、スキル、ツールを使用できるため、多くの場合シームレスです。 ただし、LDAPを初めて使用する場合は、学習用の環境を構成するためにLDAPツールの使用方法を知る必要があるため、使い始めるのが難しい場合があります。

このガイドでは、LDAPの学習とシステムの管理を開始できるように、この鶏と卵の状況を乗り越えるための基本的なOpenLDAP管理の指導に焦点を当てます。

ルートDSEへのアクセス

まず、ルートDSEと呼ばれる構造について説明します。ルートDSEは、サーバーの個々のDITをすべて保持する構造です。 これは基本的に、サーバーが知っているすべてのDITを管理するために使用されるエントリです。 このエントリから開始することで、サーバーにクエリを実行して、サーバーがどのように構成されているかを確認し、次に進むべき場所を見つけることができます。

DSEは何を表していますか?

ルートDSEにクエリを実行するには、空(null)の検索ベースと「base」の検索スコープで検索を実行する必要があります。 基本検索スコープは、指定されたエントリのみが返されることを意味します。 通常、これは検索の深さを制限するために使用されますが、ルートDSEで操作する場合はこれが必要です(他の検索範囲が選択されている場合、情報は返されません)。

必要なコマンドは次のとおりです。

ldapsearch -H ldap:// -x -s base -b "" -LLL "+"

LDAPサーバー自体からこれを実行しており、まだアクセス制限を設定していないと想定しています。 結果は次のようになります。

ルートDSE出力

dn:
structuralObjectClass: OpenLDAProotDSE
configContext: cn=config
namingContexts: dc=example,dc=com
supportedControl: 2.16.840.1.113730.3.4.18

. . .

supportedLDAPVersion: 3
supportedSASLMechanisms: GS2-IAKERB
supportedSASLMechanisms: GS2-KRB5
supportedSASLMechanisms: SCRAM-SHA-1
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: CRAM-MD5
entryDN:
subschemaSubentry: cn=Subschema

出力を少し切り詰めました。 このLDAPサーバーに関する重要なメタデータを確認できます。 これらの項目のいくつかの意味を少し説明します。 ここでは、この出力を生成したコマンドを見てみましょう。

`+ -H ldap:// `コマンドは、ローカルホストで暗号化されていないLDAPクエリを指定するために使用されます。 認証情報なしの「 -x 」は、匿名接続が必要であることをサーバーに通知します。 検索範囲を伝え、 ` -s base -b" "`で検索ベースをnullに設定します。 ` -LLL `を使用して、無関係な出力を抑制します。 最後に、 `" + "+`は、通常は非表示になる操作属性を表示することを指定します(これは、必要な情報を見つける場所です)。

このサーバーが管理するDITを見つける

ここでの目的のために、この特定のLDAPサーバーがどのDITを提供するように構成されているかを調べようとしています。 上記の出力で見ることができる「+ namingContexts +」操作属性の値としてそれを見つけることができます。

これが必要な情報の唯一の部分である場合、次のようなより適切なクエリを作成できます。

ldapsearch -H ldap:// -x -s base -b "" -LLL "namingContexts"

ここで、値を知りたい正確な属性を呼び出しました。 サーバー上の各DITのベースエントリは、 `+ namingContexts +`属性を通じて利用できます。 これは通常は非表示の操作属性ですが、明示的に呼び出すと返されます。

これにより、他の情報が抑制され、次のようなクリーンな出力が得られます。

namingContexts検索

dn:
namingContexts:

このLDAPサーバーには、 `+ dc = example、dc = com +`の識別名(DN)を持つエントリをルートとする(非管理)DITが1つしかないことがわかります。 サーバーが追加のDITを担当している場合、これにより複数の値が返される可能性があります。

構成DITを見つける

OpenLDAPサーバーの設定に使用できるDITは、 `+ namingContexts `の検索では返されません。 代わりに、config DITのルートエントリは、 ` configContext +`と呼ばれる専用の属性に保存されます。

構成DITのベースDNを学習するには、前と同じように、この特定の属性を照会します。

ldapsearch -H ldap:// -x -s base -b "" -LLL "configContext"

結果は次のようになります。

configContext検索

dn:
configContext:

設定DITは、「+ cn = config +」というDNに基づいています。 これは設定DITと完全に一致する可能性が高いため、ガイド全体で使用します。 構成DITが異なる場合は、指定されたコマンドを変更します。

構成DITへのアクセス

構成DITの場所がわかったので、現在の設定を確認するためにクエリを実行できます。 これを行うには、実際にこれまで使用してきた形式と少し異なる必要があります。

このDITを使用してLDAPシステムの設定を変更できるため、いくつかのアクセス制御が設定されています。 デフォルトでは、OSのrootまたは `+ sudo +`ユーザーの管理を許可するように設定されています。

必要なコマンドは次のようになります。

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=config" -LLL -Q

これを機能させるには、コマンドの前に `+ sudo `を使用し、以前の ` ldapsearch `コマンドの ` -x `を ` -Y EXTERNAL `に置き換えて、SASL認証方法を使用することを示す必要があります。 。 また、Unixソケットを介してリクエストを行うには、プロトコルを「 ldap:// 」から「 ldapi:// 」に変更する必要があります。 これにより、OpenLDAPはオペレーティングシステムユーザーを検証できます。これは、アクセス制御プロパティを評価するために必要です。 次に、検索の基礎として「 cn = config +」エントリを使用します。

結果は、設定の長いリストになります。 簡単に上下にスクロールできるように、ページャーにパイプすることが役立つ場合があります。

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=config" -LLL -Q | less

非常に多くの情報があり、処理するのに多くのことがあることがわかります。 このコマンドは、構成ツリー全体を印刷しました。 情報が整理されて保存されている階層をよりよく理解するには、代わりにさまざまなエントリDNを印刷します。

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=config" -LLL -Q dn

これは、コンテンツ全体ではなくエントリタイトル(DN)自体を表示する、より管理しやすいリストになります。

cn = configエントリDN

dn: cn=config

dn: cn=module{0},cn=config

dn: cn=schema,cn=config

dn: cn={0}core,cn=schema,cn=config

dn: cn={1}cosine,cn=schema,cn=config

dn: cn={2}nis,cn=schema,cn=config

dn: cn={3}inetorgperson,cn=schema,cn=config

dn: olcBackend={0}hdb,cn=config

dn: olcDatabase={-1}frontend,cn=config

dn: olcDatabase={0}config,cn=config

dn: olcDatabase={1}hdb,cn=config

これらのエントリは、LDAPシステムのさまざまな領域が構成されている構成階層を表します。 これらの各エントリで処理される設定を見てみましょう。

トップレベルのエントリには、システム全体に適用されるいくつかのグローバル設定が含まれています(より具体的なコンテキストでオーバーライドされない限り)。 次のように入力すると、このエントリに保存されている内容を確認できます。

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=config" -LLL -Q -s base

このセクションの一般的な項目は、グローバル認証設定、ログレベルの詳細設定、プロセスのPIDファイルの場所へのポインター、SASL認証に関する情報です。

この下のエントリは、システムのより具体的な領域を構成します。 表示される可能性のあるさまざまな種類のエントリを見てみましょう。

管理エントリを検索

`+ cn = config`ダイエットにアクセスできるようになったので、システム上のすべてのDITのルートを見つけることができます。 rootDNは基本的に管理エントリです。 また、そのアカウントへのログインに使用できるパスワード(通常はハッシュされている)を見つけることもできます。

各DITのrootDNを見つけるには、次を入力します。

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=config" "(olcRootDN=*)" olcSuffix olcRootDN olcRootPW -LLL -Q

次のような印刷物が得られます。

rootDN情報

dn: olcDatabase={1}hdb,cn=config
olcSuffix: dc=example,dc=com
olcRootDN: cn=admin,dc=example,dc=com
olcRootPW: {SSHA}AOADkATWBqb0SJVbGhcIAYF+ePzQJmW+

システムが複数のDITを提供している場合は、それぞれに1つのブロックが表示されるはずです。 ここで、 + dc = example、dc = com`に基づくDIRTの管理エントリが + cn = admin、dc = example、dc = com`であることがわかります。 ハッシュ化されたパスワードも確認できます。

スキーマ情報の表示

LDAPスキーマは、システムで使用可能なobjectClassesおよび属性を定義します。 実行時にスキーマをシステムに追加して、さまざまなオブジェクトのタイプと属性を使用可能にすることができます。 ただし、特定のプロパティはシステム自体に組み込まれています。

組み込みスキーマを表示する

組み込みスキーマは、 `+ cn = schema、cn = config +`エントリにあります。 次のように入力して、LDAPシステムに組み込まれているスキーマを確認できます。

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=schema,cn=config" -s base -LLL -Q | less

これにより、OpenLDAPシステム自体に含まれているスキーマが表示されます。 他のすべてのスキーマとは異なり、これを使用するシステムに追加する必要はありません。

追加のスキーマを表示

ビルトインスキーマは出発点としては便利ですが、エントリで使用したいものがすべて揃っているとは限りません。 従来のLDIFメソッドを使用して、システムにスキーマを追加できます。 これらは、組み込みスキーマを表す `+ cn = schema +`エントリの下のサブエントリとして利用できます。

通常、これらの名前は、角括弧で囲まれた番号の後に、 `+ cn = {0} core、cn = schema、cn = config +`のようなスキーマ名が続きます。 括弧で囲まれた数字は、スキーマがシステムに読み込まれる順序を決定するために使用されるインデックスを表します。 通常、これは追加されるとシステムによって自動的に行われます。

システムにロードされた追加スキーマの名前のみを表示するには、次のように入力できます。

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=schema,cn=config" -s one -Q -LLL dn

出力には、サブエントリの名前が表示されます。 システムにロードされているものに応じて、次のようになります。

追加のスキーマ

dn: cn={0}core,cn=schema,cn=config

dn: cn={1}cosine,cn=schema,cn=config

dn: cn={2}nis,cn=schema,cn=config

dn: cn={3}inetorgperson,cn=schema,cn=config

スキーマ自体と割り当てられたインデックス番号は異なる場合があります。 ベース検索を実行し、関心のある特定のスキーマをリストすることにより、特定のスキーマの内容を表示できます。 たとえば、上記の `+ cn = {3} inetorgperson +`スキーマを見たい場合、次のように入力できます。

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "" -s base -LLL -Q | less

追加のスキーマをすべて印刷する場合は、代わりに次のように入力します。

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=schema,cn=config" -s one -LLL -Q | less

組み込みのスキーマを含むすべてのスキーマを印刷する場合は、代わりにこれを使用します。

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=schema,cn=config" -LLL -Q | less

モジュール、バックエンド、およびデータベース設定

構成DITで関心のある他の領域には、モジュールとさまざまなストレージテクノロジー設定があります。

モジュール

モジュールは、OpenLDAPシステムの機能を拡張するために使用されます。 これらのエントリは、その機能を使用するためにモジュールをポイントしてロードするために使用されます。 実際の構成は、他のエントリを介して行われます。

モジュールのロードに使用されるエントリは、モジュールのロードを順序付けしてさまざまなエントリを区別するために、ブラケットに番号が含まれる「+ cn = module {#} +」で始まります。

次のように入力すると、システムに動的にロードされたモジュールを確認できます。

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=config" -LLL -Q "objectClass=olcModuleList"

現在システムにロードされているモジュールが表示されます。

ロードされたモジュール

dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb

この特定の例には、 `+ hdb +`バックエンドモジュールを使用できる単一のモジュールしかありません。

バックエンド

バックエンドエントリは、データストレージを実際に処理するストレージテクノロジーを指定するために使用されます。

システムでアクティブなバックエンドを確認するには、次を入力します。

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=config" -LLL -Q "objectClass=olcBackendConfig"

その結果、使用中のストレージテクノロジーがわかります。 これは次のようになります。

OpenLDAPアクティブバックエンド

dn: olcBackend={0}hdb,cn=config
objectClass: olcBackendConfig
olcBackend: {0}hdb

データベース

これらのストレージシステムの実際の構成は、個別のデータベースエントリで行われます。 OpenLDAPシステムがサービスするDITごとにデータベースエントリが必要です。 利用可能な属性は、各データベースで使用されるバックエンドによって異なります。

システム上のデータベースエントリの名前をすべて表示するには、次のように入力します。

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=config" -LLL -Q "olcDatabase=*" dn

データベースエントリのDNが表示されます。

データベースエントリ

dn: olcDatabase={-1}frontend,cn=config

dn: olcDatabase={0}config,cn=config

dn: olcDatabase={1}hdb,cn=config

これらのそれぞれの用途について少し説明しましょう。

  • * + olcDatabase = {-1} frontend、cn = config + *:このエントリは、特別な「フロントエンド」データベースの機能を定義するために使用されます。 これは、他のすべてのデータベースに適用されるグローバル設定を定義するために使用される擬似データベースです(オーバーライドされない限り)。

  • * + olcDatabase = {0} config、cn = config + *:このエントリは、現在使用している `+ cn = config +`データベースの設定を定義するために使用されます。 ほとんどの場合、これは主にアクセス制御設定、レプリケーション構成などになります。

  • * + olcDatabase = {1} hdb、cn = config + *:このエントリは、指定されたタイプのデータベース(この場合は + hdb +)の設定を定義します。 これらは通常、アクセス制御、データの保存、キャッシュ、バッファリングの方法の詳細、およびDITのルートエントリと管理の詳細を定義します。

括弧内の数字はインデックス値を表します。 これらは主にシステムによって自動的に作成されます。 エントリを正常に参照するには、エントリに指定された値を置き換える必要があります。

次のように入力すると、これらのエントリの内容を表示できます。

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "" -LLL -Q -s base | less

前のコマンドから返されたエントリDNを使用して、「++」フィールドに入力します。

エントリの運用属性(メタデータ)を印刷します

これまで、主に + cn = config DIRを使用してきました。 このガイドの残りの部分は、通常のDITにも適用されます。

各エントリには、管理メタデータとして機能する操作属性があります。 これらは、エントリに関する重要な情報を見つけるために、DITでアクセスできます。

エントリのすべての操作属性を印刷するには、エントリの後に特別な「」属性を指定できます。 たとえば、 ` dc = example、dc = com +`のエントリの操作属性を出力するには、次のように入力できます。

ldapsearch -H ldap:// -x -s base -b "dc=example,dc=com" -LLL "+"

これにより、すべての操作属性が出力されます。 次のようになります。

[list operational attributes]
dn: dc=example,dc=com
structuralObjectClass: organization
entryUUID: cdc658a2-8c3c-1034-8645-e30b83a2e38d
creatorsName: cn=admin,dc=example,dc=com
createTimestamp: 20150511151904Z
entryCSN: 20150511151904.220840Z#000000#000#000000
modifiersName: cn=admin,dc=example,dc=com
modifyTimestamp: 20150511151904Z
entryDN: dc=example,dc=com
subschemaSubentry: cn=Subschema
hasSubordinates: TRUE

これは、特に誰がいつエントリを変更または作成したかを確認するのに役立ちます。

サブスキーマの使用

サブスキーマは、使用可能なクラスと属性の表現です。 + cn = config + DITのスキーマエントリと同様の情報が、追加情報とともに表示されます。 これは、通常の非構成DITを介して利用できるため、ルートアクセスは必要ありません。

サブスキーマを見つける

エントリのサブスキーマを見つけるには、上記のようにエントリのすべての操作属性をクエリするか、エントリのサブスキーマを定義する特定の属性( + subschemaSubentry +)を要求できます。

ldapsearch -H ldap:// -x -s base -b "dc=example,dc=com" -LLL subschemaSubentry

これにより、現在のエントリに関連付けられているサブスキーマエントリが出力されます。

[list subchema entry]
dn: dc=chilidonuts,dc=tk
subschemaSubentry:

ツリー内のすべてのエントリが同じサブスキーマを共有することは一般的であるため、通常、各エントリに対してこれをクエリする必要はありません。

サブスキーマの表示

サブスキーマエントリの内容を表示するには、上記で見つかったサブスキーマエントリを「ベース」のスコープでクエリする必要があります。 すべての重要な情報は操作属性に保存されるため、特別な「+」セレクターを再度使用する必要があります。

必要なコマンドは次のとおりです。

ldapsearch -H ldap:// -x -s base -b "<^>cn=subschema" -LLL "+" | less

これにより、サブスキーマエントリ全体が印刷されます。 探している情報の種類に基づいてフィルタリングできます。

LDAP構文の定義を表示する場合は、次のように入力してフィルタリングできます。

ldapsearch -H ldap:// -x -s base -b "cn=subschema" -LLL ldapSyntaxes | less

エントリと一致するための検索の処理方法を制御する定義を表示するには、次のように入力します。

ldapsearch -H ldap:// -x -s base -b "cn=subschema" -LLL matchingRules | less

一致ルールを使用して一致するアイテムを確認するには、次のように入力します。

ldapsearch -H ldap:// -x -s base -b "cn=subschema" -LLL matchingRuleUse | less

使用可能な属性タイプの定義を表示するには、次を使用します。

ldapsearch -H ldap:// -x -s base -b "cn=subschema" -LLL attributeTypes | less

objectClass定義を表示するには、次を入力します。

ldapsearch -H ldap:// -x -s base -b "cn=subschema" -LLL objectClasses | less

結論

OpenLDAPサーバーの運用は最初は難しいように思えますが、構成DITとシステム内のメタデータの検索方法を理解することで、すぐに使い始めることができます。 LDIFファイルで + cn = config + DITを変更すると、実行中のシステムにすぐに影響する可能性があります。 また、DITを介してシステムを構成すると、LDAPツールのみを使用してリモート管理をセットアップできる可能性があります。 これは、LDAP管理とサーバー管理を分離できることを意味します。