組み込み LDAP サーバの管理
デフォルトでは、WebLogic 認証プロバイダ、認可プロバイダ、資格マッピング プロバイダ、およびロール マッピングのセキュリティ プロバイダ データベースとして、組み込み LDAP サーバが使用されます。 これらのプロバイダを使用する場合、組み込み LDAP サーバの管理が必要になります。 以下の節では、組み込み LDAP サーバを管理する方法について説明します。
組み込み LDAP サーバのコンフィグレーション
組み込み LDAP サーバには、ユーザ、グループ、グループ メンバシップ、セキュリティ ロール、セキュリティ ポリシー、および資格マップ情報が格納されます。 デフォルトでは、WebLogic Server ドメインごとに組み込み LDAP サーバが各属性のデフォルト値を使用してコンフィグレーションされます。 WebLogic 認証プロバイダ、認可プロバイダ、資格マッピング プロバイダ、およびロール マッピング プロバイダは、組み込み LDAP サーバをデータベースとして使用します。 新しいセキュリティ レルムでこれらのプロバイダを使用する場合、組み込み LDAP サーバのデフォルト値を変更して、環境に合わせて動作を最適化することができます。
組み込み LDAP サーバをコンフィグレーションするには、次の手順に従います。
- ドメイン ノード (examples など) を展開します。
- [セキュリティ｜組み込み LDAP] タブを選択します。
- [組み込み LDAP] タブで属性を設定します。 次の表では、[組み込み LDAP] タブの各属性について説明します。
表5-1 [組み込み LDAP] タブの属性
|
属性
|
説明
|
|
[資格]
|
組み込み LDAP サーバへの接続に使用される資格 (通常はパスワード)。 このパスワードが未設定の場合、WebLogic Server は起動時にパスワードを生成し、属性を初期化し、コンフィグレーションを config.xml ファイルに保存する。 外部 LDAP ブラウザと組み込み LDAP 管理者アカウント (cn=Admin) を使用して組み込み LDAP サーバに接続するには、この属性を生成された値から変更すること。
|
|
[バックアップ時間 (時間)]
|
組み込み LDAP サーバのデータ ファイルをバックアップする時刻 (時)。 この属性は [バックアップ時間 (分)] 属性と組み合わせて使用され、組み込み LDAP サーバのデータ ファイルをバックアップする時刻を決定する。 指定された時刻になると、WebLogic Server は組み込み LDAP サーバへの書き込みを一時停止し、データ ファイルを ldap/backup ディレクトリの zip ファイルにバックアップしてから、書き込みを再開する。デフォルトでは 23。
|
|
[バックアップ時間 (分)]
|
組み込み LDAP サーバのデータ ファイルをバックアップする時刻 (分)。 この属性は [バックアップ時間 (時間)] 属性と組み合わせて使用され、組み込み LDAP サーバのデータ ファイルをバックアップする時刻を決定する。デフォルトでは 5 分。
|
|
[バックアップ コピー数]
|
組み込み LDAP サーバのデータ ファイルのバックアップ コピー数。 この値によって、ldap/backup ディレクトリ内の zip ファイルの数が制限される。デフォルトでは 7。
|
|
[キャッシュを有効化]
|
組み込み LDAP サーバでキャッシュを使用するかどうかを指定する。 このキャッシュは、管理サーバ上で稼働するマスター組み込み LDAP サーバに対して管理対象サーバが読み込みと書き込みを実行するときに使用される。
|
|
[キャッシュ サイズ]
|
組み込み LDAP サーバで使用されるキャッシュのサイズ (単位は K)。デフォルトは 32K。
|
|
[キャッシュ TTL]
|
キャッシュの存続期間 (TTL) の秒数。デフォルトでは 60 秒。
|
|
[起動時にレプリカを更新]
|
管理対象サーバがレプリケートされたデータを起動時にすべてリフレッシュするかどうかを指定する。 この属性は、管理対象サーバがアクティブでない間に大量の変更を行ったため、それらの変更を管理サーバから管理対象サーバに送らずにレプリカ全体をダウンロードしたいときに役立つ。
この属性を使用すると、新しいシステム パスワードをドメイン内の管理対象サーバと管理サーバに伝播できる。
デフォルトは false。
|
|
[マスターを優先]
|
ローカルのレプリケート対象組み込み LDAP サーバの代わりに常にマスター LDAP サーバ (管理サーバ上で稼働) に接続するよう指定する。 これにより、管理対象サーバは、管理サーバの情報のレプリカを持つローカルの組み込み LDAP サーバではなく、管理サーバ内の組み込み LDAP サーバからセキュリティ データを取り出す。
|
- [適用] をクリックして変更を保存します。
- WebLogic Server を再起動します。
組み込み LDAP サーバを WebLogic Server ドメインで使用する場合、更新はマスター LDAP サーバに送信されます。マスター LDAP サーバは、すべての変更のログを保持します。また、マスター LDAP サーバは、レプリケート対象サーバのリストと各サーバの現在の変更ステータスも保持します。マスター LDAP サーバは、各レプリケート対象サーバに適切な変更を送信して、各サーバの変更ステータスを更新します。 この処理は、マスター LDAP サーバが更新されたときに行われます。 ただし、更新数によっては、変更が管理対象サーバにレプリケートされるまでに数秒かかることがあります。 マスター LDAP サーバは、管理サーバ上の組み込み LDAP サーバです。レプリケート対象サーバは、WebLogic Server ドメイン内のすべての管理対象サーバです。
注意: コンフィグレーション済みのセキュリティ プロバイダを WebLogic Server Administration Console で削除および修正するには、組み込み LDAP サーバの手動クリーンアップが必要となる場合があります。 不要な情報を削除するには、外部 LDAP ブラウザを使用します。
組み込み LDAP サーバのバックアップのコンフィグレーション
組み込み LDAP サーバのバックアップをコンフィグレーションするには、次の手順に従います。
- ドメイン ノード (examples など) を展開します。
- [セキュリティ｜組み込み LDAP] タブを選択します。
- [組み込み LDAP] タブで、[バックアップ時間 (時間)]、[バックアップ時間 (分)]、および [バックアップ コピー数] 属性を設定します。
- [適用] をクリックして変更を保存します。
- WebLogic Server を再起動します。
LDAP ブラウザによる組み込み LDAP サーバの内容の表示
LDAP ブラウザを使用して組み込み LDAP サーバの内容を表示するには、次の手順に従います。
- 組み込み LDAP の資格を変更します。
- ドメイン ノード (examples など) を展開します。
- [Security｜組み込み LDAP] タブを選択します。
- [資格] 属性を変更します。 詳細については、表 5-1を参照してください。
- [適用] をクリックします。
- WebLogic Server を再起動します。
- コマンド プロンプトで次のコマンドを入力して、LDAP ブラウザを起動します。
lbe.sh
- LDAP ブラウザで新しい接続をコンフィグレーションします。
- [Host] フィールドを localhost に設定します。
- [Port] フィールドを 7001 (SSL を使用する場合は 7002) に設定します。
- [Base DN] フィールドを dc=mydomain に設定します。 mydomain は使用する WebLogic Server ドメインの名前を表します。
- [Anonymous Bind] オプションのチェックをはずします。
- [User DN] フィールドを cn=Admin に設定します。
- [Password] フィールドを手順 1 で指定したパスワードに設定します。
- 新しい接続をクリックします。
LDAP ブラウザを使用して、組み込み LDAP サーバの階層をナビゲートします。
組み込み LDAP サーバの情報のエクスポートとインポート
LDAP ブラウザを使用すると、組み込み LDAP サーバに格納されている情報をエクスポートおよびインポートできます。 表 5-2 には、データが組み込み LDAP サーバの階層のどこに格納されているかをまとめてあります。
表5-2 組み込み LDAP サーバ内のセキュリティ データの場所
|
セキュリティ データ
|
組み込み LDAP サーバ DN
|
|
ユーザ
|
ou=people,ou=myrealm,dc=mydomain
|
|
グループ
|
ou=groups,ou=myrealm,dc=mydomain
|
|
セキュリティ ロール
|
ou=ERole,ou=myrealm,dc=mydomain
|
|
セキュリティ ポリシー
|
ou=EResource,ou=myrealm,dc=mydomain
|
組み込み LDAP サーバのセキュリティ データをエクスポートするには、次の手順に従います。
- コマンド プロンプトで次のコマンドを入力して、LDAP ブラウザを起動します。
lbe.sh
- エクスポートするデータを指定します。たとえば、ユーザをエクスポートするには ou=people,ou=myrealm,dc=mydomain を指定します。
- [LDIF｜Export] オプションを選択します。
- [Export all children] を選択します。
- データのエクスポート先となるファイルの名前を指定します。
組み込み LDAP サーバにセキュリティ データをインポートするには、次の手順に従います。
- コマンド プロンプトで次のコマンドを入力して、LDAP ブラウザを起動します。
lbe.sh
- インポートするデータを指定します。たとえば、ユーザをインポートするには ou=people,ou=myrealm,dc=mydomain を指定します。
- [LDIF｜Import] オプションを選択します。
- [Update/Add] を選択します。
- データのインポート元となるファイルの名前を指定します。
アクセス制御の構文
組み込み LDAP サーバは、IETF の「LDAP Access Control Model for LDAPv3」(2001 年 3 月 2 日、ドラフト) をサポートしています。 この節では、これらのルールが組み込み LDAP サーバでどのように実装されているかを説明します。 これらのルールは、標準で想定しているようにディレクトリ内のエントリに適用することも、アクセス制御ファイル (acls.prop) を編集することでコンフィグレーションおよび管理することもできます。
アクセス制御ファイル
注意: デフォルトでは、組み込み LDAP サーバには、WebLogic Server の管理者アカウントからしかアクセスできません。 外部 LDAP ブラウザだけを使用する場合は、acls.prop ファイルを編集する必要はありません。
組み込み LDAP サーバが管理しているアクセス制御ファイル (acls.prop) には、LDAP ディレクトリ全体のアクセス制御リスト (ACL) の全リストが入っています。 アクセス制御ファイルの各行には、1 つのアクセス制御ルールが入っています。アクセス制御ルールは、以下の要素で構成されています。
- ルールを適用する LDAP ディレクトリ内の場所
- ルールを適用する場所の中のスコープ
- アクセス権 (許可または拒否)
- パーミッション (許可または拒否)
- ルールを適用する属性
- アクセスの許可または拒否の対象となるサブジェクト
リスト5-1 はサンプルのアクセス制御ファイルです。
コード リスト 5-1 acl.props ファイルのサンプル
[root]|entry#grant:r,b,t#[all]#public
ou=Employees,dc=octetstring,dc=com|subtree#grant:r,c#[all]#public:
ou=Employees,dc=octetstring,dc=com|subtree#grant:b,t#[entry]#public:
ou=Employees,dc=octetstring,dc=com|subtree#deny:r,c#userpassword#public:
ou=Employees,dc=octetstring,dc=com|subtree#grant:r#userpassword#this:
ou=Employees,dc=octetstring,dc=com|subtree#grant:w,o#userpassword,title,
description,
postaladdress,telephonenumber#this:
cn=schema|entry#grant:r#[all]#public:
アクセス制御の場所
各アクセス制御ルールは、LDAP ディレクトリ内の指定した場所に適用されます。 通常、場所は識別名 (DN) ですが、ディレクトリ全体にアクセス制御ルールを適用する場合は、特殊な場所 [root] を acls.prop ファイルに指定できます。
アクセスまたは変更の対象となる LDAP サーバのエントリがアクセス制御ルールの場所またはその下の場所にない場合、指定されたアクセス制御ルールはそれ以上評価されません。
アクセス制御のスコープ
アクセス制御のスコープは次のように定義されます。
- Entry − Entry スコープは、LDAP ディレクトリ内のエントリがアクセス制御ルールの場所と同じ DN を持つ場合にのみ評価されます。 こうしたルールは、並列しているエントリやサブツリーのエントリよりも 1 つのエントリに問題の情報が含まれている場合に便利です。
- Subtree − Subtree スコープは、LDAP ディレクトリ内のエントリがアクセス制御ルールの場所と同じか、またはその場所で終わっている場合に評価されます。 このスコープは、場所エントリとそのサブツリー全体を保護します。
ディレクトリ内のエントリが相互に矛盾するアクセス制御ルールの対象となっている場合 (あるルールが Entry ルールで、他方が Subtree ルールのような場合)、Entry ルールが Subtree ルールよりも優先されます。
アクセス権とパーミッション
アクセス権は、オブジェクト全体またはオブジェクトの属性に適用されます。 アクセスは許可または拒否のいずれかです。 アクセス制御ルールを作成または更新する場合、grant または deny のいずれのアクションも指定できます。
LDAP アクセス パーミッションはそれぞれ独立しています。 あるパーミッションが別のパーミッションを意味するわけではありません。 パーミッションでは、実行可能な LDAP の処理のタイプを指定します。
属性のパーミッション
次のパーミッションは、属性に伴うアクションに適用されます。
表5-3 属性のパーミッション
|
パーミッション
|
説明
|
|
r Read
|
読み取り属性。 付与した場合、読み取りまたは検索処理で属性または値を返すことが許可される。
|
|
w Write
|
変更または追加属性。 付与した場合、変更処理で属性または値を追加することが許可される。
|
|
o Obliterate
|
変更および削除属性。 付与した場合、変更処理で属性または値を削除することが許可される。
|
|
s Search
|
指定した属性を持つエントリの検索。 付与した場合、検索処理で属性または値を含めることが許可される。
|
|
c Compare
|
属性値の比較。 付与した場合、比較処理で属性または値を含めることが許可される。
|
|
m Make
|
このエントリの下の新しいエントリに属性を作成する。
|
m パーミッションは、オブジェクトの作成時に指定したすべての属性に対して必要です。 変更処理で w および o パーミッションが使用されるように、追加処理では m パーミッションが使用されます。 w および o パーミッションは追加処理と関係がなく、m は変更処理と関係がありません。 新しいオブジェクトはまだ存在していないので、作成時に必要な a および m パーミッションは新しいオブジェクトの親に対して付与しなければなりません。 この要件は、変更対象のオブジェクトに対して付与しなければならない w および o パーミッションとは異なります。 m パーミッションは w および o パーミッションとは別個のものなので、新しい子をエントリに追加するために必要なパーミッションと、そのエントリの既存の子を変更するために必要なパーミッションとの間で、衝突は発生しません。 変更処理で値を置換するためには、ユーザは w および o パーミッションを持っていなければなりません。
エントリのパーミッション
以下のパーミッションは LDAP エントリ全体に適用されます。
表5-4 エントリのパーミッション
|
パーミッション
|
説明
|
|
a Add
|
このエントリの下にエントリを追加する。 付与した場合、DIT サブジェクトにエントリを作成することが許可され、新しいエントリの作成時に指定するすべての属性および値を制御できるようになる。 エントリを追加するためには、少なくとも必須属性を追加するためのパーミッションも付与しなければならない。
|
|
d Delete
|
このエントリを削除する。 付与した場合、エントリ内の属性に対する制御に関係なく、DIT からエントリを削除することが許可される。
|
|
e Export
|
エントリとすべてのサブエントリを新しい場所にエクスポートする。
付与した場合、エントリとそのサブエントリをエクスポート、つまり現在の場所から削除し、新しい目的の場所のパーミッションに従ってその場所に配置することが許可される。
最後の RDN を変更する場合、現在の場所には Rename パーミッションも必要となる。
エントリまたはそのサブエントリをエクスポートするために、指定されている属性 (RDN 属性を含む) に対する事前のパーミッションは必要ない。 このことは、RDN を変更した結果、新しい属性値が追加または削除されるような処理を行う場合でも同様である。
|
|
i Import
|
指定した場所からエントリとそのサブエントリをインポートする。
付与した場合、エントリとそのサブエントリをインポート、つまり他の場所から削除し、指定した場所に配置することが許可される (新しい場所に適切なパーミッションが付与されている場合)。
エントリまたはそのサブエントリをインポートする場合、指定されている属性 (RDN 属性を含む) に対する事前のパーミッションは必要ない。 このことは、RDN を変更した結果、新しい属性値が追加または削除されるような処理を行う場合でも同様である。
|
|
n RenameDN
|
LDAP エントリの DN を変更する。 エントリの名前を新しい RDN に変更するには、変更によってサブエントリの DN が変更されることを考慮して、Rename パーミッションを付与する必要がある。 上位エントリの名前が変更されない場合は、そのパーミッションを付与するだけでよい。
エントリの名前を変更する場合、指定されている属性 (RDN 属性を含む) に対する事前のパーミッションは必要ない。 このことは、RDN を変更した結果、新しい属性値が追加または削除されるような処理を行う場合でも同様である。
|
|
b BrowseDN
|
エントリの DN を参照する。 付与した場合、エントリの名前を明示的に指定しないでディレクトリを操作しながらエントリにアクセスすることが許可される。
|
|
t ReturnDN
|
処理の結果にエントリの DN を表示する。 付与した場合、エントリの識別名を処理の結果に表示することが許可される。
|
属性のタイプ
アクセス制御ルールが適用される属性のタイプは、必要に応じて表示される必要があります。 以下のキーワードを使用できます。
- [entry] は、パーミッションがオブジェクト全体に適用されることを示す。 例として、オブジェクトの削除や子オブジェクトの追加などのアクションがあります。
- [all] は、パーミッションがエントリのすべての属性に適用されることを示す。
キーワード [all] と別の属性の両方を ACL に指定した場合、属性に関してより具体的なパーミッションが、[all] キーワードによって指定されたより具体的でないパーミッションをオーバライドします。
サブジェクトのタイプ
アクセス制御ルールは、さまざまなサブジェクトのタイプに関連付けることができます。 アクセス制御ルールが接続中のセッションに適用されるかどうかは、アクセス制御ルールのサブジェクトによって決まります。
以下のサブジェクトのタイプが定義されています。
- AuthzID − サブジェクトの定義の一部として指定できる単一のユーザに適用されます。 LDAP ディレクトリでのユーザの ID は通常、DN として定義されます。
- Group − 以下のオブジェクト クラスのいずれかによって指定されるユーザ グループに適用されます。
- groupOfUniqueNames
- groupOfNames
- groupOfUniqueURLs
最初の 2 つのタイプのグループにはユーザのリストが入りますが、3 つ目のタイプでは定義した条件に基づいてユーザが自動的にグループに含められます。
- Subtree − LDAP ディレクトリ ツリー内のサブジェクトとすべてのサブエントリの一部として定義される DN に適用されます。
- IP Address − 特定のインターネット アドレスに適用されます。 このサブジェクト タイプは、すべてのアクセスがプロキシまたはその他のサーバを経由する場合に便利です。 適用対象は、ある範囲 (サブネット) ではなく、特定のホストです。
- Public − 認証されているかどうかにかかわらず、ディレクトリに接続しているすべてのユーザに適用されます。
- This − アクセス対象のエントリと一致する DN を持つユーザに適用されます。
許可/拒否の評価ルール
エントリ内の情報へのクライアント アクセスを許可するか拒否するかは、アクセス制御ルールと保護対象のエントリに関連するさまざまな要因によって決定されます。 決定過程には目安となるいくつかの原則があります。
- より具体的なルールがそうでないルールをオーバライドする。たとえば、ACL の個々のユーザ エントリはグループ エントリに優先します。
- ACL の値どうしが衝突した場合、拒否が許可に優先する
- アクセス制御情報がない場合、拒否がデフォルトとなる。 また、エントリ スコープはサブジェクト スコープに優先します。
ルールの具体性を調べても衝突が解決しない場合、どちらのルールを適用するかはルールのサブジェクトによって決定されます。 IP Address サブジェクトに基づくルールは最も優先度が高く、特定の AuthzID または This サブジェクトに適用されるルールが続きます。 さらに Group サブジェクトに適用されるルールが続き、最後は Subtree および Public サブジェクトに適用されるルールとなります。
