クライアントに適用されるセキュリティーモデルは、資格レベルと認証方法の組み合わせで定義されます。
Directory Server では、次の資格レベルがサポートされています。
匿名。ディレクトリの特定部分に匿名アクセスを許可することは、そのディレクトリへのアクセス権を持つすべてのユーザーに読み取りアクセス権を与えることを意味します。
匿名資格レベルを使用する場合、すべての LDAP ネームエントリおよび属性に読み取りアクセスを許可する必要があります。
匿名でのディレクトリへの書き込みアクセスは許可しないでください。これを許可すると、どのユーザーでも、書き込みアクセス権のある DIT 内の情報 (別のユーザーのパスワードや自分自身の識別情報など) の変更が可能になります。
プロキシ。クライアントは、プロキシアカウントを使用してディレクトリへの認証またはバインドを行います。
このプロキシアカウントには、ディレクトリへのバインドを許可されるエントリを設定できます。このプロキシアカウントは、ディレクトリでネームサービス機能を実行するための十分なアクセス権を必要とします。プロキシ資格レベルを使用して、すべてのクライアントで proxyDN および proxyPassword を設定する必要があります。暗号化された proxyPassword はクライアントのローカルに格納されます。
匿名プロキシ。複数の資格レベルが定義された複数値エントリ。
匿名プロキシレベルを割り当てられたクライアントは、最初にそのプロキシ識別情報を使用して認証を試みます。ユーザーのロックアウトやパスワードの有効期限切れなど何らかの理由でプロキシユーザーとして認証できなかった場合、クライアントは匿名アクセスを使用します。この場合、ディレクトリの構成によっては、別のサービスレベルに移行する可能性があります。
クライアント認証は、クライアントのアイデンティティーを確認するためのサーバーのメカニズムです。
クライアント認証は、次のいずれかの方法で実行できます。
DN とパスワードを提供する。
クライアントによって提供された証明書を使用する。
証明書ベースの認証では、SSL プロトコルを介して入手したクライアント証明書を使用して、ユーザーエントリの識別情報が検出されます。証明書ベースの認証では、クライアントが外部メカニズムを指定する SASL バインド要求を送信します。バインド要求は、すでに確立された SSL 認証メカニズムに依存します。
SASL ベースのメカニズムを使用する。
すべてのオペレーティングシステムで、DIGEST-MD5 による SASL。
Solaris オペレーティングシステムで、Kerberos V5 によるクライアント認証が可能である、GSSAPI メカニズムによる SASL 。
2 つのうちどちらの SASL メカニズムを使用する場合も、アイデンティティーのマッピングを行うようにサーバーを設定する必要があります。SASL 資格は、 主体と呼ばれます。主体の内容のバインド DN を決定するために、各メカニズムに特定のマッピングが必要です。主体が 1 つのユーザーエントリにマッピングされ、SASL メカニズムがそのユーザーのアイデンティティーを検証すると、ユーザーの DN がその接続のバインド DN となります。
SSL クライアント認証モードを使用する。
SSL 層ですべてのクライアントが認証されるようにするには、SSL クライアント認証を使用します。クライアントアプリケーションは、SSL 証明書をサーバーに送信することで認証を行います。SSL-client-auth-mode フラグを使用して、サーバーが SSL クライアント認証を許可する、要求する、または許可しないよう指定します。デフォルトでは、クライアントは認証を許可されます。
この節では、Directory Server での 2 つの SASL メカニズムの設定に関する次の情報について説明します。
セキュリティーの設定の詳細については、「LDAP クライアントでセキュリティーを使用するための設定」を参照してください。
SASL メカニズムを設定する前に、暗号化が必要かどうかを指定する必要があります。SASL 暗号化の要件は、最大および最小 SSF (Strength Security Factor) によって設定されます。
属性 dsSaslMinSSF(5dsat) および dsSaslMaxSSF(5dsat) は、暗号化鍵の長さを示します。これらは、cn=SASL, cn=security, cn=config に保存されています。
サーバーに対しては、暗号化しないという選択肢も含めて、すべてのレベルの暗号化を設定できます。つまり、Directory Server は 256 より大きい dsSaslMinSSF 値と dsSaslMaxSSF 値を受け入れます。しかし、現在 SASL メカニズムは 128 より大きい SSF をサポートしません。Directory Server はこれらの値のネゴシエーションを行い最大限の SSF 値 (128) にします。このため、使用されるメカニズムによっては、実際の最大 SSF 値は、設定された最大値より小さい可能性があります。
SASL セキュリティーファクタ認証は、次の 2 つの主要な項目に基づきます。サーバーとクライアントアプリケーションによって要求される最小ファクタと最大ファクタ、および使用可能な暗号化メカニズム。これらは背後のセキュリティーコンポーネントによって提供されます。つまり、サーバーとクライアントは両方で設定された最大ファクタ以下で、両方で設定された最小ファクタ以上の、使用可能な中で最も大きいセキュリティーファクタを使用しようとします。
Directory Server に対するデフォルトの最小 SASL セキュリティーファクタである dsSaslMinSSF は 0 で、保護されていないことを示します。実際の最小値は、Directory Server の最小値を変更しない限り、クライアント設定によって変わります。実際は、サーバーとクライアントに使用する最低レベルに最小値を設定します。サーバーとクライアントが最低要件を満たすメカニズムのネゴシエーションに失敗した場合、接続は確立されません。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
SASL 暗号化を要求するにはdsSaslMinSSF 値を最低限必要な暗号化に設定します。
$ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: cn=SASL, cn=security, cn=config changetype: modify replace: dsSaslMinSSF dsSaslMinSSF: 128 ^D |
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
SASL 暗号化を許可しない場合は dsSaslMinSSF と dsSaslMaxSSF の両方の値をゼロに設定します。
$ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: cn=SASL, cn=security, cn=config changetype: modify replace: dsSaslMinSSF dsSaslMinSSF: 0 replace: dsSaslMaxSSF dsSaslMaxSSF: 0 |
DIGEST-MD5 メカニズムは、クライアントによって送信されたハッシュされた値をユーザーのパスワードのハッシュと比較することによって、クライアントを認証します。ただし、このメカニズムはユーザーパスワードを読み取る必要があり、DIGEST-MD5 による認証を希望するすべてのユーザーは、ディレクトリ内に平文パスワードを持つ必要があります。平文パスワードをディレクトリに保存する場合に、第 7 章「Directory Server のアクセス制御」で説明されているように、パスワード値へのアクセスが ACI によって正しく制限されていることを確認する必要があります。さらに、「属性値の暗号化」で説明しているように、サフィックスで属性の暗号化を設定する必要があります。
次の手順は、DIGEST-MD5 を使用するように Directory Server を設定する方法を説明しています。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
DIGEST-MD5 がルートエントリ上で supportedSASLMechanisms 属性の値であることを確認するには、ldapsearch コマンドを使用します。
たとえば、次のコマンドはどの SASL メカニズムが有効であるかを表示します。
$ ldapsearch -h host -p port -D cn=admin,cn=Administrators,cn=config -w - \ -s base -b "" "(objectclass=*)" supportedSASLMechanisms Enter bind password: dn: supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: GSSAPI |
DIGEST-MD5 が有効でない場合は、有効にします。
$ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: cn=SASL, cn=security, cn=config changetype: modify add: dsSaslPluginsEnable dsSaslPluginsEnable: DIGEST-MD5 - replace: dsSaslPluginsPath dsSaslPluginsPath: SASL-library |
ここで、SASL-library は次のいずれかです。
/usr/lib/mps/sasl2
install-path/dsee6/private/lib
DIGEST-MD5 のデフォルトのアイデンティティーマッピングを使用するか新規作成します。
詳細については、「DIGEST-MD5 アイデンティティーマッピング」を参照してください。
DIGEST-MD5 を使用する SSL 経由でサーバーにアクセスするすべてのユーザーのパスワードが平文形式で格納されていることを確認します。
パスワード保存スキーマについては、第 8 章「Directory Server のパスワードポリシー」を参照してください。
SASL 設定エントリまたは DIGEST-MD5 アイデンティティーマッピングエントリの 1 つを変更した場合は、Directory Server を再起動します。
SASL メカニズムの アイデンティティーマッピングは、SASL アイデンティティーの資格をディレクトリ内のユーザーエントリと一致させようとします。マッピングによって、SASL アイデンティティーに対応する DN が見つからなかったときは、認証は失敗します。このメカニズムの詳細な説明については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』を参照してください。
SASL アイデンティティーは、Principal という文字列です。これは、各メカニズムに固有の形式でユーザーを表します。DIGEST-MD5 では、クライアントは、dn: プレフィックスと LDAP DN、または u: プレフィックスの後にクライアントが決定するテキストを続けた情報のいずれかが含まれる主体を作成すべきです。マッピング時に、クライアントが送信した主体は、${Principal}プレースホルダで使用されます。
サーバー設定内の次のエントリは、DIGEST-MD5 のデフォルトアイデンティティーマッピングです。
dn: cn=default,cn=DIGEST-MD5,cn=identity mapping,cn=config objectClass: top objectClass: nsContainer objectClass: dsIdentityMapping objectClass: dsPatternMatching cn: default dsMatching-pattern: \${Principal} dsMatching-regexp: dn:(.*) dsMappedDN: \$1 |
このアイデンティティーマッピングは、主体の dn フィールドに、ディレクトリ内の既存ユーザーの正確な DN が含まれていることを前提としています。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
cn=DIGEST-MD5,cn=identity mapping,cn=config の下でデフォルトのマッピングエントリを編集するか、新しいマッピングエントリを作成します。
次のコマンドは、このマッピングを定義する方法を示しています。
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: cn=unqualified-username,cn=DIGEST-MD5,cn=identity mapping cn=config objectclass: dsIdentityMapping objectclass: dsPatternMatching objectclass: nsContainer objectclass: top cn: unqualified-username dsMatching-pattern: \${Principal} dsMatching-regexp: u:(.*)@(.*)\\.com dsSearchBaseDN: dc=\$2 dsSearchFilter: (uid=\$1) |
Directory Server を再起動して、新しいマッピングを有効にします。
SASL 上の GSSAPI (Generic Security Service API) では、クライアントを認証するために、Kerberos V5 などのサードパーティーのセキュリティーシステムを使用できます。GSSAPI ライブラリは、Solaris OS SPARC® プラットフォームの場合にのみ使用できます。Sun Enterprise Authentication MechanismTM 1.0.1 サーバーに Kerberos V5 実装をインストールすることをお勧めします。
サーバーは、GSSAPI を使用してユーザーの識別情報を検証します。次に、SASL メカニズムは GSSAPI マッピングルールを適用して、この接続中のすべての操作のバインド DN となる DN を取得します。
製造元の指示に従って、Kerberos ソフトウェアを設定します。Sun Enterprise Authentication Mechanism 1.0.1 サーバーを使用している場合、次の手順を使用します。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
/etc/krb5 内のファイルを設定します。
ユーザーとサービスを保存するために Kerberos データベースを作成します。
データベース内で LDAP サービスの主体を作成します。
$ ldap/server-FQDN@realm |
ここで、server-FQDN は Directory Server の完全修飾ドメイン名です。
Kerberos デーモンプロセスを開始します。
DNS は、ホストマシンに設定されている必要があります。
各手順の詳細については、ソフトウェアのマニュアルを参照してください。「GSSAPI と SASL を使用した Kerberos 認証の設定例」も参照してください。
次の手順は、Solaris OS 上で GSSAPI を使用するよう Directory Server を設定する方法を説明しています。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
「GSSAPI アイデンティティーマッピング」での説明に従って、GSSAPI のデフォルトアイデンティティーマッピングと任意のカスタムマッピングを作成します。
サービスキーを保存するために鍵タブを作成します。
LDAP サービスキーは、鍵タブに保存されます。
SASL 設定エントリまたは GSSAPI アイデンティティーマッピングエントリの 1 つを変更した場合は、Directory Server を再起動します。
DNS は、ホストマシンに設定されている必要があります。
SASL メカニズムのアイデンティティーマッピングは、SASL アイデンティティーの資格をディレクトリ内のユーザーエントリと一致させようとします。マッピングによって、SASL アイデンティティーに対応する DN が見つからなかったときは、認証は失敗します。
SASL アイデンティティーは、Principal という文字列です。これは、各メカニズムに固有の形式でユーザーを表します。Kerberos で GSSAPI を使用した主体は uid [/instance][@ realm] という形式のアイデンティティーです。uid にはオプションの instance ID を含め、オプションの realm を続けることができます。これはドメイン名の場合があります。次の例は、いずれも有効なユーザー主体です。
bjensen bjensen/Sales bjensen@EXAMPLE.COM bjensen/Sales@EXAMPLE.COM |
最初は、ディレクトリ内には GSSAPI マッピングは定義されていません。デフォルトのマッピングを定義し、使用する主体をクライアントがどのように定義するかに応じてカスタムマッピングを定義する必要があります。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
cn=GSSAPI,cn=identity mapping, cn=config の下に新しいマッピングエントリを作成します。
アイデンティティーマッピングエントリ内の属性の定義については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』を参照してください。GSSAPI のマッピングの例は、instance-path/ldif/identityMapping_Examples.ldif にあります。
このファイル内のデフォルト GSSAPI マッピングは、主体にユーザー ID のみが含まれていることを前提としています。このマッピングは、ディレクトリの固定ブランチでユーザーを決定します。
dn: cn=default,cn=GSSAPI,cn=identity mapping,cn=config objectclass: dsIdentityMapping objectclass: nsContainer objectclass: top cn: default dsMappedDN: uid=\${Principal},ou=people,dc=example,dc=com |
このファイルに含まれるもう 1 つの例は、既知のレルムを含む主体にユーザー ID が記録されている場合に、ユーザー ID を決定する方法を示しています。
dn: cn=same_realm,cn=GSSAPI,cn=identity mapping,cn=config objectclass: dsIdentityMapping objectclass: dsPatternMatching objectclass: nsContainer objectclass: top cn: same_realm dsMatching-pattern: \${Principal} dsMatching-regexp: (.*)@EXAMPLE.COM dsMappedDN: uid=\$1,ou=people,dc=EXAMPLE,dc=COM |
Directory Server を再起動して、新しいマッピングを有効にします。