LDAP サーバーは、クライアント資格レベルに応じて LDAP クライアントを認証します。LDAP クライアントに対し次の資格レベルのいずれかを割り当てることができます。
anonymous – anonymous 資格レベルでは、すべての人が使用可能なデータにのみアクセスできます。LDAP BIND 操作は実行されません。anonymous 資格レベルには、高いセキュリティーリスクがあります。すべてのクライアントが、自分が書き込みアクセス権を持っている DIT 内の情報 (別のユーザーのパスワードや自分の識別情報など) を変更できます。さらに、anonymous レベルでは、すべてのクライアントがすべての LDAP ネームエントリおよび属性への読み取りアクセス権を持つことができます。
proxy – proxy 資格レベルでは、クライアントが LDAP バインド資格の単一共有セットにバインドされます。共有セットは、プロキシアカウントとも呼ばれます。プロキシアカウントには、ディレクトリへのバインドを許可されるエントリを設定できます。このアカウントには、LDAP サーバー上でネームサービス機能を実行するのに十分なアクセス権が必要です。
プロキシアカウントは、システムごとに共有されるリソースです。つまり、プロキシアクセスを使用してシステムにログインしているユーザー (root ユーザーなど) は、同じ情報を参照します。proxy 資格レベルを使用するすべてのクライアントシステムで、proxyDN および proxyPassword 属性を構成する必要があります。さらに、proxyDN には、すべての LDAP サーバーで同じ proxyPassword を指定する必要があります。
暗号化された proxyPassword はローカルのクライアントに格納されます。プロキシユーザーのパスワードが変更された場合は、そのプロキシユーザーを使用するすべてのクライアントでパスワードを更新する必要があります。また、LDAP アカウントのパスワード有効期間を使用する場合は、必ずプロキシユーザーを除外してください。
別のクライアントグループに対しては別のプロキシを設定できます。たとえば、すべての販売部門のクライアントが会社全体でアクセス可能なディレクトリおよび販売部門のディレクトリにのみアクセスできるように制限するプロキシを構成できます。給与情報が含まれる人事部門ディレクトリへのアクセスは禁止されます。もっとも極端な例として、各クライアントに別個のプロキシを割り当てることや、すべてのクライアントに同じプロキシを割り当てることも可能です。
さまざまなクライアントに複数のプロキシを設定する計画がある場合は、選択を慎重に検討してください。プロキシエージェントが不足していると、リソースへのユーザーアクセスを制御する能力が制限されることがあります。ただし、プロキシが多過ぎる場合、システムの設定および保守が困難になります。環境に応じて適切な権利をプロキシユーザーに付与する必要があります。使用する認証方法を決定する方法の詳細は、LDAP クライアントの資格情報の格納を参照してください。
proxy 資格レベルは、特定のシステム上のすべてのユーザーおよびプロセスに適用されます。異なるネーミングポリシーを使用する必要があるユーザーは、別のシステムにログインするか、ユーザー別の認証モデルを使用する必要があります。
proxy anonymous – proxy anonymous 資格レベルは複数値エントリであり、複数の資格レベルが定義されます。このレベルではクライアントは、最初にそのプロキシ識別情報を使用して認証が試みられます。ユーザーのロックアウトやパスワードの期限切れが原因で認証に失敗した場合、クライアントは匿名アクセスを使用します。ディレクトリの構成方法に応じて、さまざまな資格レベルがさまざまなレベルのサービスに関連付けられています。
self – self 資格レベルは、ユーザー別モードとも呼ばれます。このモードでは、主体と呼ばれる Kerberos 識別情報を使用して、認証対象のシステムまたはユーザーごとに検索が実行されます。ユーザー別認証では、システム管理者はアクセス制御命令 (ACI)、アクセス制御リスト (ACL)、役割、グループ、またはその他のディレクトリアクセス制御メカニズムを使用して、特定のユーザーまたはシステムの特定のネームサービスデータへのアクセスを付与または拒否できます。
ユーザー別認証モデルを使用するには、次の構成が必要です。
Kerberos シングルサインオンサービスの配備
1 つ以上のディレクトリサーバーでの SASL および SASL/GSSAPI 認証メカニズムのサポート
Kerberos でホスト名の検索を実行するためにファイルとともに使用される DNS の構成
nscd デーモンの有効化
クライアント上で enableShadowUpdate スイッチが true に設定されている場合は、シャドウデータを更新するために管理者資格情報が使用されます。シャドウデータは、ディレクトリサーバーの shadowAccount オブジェクトクラスに格納されます。管理者資格情報は、LDAP ローカルクライアント属性の定義で説明しているように、adminDN および adminPassword 属性の値によって定義されます。
管理者資格情報のプロパティーは proxy 資格情報のプロパティーと類似しています。ただし、管理者資格情報の場合、シャドウデータを読み取ったり更新するには、ユーザーはゾーンのすべての特権を持つか、root の有効な UID を持っている必要があります。
管理者資格情報は、ディレクトリへのバインドが許可されるエントリに割り当てることができます。ただし、同じディレクトリマネージャー識別情報 (cn=Directory Manager) の LDAP サーバーを使用しないでください。
管理者資格情報が設定されたエントリは、ディレクトリへのシャドウデータの読み取りおよび書き込みに対する十分なアクセス権を持っている必要があります。エントリは、システムごとに共有されるリソースです。したがって、すべてのクライアントで adminDN および adminPassword 属性を構成する必要があります。
暗号化された adminPassword はローカルのクライアントに格納されます。管理者パスワードには、クライアント用に構成されたものと同じ認証方法が使用されます。特定のシステム上のすべてのユーザーおよびプロセスは管理者資格情報を使用して、シャドウデータの読み取りおよび更新を行います。
LDAP 実装では、初期化中に設定されたプロキシ資格情報は、クライアントのプロファイルではなく、SMF リポジトリ内に格納されます。この実装によって、プロキシの識別名 (DN) およびパスワード情報に関連するセキュリティーが向上します。
SMF リポジトリは svc:/network/ldap/client です。プロキシ識別情報を使用するクライアントのプロキシ情報が格納されます。同様に、資格レベルが self 以外であるクライアントのシャドウデータの更新も、このリポジトリに保存されます。
ユーザー別認証を使用するクライアントの場合、認証時に各主体用の Kerberos 識別情報および Kerberos チケット情報が使用されます。ディレクトリサーバーは Kerberos 主体を DN にマッピングします。この DN の認証には、Kerberos 資格情報が使用されます。ディレクトリサーバーは必要に応じて、ACI メカニズムを使用してネームサービスデータへのアクセスを許可または拒否できます。
この環境では、ディレクトリサーバーへの認証に Kerberos チケット情報が使用されます。システムには、認証 DN またはパスワードは格納されません。したがって、ldapclient コマンドを使用してクライアントを初期化する場合は、adminDN および adminPassword 属性を設定する必要がありません。