LDAP の構成

XClarity Controller の LDAP 設定を表示または変更するには、このトピックの情報を使用します。

LDAP のサポートには以下が含まれます。

LDAP プロトコル・バージョン 3 (RFC 2251) のサポート
標準 LDAP クライアント API (RFC 1823) をサポート
標準 LDAP 検索フィルター構文 (RFC 2254) のサポート
Lightweight Directory Access Protocol (v3) Extension for Transport Layer Security (RFC-2830) のサポート

LDAP 実装では、以下の LDAP サーバーがサポートされます。

Microsoft Active Directory (Windows 2003、Windows 2008、Windows 2012、Windows 2016、Windows 2019)
Microsoft Active Directory アプリケーション・モード (Windows 2003 Server)
Microsoft Lightweight Directory Service (Windows 2008、Windows 2012)
Novell eDirectory Server、バージョン 8.7、8.8、および 9.4
OpenLDAP サーバー 2.1、2.2、2.3、および 2.4

XClarity Controller の LDAP 設定を表示または変更するには、「LDAP」タブをクリックします。

XClarity Controller は、XClarity Controller 自体に保存されたローカル・ユーザー・アカウントの代わりまたはアカウントに追加で、中央 LDAP サーバーを介してユーザーのアクセスをリモートで認証できます。特権は、IBMRBSPermissions ストリングを使用して、各ユーザー・アカウントごとに指定できます。また、LDAP サーバーを使用して、通常のユーザー (パスワード検査) 認証の他に、ユーザーをグループに割り当ててグループ認証を行うこともできます。たとえば、XClarity Controller を 1 つ以上のグループに関連付けることができ、ユーザーはこの XClarity Controller に関連付けられている少なくとも 1 つのグループに属している場合にのみ、グループ認証にパスします。

LDAP サーバーを構成するには、以下の手順を実行します。

「LDAP サーバー情報」内で、項目リストから以下のオプションを使用できます。
- 認証のみに LDAP サーバーを使用する (ローカル承認): この選択肢は、資格情報を LDAP サーバーへの認証にのみ使用し、グループ・メンバーシップ情報を取得するように XClarity Controller に指示します。グループ名と特権は「Active Directory 設定」セクションで構成できます。
- 認証と承認に LDAP サーバーを使用する: この選択肢は、資格情報を LDAP サーバーへの認証とユーザーのアクセス権限の識別の両方に使用するように XClarity Controller に指示します。
注
認証に使用する LDAP サーバーは、手動で構成することも DNS SRV レコード経由で動的に検出することも可能です。
- 事前構成済みのサーバーを使用する: 各サーバーの IP アドレスまたはホスト名 (DNS が有効である場合) を入力して、最大 4 つの LDAP サーバーを構成できます。各サーバーのポート番号はオプションです。このフィールドをブランクのまま残した場合、デフォルト値の 389 が、非セキュア LDAP 接続に使用されます。セキュア接続では、デフォルトのポート値は 636 です。少なくとも 1 つの LDAP サーバーが構成されている必要があります。
- DNS を使用してサーバーを探す: LDAP サーバーを動的に検出するように選択できます。RFC2782 (サービスのロケーションを指定する DNS RR) で説明されるメカニズムが LDAP サーバーの検索に使用されます。これは、DNS SRV と呼ばれています。DNS SRV 要求のドメイン名として使用する完全修飾ドメイン名 (FQDN) を指定する必要があります。
  - AD フォレスト: クロス・ドメインのユニバーサル・グループがある環境では、フォレスト名 (ドメインのセット) が、要求されたグローバル・カタログ (GC) を検出するように構成されている必要があります。ドメイン間グループ・メンバーシップが適用されない環境では、このフィールドはブランクのままにしておきます。
  - AD ドメイン: DNS SRV 要求のドメイン名として使用する完全修飾ドメイン名 (FQDN) を指定する必要があります。
セキュア LDAP を有効にする場合は、「セキュア LDAP を有効にする」チェック・ボックスをクリックします。セキュア LDAP をサポートするには、有効な SSL 証明書が所定の場所にあり、少なくとも 1 つの SSL クライアント・トラステッド証明書が XClarity Controller にインポートされている必要があります。LDAP サーバーは、XClarity Controller セキュア LDAP クライアントとの互換性を持たせるために、トランスポート層セキュリティー (TLS) バージョン 1.2 をサポートする必要があります。証明書の処理について詳しくは、SSL 証明書の処理を参照してください。

「追加のパラメーター」の下に情報を入力します。パラメーターの説明を以下に示します。

バインディング方式

LDAP サーバーの検索または照会を行うには、事前にバインド要求を送信する必要があります。このフィールドにより、この LDAP サーバーへの初期バインドを実行する方法を制御します。以下のバインド方式が選択可能です。

資格情報不要
識別名 (DN) やパスワードを使用せずにバインドするには、この方式を使用します。ほとんどのサーバーは特定のユーザー・レコードに対する検索要求を許可しないように構成されているため、この方式を使用しないことを強く推奨します。
構成済み資格情報を使用
構成済みの DN およびパスワードを使用してバインドするには、この方式を使用します。
ログイン資格情報を使用
ログイン・プロセスで提供された資格情報を使用してバインドするには、この方式を使用します。ユーザー ID は、DN、部分 DN、完全修飾ドメイン名を介して、または XClarity Controller 上で構成された UID 検索属性に一致するユーザー ID を介して提供できます。提示された資格情報が部分 DN (たとえば、cn=joe) と同様の場合、この部分 DN は、ユーザーの記録に一致する DN の作成を試行するときに、構成済みのルート DN の先頭に付けられます。バインド試行が失敗した場合、最後の試行は、ログイン資格情報の先頭に cn= を付けて試行されます。その後、その結果の文字列を構成済みのルート DN の先頭に追加します。

初期バインドが成功した場合は、ログインするユーザーに属する LDAP サーバーで項目の検索が実行されます。必要であれば 2 回目のバインド試行が実行されますが、ユーザーの LDAP レコードから取得された DN とログイン・プロセスで入力されたパスワードが使用されます。2 回目のバインド試行が失敗すると、ユーザーはアクセスを拒否されます。2 回目のバインドが実行されるのは、「資格情報不要」か「構成済み資格情報を使用」のバインディング方式が使用されている場合のみです。

ルート識別名 (DN): LDAP サーバー上のディレクトリー・ツリーのルート・エントリーの識別名 (DN) です (たとえば、dn=mycompany,dc=com)。この DN がすべての検索要求の基本オブジェクトとして使用されます。

UID 検索属性: バインディング方式が「資格情報不要」または「構成済み資格情報を使用」に設定されている場合、LDAP サーバーへの初回バインドの直後に、ユーザーの DN、ログイン許可、およびグループ・メンバーシップなど、ユーザーに関する固有の情報を取得する検索要求が行われます。この検索要求では、そのサーバー上でユーザー ID を表す属性名を指定する必要があります。この属性名は、このフィールドで構成されます。Active Directory サーバーでは、属性名は通常「sAMAccountName」です。Novell eDirectory サーバーおよび OpenLDAP サーバーでは、この属性名は「uid」です。このフィールドをブランクのまま残した場合、デフォルトは「uid」です。

グループ・フィルター: 「グループ・フィルター」フィールドは、グループ認証に使用されます。グループ認証は、ユーザーの資格情報が正常に確認された後に試行されます。グループ認証が失敗すると、ユーザーのログオン試行は拒否されます。グループ・フィルターが構成されている場合、XClarity Controller がどのグループに属しているかを指定するのに使用されます。つまり、成功するには、グループ認証向けに構成されたグループの少なくとも 1 つにユーザーが属している必要があります。「グループ・フィルター」フィールドがブランクのまま残された場合、グループ認証は自動的に成功します。グループ・フィルターが構成されている場合は、リスト内のグループの少なくとも 1 つがユーザーが属しているグループと一致しているか、マッチングが試行されます。一致するグループがない場合、ユーザーは認証に失敗し、アクセスは拒否されます。少なくとも 1 つのグループが一致する場合は、グループ認証は成功します。; この比較は大/小文字を区別します。フィルターは 511 文字が上限で、1 つ以上のグループ名から構成することができます。複数のグループ名を区切る場合は、コロン (:) 文字を使用する必要があります。先頭および末尾のスペースは無視されますが、それ以外のスペースはすべてグループ名の一部として処理されます。
注
ワイルドカード文字 (*) はワイルドカードとして処理されなくなりました。機密漏れを防止するため、ワイルドカードの概念は廃止されました。グループ名は完全 DN として、または cn 部分のみを使用して指定できます。たとえば、DN が cn=adminGroup,dc=mycompany,dc=com であるグループは、実際の DN または adminGroup を使用して指定することができます。; グループ・メンバーシップのネストは、Active Directory 環境でのみサポートされます。たとえば、ユーザーが GroupA および GroupB のメンバーで、GroupA が GroupC のメンバーである場合、ユーザーは GroupC のメンバーでもあると見なされます。ネストされた検索は、128 個のグループを検索すると停止します。1 つのレベル内のグループが、その下位レベルのグループの前に検索されます。ループは検出されません。

グループ検索属性: Active Directory 環境または Novell eDirectory 環境では、「グループ検索属性」フィールドは、ユーザーの所属先グループを識別するために使用される属性名を指定します。Active Directory 環境では、この属性名は「memberOf」です。eDirectory 環境では、この属性名は「groupMembership」です。OpenLDAP サーバー環境では、通常、ユーザーは「objectClass」が PosixGroup であるグループに割り当てられます。そのコンテキストでは、このフィールドは特定の PosixGroup のメンバーを識別するために使用する属性名を指定します。この属性名は「memberUid」です。このフィールドがブランクのまま残されると、フィルターの属性名はデフォルトの memberOf になります。

ログイン許可属性: ユーザーが LDAP サーバーを通じて正常に認証された場合、ユーザーのログイン許可を取り出す必要があります。ログイン許可を検索するには、サーバーに送信される検索フィルターでログイン許可に関連付けられている属性名を指定する必要があります。「ログイン許可属性」フィールドは、その属性名を指定します。認証と承認に LDAP サーバーを使用していて、このフィールドをブランクのまま残した場合、ユーザーはアクセスを拒否されます。; LDAP サーバーから返される属性値は、キーワード・ストリング IBMRBSPermissions= を使用して検索されます。このキーワード・ストリングの直後には、12 個の連続した 0 または 1 として入力されたビット・ストリングが続いている必要があります。各ビットは、各機能の設定を表します。ビットは、その位置に応じて番号付けられています。左端のビットはビット位置 0、右端のビットはビット位置 11 です。ビット位置が 1 の場合、そのビット位置に関連付けられた機能が有効にされています。あるビット位置の値が 0 の場合、そのビット位置に関連付けられた機能は無効になります。; ストリング IBMRBSPermissions=010000000000 は有効な例です。「IBMRBSPermissions=」キーワードを使用すると、このフィールドの任意の位置に配置することが可能になります。これにより、LDAP 管理者は既存の属性を再使用することが可能になるため、LDAP スキーマの拡張を防ぎます。また、これによって属性を元の目的で使用することができるようになります。このフィールドの任意の場所にキーワード・ストリングを追加することができます。使用する属性は、自由な形式のストリングが可能です。属性が正常に取り出された場合、LDAP サーバーから返された値は、以下の表の説明に従って解釈されます。

表 1. 許可ビット.
ビット位置の説明を含む 3 列の表。
ビット位置	機能	説明
0	常に拒否	ユーザーは常に認証に失敗します。この機能は、特定のユーザーまたは特定のグループと関連付けられているユーザーをブロックするために使用されます。
1	スーパーバイザー・アクセス権	ユーザーに管理者特権が付与されます。ユーザーは、すべての機能に対して読み取り/書き込みアクセス権を持ちます。このビットを設定した場合、他のビットを個別に設定する必要はありません。
2	読み取り専用アクセス権	ユーザーは読み取り専用のアクセス権を持ち、保守手順 (たとえば、再起動、リモート操作、またはファームウェア更新など) や変更操作 (たとえば、保存、消去、または復元機能など) を行うことはできません。ビット位置 2 と他のすべてのビットは相互に排他的で、ビット位置 2 の優先順位が最下位です。他のいずれかのビットが設定されている場合、このビットは無視されます。
3	ネットワーキングおよびセキュリティー	ユーザーは、「セキュリティー」、「ネットワーク・プロトコル」、「ネットワーク・インターフェース」、「ポート割り当て」、および「シリアル・ポート」の構成を変更できます。
4	ユーザー・アカウント管理	このユーザーは、ユーザーの追加、変更、または削除を行うことができ、「ログイン・プロファイル」ウィンドウで「グローバル・ログイン」設定を変更できます。
5	リモート・コンソール・アクセス	このユーザーは、リモート・サーバーのリモート・サーバー・コンソールにアクセスすることができます。
6	リモート・コンソールおよびリモート・ディスクのアクセス	このユーザーは、リモート・サーバーのリモート・サーバー・コンソールおよびリモート・ディスク機能にアクセスすることができます。
7	リモート・サーバー電源/再起動アクセス	ユーザーは、リモート・サーバーの電源オン機能と再起動機能にアクセスできます。
8	基本アダプター構成	ユーザーは、「システム設定」ウィンドウおよび「アラート」ウィンドウで構成パラメーターを変更できます。
9	イベント・ログをクリアする権限	このユーザーはイベント・ログを消去することができます。注すべてのユーザーがイベント・ログを表示できますが、ログを消去するには、ユーザーにこのレベルの権限が必要です。
10	拡張アダプター構成	ユーザーは、XClarity Controller を構成するときに何も制約を受けません。さらに、ユーザーは XClarity Controller に対する管理アクセス権限を持ちます。ユーザーは、ファームウェア・アップグレード、PXE ネットワーク・ブート、XClarity Controller の出荷時デフォルト値の復元、構成ファイルに入っているアダプター構成の変更と復元、および XClarity Controller の再起動とリセットなどの拡張機能を実行できます。
11	予約済み	このビット位置は、将来の使用のために予約済みです。セットされたビットがない場合、ユーザーは読み取り専用権限を持ちます。ユーザー・レコードから直接検索されるログイン許可には優先順位があります。ログイン許可属性がユーザーのレコードに入っていない場合は、そのユーザーが属するグループから許可を取り出そうと試みられます。これは、グループ認証フェーズの一部として行われます。このユーザーには、すべてのグループのすべてのビットの包含 OR が割り当てられます。読み取り専用アクセス権限ビット (位置 2) は、他のすべてのビットがゼロに設定された場合にのみ設定されます。「常に拒否」ビット (位置 0) がいずれかのグループに設定されている場合、そのユーザーはアクセスを拒否されます。「常に拒否」ビット (位置 0) は、常に他のすべてのビットに優先します。

いずれのビットも設定されていない場合、デフォルトではユーザーに「読み取り専用」が設定されます。

ユーザー・レコードから直接検索されるログイン許可には優先順位があることに注意してください。ユーザーのレコードにログイン許可属性が含まれていない場合、ユーザーが属しており、構成されていれば、グループ・フィルターに一致するグループから権限の取得が試行されます。この場合、ユーザーには、すべてのグループのすべてのビットの包含 OR が割り当てられます。同様に、「読み取り専用アクセス権」ビットはその他のビットがすべてゼロの場合にのみ設定されます。さらに、「常に拒否」ビットがいずれかのグループに設定されている場合、ユーザーはアクセスを拒否されるので注意してください。「常に拒否」ビットの優先順位は、常にその他のすべてのビットよりも高くなります。

注

ユーザーに基本、ネットワーキング、および/またはセキュリティー関連のアダプター構成パラメーターを変更する権限が付与する場合、そのユーザーに XClarity Controller を再起動する権限 (ビット位置 10) を付与することを検討してください。この権限がない場合、ユーザーはパラメーター (アダプターの IP アドレスなど) の変更はできても、そのパラメーターを有効にできない場合があります。

「Active Directory 設定」で「Active Directory ユーザーを使用可能にするための拡張役割ベース・セキュリティーを有効にする」かどうかを選択 (「認証と承認に LDAP サーバーを使用する」モードが使用されている場合) するか、「ローカル承認用グループ」を構成 (「認証のみに LDAP サーバーを使用する」 (「ローカル承認」) モードが使用されている場合) します。
- Active Directory ユーザーを使用可能にするための拡張役割ベース・セキュリティーを有効にする:
  拡張役割ベース・セキュリティー設定が有効になっている場合、自由な形式のサーバー名がその特定の XClarity Controller のターゲット名として機能するように構成する必要があります。ターゲット名は、役割ベース・セキュリティー (RBS) のスナップインを使用して Active Directory サーバー上の 1 つ以上の役割に関連付けることができます。これは、管理対象ターゲットを作成し、それらに固有の名前をつけて適切な役割に関連付けることで実現されます。このフィールドに名前が構成されている場合、ユーザーおよび同じ役割のメンバーである XClarity Controller (ターゲット) に特定の役割を定義することができます。ユーザーが XClarity Controller にログインし、Active Directory 経由で認証されると、このユーザーがメンバーである役割がディレクトリーから取得されます。ユーザーに割り当てられる権限は、メンバーとしてここで構成されたサーバー名と一致するターゲットがあるか、任意の XClarity Controller に一致しているターゲットがある役割から抽出されます。複数の XClarity Controller で同じターゲット名を共有できます。これは、たとえば、複数の XClarity Controller を 1 つのグループにして、単一の管理対象ターゲットを使用してそれを同じ役割に割り当てるために使用できます。逆に、各 XClarity Controller には固有の名前を指定できます。
- ローカル承認用グループ
  グループ名は、ユーザーのグループに対するローカル承認の指定を提供するために構成されます。各グループ名は、上記の表で説明されているものと同じ権限 (役割) を割り当てることができます。LDAP サーバーは、ユーザーをグループ名と関連付けます。ユーザーがログインする際には、ユーザーが属するグループに関連付けられたアクセス権限が割り当てられます。追加グループは、「+」アイコンをクリックして構成できます。また、「x」アイコンをクリックして削除できます。

フィードバックを送る