検索

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

download PDF

セキュリティーポリシーに関する基本的な決定は、ユーザーがディレクトリーにアクセスする方法です。匿名ユーザーはディレクトリーにアクセスできますか? それとも、すべてのユーザーがユーザー名とパスワードを使用してディレクトリーにログイン (認証) する必要がありますか?

Directory Server が提供する認証方法を説明します。このディレクトリーは、ユーザーまたは LDAP 対応のアプリケーションに関係なく、すべてのユーザーに同じ認証メカニズムを使用します。

7.4.1. 匿名および認証されていないアクセス

匿名でのアクセスは、ディレクトリーへの最も簡単なアクセス方法です。匿名アクセスでは、ディレクトリーに接続するユーザーは誰でもデータにアクセスできます。

匿名アクセスを設定すると、誰がどのような検索を実行したかを追跡することはできず、誰かが検索を実行したことのみを追跡できます。特定のユーザーまたはユーザーグループが一部のディレクトリーデータにアクセスできないようにブロックすることもできますが、そのデータへの匿名アクセスが許可されている場合は、それらのユーザーはディレクトリーに匿名でバインドするだけでデータにアクセスできます。

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

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

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

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

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

匿名バインドと同様に、認証されていないバインドを無効にして、データベースへのアクセスを制限することでセキュリティーを強化できます。さらに、認証されていないバインドを無効にして、クライアントのサイレントバインド障害を防ぐこともできます。一部のアプリケーションでは、実際にはパスワードを渡すことに失敗し、認証されていないバインドで接続しただけなのに、バインド成功メッセージを受信したため、ディレクトリーへの認証が成功したと認識する場合があります。

7.4.2. シンプルバインドとセキュアなバインド

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

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

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

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

  1. ユーザーは、ユーザー ID などの一意の識別子を入力します。たとえば、fchen などです。
  2. LDAP クライアントアプリケーションは、ディレクトリー内でその識別子を検索し、関連付けられた識別名を返します。たとえば、uid=fchen,ou=people,dc=example,dc=com などです。
  3. LDAP クライアントアプリケーションは、取得した識別名と、ユーザーが指定したパスワードを使用して、ディレクトリーにバインドします。

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

注記

シンプルパスワード認証の欠点は、パスワードがプレーンテキストで送信されることです。不正ユーザーがリッスンしている場合、そのユーザーが許可されたユーザーになりすます可能性があるため、ディレクトリーのセキュリティーが悪用される可能性があります。nsslapd-require-secure-binds 設定属性では、TLS または Start TLS を使用して、セキュアな接続を介して単純なパスワード認証を実行する必要があります。これにより、プレーンテキストのパスワードが効果的に暗号化され、悪意のある人物が盗聴できなくなります。

nsslapd-require-secure-binds 設定属性を使用して、TLS または Start TLS を使用してセキュアな接続をオンにします。SASL 認証または証明書ベースの認証も可能です。Directory Server とクライアントアプリケーションが相互に安全な接続を確立すると、クライアントはパスワードをプレーンテキストで送信しないことで、追加の保護レベルを備えた単純なバインドを実行します。

7.4.3. 証明書ベースの認証

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

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

7.4.4. プロキシー認証

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

プロキシー DN は、ユーザーが要求する操作を実行するための適切なパーミッションを持つエンティティーです。ユーザーまたはアプリケーションがプロキシーパーミッションを受け取ると、Directory Manager DN を除く任意の DN をプロキシー DN として指定できます。

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

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

ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -X "dn:cn=joe,dc=example,dc=com" -f mods.ldif

このコマンドにより、マネージャーエントリー cn=Directory Manager は、ユーザー cn=joe から mods.ldif ファイルに変更を適用するパーミッションを受け取ります。この変更を行うために、管理者はユーザーパスワードを提供する必要はありません。

注記

プロキシーメカニズムは非常に強力なので、慎重に使用する必要があります。プロキシーパーミッションはアクセス制御リスト (ACL) の範囲内で付与され、ユーザーにプロキシーパーミッションを付与すると、このユーザーはターゲットの下にある任意のユーザーのプロキシーとして機能します。プロキシーパーミッションを特定のユーザーのみに制限することはできません。

たとえば、エントリーに dc=example,dc=com ツリーへのプロキシーパーミッションがある場合、このエントリーは何でも実行できます。したがって、プロキシーアクセス制御命令 (ACI) をディレクトリーの可能な限り低いレベルに設定するようにしてください。

7.4.5. パススルー認証 (PTA)

パススルー認証 (PTA) とは、Directory Server が認証要求を 1 つのサーバーから別のサーバーに転送することです。

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

簡単なパススルー認証プロセス

多くのシステムには、Pluggable Authentication Modules (PAM) などの Unix および Linux ユーザー向けの認証メカニズムがすでに備わっています。PAM モジュールを設定して、Directory Server に LDAP クライアントの既存の認証ストアを使用するように指示できます。Directory Server は PAM サービスと対話し、PAM パススルー認証プラグインを使用して LDAP クライアントを認証します。

dg auth 経由の pam パス

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

注記

PAM を使用するように Directory Server を設定することはできますが、認証に Directory Server を使用するように PAM を設定することはできません。

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

7.4.6. パスワードレス認証

認証の試行では、まずユーザーアカウントが認証できるかどうかが評価されます。アカウントは以下の基準を満たす必要があります:

  • アクティブである必要がある。
  • ロックされていない。
  • 適用されるパスワードポリシーに従って有効なパスワードを設定している。

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

Red Hat Directory Server は、LDAP 検索用の Account Usability Extension Control エクステンションをサポートしています。このエクステンションは、返されたエントリーごとに、アカウントのステータスとそのアカウントのパスワードポリシーに関する情報を示す追加行を返します。次に、クライアントまたはアプリケーションはそのステータスを使用して、そのユーザーアカウントの Directory Server 外で行われた認証の試行を評価できます。基本的に、この制御では、認証操作なしにユーザーが認証を許可するかどうかを制御します。

さらに、このエクステンションを PAM などのシステムレベルのサービスと併用して、引き続き Directory Server を使用してアイデンティティーを保存し、アカウントステータスを制御するパスワードなしのログインを許可することもできます。

注記

デフォルトでは、Directory Manager のみが Account Usability Extension Control を使用できます。他のユーザーが制御を使用できるようにするには、サポートされるコントロールエントリーに適切な ACI を設定します (oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config)。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.