14.7 認証とセキュリティ

SSL(Secure Socket Layer) 3.1はNetscapeでリリースされました。IETFは、TLS (Transport Layer Security) 1.0を実装することで、その標準の所有権を持ちます。TLS 1.0はSSLv2およびv3と後方互換性があります。

TLSを使用すると、接続をセッション層で暗号化することができます。TLS接続のために、暗号化されたポートを使用する必要はありません。方法はもう1つあります。ポート636は暗黙的なTLSポートであり、クライアントがセキュアポートに接続すると、LDAPサーバは自動的にTLSセッションを開始します。

クライアントは、まずクリアテキストポートに接続し、後でTLSを使用して暗号化された接続にアップグレードすることもできます。

パスワードとの単純バインドにTLSを要求するには、次を実行します。

LDAP拡張オペレーションSTARTTLSにより、クリア接続から暗号化された接続にアップグレードすることができます。このアップグレードは、eDirectory8.7の新機能です。

暗号化された接続を使用すると、パケット全体が暗号化されます。このため、ネットワーク経由で送信されたデータが第三者によって診断されることはありません。

暗号化されたセッションをクリア接続に切り替えるには、TLSを停止します。クリア接続では、クライアントが送受信するデータは暗号化および解読されないので、負荷は少なくなります。そのため、クリア接続の使用時の方が、データの通信速度が速くなります。この時点で、接続は匿名にダウングレードされています。

認証を受けるにはLDAPバインド操作を使用します。バインドは、ユーザの資格情報に基づいてIDを確立します。TLSを停止するときに、LDAPサービスは以前に確立された認証をすべて削除します。認証ステータスが匿名に変わります。匿名以外の状態に切り替える場合は、再認証を受ける必要があります。

TLSセッションがインスタンス化されると、ハンドシェークが行われます。サーバとクライアントがデータを交換します。ハンドシェークの方法はサーバが決定します。サーバの正当性を証明するため、サーバは常にサーバの証明書をクライアントに送信します。このハンドシェークにより、そのサーバがクライアントに指定されたサーバであることが証明されます。

クライアントにも正当性の証明を要求するには、サーバに値を設定します。これはldapTLSVerifyClientCertificateという属性です。

サーバがTLSをサポートするよりも前に、サーバにその正当性の証明に使用するX.509証明書を提供する必要があります。

この証明書は、eDirectoryのインストール時に自動的に提供されます。インストール時に、PKI (公開鍵インフラストラクチャ)とNMAS (NetIQモジュラー認証サービス)の一部として、キーマテリアルオブジェクトが作成されます。次の図は、iManagerにおけるこれらのオブジェクトを示しています。

インストール中、これらの証明書の1つがLDAPサーバと自動的に関連付けられます。NetIQ iManagerのLDAPサーバオブジェクトの［接続］タブにDNが表示されます。このDNは、X.509認定を表しています。次の図のサーバ証明書フィールドは、このDNを示しています。

NetIQ iManagerで、暗号化キーオブジェクト(KMO)証明書をブラウズできます。また、ドロップダウンリストから、別の証明書に変更することもできます。DNSまたはIP証明書のいずれかを使用します。

検証の際には、サーバは証明書にある名前(ハードIPアドレスまたはDN)を確認します。

TLS接続を確立するには、次の条件を確認します。

LDAPサーバを再設定し、サーバをリフレッシュします。LDAPサーバをリフレッシュするを参照してください。iManagerはサーバを自動的に更新します。

LDAPクライアントとは、たとえば、Internet Explorer、ICEのようなアプリケーションのことです。クライアントは、LDAPサーバが使用する認証局を認知している必要があります。

eDirectoryツリーが構成されている場合、デフォルトでは構成によって次のものが作成されます。

LDAPサーバはこの認証プロバイダを使用します。

クライアントは、LDAPサーバが使用していると主張するツリー認証局を確認できるよう、信頼する証明書をインポートする必要があります。この証明書をサーバからインポートしておくと、サーバがその証明書を送信してきたときに、クライアントはそれを確認し正当なサーバであるかどうか確かめることができます。

クライアントが安全に接続できるよう、接続前にクライアントの環境設定をしておく必要があります。

クライアントによる証明書のインポート方法は、使用しているアプリケーションの種類によって異なります。各アプリケーションには、何らかの証明書をインポートする方法があります。IEとICEでは、方法が異なります。これらは異なるLDAPクライアントです。各クライアントは、それぞれの方法で信頼する証明書を探します。

ルート認証局は、証明書サーバを受け入れるときに自動的にエクスポートできます。

ルート認証局を手動でエクスポートするには、「ルート認証局または公開鍵証明書のエクスポート」を参照してください。

エクスポート機能により、指定したファイルが作成されます。ファイル名は変更できますが、マテリアルオブジェクトのタイプを認識できるよう、ファイル名に「DNS」または「IP」を残しておくことをお勧めします。また、サーバ名も残しておきます。

eDirectoryとの安全なLDAP接続を確立するブラウザに、自己割り当て認証局をインストールします。

InternetExplorerなど、Microsoft社の製品で証明書を使用する場合は、.der拡張子を残しておくようにします。

アプリケーションまたはSDKが証明書を要求する場合は、証明書をデータベースにインポートします。

Internet Explorer 5の場合は、ルート証明書が自動的にエクスポートされ、レジストリが更新されます。これには、Microsoftが通常使用している.x509拡張子が必要です。

相互認証には、TLSセッションとクライアント証明書が必要です。サーバとクライアントの両方が、それぞれが自分の主張するオブジェクトであることを証明する必要があります。クライアントの証明書がトランスポート層で確認されます。しかし、LDAPプロトコル層では、LDAPバインド要求を出すまでクライアントは匿名になります。

この時点で、クライアントはその正当性をサーバに証明しましたが、LDAPにはまだ証明されていません。クライアント証明書に含まれたIDで認証を受けたい場合は、クライアントはSASL EXTERNALメカニズムを使ってバインドされます。

eDirectoryのインストール時に、LDAPサーバにツリー認証局(CA)が提供されます。LDAPキーオブジェクトは、その認証局に基づいています。クライアントがLDAPサーバに送信する証明書は、このツリー認証局から検証できます。

LDAP Services for eDirectoryは、複数の認証局をサポートしています。NetIQのツリー認証局は1つの認証局にすぎません。LDAPサーバが、他のCAを持っている場合があります(例:外部団体のVeriSign*など)この追加CAもルート認証局です。

LDAPサーバが複数の認証局を使用するように設定するには、LDAPサーバオブジェクトでldapTLSTrustedRootContainer属性を設定します。LDAPサーバが複数の認証局を参照することにより、クライアントは外部の認証局を使用できます。

NetIQ eDirectoryは、認証されていないユーザに［パブリック］識別子を割り当てます。LDAPプロトコルでは、認証されていないユーザは匿名ユーザになります。デフォルトでは、LDAPサーバは匿名ユーザに[Public]識別子の権利を与えます。この権利により、非承認のeDirectoryおよび匿名LDAPユーザは、[Public]権を使用してeDirectoryを参照することができます。

また、LDAPサーバは匿名ユーザによる別のプロキシユーザの権利の使用を許可します。この値はLDAPグループオブジェクトにあります。NetIQ iManagerでは、この値は、［プロキシユーザ］フィールドで指定します。次の図は、NetIQ iManagerの［プロキシユーザ］フィールドを示しています。

プロキシユーザは識別名です。このプロキシIDに、Public識別子とは別の権利を与えることができます。プロキシユーザを使用すると、eDirectoryツリー内の特定コンテナへのLDAP匿名アクセスを制御できます。

そのために、LDAPプロキシユーザを作成し、そのユーザにDataSureディレクトリに対する特定の権利を割り当てます。LDAPグループオブジェクトにプロキシ識別名を作成し、サーバをリフレッシュします。サーバは自動的に、すべての新規または既存の匿名ユーザについて、プロキシユーザの権利の使用を開始します。

SASL (Simple Authentication and Security Layer)は、異なるメカニズムを介して、接続ベースのプロトコルに認証のサポートやデータのセキュリティサービスを追加するためのメカニズムです。プロトコルとメカニズム間の整形式のインタフェースを提供します。さらに、データ整合性、データ機密性、その他のサービスとともに、データセキュリティ層内での後続のプロトコル交換のセキュリティを保護するためのプロトコルを提供します。

SASLは、メカニズムを再設計せずに新しいプロトコルが既存のメカニズムを再使用できるように設計されており、既存のプロトコルもプロトコルの設計を変更せずに新しいメカニズムを使用できるようにします。SASLを使用するために、各プロトコルは、どのメカニズムが使用されるかを識別する方法、メカニズム固有のサーバチャレンジとクライアント応答を交換する方法、および認証交換の結果を通信する方法を提供します。

SASLメカニズムには、大文字、数字、ハイフン、およびアンダースコアで構成される、文字列によって名前が付けられます。SASLメカニズム名は、IANA (Internet Assigned Numbers Authority)に登録する必要があります。

サーバが要求されたメカニズムをサポートする場合、認証プロトコル交換を開始します。これは要求されたメカニズムに固有の一連のサーバチャレンジとクライアント応答で構成されます。認証プロトコル交換時に、メカニズムは認証を実行し、クライアントからサーバへ承認IDを送信して、メカニズム固有のセキュリティ層の使用をネゴシエートします。セキュリティ層の使用について合意すると、メカニズムは、それぞれの側で受信可能な最大の暗号テキストバッファサイズの定義つまりネゴシエートする必要もあります。

LDAPサーバでは次のメカニズムがサポートされます。

これらのメカニズムは、eDirectoryのインストールまたはアップグレード時に、サーバにインストールされます。ただし、Linuxでは、nmasinstユーティリティを使用して、NMASメソッドをインストールする必要があります。

前述したとおり、LDAPサーバは、SASLに問い合わせて環境設定時にインストールしたメカニズムを検索し、インストールされたメカニズムを自動でサポートします。また、supportedSASLMechanisms属性を使ってrootDSEで現在サポートされているSASLメカニズムをレポートします。これらは登録されているメカニズムなので、利用には正しい命名規則を使用する必要があります。

LDAPバインドプロトコルでは、クライアントは認証に様々なSASLメカニズムを使用することができます。アプリケーションがLDAPバインドAPIを使用している場合は、単純認証を選択し、DNとパスワードを入力するか、SASLバインドを選択し、SASLメカニズム名と、そのメカニズムが要求する、関連するSASL資格情報を提供する必要があります。

eDirectoryでは、NMASログインがデフォルトで有効になっています。NMASログインを無効にするには、NDSD_TRY_NMASLOGIN_FIRSTをfalseに設定します。