クライアント資格レベルの割り当て

LDAP ネームサービスクライアントは、クライアントの資格レベルに従って LDAP サーバーを認証します。LDAP クライアントには、次の 4 つの資格レベルの 1 つを割り当てて、ディレクトリサーバーの認証を行うことができます。

• anonymous

• proxy

• proxy anonymous

• self (このマニュアルでは「ユーザー別」と呼ぶ)

匿名 (anonymous)

匿名でのアクセスを利用する場合、すべてのユーザーが使用可能なデータだけにアクセスできます。匿名モードでは、LDAP BIND 操作は実行されません。また、セキュリティーの問題も考慮する必要があります。ディレクトリの特定部分に匿名アクセスを許可する場合、そのディレクトリへのアクセス権を保持するすべてのユーザーが読み取りアクセスを保持することになります。資格レベルとして anonymous を使用する場合、すべての LDAP ネームエントリおよび属性に読み取りアクセスを許可する必要があります。

匿名でのディレクトリへの書き込みは、決して許可してはなりません。この書き込みを許可すると、どのユーザーでも書き込みアクセス権のある DIT 内の情報 (別のユーザーのパスワードや自分自身の識別情報など) を変更することが可能になります。

Sun Java System Directory Server を使用すると、IP アドレス、DNS 名、認証方式、および時刻に基づいてアクセスを制限できます。さらに指定を加えて、アクセスを制限することもできます。詳細については、ご使用のバージョンの Sun Java System Directory Server の『管理者ガイド』のアクセス権の管理に関する章を参照してください。

プロキシ (Proxy)

クライアントは、単一のプロキシアカウントを使用して、ディレクトリへの認証またはバインドを行います。このプロキシアカウントには、ディレクトリへのバインドを許可されるエントリを設定できます。このプロキシアカウントは、LDAP サーバー上でネームサービス機能を実行するのに十分のアクセス権を必要とします。プロキシアカウントは、システムごとに共有されるリソースです。つまり、root ユーザーを含む、プロキシアクセスを使ってシステムにログインした各ユーザーには、そのシステム内のほかのすべてのユーザーと同じ結果が表示されます。プロキシ資格レベルを使用して、すべてのクライアントで proxyDN および proxyPassword を構成する必要があります。暗号化された proxyPassword はローカルのクライアントに格納されます。別のクライアントグループに対しては別のプロキシを設定できます。たとえば全営業クライアント用のプロキシを構成する場合、企業全体からアクセス可能なディレクトリと営業ディレクトリの両方へのアクセスを許可しつつ、給与情報を保持する人事ディレクトリへのアクセスを許可しない、という方法が可能です。最も極端な例として、各クライアントに別個のプロキシを割り当てることや、すべてのクライアントに同じプロキシを割り当てることも可能です。一般的な LDAP 配備はこの両極端の中間に位置します。選択は慎重に行なってください。プロキシエージェントが不足していると、リソースへのユーザーアクセスを制御する能力が制限されます。ただし、プロキシが多過ぎる場合、システムの設定および保守が困難になります。適切な権限をプロキシユーザーに付与する必要がありますが、その程度は環境によって異なります。使用する構成に最適の認証方式を決定するための情報については、「資格の保存」を参照してください。

プロキシユーザーのパスワードを変更した場合、そのプロキシユーザーを使用するすべてのクライアントで情報を更新する必要があります。LDAP アカウントのパスワード有効期間を設定する場合、プロキシユーザーに関してはこの設定を解除してください。

プロキシ資格レベルは、指定されたシステムのすべてのユーザーおよびプロセスに適用されます。2 人のユーザーが異なるネーミングポリシーを使用する場合は、別個のマシンを使用するか、ユーザー別の認証モデルを使用する必要があります。

また、クライアントが認証にプロキシ資格を使用する場合、proxyDN はすべてのサーバーで同じ proxyPassword を保持する必要があります。

匿名プロキシ(proxy anonymous)

匿名プロキシは複数値のエントリで、複数の資格レベルが内部に定義されています。匿名プロキシレベルを割り当てられたクライアントは、最初にそのプロキシ識別情報を使用して認証を試みます。ユーザーのロックアウト、パスワードの有効期限切れなどの何らかの理由でクライアントがプロキシユーザーとしての認証ができなかった場合、クライアントは匿名アクセスを使用します。この場合、ディレクトリの構成に応じて、別のサービスレベルに移行する可能性があります。

ユーザー別 (Per User)

ユーザー別 (self) の認証では、ディレクトリサーバーの認証時に Kerberos 識別情報 (主体) を使用して各ユーザーまたは各システムの検索が実行されます。ユーザー別の認証では、システム管理者は、アクセス制御情報 (ACI)、アクセス制御リスト (ACL)、役割、グループ、またはその他のディレクトリアクセス制御機構を使用して、特定のユーザーまたはシステムの特定のネームサービスデータへのアクセスを許可または拒否できます。

ユーザー別のモードを設定する場合は、このモードを表す設定値「self」を使用します。

ユーザー別の認証モデルを使用するには、Kerberos シングルサインオンサービスを配備する必要があります。また、配備に使用する 1 つ以上のディレクトリサーバーで SASL および SASL/GSSAPI 認証機構をサポートする必要があります。Kerberos では、ホスト名の検索に LDAP ではなく、ファイルおよび DNS を使用することを前提としているため、この環境には DNS を配備するようにしてください。また、ユーザー別の認証を使用するには、nscd を有効にする必要があります。この構成では、nscd デーモンはオプションの構成要素ではありません。

enableShadowUpdate スイッチ

Solaris 10 10/09 リリース以降では、クライアントで enableShadowUpdate スイッチが true に設定されている場合、管理者資格がシャドウデータの更新に使用されます。シャドウデータは、ディレクトリサーバーの shadowAccount オブジェクトクラスに格納されます。管理者資格は、「ローカルのクライアント属性」で説明しているように、adminDN および adminPassword 属性の値によって定義されます。これらの管理者資格は、それ以外の目的には使用されません。

管理者資格のプロパティーは Proxy 資格のプロパティと類似しています。管理者資格の場合、シャドウデータを読み取ったり更新するには、ユーザーはゾーンのすべての特権を持つか、root の有効な UID を持っている必要があるという例外があります。管理者資格は、ディレクトリへのバインドが許可されるエントリに割り当てることができます。ただし、LDAP サーバーのディレクトリマネージャー識別情報 (cn=Directory Manager) には同じものを使用しないでください。

管理者資格が設定されたこのエントリは、ディレクトリ内のシャドウデータに対する十分な読み取りおよび書き込みアクセスを持っている必要があります。エントリはシステムごとに共有されるリソースであるため、adminDN および adminPassword 属性はクライアントごとに構成する必要があります。暗号化された adminPassword はローカルのクライアントに格納されます。パスワードには、クライアント用に構成された認証方式と同じ方式が使用されます。管理者資格は、シャドウデータの読み取りと更新を行うために、特定のシステムのすべてのユーザーおよびプロセスによって使用されます。

資格の保存

プロキシ識別情報を使用するようクライアントを設定する場合、クライアントは proxyDN および proxyPassword を /var/ldap/ldap_client_cred 内に保存します。セキュリティー保護のため、このファイルへのアクセスは root のみに許可され、proxyPassword の値は暗号化されます。過去の LDAP 実装ではプロキシ資格はクライアントのプロファイル内に格納されましたが、Solaris 9 LDAP ネームサービスではこれは行われません。初期化時に ldapclient を使用して設定されたプロキシ資格は、すべてローカルに保存されます。このため、プロキシの DN およびパスワード情報に関するセキュリティーが向上します。クライアントプロファイルの設定方法の詳細については、第 12 章LDAP クライアントの設定 (手順)を参照してください。

同様に、シャドウデータの更新が有効になるようにクライアントを構成し、クライアント資格レベルが self ではない場合、クライアントは adminDN および adminPassword 属性を /var/ldap/ldap_client_cred ファイルに保存します。adminPassword の値も暗号化され、ldap_cachemgr デーモンプロセスによってのみ使用されます。

ユーザー別の認証を使用するようクライアントを構成している場合、認証時に各主体 (各ユーザーまたはホスト) 用の Kerberos 識別情報および Kerberos チケット情報が使用されます。この環境では、ディレクトリサーバーは Kerberos 主体を DN にマッピングします。この DN の認証には、Kerberos 資格が使用されます。次に、ディレクトリサーバーは、必要に応じアクセス制御情報 (ACI) 機構を使用して、ネームサービスデータへのアクセスを許可または拒否します。この状況では、ディレクトリサーバーの認証に Kerberos チケット情報が使用されます。システムが、認証 DN またはパスワードをシステムに保存することはありません。したがって、この種類の構成では、クライアントを ldapclient コマンドを使用して初期化するときに、adminDN および adminPassword 属性を指定する必要はありません。