OpenLDAPを設定して管理LDAPタスクを実行する方法
序章
システムの構成方法や必要な重要な情報の場所がわからない場合、OpenLDAPシステムの管理は難しい場合があります。 このガイドでは、OpenLDAPサーバーに重要な情報を照会する方法と、実行中のシステムに変更を加える方法を示します。
前提条件
開始するには、OpenLDAPがインストールおよび設定されているシステムにアクセスできる必要があります。 OpenLDAPサーバーの設定方法についてはこちらをご覧ください。 LDAPディレクトリサービスを使用するときに使用される基本的な用語に精通している必要があります。 このガイドは、これらのトピックをよりよく理解するために使用できます。
OpenLDAPオンライン設定
LDAPシステムは、格納するデータを Directory InformationTreesまたは略してDITsと呼ばれる階層構造に編成します。 バージョン2.3以降、OpenLDAPサーバーの実際の構成は、通常cn=config
というエントリをルートとする特別なDIT内で管理されます。
この設定システムは、OpenLDAPオンライン設定またはOLCとして知られています。 サービスの開始時に構成ファイルの読み取りに依存していた非推奨の構成方法とは異なり、OLCに加えられた変更はすぐに実装され、多くの場合、サービスを再起動する必要はありません。
OLCシステムは、標準のLDAPメソッドを使用して、認証と変更を行います。 このため、経験豊富なLDAP管理者の管理は、データDITの操作に使用するのと同じ知識、スキル、およびツールを使用できるため、シームレスであることがよくあります。 ただし、LDAPを初めて使用する場合は、学習用の環境を構成するためにLDAPツールの使用方法を知る必要があるため、開始するのが難しい場合があります。
このガイドでは、LDAPの学習とシステムの管理を開始できるように、この鶏が先か卵が先かという状況を乗り越えるための基本的なOpenLDAP管理について説明します。
ルートDSEへのアクセス
まず、ルートDSEと呼ばれる構造について説明します。これは、サーバーの個々のDITをすべて保持する構造です。 これは基本的に、サーバーが認識しているすべてのDITを管理するために使用されるエントリです。 このエントリから開始することで、サーバーにクエリを実行して、サーバーがどのように構成されているかを確認し、次に進む場所を見つけることができます。
DSEは何の略ですか?
DSEは、「DSA固有のエントリ」の略で、LDAPサーバーの管理または制御エントリです。 DSAは「ディレクトリシステムエージェント」の略で、基本的にLDAPプロトコルを実装するディレクトリサーバーを意味します。
ルートDSEを照会するには、空白(null)の検索ベースと「ベース」の検索範囲で検索を実行する必要があります。 基本検索範囲は、指定されたエントリのみが返されることを意味します。 通常、これは検索の深さを制限するために使用されますが、ルートDSEで操作する場合は、これが必要です(他の検索範囲が選択されている場合、情報は返されません)。
必要なコマンドは次のとおりです。
- ldapsearch -H ldap:// -x -s base -b "" -LLL "+"
LDAPサーバー自体からこれを実行しており、アクセス制限をまだ設定していないことを前提としています。 結果は次のようになります。
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
属性を介して利用できます。 これは通常は非表示になる操作属性ですが、明示的に呼び出すと返されます。
これにより、他の情報が抑制され、次のようなクリーンな出力が得られます。
dn:
namingContexts: dc=example,dc=com
このLDAPサーバーには、dc=example,dc=com
の識別名(DN)を持つエントリをルートとする(非管理)DITが1つしかないことがわかります。 サーバーが追加のDITを担当している場合、これによって複数の値が返される可能性があります。
構成DITを見つける
OpenLDAPサーバーの設定に使用できるDITは、namingContexts
の検索では返されません。 代わりに、構成DITのルートエントリは、configContext
と呼ばれる専用の属性に格納されます。
構成DITのベースDNを学習するには、以前と同じように、この特定の属性を照会します。
- ldapsearch -H ldap:// -x -s base -b "" -LLL "configContext"
結果はおそらく次のようになります。
dn:
configContext: cn=config
構成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)自体が表示されます。
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にアクセスできるようになったので、システム上のすべてのDITのrootDNを見つけることができます。 rootDNは、基本的に管理エントリです。 また、そのアカウントへのログインに使用できるパスワード(通常はハッシュ化されている)を見つけることもできます。
各DITのrootDNを見つけるには、次のように入力します。
- sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=config" "(olcRootDN=*)" olcSuffix olcRootDN olcRootPW -LLL -Q
次のようなプリントアウトが表示されます。
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
に基づくDITの管理エントリが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 "cn={3}inetorgperson,cn=schema,cn=config" -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"
その結果、使用されているストレージテクノロジーがわかります。 次のようになります。
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 "entry_to_view" -LLL -Q -s base | less
前のコマンドから返されたエントリDNを使用して、entry_to_view
フィールドに入力します。
エントリの操作属性(メタデータ)を印刷する
これまでは、主にcn=config
DITを使用してきました。 このガイドの残りの部分は、通常の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を介して利用できるため、rootアクセスは必要ありません。
サブスキーマを見つける
エントリのサブスキーマを見つけるには、上記のようにエントリのすべての操作属性をクエリするか、エントリのサブスキーマを定義する特定の属性を要求できます(subschemaSubentry
)。
- ldapsearch -H ldap:// -x -s base -b "dc=example,dc=com" -LLL subschemaSubentry
これにより、現在のエントリに関連付けられているサブスキーマエントリが出力されます。
[list subchema entry]
dn: dc=chilidonuts,dc=tk
subschemaSubentry: cn=Subschema
ツリー内のすべてのエントリが同じサブスキーマを共有することは一般的であるため、通常、エントリごとにこれをクエリする必要はありません。
サブスキーマの表示
サブスキーマエントリの内容を表示するには、上記で見つけたサブスキーマエントリを「base」のスコープでクエリする必要があります。 重要な情報はすべて操作属性に格納されるため、特別な「+」セレクターを再度使用する必要があります。
必要なコマンドは次のとおりです。
- 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とシステム内のメタデータを見つける方法を理解することは、着実に実行するのに役立ちます。 cn=config
DITをLDIFファイルで変更すると、実行中のシステムにすぐに影響を与える可能性があります。 また、DITを介してシステムを構成すると、LDAPツールのみを使用してリモート管理をセットアップできる可能性があります。 これは、LDAP管理をサーバー管理から分離できることを意味します。