OpenLDAPユーティリティでLDAPサーバーを管理および使用する方法

OpenLDAPツールでは、操作ごとに認証方法とサーバーの場所を指定する必要があります。 サーバーを指定するには、-Hフラグに続けて、問題のサーバーのプロトコルとネットワークの場所を使用します。

基本的な暗号化されていない通信の場合、プロトコルスキームは次のようにldap://になります。

ローカルサーバーと通信している場合は、サーバーのドメイン名またはIPアドレスを省略できます（スキームを指定する必要があります）。

LDAP over SSLを使用してLDAPサーバーに接続している場合は、代わりにldaps://スキームを使用することをお勧めします（これは非推奨の方法であることに注意してください）。 OpenLDAPプロジェクトでは、代わりに通常のLDAPポートでSTARTTLSアップグレードを使用することをお勧めします。 これを設定する方法を学ぶhere）：

これらのプロトコルは、デフォルトのポート（従来のLDAPの場合は389、LDAP over SSLの場合は636）を想定しています。 非標準のポートを使用している場合は、コロンとポート番号を末尾に追加する必要があります。

Linux IPC（プロセス間通信）を介して照会しているサーバー上のLDAPディレクトリーに接続するには、ldapi://プロトコルを使用できます。 これは、より安全で、一部の管理タスクに必要です。

ldapiスキームにはローカル接続が必要なため、ここでサーバー名を指定する必要はありません。 ただし、LDAPサーバー構成内でソケットファイルの場所を変更した場合は、アドレスの一部として新しいソケットの場所を指定する必要があります。

LDAPでは、要求を許可するためのアクセスレベルをサーバーが決定できるように、クライアントが自身を識別する必要があります。 これは、「バインディング」と呼ばれるLDAPメカニズムを使用して機能します。これは、基本的に、リクエストを既知のセキュリティエンティティに関連付けるための単なる用語です。 LDAPが認識する認証には3つの異なるタイプがあります。

クライアントが使用できる認証の最も一般的なタイプは、「匿名」バインドです。 これはほとんど認証の欠如です。 LDAPサーバーは、特定の操作を誰でもアクセスできるように分類できます（通常、デフォルトでは、公開DITは匿名ユーザーに対して読み取り専用として構成されます）。 匿名バインドを使用している場合、これらの操作は利用可能です。

OpenLDAPツールはデフォルトでSASL認証を想定しているため（これについては後で説明します）、匿名バインドを許可するには、-x引数を指定する必要があります。 サーバー仕様と組み合わせると、これは次のようになります。

追加の引数を指定せずに入力すると、次のようになります。

匿名バインドを使用したldapsearchの出力

これは、ツールが検索したものを見つけられなかったことを示しています。 クエリパラメータを提供しなかったため、これは予期されていますが、匿名バインドがサーバーによって受け入れられたことを示しています。

LDAPサーバーに対する認証の2番目の方法は、単純なバインドを使用することです。 シンプルバインドは、LDAPサーバー内のエントリを使用して要求を認証します。 エントリのDN（識別名）は、認証のユーザー名として機能します。 エントリ内で、属性は要求中に提供する必要があるパスワードを定義します。

SASLは、単純な認証およびセキュリティレイヤーの略です。 これは、特定の実装に結び付けられていない柔軟な認証システムを提供するために、プロトコルに認証方法を接続するためのフレームワークです。 wikipedia pageをチェックして、利用可能なさまざまな方法について学ぶことができます。

LDAPサーバーは、おそらく、可能なSASLメカニズムのサブセットのみをサポートします。 許可されるメカニズムを確認するには、次のように入力します。

表示される結果は、接続に使用したスキームによって異なります。 暗号化されていないldap://スキームの場合、ほとんどのシステムはデフォルトで以下を許可します。

ldap:// supportedSASLMechanisms

安全なプロセス間通信を使用するldapi://スキームを使用している場合は、選択肢のリストが拡張されている可能性があります。

ldapi:// supportedSASLMechanisms

ほとんどのSASL認証方法の設定には時間がかかることがあるため、ここでは詳細を詳しく説明しません。 SASL認証は一般にこの記事の範囲外ですが、ldapi://スキームで使用できると思われるEXTERNALメソッドについて説明する必要があります。

EXTERNALメカニズムは、認証とセキュリティが接続に関連付けられた他の手段によって処理されることを示します。 たとえば、SSLとともに使用して、暗号化と認証を提供できます。

最も一般的には、ルートまたはsudoユーザーとのldapi://インターフェースで使用されます。 ldapi://はUnixソケットを使用するため、要求を開始するユーザーを取得して、特定の操作の認証に使用できます。 LDAPが構成に使用するDITは、このメカニズムを使用してrootユーザーを認証し、LDAPの読み取りと変更を行います。 これらのリクエストは次のようになります。

これは、通常、cn=configルートエントリで始まるDITに保持されるLDAP構成を変更するために使用されます。

これまで主にコマンドラインで接続情報を指定してきました。 ただし、構成ファイルに一般的な接続値をいくつか入力することで、入力を節約できます。

グローバルクライアント構成ファイルは/etc/ldap/ldap.confにありますが、主にホームディレクトリの~/.ldaprcにあるユーザーの構成ファイルに変更を追加する必要があります。 テキストエディタでこの名前のファイルを作成して開きます。

内部では、おそらく構成する必要のある基本設定は、BASE、URI、およびBINDDNです。

これにより、単純な認証情報が処理されます。 SASL認証を使用している場合は、man ldap.confをチェックして、SASL資格情報を構成するためのオプションを確認してください。

LDAPのベースエントリがdc=example,dc=comであり、サーバーがローカルコンピューターにあり、バインドにcn=admin,dc=example,dc=comを使用している場合、次のような~/.ldaprcファイルがある可能性があります。

~/.ldaprc

これを使用して、非SASL認証を指定し、adminエントリに関連付けられたパスワードを提供するだけで、基本的な検索を実行できます。 これにより、指定したデフォルトのベースDNの完全なサブツリー検索が提供されます。

これは、LDAPユーティリティを使用する際の「定型」接続オプションを短縮するのに役立ちます。 このガイドでは、明確にするためにコマンドに接続情報を含めますが、コマンドを実行するときに、構成ファイルで指定した部分を削除できます。

LDAPでは、検索が開始される場所はsearch baseと呼ばれます。 これは、DIT内のエントリであり、そこから操作が開始され、アンカーとして機能します。 -bフラグを使用してエントリ名を渡すことにより、検索ベースを指定します。

たとえば、dc=example,dc=com DITのルートから開始するには、次のように検索ベースとして使用できます。

このコマンドは、バインドされているユーザーがアクセスできるdc=example,dc=comエントリの下にあるすべてのエントリを生成する必要があります。 別のエントリを使用すると、ツリーの別のセクションが取得されます。 たとえば、管理エントリから開始する場合、管理エントリ自体のみを取得できます。

cn = admin、dc = example、dc = comの検索ベース

これらの例でベースを指定しましたが、検索スコープを指定することで、ツールが結果を検索する方法をさらに形作ることができます。 このオプションは-sオプションによって設定され、次のいずれかになります。

-sフラグと-bフラグを使用して、ツールで調べたいDITの領域の形成を開始できます。 たとえば、次のようにoneスコープを使用すると、ベースエントリのすべての第1レベルの子を表示できます。

出力を少しフィルタリングするために、最後に-LLL dnを追加しました。 これについては、この記事の後半で詳しく説明します。 ツリーにさらにいくつかのエントリを追加した場合、これは次のような結果を返した可能性があります。

出力

ou=peopleエントリの下にあるすべてのものを表示したい場合は、それを検索ベースとして設定し、childrenスコープを使用できます。

検索ベースと検索範囲を微調整することにより、関心のあるDITの部分のみを操作できます。 これにより、ツリーのセクションを検索するだけでクエリのパフォーマンスが向上し、関心のあるエントリのみが返されます。

先に進む前に、ldapsearchが生成​​する余分な出力の一部を削除する方法について説明しましょう。

追加の出力の大部分は、-Lフラグで制御されます。 表示する出力のレベルに応じて、0〜3個の-Lフラグを使用できます。 追加する-Lフラグが多いほど、より多くの情報が抑制されます。 学習またはトラブルシューティングの際に出力を抑制することは控えることをお勧めしますが、通常の操作中は、3つのレベルをすべて使用すると、おそらくより良いエクスペリエンスにつながります。

SASL認証を使用している場合、たとえばcn=config DITを変更するときは、-Qフラグを追加で使用できます。 これにより、SASLクワイエットモードが有効になり、SASL関連の出力が削除されます。 これは-Y EXTERNALメソッドを使用する場合は問題ありませんが、資格情報の入力を求めるメカニズムを使用している場合は注意が必要です。これも抑制されるためです（認証の失敗につながります）。

検索範囲全体を単に出力するのではなく、実際に検索を実行するには、検索フィルターを指定する必要があります。

これらは行末に配置でき、属性タイプ、比較演算子、および値の形式を取ります。 多くの場合、シェルによる解釈を防ぐために引用符で囲まれています。 括弧は、あるフィルターと別のフィルターの境界を示すために使用されます。 これらは、単純な単一属性検索ではオプションですが、より複雑な複合フィルターでは必須です。 ここでそれらを使用して、検索フィルターの場所をより適切に示します。

例として、dc=example,dc=com DIT内に、ユーザー名（uid）属性が「jsmith」に設定されたエントリがあるかどうかを確認できます。 これにより、検索スコープ内の各エントリで、その値に設定された属性が検索されます。

上記の例では、属性値の完全一致をテストする等値演算子を使用しました。 他にもさまざまな演算子があり、期待どおりに機能します。 たとえば、値セットを気にせずにcontainが属性であるエントリを検索するには、「プレゼンス」演算子を使用できます。これは、比較の右側にワイルドカードが付いた等号です。 次のように入力して、パスワードを含むエントリを検索できます。

便利な検索フィルターは次のとおりです。

また、「！」否定記号を前に付けた括弧の追加セットで検索フィルターをラップすることにより、ほとんどの検索を否定することもできます。 たとえば、すべての組織単位エントリを検索するには、次のフィルターを使用できます。

notの組織単位エントリであるすべてのエントリを検索するには、次のフィルタを使用できます。

否定修飾子は、後続の検索フィルターの意味を逆にします。

フィルター仕様に従って、属性出力フィルターを追加することもできます。 これは、一致した各エントリから表示する属性のリストです。 デフォルトでは、資格情報に読み取りアクセス権があるすべての属性が、一致した各エントリに表示されます。 属性出力フィルターを設定すると、表示する出力の種類を正確に指定できます。

たとえば、ユーザーIDを持つすべてのエントリを検索できますが、次のように入力することで、各エントリの関連するcommon nameのみを表示できます。

これにより、次のようなリストが作成されます。

出力

エントリの説明も表示する場合は、表示する属性のリストにそれを追加するだけです。

代わりに次のようなものが表示されます。

出力

属性フィルターが指定されていない場合、すべての属性が返されます。 これは、「*」文字を使用して明示できます。 操作属性（各エントリのバックグラウンドで管理される特別なメタデータ属性）を返すには、特別な「+」記号を使用できます。 たとえば、rootDNの操作属性を表示するには、次のように入力できます。

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

出力

複合検索では、2つ以上の個別の検索フィルターを組み合わせて、より正確な結果を取得します。 検索フィルターは、最初の項目として関係演算子を使用して別の括弧のセットでラップすることにより結合されます。 これは、説明するよりも簡単に説明できます。

関係演算子は、論理ANDとして機能する「＆」文字と、論理ORを表す「|」文字です。 これらは、外側の括弧のセット内で関係を定義するフィルターに先行します。

したがって、ドメインに説明とメールアドレスの両方があるエントリを検索するには、次のようなフィルターを作成できます。

エントリが返されるには、これらの属性の両方が定義されている必要があります。

サブフィルターのいずれかが真の場合、ORシンボルは結果を返します。 連絡先情報があるエントリを出力する場合は、次のようなフィルターを試してください。

ここでは、演算子が3つ以上のサブフィルターに適用できることがわかります。 必要に応じてこれらの論理構造をネストして、非常に複雑なパターンを作成することもできます。

これらのボイラープレートオプションを提供した後、最も一般的なアクションは、LDIFファイルを読み込んでDITに適用することです。 これは、-fオプションを使用して実行できます（-fオプションを使用しない場合は、コマンドラインでLDIF形式を使用して変更を入力する必要があります）。 上記にリンクされているガイドで説明されている構文を使用して、LDIFファイルを自分で作成する必要があります。

これにより、LDIFファイルが読み取られ、指定された変更が適用されます。 ldapmodifyコマンドの場合、各LDIF変更にはchangetypeを指定する必要があります。 ldapmodifyコマンドは、DIT操作コマンドの最も一般的な形式です。

LDIFファイルが新しいエントリを追加していて、does notに各エントリのchangetype: addが含まれている場合は、-aフラグをldapmodifyとともに使用するか、単にldapaddを使用できます。コマンド。基本的にこの動作のエイリアスです。 たとえば、includesがchangetypeであるLDIFファイルは次のようになります。

changetypeを使用したLDIF

このファイルを処理するには、ldapmodifyを使用するだけです。

ただし、次のように、ファイルをwithoutchangetypeで作成することもできます。

変更タイプのないLDIF

この場合、このエントリをDITに追加するには、ldapmodifyで-aフラグを使用するか、ldapaddコマンドを使用する必要があります。 どちらか

またはこれ：

同様のコマンドは、エントリの削除（ldapdelete）およびLDAPエントリの移動（ldapmodrdn）に使用できます。 これらのコマンドを使用すると、ファイルでchangetype: deleteとchangetype: modrdnをそれぞれ明示的に指定する必要がなくなります。 これらのそれぞれについて、どのフォーマットを使用するかはあなた次第です（LDIFファイルまたはコマンドラインで変更を指定するかどうか）。

LDIFファイルのドライランを実行する場合は、-nフラグと-vフラグを使用できます。 これにより、実際のDITを変更せずに実行される変更がわかります。

通常、LDIFファイルの処理中にエラーが発生した場合、操作はすぐに停止します。 多くの場合、ファイルの後半にある変更要求は、以前の変更が正しく適用されたという前提でDITを変更するため、これは一般的に最も安全なことです。

ただし、エラーの原因となる変更をスキップしてコマンドをファイル全体で続行する場合は、-cフラグを使用できます。 また、-Sフラグを使用して、エラーを書き込むことができるファイルをポイントし、問題のあるリクエストを修正して再実行できるようにすることもできます。

このように、操作後に評価するログ（問題のあるエントリを示すコメントを含む）があります。

一部のLDAPエントリにパスワードがある場合は、ldappasswdコマンドを使用してエントリを変更できます。 これは、問題のアカウントまたは管理アカウントを使用して認証し、新しいパスワード（およびオプションで古いパスワード）を提供することで機能します。

古いパスワードは、-aフラグ（古いパスワードは次の項目としてインラインで指定されます）、-Aフラグ（古いパスワードの入力を求められます）、または-tフラグ（古いパスワードは次の項目として指定されたファイルから読み取られます）。 これは一部のLDAP実装ではオプションですが、他の実装では必須であるため、含めることをお勧めします。

新しいパスワードは、-sフラグ（新しいパスワードは次の項目としてインラインで指定されます）、-Sフラグ（新しいパスワードの入力を求められます）、または-Tフラグ（新しいパスワードは次の項目として指定されたファイルから読み取られます）。

したがって、典型的な変更は次のようになります。

エントリが指定されていない場合、バインドに使用されているエントリが変更されます。 管理エントリにバインドしている場合は、コマンドの後に入力することにより、書き込みアクセス権がある他のエントリを変更できます。

パスワードの変更とリセットの詳細については、this guideを確認してください。

ldapwhoamiコマンドは、認証後にLDAPサーバーがどのようにユーザーを認識しているかを示します。

匿名認証または単純認証を使用している場合、結果はおそらくあまり有用ではありません（それぞれ「匿名」またはバインドしている正確なエントリ）。 ただし、SASL認証の場合、これにより、認証メカニズムがどのように見えるかについての洞察が得られます。

たとえば、-Y EXTERNAL SASLメカニズムをsudoとともに使用してcn=config DITで操作を実行する場合、ldapwhoamiで認証DNを確認できます。

ldapwhoamiの出力

これはDITの実際のエントリではなく、LDAPが理解できる形式にSASL認証が変換される方法です。 ただし、認証DNを確認することでマッピングとアクセス制限を作成できるため、この情報を取得する方法を知っておくと便利です。

ldapurlツールを使用すると、クエリに含まれるさまざまなコンポーネントを指定してLDAPURLを作成できます。 LDAP URLは、標準化されたURLを介してLDAPサーバーからリソースを要求できる方法です。 これらは認証されていない接続であり、読み取り専用です。 多くのLDAPソリューションは、リソースをリクエストするためのLDAP URLをサポートしなくなったため、使用しているソフトウェアによってはその使用が制限される場合があります。

標準LDAP URLは、次の構文を使用してフォーマットされます。

コンポーネントは次のとおりです。

URL内の各アイテムは疑問符で区切られています。 使用していないアイテムを提供する必要はありませんが、アイテムタイプは文字列内の位置によって識別されるため、そのアイテムの「スロット」を空のままにしておく必要があります。行。 情報を追加したらすぐにURLを停止できます（最後に疑問符を付けなくても、未使用の「スロット」を表すことができます）。

たとえば、URLは次のようになります。

これをldapurlツールにフィードする場合は、-Hフラグを使用して、URLを引用符で囲みます。

コマンドは次のようにそれをバラバラにします：

ldapurlの出力

また、これらのフラグを使用してプロセスを逆にし、LDAP URLをまとめます。 これらは、LDAP URLのさまざまなコンポーネントをミラーリングします。

これらを使用して、次のように入力できます。

このコマンドは、構築されたURLを返します。これは次のようになります。

ldapurlの出力

これを使用して、この形式を使用して通信できるLDAPクライアントで使用できるURLを作成できます。

ldapcompareツールを使用して、エントリの属性を値と比較できます。 これは、単純なアサーションチェックを実行してデータを検証するために使用されます。

このプロセスには、通常、クエリ対象のデータに応じてバインドを行い、エントリDNと確認するアサーションを提供します。 アサーションは、1つまたは2つのコロンで区切られた属性と値を指定することにより与えられます。 単純な文字列値の場合、単一のコロンを使用する必要があります。 二重コロンは、base64エンコード値が指定されたことを示します。

したがって、Johnは次のような「パワーユーザー」グループのメンバーであると断言できます。

彼がグループに属している場合は、TRUEを返します。 そうでない場合、コマンドはFALSEを返します。 バインドに使用されているDNに、問題の属性を読み取るための十分な権限がない場合は、UNDEFINEDが返されます。

これは、要求されたアクションを実行する前にグループメンバーシップを確認することにより、承認システムの基礎として使用できます。