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

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

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

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

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

次の項では、セキュリティを使用するために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

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

`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オプションを指定しています。realmは省略できますが、指定する場合は、サーバー・ホスト・マシンの完全修飾ドメイン名を指定する必要があります。プロキシ操作を対象とする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接続を使用する場合、「証明書の管理」で説明した方法で、サーバー証明書を信頼する必要があります。

ホスト上でKerberos V5を構成するには:

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

このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。

インストール手順に従ってKerberos V5をインストールします。
Sun Enterprise Authentication Mechanism 1.0.1クライアント・ソフトウェアをインストールすることをお薦めします。
Kerberosソフトウェアを構成します。
Sun Enterprise Authentication Mechanismソフトウェアを使用して、/etc/krb5の下のファイルを構成します。この構成は、kdcサーバーを設定し、デフォルト・レルムとKerberosシステムが必要とするその他の構成を定義します。
kerberos_v5に関する行が先頭になるように、必要に応じて/etc/gss/mechファイルを変更します。

Kerberos認証のSASLオプションを設定するには:

このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。

GSSAPIメカニズムで有効にするクライアント・アプリケーションを使用する前に、ユーザーの主体でKerberosセキュリティ・システムを初期化します。
```
$ kinit user-principal
```
ここで、user-principalは、ご使用のSASLアイデンティティです。たとえば、bjensen@example.comとなります。
Kerberosの使用を設定するSASLオプションを指定します。
UNIX環境では、SASL_PATH環境変数をSASLライブラリの正しいパスに設定する必要があります。Kornシェルでの設定例は次のようになります。
```
$ export SASL_PATH=SASL-library
```
このパスは、LDAPツールが起動されたホストと同じホストにDirectory Serverがインストールされていることを前提としています。
次に示す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の構成と使用の詳細は、システム管理ガイド: セキュリティ・サービスを参照してください。このマニュアルはSolarisマニュアル・セットの一部です。マニュアル・ページを参照することもできます。

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

この例の前提
すべてのマシン: Kerberosクライアント構成ファイルの編集
すべてのマシン: 管理サーバーACL構成ファイルの編集
KDCマシン: KDCサーバー構成ファイルの編集
KDCマシン: KDCデータベースの作成
KDCマシン: 管理の主体と鍵タブの作成
KDCマシン: Kerberosデーモンの開始
KDCマシン: KDCマシンとDirectory Serverマシンに対するホスト主体の追加
KDCマシン: Directory Serverに対するLDAP主体の追加
KDCマシン: KDCへのテスト・ユーザーの追加
Directory Serverマシン: Directory Serverのインストール
Directory Serverマシン: GSSAPIを有効にするためのDirectory Serverの構成
Directory Serverマシン: Directory Server鍵タブの作成
Directory Serverマシン: Directory Serverへのテスト・ユーザーの追加
Directory Serverマシン: テスト・ユーザーとしてのKerberosチケットの取得
クライアント・マシン: GSSAPIによるDirectory Serverに対する認証

この例の前提

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

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

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

このシステムには、推奨される最新のパッチ・クラスタのインストールされた最新のSolaris 9ソフトウェアがインストールされている。適切なSolarisパッチがインストールされていない場合、Directory Serverに対するKerberos認証は失敗する可能性があります。

マニュアルに記述された手順はSolaris 10およびLinuxとほとんど同じですが、いくつかの違いがあります。構成ファイルの形式が多少異なり、コマンドおよび構成ファイルのパスは異なり、いくつかのコマンドの出力が同じでない場合もあります。
Kerberosデーモンを実行するマシンは、kdc.example.comという完全修飾ドメイン名を持つ。このマシンは、ネーミング・サービスにDNSを使用するように構成する必要があります。この構成は、Kerberosの必要条件です。fileなど、他のネーミング・サービスをかわりに使用すると、特定の操作が失敗することもあります。
Directory Serverを実行するマシンは、directory.example.comという完全修飾ドメイン名を持つ。このマシンも、ネーミング・サービスにDNSを使用するように構成する必要があります。
Directory Serverマシンは、KerberosによってDirectory Serverに対する認証を行うためのクライアント・システムとして機能する。この認証は、Directory ServerとKerberosデーモンの両方と通信できる任意のシステムから実行できます。しかし、この例で必要なコンポーネントはすべて、Directory Serverによって提供され、認証はこのシステムから実行されます。
Directory Serverのユーザーは、uid=username,ou=People,dc=example,dc=comという形式のDNを持つ。対応するKerberos主体は、username@EXAMPLE.COMusername@EXAMPLE.COMです。別のネーミング・スキームを使用する場合は、別のGSSAPIアイデンティティ・マッピングを使用する必要があります。

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

Kerberosクライアント構成ファイルは、KDCと通信するためにKerberosクライアントが必要とする情報を提供しています。

Solaris:: /etc/krb5/krb5.conf
Linux:: /etc/krb5.conf

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

"___default_realm___"をすべて"EXAMPLE.COM"に置き換えます。
"___master_kdc___"をすべて"kdc.example.com"に置き換えます。
"___slave_kdcs___"の含まれる行を削除して、Kerberosサーバーが1つしか存在しないようにします。
"___domain_mapping___"を".example.com = EXAMPLE.COM"に置き換えます(.example.comの最初のピリオドに注意)。

Solaris上で更新されたKerverosクライアント構成ファイルは、次の例の内容のようになります。

例5-1 編集後のSolaris上の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 編集後のSolaris上の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データベースの作成

$ 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という主体の管理ユーザーと、管理デーモンによって使用されるサービス鍵を作成します。

$ 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ユーティリティによって使用されます。

$ 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主体を作成するには、次の一連のコマンドを使用します。

$ 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になります。

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

$ 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のインストール

Oracle Directory Server Enterprise Edition 11g R1(11.1.1.5.0)と最新のパッチをインストールします。設定例は次のとおりです。

変数タイプ	値の例
完全修飾コンピュータ名	`directory.example.com`
インストール・ディレクトリ	`/opt/SUNWdsee`
インスタンスのパス	`/local/dsInst`
サーバーのユーザー	`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: SASL-library

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

ネイティブ・パッケージ・ベース・インストール: /usr/lib/mps/sasl2
Zipインストール: install-path/lib/private/

次に、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が動作するユーザー・アカウントが参照できるファイル内にある必要があります。

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

$ kadmin -p kws/admin
Enter Password: secret
kadmin:  ktadd -k /local/dsInst/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/dsInst/config/ldap.keytab.
kadmin:  quit
$

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

$ chown unixuser:unixgroup /local/dsInst/config /ldap.keytab
$ chmod 600 /local/dsInst/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/dsInst

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/dsInst/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"は、このバインドが適切なユーザーとして実行されたことを示しています。

ナビゲーション・リンクをスキップ
印刷ビューの終了
	Oracle Directory Server Enterprise Edition管理ガイド 11gリリース1(11.1.1.5.0)