第 11 章認証と暗号化の管理

Directory Server には、ネットワーク上でセキュリティ保護され、かつ信頼できる通信を可能にするためのメカニズムが用意されています。LDAPS は標準の LDAP プロトコルのうち、データを暗号化したり認証のために証明書を使用したりするために SSL (Secure Sockets Layer) 上で実行されるものです。

Directory Server は Start TLS (Start Transport Layer Security) 拡張処理もサポートしているため、元は暗号化されていない LDAP 接続でも TLS を有効にできます。

Directory Server では、SASL (Simple Authentication and Security Layer) を介した GSSAPI (Generic Security Services API) にも対応するようになりました。これにより、Solaris オペレーティングシステムで Kerberos Version 5 セキュリティプロトコルを利用できます。ID マッピングメカニズムによって、Kerberos 主体とディレクトリ内の ID が関連づけられます。

セキュリティ情報の詳細は、次に示す NSS の Web サイトを参照してください。

Directory Server における SSL の概要

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

Directory Server における SSL の概要

SSL (Secure Sockets Layer) は暗号化された通信と、オプションとして Directory Server とクライアントの間の認証を提供します。LDAP プロトコルと DSML-over-HTTP プロトコルの両方で SSL を有効化し、サーバーとのすべての接続にセキュリティを提供することができます。また、レプリケーションと連鎖サフィックスのメカニズムが SSL を利用するように設定して、サーバー間の通信をセキュリティ保護することもできます。

簡易認証 (バインド DN とパスワード) の SSL を使用することで、サーバーとやり取りされるすべてのデータが暗号化され、データの機密と整合性が保証されます。必要に応じて、クライアントは証明書を使用して Directory Server への接続の認証、およびSASL (Simple Authentication and Security Layer) を利用したサードパーティ製のセキュリティメカニズムへの接続の認証ができます。証明書ベースの認証では、公開鍵暗号方式を使用してクライアントまたはサーバーを偽装したり、認証されているユーザーになりすますことはできなくなります。

Directory Server では、SSL による通信と SSL を使用しない通信を別々のポートで同時に実行できます。また、セキュリティのためにすべての通信をセキュリティ保護されたポートに限定することもできます。クライアント認証を設定して、指定したセキュリティレベルを必須にするか、単にそのレベルを許可するかを定義できます。

SSL を有効にすることで、通常の LDAP 接続をセキュリティ保護する Start TLS 拡張処理への対応も有効になります。クライアントが SSL 以外のポートにバインドされても、TLS (Transport Layer Security) プロトコルを使用して SSL 接続を開始できます。Start TLS 処理では、クライアントに一層の柔軟性が与えられ、ポートの割り当ても簡素化されます。

SSL が提供する暗号化メカニズムは、属性の暗号化にも使用されます。SSL を有効にすることで、サフィックスでの属性の暗号化を設定し、ディレクトリに格納するときにデータを保護することができます。詳細は、「属性値の暗号化」を参照してください。

これ以外のセキュリティとして、クライアント側の SSL と証明書の使用状況に応じてディレクトリの内容へのアクセス制御を設定できます。特定の認証メソッドを必要とする ACI (アクセス制御命令) を定義することで、セキュリティ保護されたチャンネルだけを通じてデータを転送することができます。詳細は、「バインドルール」を参照してください。

管理サーバーに SSL を設定する方法など、SSL、インターネットセキュリティ、証明書の詳細な説明については、『Administration Server Administration Guide』の第 10 章「Using SSL and TLS with Sun Java System Servers」を参照してください。

SSL を有効化する手順の概要

この章の以後の各項では、次の各手順について説明します。

Directory Server で使用する証明書を入手してインストールし、認証局 (CA) の証明書を信頼するように Directory Server を設定します。この処理には、次の手順が含まれます。

必要に応じて証明書データベースを作成する

証明書要求を作成し、サーバーからサーバー証明書を提供する認証局 (CA) に対して送信する

新しい証明書をサーバーにインストールする

CA、およびその CA が発行するすべての証明書を信頼する

LDAP 処理および DSML 処理用のセキュリティ保護されたポートの指定を含め、ディレクトリで SSL を有効化し、設定します。サーバーへのアクセスに SSL を使用するように Directory Server コンソールを設定することもできます。

必要に応じて、サーバーに次のクライアント認証メカニズムを 1 つまたは複数設定します。

デフォルトの証明書ベースの認証

SASL を利用した DIGES_MD5 認証メカニズム

Kerberos V5 セキュリティメカニズムを利用できる、SASL を利用した GSSAPI 認証

使用するオプションの認証メカニズムの指定も含め、Directory Server との通信に SSL を使用するようにクライアントを設定します。

上の一部の手順は、コマンド行から証明書を管理するための certutil ツールを使用して実行することもできます。このツールは SUNWtlsu パッケージ内に提供されています。

サーバー証明書の入手とインストール

ここでは、証明書データベースの作成、Directory Server で使用する証明書の入手とインストール、および認証局 (CA) の証明書を信頼するように Directory Server を設定するそれぞれのプロセスについて説明します。

証明書データベースの作成

サーバーに初めて SSL を設定するときは、セキュリティデバイスのパスワードを設定する必要があります。既存のハードウェアセキュリティデバイスを使用していない場合は、次のファイルに格納されている証明書と鍵データベースが内部セキュリティデバイスとなります。

serverID に大文字が含まれている場合は、後述するコマンド行の手順を実行して証明書データベースを作成する必要があります。

コンソールから

コンソールを使う場合、証明書マネージャダイアログを初めて呼び出すときに、サーバーが証明書データベースファイルを自動的に作成します。

Directory Server コンソールの最上位にある「タスク」タブで、「証明書の管理」ボタンをクリックします。あるいは、「タスク」タブを表示した状態でコンソールの「セキュリティ」メニューから「証明書の管理」を選択します。

サーバーは、証明書と鍵データベースを自動的に作成します。このとき、セキュリティデバイスのパスワードの設定が求められます。このパスワードは、サーバーに格納される、証明書の非公開鍵を保護します。確認のためにパスワードをもう一度入力し、「了解」をクリックします。

コマンド行を使用

コマンド行から証明書データベースファイルを作成するときは、サーバーが検出できるように、パスとファイル名のプレフィックスを次の手順のように指定する必要があります。

サーバーのホストマシンで、次のコマンドを実行して証明書データベースを作成します。

certutil -N -d ServerRoot/alias -P slapd-LCserverID

ここで、LCserverID は、すべて小文字で表記したサーバー名です。

証明書の鍵を保護するためのパスワードの入力が求められます。

証明書要求の生成

PKCS #10 証明書要求を PEM 形式で生成するときは、次のいずれかの手順を実行します。PEM (Privacy Enhanced Mail) は、RFC 1421 ～ 1424 (http://www.ietf.org/rfc/rfc1421.txt) で指定されている形式で、US-ASCII 文字を使用した base64 形式で符号化されます。要求の内容は、次の例のようになります。

コンソールから

「証明書の管理」ダイアログが表示されます。

「サーバー証明書」タブを選択し、「要求」ボタンをクリックします。

証明書リクエストウィザードが表示されます。

サーバーが CA と直接通信するためのプラグインがインストールされている場合は、ここでそのプラグインを選択します。プラグインがインストールされていない場合は、生成した要求を電子メールまたは Web サイト経由で送信し、手動で証明書を要求する必要があります。「次へ」をクリックして処理を続けます。

何も入力されていないテキストフィールドに要求者の情報を入力します。

サーバー名 : DNS 検索で使用される、Directory Server の完全修飾ホスト名を入力します (たとえば、east.example.com)。

組織 : 企業または組織の正式名称を入力します。CA の多くは、ここに入力された情報を、営業許可証の複写などの法的文書で確認することを要求します。

組織単位 : (省略可能) 企業内の部署名またはビジネス単位の名称を入力します。

都市 / 地域 : (省略可能) 会社の所在地 (市町村名) を入力します。

都道府県 : 会社の所在地 (都道府県) を完全名で入力します (省略形は不可)。

国 / 地域 : 国名を表す 2 文字の略号 (ISO 形式) を選択します。日本の国コードは「JP」です。ISO 国コードのリストは、『Directory Server Administration Reference』の第 5 章にある「Directory Internationalization Reference」に記載されています。

「次へ」をクリックして処理を続けます。

セキュリティデバイスのパスワードを入力し、「次へ」をクリックします。これは、「証明書データベースの作成」で設定したパスワードです。

「クリップボードにコピー」または「ファイルに保存」を選択し、CA に送る必要のある証明書要求情報を保存します。

「完了」をクリックして、証明書リクエストウィザードを終了します。

コマンド行を使用

次のコマンドを実行して、サーバー証明書の要求を作成します。

certutil -R ¥
-s "cn=serverName,ou=division,o=company,l=city,st=state,c=country" ¥
-a -d ServerRoot/alias -P slapd-serverID-

-s オプションは、要求するサーバー証明書の DN を指定します。通常、CA はサーバーを完全に識別するために、この例に含まれるすべての属性を必要とします。各属性の説明については、手順 4 を参照してください。

certutil ツールは、サーバーの鍵データベースを保護しているパスワードの入力を要求します。これは、「証明書データベースの作成」で設定したパスワードです。これにより、PEM で符号化されたテキスト形式の PKCS #10 証明書要求が生成されます。

サーバー証明書のインストール

ここで説明する手順に従って、前の項で生成した要求を CA に送信します。証明書要求は、電子メールとしての送信が求められることもありますが、CA の Web サイトに入力できる場合もあります。

証明書要求を送信したら、証明書に関する CA からの回答を待つ必要があります。要求に対する回答が届くまでの時間は、状況によって異なります。たとえば、CA が社内にある場合は、要求に対する回答は 1 ～ 2 日しかかからないこともあります。CA が社外にある場合は、数週間かかることもあります。

CA から回答が届いたら、その情報をテキストファイルに確実に保存してください。次に、PEM 形式の PKCS #11 証明書の例を示します。

また、証明書データのバックアップを安全な場所に置く必要もあります。これにより、システムに保存された証明書データが失われても、バックアップファイルから証明書をインストールし直すことができます。

サーバー証明書を受け取ったら、それをサーバーの証明書データベースにインストールできます。

コンソールから

「証明書の管理」ウィンドウが表示されます。

「サーバー証明書」タブを選択し、「インストール」をクリックします。

証明書インストールウィザードが表示されます。

次のオプションから証明書の保存場所を 1 つ選択します。

このファイル内 : 証明書の絶対パスをこのフィールドに入力します。

次の符号化されたテキストブロック中 : CA から、または作成したテキストファイルからテキストをコピーし、このフィールドにペーストします。たとえば、次のようにします。

「次へ」をクリックして処理を続けます。

表示された証明書情報が正しいことを確認し、「次へ」をクリックします。

証明書の名前を指定し、「次へ」をクリックします。これは、証明書のテーブルに表示される名前です。

非公開鍵を保護するパスワードを入力して、証明書を検証します。このパスワードは、「証明書データベースの作成」の手順 2 で入力したものと同じです。処理が終了したら、「完了」をクリックします。

「サーバー証明書」タブのリストに新しい証明書が表示されます。これで、サーバーで SSL を有効にする準備が整いました。

コマンド行を使用

次のコマンドを実行して、証明書データベースに新しいサーバー証明書をインストールします。

certutil -A -n "certificateName" -t "u,," -a -i certFile ¥
-d ServerRoot/alias -P slapd-serverID-

ここで、certificateName は証明書を識別するために指定する名前です。certFile は、PEM 形式の PKCS #11 証明書を含むテキストファイルです。-t "u,," オプションは、この証明書が SSL 通信用のサーバー証明書であることを示します。

必要に応じて、次の certutil コマンドを実行して、インストールした証明書を検証することができます。

certutil -L -d ServerRoot/alias -P slapd-serverID-

u,, という信頼属性が表示される証明書は、サーバー証明書です。

CA の信頼設定

CA を信頼するように Directory Server を設定するには、証明書を入手し、それをサーバーの証明書データベースにインストールします。このプロセスは、使用する CA によって異なります。一部の商用 CA では、証明書を自動的にダウンロードできる Web サイトを用意しています。それ以外の CA からは、要求に応じて電子メールで証明書が送られます。

コンソールから

CA の証明書を入手したら、証明書インストールウィザードを使用して、CA を信頼するように Directory Server を設定できます。

「証明書の管理」ウィンドウが表示されます。

「CA 証明書」タブを選択し、「インストール」をクリックします。

証明書インストールウィザードが表示されます。

CA の証明書をファイルに保存した場合は、ファイルのパスを該当のフィールドに入力します。CA の証明書を電子メールで受け取った場合は、ヘッダーを含む証明書をコピーし、該当のテキストフィールドにペーストします。「次へ」をクリックします。

表示された証明書情報が正しい CA からの証明書に関するものであることを確認し、「次へ」をクリックします。

証明書の名前を指定し、「次へ」をクリックします。

この CA を信頼する目的を選択します。次のいずれか、または両方を選択できます。

クライアントからの接続を受け入れる (クライアント認証): LDAP クライアントが、この CA が発行する証明書を示すことで証明書ベースのクライアント認証を行う場合は、このチェックボックスを選択します。

ほかのサーバーに接続する (サーバー認証): サーバーが、この CA が発行する証明書を持つ他のサーバーに対して SSL 経由のレプリケーションサプライヤーまたは連鎖マルチプレクサとして機能する場合は、このチェックボックスを選択します。

「完了」をクリックして、ウィザードを終了します。

コマンド行を使用

次のコマンドを実行して、CA 証明書を信頼することもできます。

certutil -A -n "CAcertificateName" -t "trust,," -a -i certFile ¥
-d ServerRoot/alias -P slapd-serverID-

ここで、CAcertificateName は信頼した CA を識別するために指定する名前です。certFile は、PEM で符号化されたテキスト形式の PKCS #11 CA 証明書を含むテキストファイルです。trust には、次のいずれかのコードを指定します。

T : クライアント証明書の発行について、この証明書を信頼する。LDAP クライアントが、この CA が発行する証明書を示すことで証明書ベースのクライアント認証を行う場合は、このコードを選択する

C : サーバー証明書の発行について、この証明書を信頼する。サーバーが、この CA が発行する証明書を持つ他のサーバーに対して SSL 経由のレプリケーションサプライヤーまたは連鎖マルチプレクサとして機能する場合は、このコードを選択する

CT : クライアント証明書とサーバー証明書の両方の発行について、この証明書を信頼する。上記の両方にこの CA を適用するときは、このコードを選択する

必要に応じて、次の certutil コマンドを実行して、インストールした証明書を検証することができます。

certutil -L -d ServerRoot/alias -P slapd-serverID

u,, という信頼属性が表示される証明書はサーバー証明書で、CT,, が表示される証明書は CA 証明書です。

SSL の有効化

サーバー証明書をインストールし、CA の証明書を信頼すると、SSL を有効にすることができます。通常、サーバーは SSL を有効にした状態で動作させます。SSL を一時的に無効にする場合は、機密性、認証、またはデータの整合性を必要とする操作を処理する前に、SSL を必ず有効にしてください。

SSL を有効にする前に、「サーバー証明書の入手とインストール」の説明に従って、証明書データベースを作成し、サーバーの証明書を入手およびインストールして、CA の証明書を信頼する必要があります。

次に、次の手順を実行して SSL 通信を有効にし、ディレクトリサーバー内の暗号化メカニズムを有効化します。

Directory Server コンソールの最上位の「設定」タブで、サーバー名のルートノードを選び、右側のパネルで「暗号化」タブを選びます。

このタブには、サーバーの現在の暗号化設定が表示されます。

「このサーバーの SSL を有効にする」チェックボックスを選択して、暗号化を有効にするよう指定します。

「この暗号化方式ファミリを使用」チェックボックスを選択します。

ドロップダウンメニューから使用する証明書を選択します。

「暗号化方式」の「設定」ボタンをクリックし、「暗号化方式のプリファレンス」ダイアログで使用する暗号化方式を選択します。暗号化方式の詳細については、「暗号化方式の選択」を参照してください。

クライアント認証を設定します。

クライアント認証を許可しない: このオプションを選択すると、サーバーはクライアントの証明書を無視し、この証明書に基づいた認証を拒否します。

クライアント認証を許可する: これはデフォルトの設定です。このオプションを選択すると、クライアントの要求に対して認証が実行されます。証明書に基づく認証については、「クライアント認証の設定」を参照してください。



注	証明書に基づく認証をレプリケーションに使用する場合は、クライアント認証を許可するか、または要求するようにコンシューマサーバーを設定する必要があります。

クライアント認証を要求する: このオプションを選択すると、サーバーからの認証の要求にクライアントが応答しない場合に、クライアント接続が拒否されます。



注	Server Console が SSL 経由で Directory Server に接続する場合に「クライアント認証を要求する」を選択すると、Server Console にはクライアント認証に使用する証明書が用意されていないため、接続が無効になります。この属性をコマンド行から変更する方法については、「クライアント認証の許可」を参照してください。

必要に応じて、Directory Server との通信にコンソールが SSL を使うときは、「Sun Java ^TM サーバーコンソールで SSL を使用」を選択します。

設定が完了したら「保存」をクリックします。

必要に応じて、サーバーが LDAP プロトコルと DSML-over-HTTP プロトコルの両方で SSL 通信に使うセキュリティ保護されたポートを設定します。詳細は、「Directory Server のポート番号の変更」を参照してください。

セキュリティ保護されたポートへのすべての接続は、SSL を使用する必要があります。SSL を有効にした場合は、セキュリティ保護されたポートを設定するかどうかに関係なく、クライアントは Start TLS 処理を使用して、セキュリティ保護されていないポートを通じて SSL 暗号化を行えます。

Directory Server を再起動します。

詳細は、「SSL が有効になった状態でのサーバーの起動」を参照してください。

暗号化方式の選択

暗号化方式は、データの暗号化と復号化に使用されるアルゴリズムです。一般に、暗号化に使用するビット数が多いほど、強度と安全性は高まります。SSL の暗号化方式は、使用するメッセージ認証のタイプによっても識別されます。メッセージ認証は、データの整合性を保証するチェックサムを計算する別のアルゴリズムです。暗号化アルゴリズムとその強度の詳細については、『Administration Server Administration Guide』の付録 B にある「Ciphers Used With SSL」を参照してください。

クライアントがサーバーとの SSL 接続を開始するときは、情報の暗号化にどの暗号を使用するかをについて、クライアントとサーバーが合意する必要があります。双方向の暗号化プロセスでは、サーバーとクライアントで同じ暗号化方式を使用する必要があり、通常は、両者が共通して対応している最強の方式が選択されます。

Directory Server には、SSL3.0 と TLS 用に次の暗号化方式が用意されています。

表 11-1 Directory Server が提供する暗号化方式
暗号化方式名	内容
なし	暗号化なし。MD5 メッセージ認証だけを使用する (rsa_null_md5)
RC4 (128 ビット)	128 ビットの暗号化と MD5 メッセージ認証を使用した RC4 暗号化方式 (rsa_rc4_128_md5)
RC4 (エクスポート)	40 ビットの暗号化と MD5 メッセージ認証を使用した RC4 暗号化方式 (rsa_rc4_40_md5)
RC2 (エクスポート)	40 ビットの暗号化と MD5 メッセージ認証を使用した RC2 暗号化方式 (rsa_rc2_40_md5)
DES または DES (エクスポート)	56 ビットの暗号化と SHA メッセージ認証を使用した DES (rsa_des_sha)
DES (FIPS)	56 ビットの暗号化と SHA メッセージ認証を使用した FIPS DES。この暗号化方式は、暗号化モジュール (rsa_fips_des_sha) の実装用 FIPS 140-1 米国政府規格に準拠する
トリプル DES	168 ビットの暗号化と SHA メッセージ認証を使用したトリプル DES (rsa_3des_sha)
トリプル DES (FIPS)	168 ビットの暗号化と SHA メッセージ認証を使用した FIPS トリプル DES。この暗号化方式は、暗号化モジュール (rsa_fips_3des_sha) の実装用 FIPS 140-1 米国政府規格に準拠する
Fortezza	80 ビットの暗号化と SHA メッセージ認証を使用する Fortezza 暗号化方式
RC4 (Fortezza)	128 ビットの暗号化と SHA メッセージ認証を使用する Fortezza RC4 暗号化方式
なし (Fortezza)	暗号化は行われず、Fortezza SHA メッセージ認証のみ

Server Console で常に SSL を使用するには、次の暗号の中から少なくとも 1 つの暗号を選択する必要があります。

40 ビットの暗号化と MD5 メッセージ認証を使用する RC4 暗号

暗号化は行われず、MD5 メッセージ認証のみ (お勧めできない)

56 ビットの暗号化と SHA メッセージ認証を使用する DES

128 ビットの暗号化と MD5 メッセージ認証を使用する RC4 暗号

168 ビットの暗号化と SHA メッセージ認証を使用するトリプル DES

サーバーが使用する暗号化方式を選択するには、次の手順を実行します。

Directory Server コンソールの最上位の「設定」タブで、サーバー名のルートノードを選び、右側のパネルで「暗号化」タブを選びます。

このタブには、サーバーの現在の暗号化設定が表示されます。「SSL の有効化」で説明している方法で、SSL がサーバーで有効になっていることを確認します。

「暗号化方式のプリファレンス」をクリックします。

「暗号化方式のプリファレンス」ダイアログボックスが表示されます。

「暗号化方式のプリファレンス」ダイアログボックスで、暗号化方式の名前の隣にあるチェックボックスを選択または選択解除して、サーバーで使用する暗号化方式を選択します。

セキュリティ上の理由で特定の暗号を使用できない場合を除き、none,MD5 以外のすべての暗号を選択します。



警告	暗号化を行わずに MD5 メッセージ認証だけを行うことは避けてください。クライアントで使用可能な暗号がほかにない場合に、サーバーはこのオプションを使用します。この方式は暗号化が行われないため、セキュリティ保護されません。

「暗号化方式のプリファレンス」ダイアログの「了解」をクリックし、「暗号化」タブの「保存」をクリックします。

クライアント認証の許可

Directory Server にクライアント認証を要求し、SSL を使用して Server Console に接続するように設定した場合は、Server Console を使用して Sun Java System サーバーを管理することができなくなります。その代わりに、該当するコマンド行ユーティリティを使用する必要があります。

ただし、Server Console を使用できるようにディレクトリ設定を変更するときは、次の手順を実行して、クライアント認証を要求するのではなく許可するように設定します。

次のコマンドを実行して cn=encryption,cn=config エントリを変更します。

ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn:cn=encryption,cn=config
changetype:modify
replace:nsSSLClientAuth
nsSSLClientAuth:allowed
^D

「コマンド行からのサーバーの起動と停止」で説明している方法で、Directory Server を再起動します。

これで、Server Console を起動できるようになりました。

クライアント認証の設定

クライアント認証は、サーバーがクライアントの識別情報を検証するメカニズムです。クライアント認証は (dn およびパスワードを指定することで)、クライアントが定義する証明書を使用するか、DIGEST-MD5 などの SASL ベースのメカニズムを利用して行われます。Solaris オペレーティングシステムでは、Directory Server は SASL による GSSAPI メカニズムをサポートするようになりました。これにより、Kerberos V5 によるクライアント認証が可能になりました。

証明書ベースの認証では、SSL プロトコルを介して入手したクライアント証明書を使用して、ユーザーエントリの識別情報が検出されます。このメカニズムは EXTERNAL とも呼ばれます。すでに下位部分で確立した認証メカニズムに依存しているからです。外部認証は将来的に IPsec (Internet Protocol Security Protocol) で使用される可能性があります。

証明書ベースの認証の詳細については、『Administration Server Administration Guide』の第 9 章にある「Using Client Authentication」を参照してください。

DIGEST-MD5 を利用した SASL 認証

DIGEST-MD5 メカニズムは、クライアントが送信したハッシュ値とユーザーのパスワードのハッシュ値を比較してクライアントを認証します。ただし、このメカニズムはユーザーパスワードを読み取る必要があり、DIGEST-MD5 による認証を希望するすべてのユーザーは、ディレクトリ内に {CLEAR} パスワード (クリアテキスト形式のパスワード) を持つ必要があります。ディレクトリに{CLEAR} パスワードを格納するときは、パスワード値へのアクセスが ACI によって適切に制限されていることを確認する必要があります。アクセス制御については、第 6 章「アクセス制御の管理」を参照してください。サフィックスに属性の暗号化を設定して {CLEAR} パスワードをさらに保護する方法については、「属性値の暗号化」を参照してください。

DIGEST-MD5 メカニズムの設定

DIGEST-MD5 を使用するように Directory Server を設定するときは、次の手順を実行します。

コンソールまたは ldapsearch コマンドを使用して、ルートエントリの supportedSASLMechanisms 属性の値が DIGEST-MD5 であることを確認します。たとえば、次のコマンドはどの SASL メカニズムが有効であるかを表示します。

ldapsearch -h host -p port -D "cn=Directory Manager" -w password ¥
-s base -b "" "(objectclass=*)" supportedSASLMechanisms

dn:
supportedSASLMechanisms:EXTERNAL
supportedSASLMechanisms:DIGEST-MD5
supportedSASLMechanisms:GSSAPI
^D

DIGEST-MD5 が有効でない場合は、次の ldapmodify コマンドを実行して有効化します。

ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn:cn=SASL, cn=security, cn=config
changetype:modify
add:dsSaslPluginsEnable
dsSaslPluginsEnable:DIGEST-MD5
-
replace:dsSaslPluginsPath
dsSaslPluginsPath: ServerRoot/lib/sasl
^D

DIGEST-MD5 のデフォルトの ID マッピングを使用するか、「DIGEST-MD5 ID マッピング」で説明している方法で新規作成します。

DIGEST-MD5 を使用する SSL 経由でサーバーにアクセスするすべてのユーザーのパスワードが {CLEAR} に含まれていることを確認します。パスワードの保存スキームを設定する方法については、第 7 章「ユーザーアカウントとパスワードの管理」を参照してください。



警告

SASL 設定エントリ、または DIGEST-MD5 ID マッピングエントリの 1 つを変更した場合は、ディレクトリサーバーを再起動します。

DIGEST-MD5 ID マッピング

SASL メカニズムの ID マッピングでは、SASL ID の証明情報と、ディレクトリ内のユーザーエントリの一致が確認されます。このメカニズムの詳細については、「ID マッピング」を参照してください。マッピングによって、SASL ID に対応する DN が見つからなかったときは、認証は失敗します。

SASL ID は、Principal という文字列です。これは、各メカニズムに固有の形式でユーザーを表します。DIGEST-MD5 では、クライアントは、dn:プレフィックスと LDAP DN、または u:プレフィックスの後にクライアントが決定するテキストを続けた情報のいずれかが含まれる主体を作成することをお勧めします。マッピング時に、クライアントが送信した主体は、${Principal} プレースホルダで使用されます。

DIGEST-MD5 のデフォルトの ID マッピングは、サーバー設定の次のエントリで指定されます。

この ID マッピングは、主体の dn フィールドに、ディレクトリ内の既存ユーザーの正確な DN が含まれていることを前提としています。

DIGEST-MD5 用の独自の ID マッピングを定義するには、次の手順を実行します。

cn=DIGEST-MD5,cn=identity mapping,cn=config の下でデフォルトのマッピングエントリを編集するか、新しいマッピングエントリを作成します。ID マッピングエントリの属性の定義については、「ID マッピング」を参照してください。DIGEST-MD5 用のマッピングの例は、次のファイルに保存されています。

ServerRoot/slapd-serverID/ldif/identityMapping_Examples.ldif

この例は、主体の修飾されていないテキストフィールドに、指定の ID のユーザー名が含まれることを前提としています。次のコマンドは、このマッピングを定義する方法を示しています。

ldapmodify -a -h host -p port -D "cn=Directory Manager" -w 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 を再起動します。

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

SASL を介した GSSAPI (Generic Security Services API) では、クライアントの認証に Kerberos V5 などのサードパーティ製セキュリティメカニズムを利用できます。GSSAPI ライブラリは、Solaris プラットフォームだけで利用できます。SEAM (Sun Enterprise Authentication Mechanism) 1.0.1 サーバーに Kerberos V5 実装をインストールすることをお勧めします。

サーバーは、この API を使用してユーザーの識別情報を検証します。次に、SASL メカニズムは GSSAPI マッピングルールを適用して、この接続中のすべての操作のバインド DN となる DN を取得します。

Keberos システムの設定

製造元の指示に従って、Kerberos ソフトウェアを設定します。SEAM 1.0.1 サーバーを利用している場合は、次の手順を実行します。

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

ユーザーとサービスを格納する Kerberos データベースを作成し、その中に LDAP サービスの主体を作成します。LDAP サービスの主体は次のとおりです。

ldap/serverFQDN@REALM

ここで、serverFQDN はサーバーの完全修飾ドメイン名です。

LDAP サービスの鍵を含む、サービス鍵を格納する鍵タブを作成します。

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

各手順の詳細については、ソフトウェアのマニュアルを参照してください。

GSSAPI メカニズムの設定

Solaris プラットフォームで GSSAPI を使用するように Directory Server を設定するときは、次の手順を実行します。

コンソールまたは ldapsearch コマンドを使用して、ルートエントリの supportedSASLMechanisms 属性の値が GSSAPI であることを確認します。たとえば、次のコマンドはどの SASL メカニズムが有効であるかを表示します。

ldapsearch -h host -p port -D "cn=Directory Manager" -w password ¥
-s base -b "" "(objectclass=*)" supportedSASLMechanisms

dn:
supportedSASLMechanisms:EXTERNAL
supportedSASLMechanisms:DIGEST-MD5

デフォルトでは、GSSAPI は無効化されているので、次の ldapmodify コマンドを実行して有効化します。

ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn:cn=SASL, cn=security, cn=config
changetype:modify
add:dsSaslPluginsEnable
dsSaslPluginsEnable:GSSAPI
-
replace:dsSaslPluginsPath
dsSaslPluginsPath: ServerRoot/lib/sasl

「GSSAPI ID マッピング」で説明する方法で、GSSAPI のデフォルトの ID マッピングと、必要に応じてカスタムマッピングを作成します。

ホストマシン上で、サーバーの Kerberos を設定します。

セッション鍵を使用して、LDAP サービス主体 (ldap/serverHostname@Realm) を Kerberos に作成します。serverHostname は、サーバーホストマシンの完全修飾ドメイン名です。

この値は、cn=config の nsslapd-localhost 属性と同じ値である必要があります。ただし、こちらはすべて小文字で指定します。

Realm は、サーバーの Kerberos Realm です。

LDAP サービスは、次のファイルに保存されている鍵データベースに対する読み取りアクセス権をもっている必要があります。/etc/krbs/krb5.keytab.

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

SASL 設定エントリ、または GSSAPI ID マッピングエントリの 1 つを変更したときは、ディレクトリサーバーを再起動します。

GSSAPI ID マッピング

SASL ID は、Principal という文字列です。これは、各メカニズムに固有の形式でユーザーを表します。GSSAPI を利用する Kerberos の主体は、uid[/instance][@realm] という形式の ID です。ここで、uid には、オプションの instance 識別子と、それに続けてオプションの realm (多くの場合はドメイン名) が含まれることがあります。次の例は、いずれも有効なユーザー主体です。

最初は、ディレクトリ内には GSSAPI マッピングは定義されていません。デフォルトのマッピングを定義し、使用する主体をクライアントがどのように定義するかに応じてカスタムマッピングを定義する必要があります。

GSSAPI 用の ID マッピングを定義するには、次の手順を実行します。

cn=GSSAPI,cn=identity mapping, cn=config の下に新しいマッピングエントリを作成します。ID マッピングエントリの属性の定義については、「ID マッピング」を参照してください。

GSSAPI マッピングの例は、次のファイルに保存されています。

ServerRoot/slapd-serverID/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

このファイルに含まれるもう一つの例は、既知の Realm を含む主体にユーザー 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 を再起動します。

ID マッピング

Directory Server のいくつかの認証メカニズムでは、別のプロトコルの証明情報をディレクトリ内の DN にマッピングする必要があります。現時点では、DSML-over-HTTP プロトコルと、DIGEST-MD5 メカニズムおよび GSSAPI SASL メカニズムの場合がこれにあたります。いずれの場合も ID マッピングを使用して、クライアントが提示するプロトコル固有の証明情報に基づいてバインド ID を決定しています。

ID マッピングには、cn=identity mapping, cn=config 設定ブランチに含まれるエントリが利用されます。この分岐には、ID マッピングを必要とするプロトコルごとにコンテナが含まれます。

cn=HTTP-BASIC, cn=identity mapping, cn=config : DSML-over-HTTP 接続用のマッピングを含む

cn=DIGEST-MD5, cn=identity mapping, cn=config : DIGEST-MD5 SASL メカニズムによるクライアント認証に必要なマッピングを含む

cn=GSSAPI, cn=identity mapping, cn=config : GSSAPI SASL メカニズムによるクライアント認証に必要なマッピングを含む

マッピングエントリは、ディレクトリの検索に利用できるように、プロトコルに固有の証明情報の要素を展開する方法を定義します。検索が 1 つのユーザーエントリを返す場合、マッピングは成功し、接続ではすべての操作のバインド DN としてこのエントリが使われます。検索結果がゼロ、または複数のエントリである場合、マッピングは失敗し、他のマッピングが適用されます。

各分岐には、そのプロトコルのデフォルトのマッピングと、任意の数のカスタムマッピングが含まれます。デフォルトのマッピングには cn=default という RDN が含まれ、カスタムマッピングには cn をネーミング属性として使用した別の RDN が含まれることがあります。最初に、いずれかのマッピングが成功するまで、すべてのカスタムマッピングが順不同に評価されます。すべてのカスタムマッピングが失敗した場合は、最後にデフォルトのマッピングが適用されます。デフォルトマッピングも失敗した場合は、そのクライアントの認証は失敗します。

マッピングエントリには、top、Container、dsIdentityMapping オブジェクトクラスが含まれている必要があります。エントリには、次の属性を含めることができます。

dsMappedDN: DN : ディレクトリ内の DN を定義するリテラル文字列。マッピングの実行時にこの DN が存在する場合、この DN はバインドに使われます。この DN が存在しない場合に検索を実行するために、次の属性を定義することもできます。

dsSearchBaseDN: DN : 検索のベース DN。この属性を省略すると、マッピングではディレクトリツリー全体ですべてのルートサフィックスが検索されます。

dsSearchScope:base|one|sub : 検索の適用範囲。検索ベース、ベースの 1 つ下のレベル、またはベースの下にあるサブツリー全体を指定できます。この属性を省略すると、マッピング検索の適用範囲は、デフォルトでサブツリー全体となります。

dsSearchFilter: filterString : マッピング検索を実行するためのフィルタ文字列。LDAP 検索フィルタは、RFC 2254 (http://www.ietf.org/rfc/rfc2254.txt) に定義されています。

また、マッピングエントリには dsPatternMatching オブジェクトクラスを含めることができます。このオブジェクトクラスでは、次の属性を利用できます。

dsMatching-pattern:patternString : パターンマッチングを実行する文字列を指定します。

dsMatching-regexp:regularExpression : パターン文字列に適用する正規表現を指定します。

dsSearchScope を除いて、これらのすべての属性値は、${keyword} という形式のプレースホルダを持つことができます。keyword は、プロトコル固有の証明情報に含まれる要素名です。プレースホルダは、マッピング時にクライアントから提供される要素の実際の値に置き換えられます。

すべてのプレースホルダの置換が完了すると、定義されているパターンマッチングが行われます。一致するパターンは、正規表現と比較されます。正規表現がパターン文字列と一致しない場合、そのマッピングは失敗です。一致する場合、正規表現中でカッコで囲まれている値は、番号つきのプレースホルダとして他の属性値で利用できます。たとえば、SASL 用に次のマッピングを定義できます。

bjensen@example.com という主体でクライアント認証を行う場合、このマッピングは uid=bjensen,ou=people,dc=example,dc=com というバインド DN を定義します。この DN がディレクトリに存在すれば、マッピングは成功し、クライアントは認証されます。また、この接続で実行されるすべての操作には、このバインド DN が使われます。

dsMatching-pattern は、Posix regexec(3C) および regcomp(3C) 関数呼び出しを使用して、dsMatching-regexp と比較されます。Directory Server では拡張正規表現が使用され、すべての比較で大文字と小文字が区別されません。詳細については、これらの関数の man ページを参照してください。

これらのプレースホルダを使う可能性のある属性値では、プレースホルダを使わない場合でも、プレースホルダ部分以外の $、{、} の各文字を符号化する必要があります。$ は ¥24、{ は ¥7B、} は ¥7D という値にそれぞれ符号化します。

プレースホルダにより値の置き換えを利用することで、プロトコル固有の証明情報からユーザー名などの値を抽出し、その値を使用してマップ先の DN を定義したり、ディレクトリ内の任意の場所にある対応する DN を検索するようなマッピングを作成できます。ディレクトリクライアントが提供する証明情報に含まれていることが予想される値を抽出し、特定のディレクトリ構造にそれをマップするマッピングを作成する必要があります。


警告	マッピングの定義が不十分だと、セキュリティホールが生じます。たとえば、パターンマッチングを利用しないハードコードされた DN へのマッピングは常に成功します。このため、ディレクトリユーザー以外のクライアントを認証してしまいます。形式の異なるクライアント証明情報に対応するには、汎用的に、より許容傾向のある 1 つのマッピングを作成するよりも、複数のマッピングを定義するほうが安全です。クライアントの証明情報に基づいて、クライアント接続を特定のユーザーにマップするように心がける必要があります。

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

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

次の各項では、SSL が有効な LDAP クライアントの例として、ldapsearch ツールを使用します。ディレクトリサーバーが提供する ldapmodify、ldapdelete、および ldapcompare ツールは、同じ方法で設定できます。これらのディレクトリアクセスツールは、Directory SDK for C に基づいています。詳細については、『Directory Server Resource Kit Tools Reference』を参照してください。

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

クライアントでのサーバー認証の設定

クライアントがサーバーとの SSL 接続を確立するときは、サーバーが定義する証明書を信頼する必要があります。このとき、クライアントは次の処理を行う必要があります。


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

証明書データベースを用意する

サーバー証明書を発行する CA を信頼する

LDAP クライアントの SSL オプションを指定する

Mozilla は、Web サーバーとの通信に HTTP プロトコルを介して SSL を使用するクライアントアプリケーションです。Mozilla を使用して、LDAP クライアントが使用する証明書を管理することもできます。また、certutil ツールを使用して、証明書データベースを管理することもできます。

Mozilla によるクライアント証明書の管理

次に、Mozilla を使用してクライアントマシン上の証明書データベースを管理する方法について説明します。

Mozilla は、起動時に証明書データベースが存在することを確認し、存在しない場合は証明書データベースを作成します。証明書データベースは、他の Mozilla の設定などと同様にファイルに保存されます。
例：
.mozilla/username/string.slt/cert8.db

この手順を利用する場合、Mozilla が作成する証明書データベースを特定し、クライアントアプリケーションが利用できるように、そのパスを記録しておきます。

Mozilla を使用して、アクセスするディレクトリサーバーの証明書を発行した CA の Web サイトを表示します。Mozilla は、自動的に CA の証明書を取得し、それを信頼するかどうかを確認するメッセージを表示します。

たとえば、内部に導入された Sun Java System Certificate Server を使用している場合は、https://hostname:444 という URL にアクセスします。

Mozilla が CA の証明書を信頼するかどうかを確認するメッセージを表示したら、それを信頼します。サーバー認証のためには、CA の証明書を信頼する必要があります。

CA の Web サイトによっては、この手順を実行することはできません。Mozilla が CA 証明書の信頼を確認するメッセージを表示しない場合は、次の手順を実行して手動で処理します。

コマンド行からのクライアント証明書の管理

コマンド行から証明書を管理するときは、certutil ツールを使います。このツールは SUNWtlsu パッケージ内に提供されています。

クライアントのホストマシンで、次のコマンドを実行して証明書データベースを作成します。

certutil -N -d path -P prefix

証明書の保護のためにパスワードを入力するように求めるメッセージが表示されます。次に、ツールは path/prefixcert8.db ファイル、および path/prefixkey3.db ファイルを作成します。

証明書データベースは、LDAP クライアントアプリケーションのユーザーごとに、そのユーザーだけがアクセスできる場所に個別に作成する必要があります。たとえば、ユーザーのホームディレクトリ内の保護されたサブディレクトリに作成します。

アクセスする Directory Server の証明書を発行した CA に連絡し、CA 証明書を要求します。電子メールを送信するか、Web サイトにアクセスして PEM 方式で暗号化されたテキスト形式の PKCS #11 証明書を取得します。この証明書をファイルとして保存します。

たとえば、内部に導入された Sun Java System Certificate Server を使用している場合は、https://hostname:444 という URL にアクセスします。最上位の「Retrieval」タブで、「Import CA Certificate Chain」を選択して、符号化された証明書をコピーします。

クライアント証明書とサーバー証明書の両方を同じ CA から取得した場合は、「CA の信頼設定」で説明した手順で取得した CA 証明書を再利用することもできます。

SSL 接続に使用するサーバー証明書を発行する信頼できる CA として、CA 証明書をインポートします。次のコマンドを実行します。

certutil -A -n "certificateName" -t "C,," -a -i certFile -d path -P prefix

ここで、certificateName はこの証明書を識別するために指定する値です。certFile は、CA の PEM 方式で符号化されたテキスト形式の PKCS #11 証明書を含むテキストファイル、path と prefix は、手順 1 と同様です。

LDAP クライアントアプリケーションのすべてのユーザーは、各自の証明書データベースに CA 証明書をインポートする必要があります。すべてのユーザーが、certFile に保存されている同じ証明書をインポートできます。

サーバー認証の SSL オプションの設定

ldapsearch ツールを使用して SSL を利用したサーバー認証を行う場合、ユーザーは各自の証明書データベースのパスを指定するだけで設定が完了します。セキュリティ保護されたポートを通じて SSL 接続を確立するときに、サーバーは証明書を送信します。ldapsearch ツールは、ユーザーの証明書データベースを検索し、サーバー証明書を発行した CA の信頼されている CA 証明書を検出します。

次のコマンドは、ユーザーが、Mozilla によって作成された各自の証明書データベースを指定する方法を示しています。

クライアントでの証明書ベースの認証の設定

クライアント認証のデフォルトのメカニズムでは、ディレクトリサーバーにアクセスするユーザーを、証明書を使用して安全に識別しています。証明書ベースのクライアント認証を行うには、次の処理を行う必要があります。

すべてのディレクトリユーザーの証明書を取得し、クライアントアプリケーションがアクセスする場所にインストールします。

同じ証明書のバイナリコピーを使用して、ユーザーのディレクトリエントリを設定します。認証時に、サーバーはクライアントアプリケーションが提示する証明書と、このコピーを比較してユーザーを識別します。

サーバーに証明書ベースの認証を設定します。詳細については、『Administration Server Administration Guide』の第 9 章にある「Using Client Authentication」を参照してください。

証明書ベースの認証用に、LDAP クライアントの SSL オプションを指定します。

これらの手順を実行するには、コマンド行から証明書を管理するための certutil ツールを使います。このツールは SUNWtlsu パッケージ内に提供されています。

ユーザー証明書の取得とインストール

証明書ベースの認証を使用してディレクトリにアクセスするユーザーごとに、クライアント証明書を要求し、それをインストールする必要があります。この手順は、「クライアントでのサーバー認証の設定」で説明した方法で、ユーザーがすでに証明書データベースを設定していることを前提としています。

次のコマンドを実行して、ユーザー証明書の要求を作成します。

certutil -R ¥
-s "cn=Babs Jensen,ou=Sales,o=example.com,l=city,st=state,c=country"¥
-a -d path -P prefix

-s オプションは、要求する証明書の DN を指定します。通常、CA は証明書の所有者を完全に識別するために、この例に含まれるすべての属性を必要とします。手順 9 の証明書マッピングメカニズムによって、証明書の DN はユーザーのディレクトリ DN にマッピングされます。

path と prefix は、ユーザーの証明書データベースと鍵データベースの場所を特定します。certutil ツールは、鍵データベースを保護しているパスワードを要求します。これにより、PEM で符号化されたテキスト形式の PKCS #10 証明書要求が生成されます。

符号化された要求をファイルとして保存し、所定の方法でそれを CA に送信します。証明書要求は、電子メールとしての送信が求められることもありますが、CA の Web サイトに入力できる場合もあります。

CA が応答を送信したら、新しい証明書の PEM で符号化されたテキストをダウンロードするか、テキストファイルにコピーします。

次のコマンドを実行して、証明書データベースに新しいユーザー証明書をインストールします。

certutil -A -n "certificateName" -t "u,," -a -i certFile -d path -P prefix

ここで、certificateName はこの証明書を識別するために指定する値です。certFile は、PEM 形式の PKCS #11 証明書を含むテキストファイル、path と prefix は、手順 1 と同様です。

Mozilla を使用して証明書データベースを管理している場合は、証明書を直接インストールできるように、CA の Web サイトのリンクが含まれていることがあります。このリンクをクリックして、Mozilla によって表示されるダイアログボックスの指示に従って処理を行います。

次のコマンドを実行して、証明書のバイナリコピーを作成します。

certutil -L -n "certificateName" -d path -r > userCert.bin

ここで、certificateName はインストール時に指定した証明書の名前です。path は証明書データベースの場所、userCert.bin はバイナリ形式の証明書の出力先となるファイルの名前です。

Directory Server で、クライアント証明書を所有するユーザーのディレクトリエントリに userCertificate 属性を追加します。

コンソールから証明書を追加するには、次の手順を実行します。

Directory Server コンソールの最上位にある「ディレクトリ」タブで、ディレクトリツリーを表示してユーザーエントリを探し、そのエントリをマウスの右ボタンでクリックして、ポップアップメニューから「汎用エディタで編集」を選択します。

汎用エディタで「属性の追加」をクリックします。

ポップアップダイアログから userCertificate 属性を選択し、「サブタイプ」ドロップダウンリストから binary を選択します。ここでは binary サブタイプを指定する必要があります。それ以外を指定すると証明書のマッピングが失敗します。

汎用エディタで新しい userCertificate フィールドを探します。対応する「値の設定」ボタンをクリックして、この属性のバイナリ値を設定します。

「値の設定」ダイアログで、手順 6 で作成した userCert.bin ファイルの名前を入力するか、「参照」をクリックしてファイルを選択します。

「値の設定」ダイアログの「了解」をクリックし、汎用エディタの「保存」をクリックします。

コマンド行から証明書を追加するには、次の例のように、ldapmodify コマンドを実行します。このコマンドは、SSL を利用してセキュリティ保護された接続を通じて証明書を送信します。

ldapmodify -h host -p securePort ¥
-D "uid=bjensen,dc=example,dc=com" -w bindPassword ¥
-Z -P .mozilla/bjensen/string.slt/cert8.db
version: 1
dn:uid=bjensen,dc=example,dc=com
changetype:modify
add:userCertificate
userCertificate;binary: < file:///path/userCert.bin

ここでは binary サブタイプを指定する必要があります。それ以外を指定すると証明書のマッピングが失敗します。< の前後の空白文字は重要です。ここに示されるとおりに指定する必要があります。ファイル名の指定に < 構文を利用するには、LDIF 文を version: という行から開始する必要があります。1ldapmodify がこの文を処理するときに、このツールは、指定ファイルの内容全体から読み取った値を属性に設定します。

Directory Server で、必要に応じてユーザー証明書を発行した CA の証明書をインストールし、それを信頼します。この CA は、クライアントからの接続の許可について信頼されている必要があります。詳細は、「CA の信頼設定」を参照してください。

Directory Server に証明書ベースの認証を設定します。詳細については、『Administration Server Administration Guide』の第 9 章にある「Using Client Authentication」を参照してください。この処理では、LDAP クライアントから提示されるユーザー証明書をサーバーが対応するユーザー DN にマッピングできるように、certmap.conf ファイルを編集します。

certmap.conf ファイルで、verifyCert パラメータに on が設定されていることを確認します。サーバーは、ユーザーエントリに同じ証明書が含まれることを確認し、ユーザーを識別します。

証明書ベースのクライアント認証の SSL オプションの設定

ldapsearch ツールを使用して SSL による証明書ベースのクライアント認証を行うには、証明書が利用するいくつかのコマンド行オプションを指定する必要があります。セキュリティ保護されたポートを通じて SSL 接続を確立する場合、このツールはサーバーの証明書を認証し、それからユーザー証明書をサーバーに送信します。

次のコマンドは、ユーザーが、Mozilla によって作成された各自の証明書データベースへのアクセスに適用されるオプションを指定する方法を示しています。

-Z オプションは証明書ベースの認証を示します。certificateName は送信する証明書を指定します。-K オプションと -W オプションは、クライアントアプリケーションが送信のために証明書にアクセスすることを許可します。-D オプションと -w オプションを指定しない場合、バインド DN は証明書マッピングに基づいて決定されます。

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

クライアントで DIGEST-MD5 メカニズムを使用するときは、ユーザー証明書をインストールする必要はありません。ただし、暗号化された SSL 通信を利用するには、「クライアントでのサーバー認証の設定」で説明した方法で、サーバー証明書を信頼する必要があります。

レルムの指定

レルムは、認証 ID が選択されるネームスペースを定義します。DIGEST-MD5 認証では、特定のレルムに対して認証を行う必要があります。

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

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

環境変数の指定

UNIX 環境では、LDAP ツールが DIGEST-MD5 ライブラリを見つけることができるように、SASL_PATH 環境変数を設定する必要があります。DIGEST-MD5 ライブラリは、SASL プラグインによってダイナミックにロードされる共有ライブラリであるため、SASL_PATH 変数を次のように設定する必要があります (Korn シェルでの例)

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

ldapsearch コマンドの例

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

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

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

通常は、SSL 接続を利用することで、セキュリティ保護されたポートを通じて暗号化された情報をやり取りし、DIGEST-MD5 がクライアント認証を行うことが求められます。次の例は、同じ処理を SSL 経由で実行します。

この例では、ldapsearch コマンドに -N オプションと -W オプションを指定する必要がありますが、これはクライアント認証には使われません。その代わりに、サーバーは authid の値に含まれる主体の DIGEST-MD5 ID マッピングを行います。

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

クライアントで GSSAPI メカニズムを使用するときは、ユーザー証明書をインストールする必要はありません。ただし、Kerberos V5 セキュリティシステムを設定する必要があります。また、暗号化された SSL 通信を利用するには、「クライアントでのサーバー認証の設定」で説明した方法で、サーバー証明書を信頼する必要があります。

クライアントホストでの Kerberos V5 の設定

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

インストール手順に従って Kerberos V5 をインストールします。SEAM (Sun Enterprise Authentication Mechanism) 1.0.1 クライアントソフトウェアをインストールすることをお勧めします。

Kerberos ソフトウェアを設定します。SEAM では、/etc/krb5 の下にあるファイルを設定して kdc サーバーを設定し、デフォルトレルムを定義して、Kerberos システムに必要なその他の設定を行います。

最初の値が kerberos_v5 となるように、必要に応じて /etc/gss/mech ファイルを編集します。

Kerberos 認証の SASL オプションの設定

GSSAPI が有効なクライアントアプリケーションを使用する前に次のコマンドを実行し、Kerberos セキュリティシステムをユーザー主体で初期化する必要があります。

kinit userPrincipal

userPrincipal は、たとえば bjensen@example.com のような SASL ID です。

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

ldapsearch -h host -p securePort ¥
           -Z -P .mozilla/bjensen/string.slt/cert8.db ¥
           -N "certificateName" -W keyPassword ¥
           -o mech=GSSAPI [-o realm="example.com" ¥
           -o authid="bjensen@example.com" ¥
           -o authzid="bjensen@example.com"] ¥
           -b "dc=example,dc=com" "(givenname=Richard)"

この例では、ldapsearch コマンドに -N オプションと -W オプションを指定する必要がありますが、これはクライアント認証には使われません。realm、authid、および authzid は、kinit コマンドによって初期化された Kerberos キャッシュに含まれるので、省略することができます。指定する場合は、authzid はプロキシ操作が利用されないことを示しますが、authid と authzid には、どちらにも同じ値を指定する必要があります。authid の値は、ID マッピングで使用される主体です。詳細は、「GSSAPI ID マッピング」を参照してください。

前へ目次索引次へ
Sun Java™ System Directory Server 5 2004Q2 管理ガイド