9.4. 適切な認証方法の選択

匿名でのアクセスは、ディレクトリーへの最も簡単なアクセス方法です。これは、認証の有無に関係なく、ディレクトリーのすべてのユーザーがデータを利用できるようになります。

しかし、匿名アクセスでは、管理者は誰がどのような検索を行っているかを追跡することはできず、誰かが検索を行っていることだけがわかります。匿名アクセスでは、ディレクトリーに接続するユーザーは誰でもデータにアクセスできます。

したがって、管理者は特定のユーザーまたはユーザーのグループが特定の種類のディレクトリーデータにアクセスするのをブロックしようとする場合がありますが、そのデータへの匿名アクセスが許可されている場合は、それらのユーザーはディレクトリーに匿名でバインドするだけでデータにアクセスできます。

匿名アクセスは制限することができます。通常、ディレクトリー管理者は、読み取り、検索、および権限の比較に対してのみ匿名アクセスを許可します (書き込み、追加、削除、または自己書き込みは許可しません)。多くの場合、管理者は名前、電話番号、電子メールアドレスなどの一般的な情報を含む属性のサブセットへのアクセスを制限します。政府が管理する ID 番号 (アメリカの Social Security Number など)、自宅の電話番号や住所、給料明細などのより機密性の高いデータへの匿名アクセスはは絶対に許可しないでください。

ディレクトリーデータにアクセスするユーザーにより厳密なルールが必要な場合は、匿名アクセスを完全に無効にすることもできます。

認証されていないバインド は、ユーザーがユーザー名でバインドしようとするが、ユーザーのパスワード属性を持たない場合です。以下に例を示します。

ldapsearch -x -D "cn=jsmith,ou=people,dc=example,dc=com" -b "dc=example,dc=com" "(cn=joe)"

ldapsearch -x -D "cn=jsmith,ou=people,dc=example,dc=com" -b "dc=example,dc=com" "(cn=joe)"

Directory Server は、ユーザーがパスワードを提供しようとしない場合に、匿名アクセスを付与します。認証されていないバインドでは、バインド DN が既存のエントリーである必要はありません。

匿名バインドと同様に、データベースへのアクセスを制限し、未認証のバインドを無効にして、セキュリティーを強化できます。非認証バインドの無効化には別の利点があります。クライアントのサイレントバインドの失敗を防ぐために使用できます。不適切に作成されたアプリケーションの場合、実際にはパスワードの受け渡しに失敗し、未認証のバインドに接続しただけでも、バインド成功メッセージを受信すると、ディレクトリーの認証に成功したと判断する可能性があります。

匿名アクセスが許可されない場合、ユーザーはディレクトリーの内容にアクセスする前にディレクトリーに対して認証する必要があります。シンプルパスワード認証では、クライアントは再利用可能なパスワードを送信してサーバーに対して認証します。

たとえば、クライアントは、識別名と認証情報のセットを提供するバインド操作を使用して、ディレクトリーに対して認証を行います。サーバーは、クライアント DN に対応するディレクトリーのエントリーを特定し、クライアントによって指定されるパスワードがエントリーに保存されている値と一致するかどうかを確認します。一致する場合、サーバーはクライアントを認証します。そうでない場合は、認証操作は失敗し、クライアントはエラーメッセージを受信します。

バインド DN は多くの場合、ユーザーのエントリーに対応しています。ただし、一部のディレクトリー管理者は、個人ではなく組織エントリーとしてバインドすると便利であると感じています。このディレクトリーでは、バインドに使用されるエントリーが、userPassword 属性を許可するオブジェクトクラスである必要があります。これにより、ディレクトリーはバインド DN およびパスワードを確実に認識します。

ほとんどの LDAP クライアントはバインド DN をユーザーに対して非表示にします。これは、長い文字列の DN を覚えるのは難しい可能性があるからです。クライアントがユーザーに対してバインド DN を非表示にする場合、以下のようなバインドアルゴリズムが使用されます。

シンプルなパスワード認証では、ユーザーの認証が簡単になりますが、安全に使用するためには、追加のセキュリティーが必要です。組織のイントラネットでその使用を制限することを検討してください。エクストラネットを介したビジネスパートナー間の接続、またはインターネット上の顧客との送信に使用するには、安全な (暗号化された) 接続を要求するのが最良である場合があります。

TLS または Start TLS 操作を使用して Directory Server とクライアントアプリケーションの間でセキュアな接続が確立されると、クライアントはパスワードをプレーンテキストで送信しないという保護レベルを追加したシンプルバインドを実行します。nsslapd-require-secure-binds 設定属性には、TLS または Start TLS などのセキュアな接続でシンプルなパスワード認証が必要です。この設定により、SASL 認証や証明書ベースの認証などの他のセキュアな接続も使用できます。

セキュアな接続の詳細は、「サーバー接続の保護」 を参照してください。

ディレクトリー認証の代替形式は、デジタル証明書を使用してディレクトリーにバインドします。ディレクトリーは、ユーザーの初回アクセス時にパスワードを要求します。ただし、ディレクトリーに保存されているパスワードと照合するのではなく、パスワードによってユーザーの証明書データベースが解放されます。

ユーザーが正しいパスワードを入力すると、ディレクトリークライアントアプリケーションは証明書データベースから認証情報を取得します。次に、クライアントアプリケーションとディレクトリーは、この情報を使用して、ユーザーの証明書をディレクトリー DN にマッピングし、ユーザーを識別します。ディレクトリーはこの認証プロセス中に特定されたディレクトリー DN に基づいて、アクセスを許可または拒否します。

証明書および TLS の詳細は、『Administration Guide』を参照してください。

ディレクトリーへのアクセスを要求するユーザーは、自身の DN ではなくプロキシー DN にバインドするため、プロキシー認証は特殊な形式の認証です。

プロキシー DN は、ユーザーが要求する操作を実行するための適切な権限を持つエンティティーです。プロキシー権限が個人またはアプリケーションに付与されると、Directory Manager DN を除き、プロキシー DN として DN を指定する権限が付与されます。

プロキシー権限の主な利点の 1 つは、LDAP アプリケーションを有効にして、単一のバインドで単一のスレッドを使用し、Directory Server に対して要求を行う複数のユーザーに対応できることです。クライアントアプリケーションは、ユーザーごとにバインドおよび認証する代わりに、プロキシー DN を使用して Directory Server にバインドします。

プロキシー DN は、クライアントアプリケーションによって送信される LDAP 操作で指定されます。以下に例を示します。

この ldapmodify コマンドは、manager エントリー(cn=Directory Manager)に Joe という名前のユーザー(cn=joe)のパーミッションを付与し、mods.ldif ファイルに変更を適用します。マネージャーは、この変更を加えるためにジョーのパスワードを提供する必要はありません。

パススルー認証とは、認証要求が 1 つのサーバーから別のサービスに転送されることです。

たとえば、インスタンスのすべての設定情報が別のディレクトリーインスタンスに保存されている場合、Directory Server は User Directory Server にパススルー認証を使用して Configuration Directory Server に接続します。Directory Server から Directory Server へのパススルー認証は、PTA プラグインで処理されます。

多くのシステムでは、Unix ユーザーおよび Linux ユーザー用の認証メカニズムがすでに含まれています。最も一般的な認証フレームワークの 1 つは、プラグ可能な認証モジュール (PAM) です。多くのネットワークではすでに既存の認証サービスを利用できるため、管理者はこれらのサービスを引き続き使用したいことがあります。PAM モジュールは、Directory Server に対して LDAP クライアントに既存の認証ストアを使用するように指示するように設定できます。

Red Hat Directory Server における PAM パススルー認証は、PAM パススルー認証プラグインを使用します。これにより、Directory Server が PAM サービスと通信して LDAP クライアントを認証できます。

PAM パススルー認証では、ユーザーが Directory Server にバインドしようとすると、クレデンシャルが PAM サービスに転送されます。クレデンシャルが PAM サービスの情報と一致すると、ユーザーは Directory Server アクセス制御の制限とアカウント設定がある状態で、Directory Server に正常にバインドできます。

PAM サービスは、System Security Services Daemon (SSSD) などのシステムツールを使用して設定できます。SSSD は、Active Directory、Red Hat Directory Server、OpenLDAP などのその他のディレクトリー、またはローカルシステム設定などのさまざまなアイデンティティープロバイダーを使用できます。SSSD を使用するには、PAM パススルー認証プラグインが、SSSD が使用する PAM ファイル（デフォルトでは /etc/pam.d/system-auth ）を指すようにします。

認証の試行では、最初に、ユーザーアカウントに認証機能があるかどうかが評価されます。アカウントはアクティブである必要があり、ロックされてはならず、該当するパスワードポリシーに従って有効なパスワードを持っている必要があります (つまり、期限切れにならず、リセットする必要があります)。

ユーザーに認証を許可する必要があるかどうかの 評価 を実行する必要がある場合がありますが、ユーザーは実際には Directory Server にバインドするべきではありません (またはバインドできません)。たとえば、システムは PAM を使用してシステムアカウントを管理することができ、PAM は LDAP ディレクトリーをアイデンティティーストアとして使用するように設定されます。ただし、システムは SSH キーや RSA トークンなどのパスワードなしのクレデンシャルを使用しており、これらのクレデンシャルを渡して Directory Serve r に認証することはできません。

Red Hat Directory Server は、ldapsearchの Account Usability Extension Control をサポートしています。このコントロールは、アカウントのステータスと有効なパスワードポリシー (リセットの要求、パスワード期限切れの警告、パスワード期限切れ後の猶予ログインの回数など) に関する情報を返します。これは、バインドの試行で返されるすべての情報ですが、ユーザーとして Directory Server には認証およびバインドされません。これにより、クライアントは Directory Server の設定と情報に基づいてユーザーに認証を許可するかどうかを決定できますが、実際の認証プロセスは Directory Server の外部で実行されます。

この制御を PAM などのシステムレベルのサービスで使用すると、パスワードなしのログインが可能になります。このログインでは、引き続き Directory Server を使用して ID を保存し、アカウントのステータスを制御します。