このセクションでは、次の情報について説明します。
SSL(Secure Socket Layer) 3.1はNetscapeでリリースされました。IETFはTLS(Transport Layer Security) 1.0を実装することにより、SSL標準の所有権を持っています。
TLSを使用すると、接続をセッション層で暗号化することができます。TLS接続のために、暗号化されたポートを使用する必要はありません。また、次の方法もあります。ポート636は暗黙的なTLSポートであり、クライアントがセキュアポートに接続すると、LDAPサーバは自動的にTLS接続を開始することができます。
クライアントは、まずクリアテキストポートに接続し、後でTLSを使用して暗号化された接続にアップグレードすることもできます。
パスワードとの単純バインドにTLSを要求するには、次を実行します。
LDAP拡張オペレーションSTARTTLSにより、クリア接続から暗号化された接続にアップグレードすることができます。このアップグレードは、eDirectory8.7の新機能です。
暗号化された接続を使用すると、パケット全体が暗号化されます。このため、ネットワーク経由で送信されたデータが第三者によって診断されることはありません。
シナリオ:STARTTLSを使用する---ポート389にクリア接続し、匿名検索を行います。ただし、セキュリティ保護されたデータを扱う場合にはTLSセッションに切り換えます。拡張オペレーションSTARTTLSを実行し、クリア接続から暗号化された接続にアップグレードします。これでデータの安全が確保されます。
暗号化されたセッションをクリア接続に切り替えるには、TLSを停止します。クリア接続では、クライアントが送受信するデータは暗号化および解読されないので、負荷は少なくなります。そのため、クリア接続の使用時の方が、データの通信速度が速くなります。この時点で、接続は匿名にダウングレードされています。
認証を受けるにはLDAPバインド操作を使用します。バインドは、ユーザの認証情報に基づいてIDを作成します。TLSを停止するときに、LDAPサービスは以前に確立された認証をすべて削除します。認証ステータスが匿名に変わります。匿名以外の状態に切り替える場合は、再認証を受ける必要があります。
シナリオ:再認証を受ける---あるユーザがSTOPTLSを実行します。すると、そのユーザの状態が匿名に変わります。このユーザのファイルにネット上でアクセスするには、Bindコマンドを実行し、ログイン認証情報を入力します。ユーザが認証され、インターネット上でクリアテキストで作業を続行できます。
TLSセッションがインスタンス化されると、ハンドシェークが行われます。サーバとクライアントがデータを交換します。ハンドシェークの方法はサーバが決定します。サーバの正当性を証明するため、サーバは常にサーバの証明書をクライアントに送信します。このハンドシェークにより、そのサーバがクライアントに指定されたサーバであることが証明されます。
クライアントにも正当性の証明を要求するには、サーバに値を設定します。これはldapTLSVerifyClientCertificateという属性です。
サーバがTLSをサポートするよりも前に、サーバの正当性の証明に使用されるX.509証明書をサーバに提供する必要があります。
この証明書は、eDirectoryのインストール時に自動的に提供されます。インストール時に、パブリックキー暗号化サービス(PKI)で、キーオブジェクトとNovell Modular Authentication Services(NMASTM)が作成されます。次の図は、iManagerにおけるこれらのオブジェクトを示しています。
インストール中、これらの証明書の1つがLDAPサーバと自動的に関連付けられます。Novell iManagerのLDAPサーバオブジェクトの[接続]タブにDNが表示されます。このDNは、X.509の証明書を表しています。次の図のサーバ証明書フィールドは、このDNを示しています。
Novell iManagerで、暗号化キーオブジェクト(KMO)証明書を参照できます。また、ドロップダウンリストから、別の証明書に変更することもできます。DNSまたはIP証明書のいずれかを使用します。
検証の際には、サーバは証明書にある名前(ハードIPアドレスまたはDN)を確認します。
TLS接続を確立するには、次の条件を確認します。
LDAPサーバを再設定し、サーバをリフレッシュします。「LDAPサーバをリフレッシュする」を参照してください。ConsoleOneとNovell iManagerは、自動的にサーバをリフレッシュします。
LDAPクライアントとは、たとえばNetscape Communicator、Internet Explorer、ICEのようなアプリケーションです。クライアントは、LDAPサーバが使用する認証局を認知している必要があります。
サーバがeDirectoryツリーに追加されると、インストールの際にデフォルトで次が作成されます。
LDAPサーバはこの認証プロバイダを使用します。
クライアントは、LDAPサーバが使用していると主張するツリーCAを確認できるよう、信頼する証明書をインポートする必要があります。この証明書をサーバからインポートしておくと、サーバがその証明書を送信してきたときに、クライアントはそれを確認し正当なサーバであるかどうか確かめることができます。
クライアントが安全に接続できるよう、接続前にクライアントの環境設定をしておく必要があります。
クライアントによる証明書のインポート方法は、使用しているアプリケーションの種類によって異なります。各アプリケーションには、何らかの証明書をインポートする方法があります。Netscapeブラウザ、IE、ICEは、それぞれ別々の方法でインポートを行います。これらのインポート手段は、3つの異なるLDAPクライアントです。各クライアントは、それぞれの方法で信頼する証明書を探します。
ルート認証局は、証明書サーバを受け入れるときに自動的にエクスポートできます。
ルート認証局を手動でエクスポートするには、Exporting a Trusted Root or Public Key Certificateを参照してください。
エクスポート機能により、指定したファイルが作成されます。ファイル名は変更できますが、オブジェクトのタイプを認識できるよう、ファイル名に「DNS」または「IP」を残しておくことをお勧めします。また、サーバ名も残しておきます。
eDirectoryとの安全なLDAP接続を確立するブラウザに、自己割り当て認証局をインストールします。
InternetExplorerなど、Microsoft社の製品で証明書を使用する場合は、.der拡張子を残しておくようにします。
アプリケーションまたはSDKが証明書を要求する場合は、証明書をデータベースにインポートします。
Internet Explorer 5の場合は、ルート証明書が自動的にエクスポートされ、レジストリが更新されます。これには、Microsoftが通常使用している.x509拡張子が必要です。
相互認証には、TLSセッションとクライアント証明書が必要です。サーバとクライアントの両方が、それぞれが自分の主張するオブジェクトであることを証明する必要があります。クライアントの証明書がトランスポート層で確認されます。しかし、LDAPプロトコル層では、LDAPバインド要求を出すまでクライアントは匿名になります。
この時点で、クライアントはその正当性をサーバに証明しましたが、LDAPにはまだ証明されていません。クライアント証明書に含まれたIDで認証を受けたい場合は、クライアントはSASL EXTERNALメカニズムを使ってバインドされます。
eDirectoryのインストール時に、LDAPサーバにツリー認証局(CA)が提供されます。LDAPキーオブジェクトは、そのCAに基づいています。クライアントがLDAPサーバに送信する証明書は、このツリーCAから確認できます。
LDAP Services for eDirectory 8.8は、複数の認証局をサポートしています。NovellのツリーCAはそのうちの1つです。LDAPサーバが、他のCAを持っている場合があります(例:外部団体のVeriSign*など)この追加CAもルート認証局です。
LDAPサーバが複数の認証局を使用するように環境設定するには、LDAPサーバオブジェクトのldapTLSTrustedRootContainer属性を設定します。LDAPサーバが複数の認証局を参照することにより、クライアントは外部の認証局を使用できます。
Novell eDirectoryは、認証されていないユーザに[Public]識別子を割り当てます。LDAPプロトコルでは、認証されていないユーザは匿名ユーザになります。デフォルトでは、LDAPサーバは匿名ユーザに[Public]識別子の権利を与えます。この権利により、非承認のeDirectoryおよび匿名LDAPユーザは、[Public]権を使用してeDirectoryを参照することができます。
また、LDAPサーバは匿名ユーザによる別のプロキシユーザの権利の使用を許可します。この値はLDAPグループオブジェクトにあります。Novell iManagerでは、この値は、[プロキシユーザ]フィールドで指定します。またConsoleOneの場合は、[プロキシユーザ名]フィールドで指定します。次の図は、Novell iManagerの[プロキシユーザ]フィールドを示しています。
プロキシユーザは識別名です。このプロキシIDに、Public識別子とは別の権利を与えることができます。プロキシユーザを使用すると、eDirectoryツリー内の特定コンテナへのLDAP匿名アクセスを制御できます。
注: プロキシユーザのログイン制限は、すべての匿名LDAPユーザに適用する場合以外は設定しないでください。
シナリオ:NLDAPプロキシユーザを設定する---Digital Airlines社はリサーチ会社のDataSure社と契約を締結しています。DataSure社はLDAPを使用して、Digital Airlines社のNetWare 6サーバであるDigitalAir43にアクセスし、そのリサーチを保存します。Digital Airlines社は、DataSure社にDigitalAir43のディレクトリに対する[Public]権を与えたくないとします。
そのために、LDAPプロキシユーザを作成し、そのユーザにDataSureディレクトリに対する特定の権利を割り当てます。LDAPグループオブジェクトにプロキシ識別名を作成し、サーバをリフレッシュします。サーバは自動的に、すべての新規または既存の匿名ユーザについて、プロキシユーザの権利の使用を開始します。
SASL (Simple Authentication and Security Layer)は、IANA (Internet Assigned Numbers Authority)で登録する必要のあるさまざまな認証メカニズムを定義します。LDAPサーバでは次のメカニズムがサポートされます。
これらのメカニズムは、eDirectoryのインストールまたはアップグレード時に、サーバにインストールされます。ただし、LinuxおよびUNIXの場合はnmasinstユーティリティを実行してNMASメソッドをインストールする必要があります。
LDAPサーバは、SASLに問い合わせて環境設定時にインストールしたメカニズムを検索し、インストールされたメカニズムを自動でサポートします。また、supportedSASLMechanisms属性を使ってrootDSEで現在サポートされているSASLメカニズムをレポートします。
これらのメカニズムは登録されているため、名前はすべて大文字で入力します。大文字で入力しない場合、LDAPサーバはメカニズムを認識しません。
LDAPバインドプロトコルでは、クライアントは認証に様々なSASLメカニズムを使用することができます。アプリケーションがLDAPバインドAPIを使用している場合は、単純バインドを選択し、DNとパスワードを入力するか、SASLバインドを選択し、SASLメカニズム名(大文字)と、そのメカニズムが要求する、関連するSASL認証情報を提供する必要があります。
DIGEST-MD5メカニズムにはTLSは必要ありません。LDAPサーバは、クリア接続およびセキュア接続の両方でDIGEST-MD5をサポートします。
LDAPは、バインド要求でSASLメカニズムをサポートします。ユーザがLDAP単純バインド(DNおよびクリアテキストパスワード)の代わりに、LDAP SASLバインドを要求すると、DNとMD5認証情報が提供されます。
MD5は、暗号化されたパスワードのハッシュを提供します。パスワードは、クリア接続でも暗号化されます。そのためLDAPサーバは、ポートがクリアテキストポートか暗号化されたポートかに関係なく、MD5を使ったパスワードを受け入れます。
このパスワードが第三者によって見破られることはありません。ただし、接続全体に対してなりすましやハイジャックがなされる可能性はあります。
メカニズムはLDAP SASLバインドです(単純バインドではありません)。そのため、インストール時に[パスワードとの単純バインドにTLSを必要とする]チェックボックスがオンになっていても、LDAPサーバはこの要求を受け入れます。
EXTERNALメカニズムにより、ユーザのDNおよび認証情報がサーバに提供されたことがLDAPサーバに通知されます。そのため、バインド要求時にはDNと認証情報は必要ありません。
SASL EXTERNALメカニズムを使用したLDAPバインド要求は、サーバに次を実行するよう要求します。
安全なハンドシェークが行われます。サーバはクライアントから認証情報を要求し、クライアントはそれをサーバに渡します。LDAPサーバはクライアントから渡された証明書を受け取り、それをNMASモジュールに渡して、ユーザを証明書にあるDNとして認証します。
使用できるDNの証明書を使用するには、クライアントを設定する必要があります。証明書の設定に関する詳細は、NMAS オンラインマニュアルを参照してください。
クライアントがEXTERNALメカニズムを送信しても、LDAPサーバは要求の処理に失敗することがあります。Novell iMonitorにより、処理が失敗した原因が通知されます。次のような原因が考えられます。
NMAS_LOGINメカニズムにより、LDAPサーバにNMASのバイオメトリック機能が提供されます。詳細については、Novell NDKを参照してください。
サーバの起動時に、LDAPサーバはSASLモジュールを初期化し、そのLDAPサーバがどのメカニズムを使用できるかをSASLモジュールに問い合わせます。
クライアントはrootDSEに問い合わせて、サポートされているメカニズム属性を検索することできます。LDAPサーバはその後、サポートされているメカニズムを表示します。
GSSAPIメカニズムにより、チケットを使用してKerberosユーザのeDirectoryサーバへの認証を行うことができます。その際に、個別のLDAPユーザパスワードの入力は不要です。
この機能は、Kerberosインフラストラクチャがすでに配置された環境があるLDAPアプリケーションユーザ向けのものです。このようなユーザは、個別のLDAPユーザパスワードを入力することなく、Kerberosサーバで発行されたチケットを使用してLDAPサーバへの認証を行うことができます。
GSSAPIの設定については、eDirectoryでのGSSAPIの設定を参照してください。