Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド

資格レベルと認証方法の設定

クライアントに適用されるセキュリティーモデルは、資格レベルと認証方法の組み合わせで定義されます。

Directory Server では、次の資格レベルがサポートされています。

クライアント認証は、クライアントのアイデンティティーを確認するためのサーバーのメカニズムです。

クライアント認証は、次のいずれかの方法で実行できます。

この節では、Directory Server での 2 つの SASL メカニズムの設定に関する次の情報について説明します。

セキュリティーの設定の詳細については、「LDAP クライアントでセキュリティーを使用するための設定」を参照してください。

Directory Server での SASL 暗号化レベルの設定

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 セキュリティーファクタである dsSaslMinSSF0 で、保護されていないことを示します。実際の最小値は、Directory Server の最小値を変更しない限り、クライアント設定によって変わります。実際は、サーバーとクライアントに使用する最低レベルに最小値を設定します。サーバーとクライアントが最低要件を満たすメカニズムのネゴシエーションに失敗した場合、接続は確立されません。

ProcedureSASL 暗号化を要求する

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

  1. 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

ProcedureSASL 暗号化を許可しない

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

  1. SASL 暗号化を許可しない場合は dsSaslMinSSFdsSaslMaxSSF の両方の値をゼロに設定します。


    $ 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
    ^D

DIGEST-MD5 を利用した SASL 認証

DIGEST-MD5 メカニズムは、クライアントによって送信されたハッシュされた値をユーザーのパスワードのハッシュと比較することによって、クライアントを認証します。ただし、このメカニズムはユーザーパスワードを読み取る必要があり、DIGEST-MD5 による認証を希望するすべてのユーザーは、ディレクトリ内に {CLEAR} パスワードを持つ必要があります。{CLEAR} パスワードをディレクトリに保存する場合に、第 6 章「Directory Server のアクセス制御」で説明されているように、パスワード値へのアクセスが ACI によって正しく制限されていることを確認する必要があります。さらに、「属性値の暗号化」で説明しているように、サフィックスで属性の暗号化を設定する必要があります。

ProcedureDIGEST-MD5 メカニズムを設定する

次の手順は、DIGEST-MD5 を使用するように Directory Server を設定する方法を説明しています。

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

  1. 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
    ^D
  2. 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
    ^D

    ここで、SASL-library は次のいずれかです。

    JES installation

    /usr/lib/mps/sasl2

    Zip installation

    install-path/dsee6/private/lib

  3. DIGEST-MD5 のデフォルトのアイデンティティーマッピングを使用するか新規作成します。

    詳細については、「DIGEST-MD5 アイデンティティーマッピング」を参照してください。

  4. DIGEST-MD5 を使用する SSL 経由でサーバーにアクセスするすべてのユーザーのパスワードが {CLEAR} に含まれていることを確認します。

    パスワード保存スキーマについては、第 7 章「Directory Server のパスワードポリシー」を参照してください。

  5. SASL 設定エントリまたは DIGEST-MD5 アイデンティティーマッピングエントリの 1 つを変更した場合は、Directory Server を再起動します。

DIGEST-MD5 アイデンティティーマッピング

SASL メカニズムの アイデンティティーマッピングは、SASL アイデンティティーの資格をディレクトリ内のユーザーエントリと一致させようとします。マッピングによって、SASL アイデンティティーに対応する DN が見つからなかったときは、認証は失敗します。このメカニズムの詳細な説明については、『Sun Java System Directory Server Enterprise Edition 6.1 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 が含まれていることを前提としています。

ProcedureDIGEST-MD5 用の独自のアイデンティティーマッピングを定義する

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

  1. 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)
  2. Directory Server を再起動して、新しいマッピングを有効にします。

GSSAPI を利用した SASL 認証 (Solaris OS のみ)

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 を取得します。

ProcedureKeberos システムを設定する

製造元の指示に従って、Kerberos ソフトウェアを設定します。Sun Enterprise Authentication Mechanism 1.0.1 サーバーを使用している場合、次の手順を使用します。

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

  1. /etc/krb5内のファイルを設定します。

  2. ユーザーとサービスを保存するために Kerberos データベースを作成します。

  3. データベース内で LDAP サービスの主体を作成します。


    $ ldap/server-FQDN@realm
    

    ここで、server-FQDN は Directory Server の完全修飾ドメイン名です。

  4. Kerberos デーモンプロセスを開始します。


    注 –

    DNS は、ホストマシンに設定されている必要があります。


    各手順の詳細については、ソフトウェアのマニュアルを参照してください。「GSSAPI と SASL を使用した Kerberos 認証の設定例」も参照してください。

ProcedureGSSAPI メカニズムを設定する

次の手順は、Solaris OS 上で GSSAPI を使用するよう Directory Server を設定する方法を説明しています。

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

  1. 「GSSAPI アイデンティティーマッピング」での説明に従って、GSSAPI のデフォルトアイデンティティーマッピングと任意のカスタムマッピングを作成します。

  2. サービスキーを保存するために鍵タブを作成します。

    LDAP サービスキーは、鍵タブに保存されます。

    1. 鍵タブは必ず Directory Server ユーザーのみが読み取れるようにします。

    2. ファイル名をデフォルトの /etc/krb5/krb5.keytab から変更します。

    3. デフォルトの鍵タブではなく、必ず新しい鍵タブが使用されるように、環境変数 KRB5_KTNAME を設定します。

  3. SASL 設定エントリまたは GSSAPI アイデンティティーマッピングエントリの 1 つを変更した場合は、Directory Server を再起動します。

    DNS は、ホストマシンに設定されている必要があります。

GSSAPI アイデンティティーマッピング

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 マッピングは定義されていません。デフォルトのマッピングを定義し、使用する主体をクライアントがどのように定義するかに応じてカスタムマッピングを定義する必要があります。

ProcedureGSSAPI 用のアイデンティティーマッピングを定義する

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

  1. cn=GSSAPI,cn=identity mapping, cn=config の下に新しいマッピングエントリを作成します。

    アイデンティティーマッピングエントリ内の属性の定義については、『Sun Java System Directory Server Enterprise Edition 6.1 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
  2. Directory Server を再起動して、新しいマッピングを有効にします。