test

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

LDAP クライアントでセキュリティーを使用するための設定

次に、Directory Server とセキュリティー保護された接続を確立する LDAP クライアント内で SSL を設定および使用する方法を説明します。SSL 接続では、サーバーがクライアントに証明書を送信します。クライアントは、まず最初に証明書を信頼することで、サーバーが信頼できるものであることを確認します。次に、必要に応じてクライアントは独自の証明書または SASL メカニズム (2 つのうち 1 つ) の情報を送信することで、いずれかのクライアント認証メカニズムを開始できます。SASL メカニズムは、Kerberos V5 を使用した DIGEST-MD5 および GSSAPI です。

次の各項では、SSL が有効な LDAP クライアントの例として、ldapsearch ツールを使用します。

他の LDAP クライアントに SSL 接続を設定する方法については、アプリケーションに付属するマニュアルを参照してください。

注 –

クライアントアプリケーションによっては、SSL を実装しても、信頼された証明書がサーバーにあるかどうかを検証しません。これらのクライアントアプリケーションは SSL プロトコルを使用してデータの暗号化を行いますが、機密の保護を保証することも第 3 者がユーザーとして認証されることを防止することもできません。

次の項では、セキュリティーを使用するために LDAP クライアントを設定する方法を説明します。

クライアントでの SASL DIGEST-MD5 の使用

クライアントで DIGEST-MD5 メカニズムを使用している場合、ユーザー証明書をインストールする必要はありません。ただし、暗号化された SSL 接続を利用するには、「証明書を管理する」で説明した方法で、サーバー証明書を信頼する必要があります。

レルムの指定

レルムは、認証アイデンティティーが選択される名前空間を定義します。DIGEST-MD5 認証では、特定のレルムに対して認証を行う必要があります。

Directory Server は、DIGEST-MD5 のデフォルトレルムとして、マシンの完全修飾ホスト名を使います。サーバーは、nsslapd-localhost 設定属性に含まれる小文字のホスト名を使用します。

レルムを指定しない場合、サーバーが提供するデフォルトのレルムが適用されます。

環境変数の指定

UNIX 環境では、LDAP ツールが DIGEST-MD5 ライブラリを見つけることができるように、SASL-PATH 環境変数を設定する必要があります。DIGEST-MD5 ライブラリは、SASL プラグインに動的に読み込まれる共有ライブラリです。SASL_PATH 環境変数を次のように設定します。


export SASL_PATH=SASL-library

このパスは、Directory Server が LDAP ツールが起動されたホストと同じホストにインストールされていることを前提としています。

ldapsearch コマンドの例

SSL を使用せずに DIGEST-MD5 クライアント認証を実行することができます。次の例は、デフォルトの DIGEST-MD5 アイデンティティーマッピングを使用してバインド DN を決定します。


$ ldapsearch -h host1 -p 1389 \
 -o mech=DIGEST-MD5 [ \
 -o realm="example.com"] \
 -o authid="dn:uid=bjensen,dc=example,dc=com" \
 -w - \
 -o authzid="dn:uid=bjensen,dc=example,dc=com" \
 -o secProp="minssf=56,maxssf=256,noplain" \
 -b "dc=example,dc=com" "(givenname=Richard)"

上の例は、-o (小文字の o) オプションを使用して SASL オプションを指定しています。レルムの指定は省略できますが、指定する場合は、サーバーホストマシンの完全修飾ドメイン名を指定する必要があります。プロキシ操作を対象とする authzid は使用されませんが、authid と authzid はどちらも必要であり、同じ値を指定する必要があります。-w パスワードオプションは authid に適用されます。

authid の値は、アイデンティティーマッピングで使用される主体です。authid には、ディレクトリ内の有効なユーザー DN が後に続くdn: プレフィックス か、クライアントが決定した任意の文字列が後に続く u: プレフィックスが含まれているはずです。このように authid を使用すると、「DIGEST-MD5 アイデンティティーマッピング」で説明しているマッピングを使用することができます。

最も一般的な設定は、クライアント認証のために LDAPS セキュアポートと DIGEST-MD5 を使用して暗号化を行う SSL 接続に対する設定です。次の例は、同じ処理を SSL 経由で実行します。


$ ldapsearch -h host1 -P 1636 \
 -Z -P .mozilla/bjensen/BJE6001.slt/cert8.db \
 -N "cert-example" -w - \
 -o mech=DIGEST-MD5 [-o realm="example.com"] \
 -o authid="dn:uid=bjensen,dc=example,dc=com" \
 -o authzid="dn:uid=bjensen,dc=example,dc=com" \
 -o secProp="minssf=0,maxssf=0,noplain" \
 -b "dc=example,dc=com" "(givenname=Richard)"

この例では、SSL を経由して処理を行う場合に ldapsearch コマンドに -N オプションと -w オプションが必要です。ただし、これらのオプションはクライアント認証には使用されません。その代わりに、サーバーは authid の値に含まれる主体の DIGEST-MD5 アイデンティティーマッピングを行います。

クライアントでの Kerberos SASL GSSAPI の使用

クライアントで GSSAPI メカニズムを使用する場合、ユーザー認証をインストールする必要はありませんが、Kerberos V5 セキュリティーシステムを設定する必要があります。また、暗号化された SSL 接続を使用する場合、「証明書を管理する」で説明しているように、サーバー証明書を信頼します。

Procedureホスト上で Kerberos V5 を設定する

LDAP クライアントを実行するホストマシンで Kerberos V5 を設定する必要があります。

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

  1. インストール手順に従って Kerberos V5 をインストールします。

    Sun Enterprise Authentication Mechanism 1.0.1 クライアントソフトウェアをインストールすることをお勧めします。

  2. Kerberos ソフトウェアを設定します。

    Sun Enterprise Authentication Mechanism ソフトウェアを使用して、/etc/krb5 の下のファイルを設定します。この設定は、kdc サーバーを設定し、デフォルトレルムと Kerberos システムが必要とするその他の設定を定義します。

  3. kerberos_v5 に関する行が先頭になるように、必要に応じて /etc/gss/mech ファイルを編集します。

ProcedureKerberos 認証の SASL オプションを設定する

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

  1. GSSAPI メカニズムで有効にするクライアントアプリケーションを使用する前に、ユーザーの主体で Kerberos セキュリティーシステムを起動します。


    $ kinit user-principal

    ここで、user-principal は、お使いの SASL アイデンティティーです。たとえば、bjensen@example.com となります。

  2. Kerberos の使用を設定する SASL オプションを指定します。

    UNIX 環境では、SASL_PATH 環境変数を SASL ライブラリの正しいパスに設定します。Korn シェルでの設定例は次のようになります。


    $ export SASL_PATH=SASL-library

    このパスは、Directory Server が LDAP ツールが起動されたホストと同じホストにインストールされていることを前提としています。

    次に示す ldapsearch ツールの例は、-o (小文字の o) オプションを使用して Kerberos の使用を設定する SASL オプションを指定する方法を示しています。


    $ ldapsearch -h www.host1.com -p 1389 -o mech=GSSAPI -o authid="bjensen@EXAMPLE.COM" \
 -o authzid="bjensen@EXAMPLE.COM" -b "dc=example,dc=com" "(givenname=Richard)"

    authid は、kinit コマンドによって初期化された Kerberos キャッシュに含まれるので、省略することができます。authid を指定する場合、プロキシ操作を対象とする authzid は使用されませんが、authid と authzid にはどちらにも同じ値を指定する必要があります。authid の値は、アイデンティティーマッピングで使用される主体です。レルムを含み、主体はすべて完全な主体にする必要があります。「GSSAPI アイデンティティーマッピング」を参照してください。

GSSAPI と SASL を使用した Kerberos 認証の設定例

Directory Server に対する Kerberos の設定は、複雑な場合があります。最初に Kerberos のマニュアルを参照してください。

さらに詳細について知りたい場合は、次に示す手順例を参考にしてください。ただし、この手順は例であることを忘れないでください。自分の設定と環境に合わせて手順を変更してください。

Solaris OS での Kerberos の設定と使用の詳細については、『System Administration Guide: Security Services』を参照してください。このマニュアルは Solaris マニュアルセットの一部です。マニュアルページを参照することもできます。

    この例についての情報と使用する手順は、次のとおりです。

  1. 「この例の前提」

  2. 「すべてのマシン : Kerberos クライアント設定ファイルの編集」

  3. 「すべてのマシン : 管理サーバー ACL 設定ファイルの編集」

  4. 「KDC マシン : KDC サーバー設定ファイルの編集」

  5. 「KDC マシン : KDC データベースの作成」

  6. 「KDC マシン : 管理の主体と鍵タブの作成」

  7. 「KDC マシン : Kerberos デーモンの開始」

  8. 「KDC マシン : KDC マシンと Directory Server マシンに対するホスト主体の追加」

  9. 「KDC マシン : Directory Server に対する LDAP 主体の追加」

  10. 「KDC マシン : KDC へのテストユーザーの追加」

  11. 「Directory Server マシン : Directory Server のインストール」

  12. 「Directory Server マシン : GSSAPI を有効にするための Directory Server の設定」

  13. 「Directory Server マシン : Directory Server 鍵タブの作成」

  14. 「Directory Server マシン : Directory Server へのテストユーザーの追加」

  15. 「Directory Server マシン : テストユーザーとしての Kerberos チケットの取得」

  16. 「クライアントマシン : GSSAPI による Directory Server に対する認証」

この例の前提

この手順例では、1 つ目のマシンを KDC (Key Distribution Center) として操作し、2 つ目のマシンでは Directory Server を実行できるように設定する処理について説明します。この手順の結果として、ユーザーは GSSAPI によって Kerberos 認証を実行できるようになります。

同じマシン上で KDC と Directory Server の両方を実行することもできます。両方を同じマシン上で実行することを選択した場合にも同じ手順を使用できます。この場合、KDC マシンと Directory Server マシンで重複する手順は、一度行うだけで済みます。

この手順では、使用される環境に関する多くの前提条件が発生します。手順例を使用する場合は、環境に合わせて値を変更してください。前提は次のとおりです。

すべてのマシン : Kerberos クライアント設定ファイルの編集

/etc/krb5/krb5.conf 設定ファイルは、KDC と通信するために Kerberos クライアントが必要とする情報を提供しています。

Kerberos を使用して Directory Server に対する認証を行う KDC マシン、Directory Server マシン、および任意のクライアントマシン上の /etc/krb5/krb5.conf 設定ファイルを編集します。

更新された /etc/krb5/krb5.conf 設定ファイルは、次の例の内容のようになります。

例 5–1 編集後の kerberos クライアント設定ファイル /etc/krb5/krb5.conf 


#pragma ident   "@(#)krb5.conf  1.2     99/07/20 SMI"
# Copyright (c) 1999, by Sun Microsystems, Inc.
# All rights reserved.
#
# krb5.conf template
# In order to complete this configuration file
# you will need to replace the __<name\>__ placeholders
# with appropriate values for your network.
#

[libdefaults]
        default_realm = EXAMPLE.COM
[realms]
        EXAMPLE.COM = {
                kdc = kdc.example.com
                admin_server = kdc.example.com
        }
[domain_realm]
        .example.com = EXAMPLE.COM
[logging]
        default = FILE:/var/krb5/kdc.log
        kdc = FILE:/var/krb5/kdc.log
        kdc_rotate = {

# How often to rotate kdc.log. Logs will get rotated no more
# often than the period, and less often if the KDC is not used
# frequently.
                period = 1d

# how many versions of kdc.log to keep around (kdc.log.0, kdc.log.1, ...)
                versions = 10
        }

[appdefaults]
        kinit = {
                renewable = true
                forwardable= true
        }
        gkadmin = {
                help_url =
 http://docs.sun.com:80/ab2/coll.384.1/SEAM/@AB2PageView/1195
        }

すべてのマシン : 管理サーバー ACL 設定ファイルの編集

/etc/krb5/kadm5.acl 設定ファイル内で、"___default_realm___" を "EXAMPLE.COM" に置き換えます。更新されたファイルは、次の例のようになります。

例 5–2 編集後の管理サーバー ACL 設定ファイル


#
# Copyright (c) 1998-2000 by Sun Microsystems, Inc.
# All rights reserved.
#
# pragma ident   "@(#)kadm5.acl  1.1     01/03/19 SMI"
*/admin@EXAMPLE.COM *

KDC マシン : KDC サーバー設定ファイルの編集

/etc/krb5/kdc.conf ファイルで、"___default_realm___" を "EXAMPLE.COM" に置き換えます。更新されたファイルは、次の例のようになります。

例 5–3 編集後の KDC サーバー設定ファイル /etc/krb5/kdc.conf 


# Copyright 1998-2002 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
#ident  "@(#)kdc.conf   1.2     02/02/14 SMI"

[kdcdefaults]
        kdc_ports = 88,750

[realms]
        EXAMPLE.COM = {
                profile = /etc/krb5/krb5.conf
                database_name = /var/krb5/principal
                admin_keytab = /etc/krb5/kadm5.keytab
                acl_file = /etc/krb5/kadm5.acl
                kadmind_port = 749
                max_life = 8h 0m 0s
                max_renewable_life = 7d 0h 0m 0s
                default_principal_flags = +preauth
        }

KDC マシン : KDC データベースの作成


$ /usr/sbin/kdb5_util create -r EXAMPLE.COM -s
Initializing database ’/var/krb5/principal’ for realm ’EXAMPLE.COM’,
master key name ’K/M@EXAMPLE.COM’
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: password
Re-enter KDC database master key to verify: password
$

KDC マシン : 管理の主体と鍵タブの作成

次のコマンドを使用して、kws/admin@EXAMPLE.COM という主体の管理ユーザーと、管理デーモンによって使用されるサービス鍵を作成します。


$ /usr/sbin/kadmin.local
kadmin.local:  add_principal kws/admin
Enter password for principal "kws/admin@EXAMPLE.COM": secret
Re-enter password for principal "kws/admin@EXAMPLE.COM": secret
Principal "kws/admin@EXAMPLE.COM" created.
kadmin.local:  ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc.example.com
Entry for principal kadmin/kdc.example.com with kvno 3, encryption type
 DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local:  ktadd -k /etc/krb5/kadm5.keytab changepw/kdc.example.com

Entry for principal changepw/kdc.example.com with kvno 3, encryption type
 DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local:  ktadd -k /etc/krb5/kadm5.keytab kadmin/changepw
Entry for principal kadmin/changepw with kvno 3, encryption type
 DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local:  quit$

KDC マシン : Kerberos デーモンの開始

次のコマンドを実行して、KDC および管理のデーモンを開始します。


$ /etc/init.d/kdc start
$ /etc/init.d/kdc.master start
$

KDC プロセスはプロセス一覧に /usr/lib/krb5/krb5kdc と表示されます。管理デーモンは、/usr/lib/krb5/kadmind と表示されます。

Solaris 10 OS では、デーモンは SMF (Service Management Facility) フレームワークによって管理されます。Solaris 10 OS でデーモンを起動します。


$ svcadm disable network/security/krb5kdc
$ svcadm enable network/security/krb5kdc
$ svcadm disable network/security/kadmin
$ svcadm enable network/security/kadmin
$

KDC マシン : KDC マシンと Directory Server マシンに対するホスト主体の追加

KDC の Kerberos データベースと Directory Server マシンにホスト主体を追加するには、次の一連のコマンドを使用します。ホスト主体は、klist などの特定の Kerberos ユーティリティーによって使用されます。


$ /usr/sbin/kadmin -p kws/admin
Enter Password: secret
kadmin:  add_principal -randkey host/kdc.example.com
Principal "host/kdc.example.com@EXAMPLE.COM" created.
kadmin:  ktadd host/kdc.example.com
Entry for principal host/kdc.example.com with kvno 3, encryption type
 DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:  add_principal -randkey host/directory.example.com
Principal "host/directory.example.com@EXAMPLE.COM" created.
kadmin:  ktadd host/directory.example.com
Entry for principal host/directory.example.com with kvno 3, encryption type
 DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:  quit
$

KDC マシン : Directory Server に対する LDAP 主体の追加

Directory Server で認証中のユーザーが持っている Kerberos チケットを検証できるようにするには、Directory Server が独自の主体を持っている必要があります。現在、Directory Server は ldap/fqdn@realm の主体を要求するためにハードコードされています。ここで、 fqdn は Directory Server の完全修飾ドメイン名で、realm は Kerberos レルムです。fqdn は、Directory Server のインストール時に設定される完全修飾名と一致させる必要があります。この場合、Directory Server の主体は、ldap/directory.example.com@EXAMPLE.COM となります。

Directory Server の LDAP 主体を作成するには、次の一連のコマンドを使用します。


$ /usr/sbin/kadmin -p kws/admin 
Enter Password: secret 
kadmin: add_principal -randkey ldap/directory.example.com 
Principal "ldap/directory.example.com@EXAMPLE.COM" created. 
kadmin: quit 
$

KDC マシン : KDC へのテストユーザーの追加

Kerberos 認証を実行するには、Kerberos データベース内にユーザー認証が存在している必要があります。この例では、ユーザーのユーザー名を kerberos-test にします。つまり Kerberos 主体が kerberos-test@EXAMPLE.COM になります。

この例の一連のコマンドを使用してユーザーを作成します。


$ /usr/sbin/kadmin -p kws/admin
Enter Password: secret
kadmin:  add_principal kerberos-test
Enter password for principal "kerberos-test@EXAMPLE.COM": secret

Re-enter password for principal "kerberos-test@EXAMPLE.COM": secret

Principal "kerberos-test@EXAMPLE.COM" created.
kadmin:  quit
$

Directory Server マシン : Directory Server のインストール

Directory Server 6.0 と最新のパッチをインストールします。設定例は次のとおりです。

変数のタイプ 

値の例 

完全修飾コンピュータ名 

directory.example.com

インストールディレクトリ 

/opt/SUNWdsee

インスタンスのパス 

/local/ds

サーバーユーザー 

unixuser

サーバーグループ 

unixgroup

サーバーポート 

389

サフィックス 

dc=example,dc=com

Directory Server マシン : GSSAPI を有効にするための Directory Server の設定

最初に、ファイル /data/ds/shared/bin/gssapi.ldif を作成して、主体に基づいて認証を行う Kerberos ユーザーを識別するために Directory Server によって使用されるマッピングを定義します。次の例と同じ内容のファイルを作成します。

例 5–4 gssapi.ldif ファイルの内容


dn: cn=GSSAPI,cn=identity mapping,cn=config
changetype: add
objectClass: top
objectClass: nsContainer
cn: GSSAPI
dn: cn=default,cn=GSSAPI,cn=identity mapping,cn=config
changetype: add
objectClass: top
objectClass: nsContainer
objectClass: dsIdentityMapping
objectClass: dsPatternMatching
cn: default
dsMatching-pattern: \${Principal}
dsMatching-regexp: (.*)@EXAMPLE.COM
dsMappedDN: uid=\$1,ou=People,dc=example,dc=com

dn: cn=SASL,cn=security,cn=config
changetype: modify
replace: dsSaslPluginsPath
dsSaslPluginsPath: /usr/lib/mps/sasl2/libsasl.so

次に、ldapmodify コマンドを使用して、適切なマッピングで GSSAPI を有効にするために Directory Server を更新します。次の例を参照してください。


$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -a -f /data/ds/shared/bin/gssapi.ldif
adding new entry cn=GSSAPI,cn=identity mapping,cn=config
adding new entry cn=default,cn=GSSAPI,cn=identity mapping,cn=config
modifying entry cn=SASL,cn=security,cn=config
$

Directory Server マシン : Directory Server 鍵タブの作成

これまでに説明したように、GSSAPI によって Kerberos ユーザーを認証するには、Directory Server は KDC 内に独自の主体が必要です。認証が正しく行われるためには、主体情報が Directory Server マシン上の Kerberos 鍵タブ内にある必要があります。この情報は、Directory Server が動作するユーザーアカウントが読み取れるファイル内にある必要があります。

正しいプロパティーを持つ鍵タブファイルを作成するには、次の一連のコマンドを使用します。


$ /usr/sbin/kadmin -p kws/admin
Enter Password: secret
kadmin:  ktadd -k //local/ds/config/ldap.keytab ldap/directory.example.com
Entry for principal ldap/directory.example.com with kvno 3, encryption type
 DES-CBC-CRC added to keytab
 WRFILE:/local/ds/config/ldap.keytab.
kadmin:  quit
$

このカスタム鍵タブのアクセス権と所有権を変更します。鍵タブを Directory Server を実行するために使用されるユーザーアカウントの所有にし、そのユーザーしか読み取れないようにします。


$ chown unixuser:unixgroup /local/ds/config /ldap.keytab
$ chmod 600 /local/ds/config/ldap.keytab
$

Directory Server は、デフォルトではファイル /etc/kerb5/krb5.keytab 内にある標準の Kerberos の鍵タブを使用しようとします。しかし、このファイルを Directory Server ユーザーが読めるようにすると、セキュリティー上のリスクが発生する可能性があります。これが、Directory Server 用のカスタム鍵タブを作成した理由です。

新しいカスタム鍵タブを使用するよう Directory Server を設定します。これは、KRB5_KTNAME 環境変数を設定して行います。

最後に Directory Server を再起動してこれらの変更を有効にします。


$ KRB5_KTNAME=/etc/krb5/ldap.keytab dsadm restart /local/ds

Directory Server マシン : Directory Server へのテストユーザーの追加

Kerberos ユーザーを Directory Server に対して認証するには、そのユーザーの Kerberos 主体に対応する、ユーザーのディレクトリエントリが必要です。

これまでの手順で、kerberos-test@EXAMPLE.COM という主体を持つテストユーザーが Kerberos データベースに追加されました。ディレクトリに追加されたアイデンティティーマッピング設定のために、そのユーザーに対応するディレクトリエントリには、uid=kerberos-test,ou=People,dc=example,dc=com という DN が必要です。

ユーザーをディレクトリに追加する前に、次の内容でファイル testuser.ldif を作成する必要があります。

例 5–5 新しい testuser.ldif ファイル


dn: uid=kerberos-test,ou=People,dc=example,dc=com
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: kerberos-test
givenName: Kerberos
sn: Test
cn: Kerberos Test
description: An account for testing Kerberos authentication through GSSAPI

次に、ldapmodify を使用して、このエントリをサーバーに追加します。


$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -f testuser.ldif
adding new entry uid=kerberos-test,ou=People,dc=example,dc=com
$

Directory Server マシン : テストユーザーとしての Kerberos チケットの取得

テストユーザーは、Kerberos データベース、Directory Server、および KDC 内に存在します。このため、Directory Server のテストユーザーとして GSSAPI を経由した Kerberos によって認証を行うことができるようになります。

まず、kinit コマンドを使用してユーザーの Kerberos チケットを取得します。次の例を参照してください。


$ kinit kerberos-test
Password for kerberos-test@EXAMPLE.COM: secret
$

次に、klist コマンドを使用して、このチケットに関する情報を表示します。


$ klist
Ticket cache: /tmp/krb5cc_0
Default principal: kerberos-test@EXAMPLE.COM

Valid starting            Expires                   Service principal
Sat Jul 24 00:24:15 2004  Sat Jul 24 08:24:15 2004  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until Sat Jul 31 00:24:15 2004
$

クライアントマシン : GSSAPI による Directory Server に対する認証

最後の手順は GSSAPI を使用した Directory Server に対する認証です。Directory Server の提供する ldapsearch ユーティリティーは、GSSAPI、DIGEST-MD5、および EXTERNAL メカニズムを含む SASL 認証をサポートしています。しかし、GSSAPI を使用してバインドするために、SASL ライブラリへのパスをクライアントに設定する必要があります。SASL_PATH 環境変数を lib/sasl ディレクトリに設定してパスを提供します。


$ SASL_PATH=SASL-library
$ export SASL_PATH
$

ldapsearch を使用して Directory Server に対して実際に Kerberos ベースの認証を実行するには、-o mech=GSSAPI 引数と -o authzid=principal 引数を含める必要があります。

また、ここで -h directory.example.com と表示している完全修飾ホスト名も指定する必要があります。これは、サーバーに対する cn=config 上の nsslapd-localhost 属性の値と一致する必要があります。GSSAPI 認証プロセスでは、クライアントから提供されたホスト名がサーバーから提供されたホスト名と一致する 必要があるため、ここでは -h オプションを使用する必要があります。

次の例では、これまでに作成した Kerberos テストユーザーアカウントとして認証を行なって、dc=example,dc=comエントリを取得しています。


$ ldapsearch -h directory.example.com -p 389 -o mech=GSSAPI \
 -o authzid="kerberos-test@EXAMPLE.COM" -b "dc=example,dc=com" -s base "(objectClass=*)"
version: 1
dn: dc=example,dc=com
dc: example
objectClass: top
objectClass: domain
$

正常に認証されたかどうか Directory Server のアクセスログを確認します。


$ tail -12 /local/ds/logs/access

[24/Jul/2004:00:30:47 -0500] conn=0 op=-1 msgId=-1 - fd=23 slot=23 LDAP 
		connection from 1.1.1.8 to 1.1.1.8
[24/Jul/2004:00:30:47 -0500] conn=0 op=0 msgId=1 - BIND dn="" method=sasl 
     version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=0 msgId=1 - RESULT err=14 tag=97 
     nentries=0 etime=0, SASL bind in progress
[24/Jul/2004:00:30:47 -0500] conn=0 op=1 msgId=2 - BIND dn="" method=sasl 
     version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=1 msgId=2 - RESULT err=14 tag=97 
     nentries=0 etime=0, SASL bind in progress
[24/Jul/2004:00:30:47 -0500] conn=0 op=2 msgId=3 - BIND dn="" method=sasl 
     version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=2 msgId=3 - RESULT err=0 tag=97 
     nentries=0 etime=0 dn="uid=kerberos-test,ou=people,dc=example,dc=com"
[24/Jul/2004:00:30:47 -0500] conn=0 op=3 msgId=4 - SRCH base="dc=example,dc=com"
     scope=0 filter="(objectClass=*)" attrs=ALL
[24/Jul/2004:00:30:47 -0500] conn=0 op=3 msgId=4 - RESULT err=0 tag=101 nentries=1 
     etime=0
[24/Jul/2004:00:30:47 -0500] conn=0 op=4 msgId=5 - UNBIND
[24/Jul/2004:00:30:47 -0500] conn=0 op=4 msgId=-1 - closing - U1
[24/Jul/2004:00:30:48 -0500] conn=0 op=-1 msgId=-1 - closed.
$

この例は、バインドが 3 つの手順によるプロセスであることを示しています。最初の 2 つの手順で LDAP 結果 14 (SASL バインド実行中) を返し、3 番目の手順はバインドが成功したことを示します。method=sasl タグと mech=GSSAPI タグは、このバインドに GSSAPI SASL メカニズムが使用されたことを示しています。成功したバインド応答の最後の dn="uid=kerberos-test,ou=people,dc=example,dc=com" は、このバインドが適切なユーザーとして実行されたことを示しています。