この章では、WebLogic Server 10.3.6に含まれ、デフォルト認証プロバイダ、認可プロバイダ、資格証明マッピング・プロバイダ、およびロール・マッピング・プロバイダのデフォルトのセキュリティ・プロバイダ・データ・ストアとしての役割を持つ組込みLDAPサーバーを構成および管理する方法について説明します。
この章の内容は以下のとおりです。
組込みLDAPサーバーには、ユーザー、グループ、グループ・メンバーシップ、セキュリティ・ロール、セキュリティ・ポリシー、および資格証明マップ情報が格納されます。デフォルトでは、各WebLogicドメインに、各種の情報のデフォルト値が構成されている組込みLDAPサーバーが1つあります。デフォルト認証、認可、資格証明マッピング、およびロール・マッピングの各プロバイダは、組込みLDAPサーバーをデータ・ストアとして使用します。新しいセキュリティ・レルムでこれらのプロバイダを使用する場合は、組込みLDAPサーバーのデフォルト値を変更して、環境に合せて最適化できます。
注意: 組込みLDAPサーバーは、10,000ユーザー未満の環境で最高のパフォーマンスを示します。これよりユーザーが多い場合は、別のLDAPサーバーと認証プロバイダの使用を検討してください。 |
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの組込みLDAPサーバーの構成に関する項を参照してください。
組込みLDAPサーバーで使用されるデータ・ファイルおよび変更ログ・ファイルは、非常に大きなサイズになる場合があります。以下のweblogic.Server
コマンド・ライン引数を使用すると、こうしたファイルに対して最大サイズを構成できます。
-Dweblogic.security.ldap.maxSize=<max bytes>
。組込みLDAPサーバーで使用されるデータ・ファイルのサイズを制限します。データ・ファイルが指定されたサイズを超えると、削除済みのエントリによって占有されていたスペースがデータ・ファイルから削除されます。
-Dweblogic.security.ldap.changeLogThreshold=<number of entries>
。組込みLDAPサーバーで使用される変更ログ・ファイルのサイズを制限します。変更ログ・ファイルが指定されたエントリ数を超えると、すべての管理対象サーバーに送信されていたすべてのエントリを削除することによって変更ログが切り詰められます。
ドメインのWebLogic Serverの組込みLDAPサーバーは、1つのマスターLDAPサーバー(ドメインの管理サーバーが保持する)と、レプリケートされたLDAPサーバー(ドメインの各管理対象サーバーが保持する)で構成されます。管理対象サーバーを使用して変更が行われると、その更新データは管理サーバー上の組込みLDAPサーバーに送信されます。管理サーバー上の組込みLDAPサーバーは、すべての変更のログを保持します。また、管理サーバー上の組込みLDAPサーバーは、管理対象サーバーのリストと各管理対象サーバーの現在の変更ステータスも保持します。管理サーバー上の組込みLDAPサーバーは、各管理対象サーバーに適切な変更を送信して、各サーバーの変更ステータスを更新します。この処理は管理サーバー上の組込みLDAPサーバーで更新が行われたときに発生します。ただし、更新の回数によっては、変更が管理対象サーバーにレプリケートされるのに数秒以上かかることがあります。
管理コンソールを使用すると、ドメイン内の管理サーバーと管理対象サーバー上の組込みLDAPサーバーの動作を構成できます。管理コンソールの「ドメイン」→「セキュリティ」→「組込みLDAP」ページで、次の属性を設定します。
起動時にレプリカをリフレッシュ - 管理対象サーバーの組込みLDAPサーバーがすべてのレプリケートされたデータを起動時にリフレッシュするかどうかを指定します。この設定は、管理対象サーバーがアクティブでないときに大量の変更を行った場合に、各変更を管理サーバーから管理対象サーバーに送るのではなく、レプリカ全体をダウンロードする場合に役立ちます。
マスター優先 - 管理対象サーバーが、ローカルのレプリケートされたLDAPサーバーではなく常に管理サーバー上の組込みLDAPサーバーに接続するかどうかを指定します。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの組込みLDAPサーバーの構成に関する項を参照してください。
注意: 構成済みのセキュリティ・プロバイダをWebLogic管理コンソールで削除および修正する際には、組込みLDAPサーバーの手動クリーンアップが必要になることがあります。外部LDAPブラウザを使用して、不要な情報を削除します。 |
LDAPブラウザで組込みLDAPサーバーの内容を表示するには:
外部LDAPブラウザをダウンロードしてインストールします。LDAPブラウザの1つは次のサイトにあります。
この手順では、このLDAPブラウザを使用することを前提としています。他のLDAPブラウザでは詳細が異なる場合があります。
WebLogic Server管理コンソールで、組込みLDAPサーバーの資格証明を変更します。
「ドメイン」→「セキュリティ」→「組込みLDAP」の順に展開します。
「資格証明」フィールドに、新しい資格証明を入力します。
「資格証明の確認」フィールドに、新しい資格証明をもう一度入力します。
「保存」をクリックします。
WebLogic Serverを再起動します。
警告: 資格証明を変更すると、ドメインの動作に影響することがあります。本番サーバーでは、この手順は実行しないでください。 |
LDAPブラウザを起動します。ステップ1で示したLDAPブラウザ/エディタを起動するには、次のコマンドを使用します。
lbe.sh
LDAPブラウザで、新しい接続を構成します。
「QuickConnect」タブを選択します。
「ホスト」フィールドをlocalhost
に設定します。
「ポート」フィールドを7001
(SSLを使用する場合は7002
)に設定します。
「ベースDN」フィールドをdc=
mydomain
に設定します。mydomain
は使用するWebLogicドメインの名前です。
「匿名バインド」オプションのチェックを解除します。
「ユーザーDN」フィールドをcn=Admin
に設定します。
「パスワード」フィールドにステップ2で指定した資格証明を設定します。
新しい接続をクリックします。
LDAPブラウザを使用して、組込みLDAPサーバーの階層をナビゲートします。
注意: データをエクスポートし、エクスポート・ファイルを参照することで、組込みLDAPサーバーの内容を表示することもできます。「組込みLDAPサーバーの情報のエクスポートおよびインポート」を参照してください。 |
WebLogic Server管理コンソールまたはLDAPブラウザでは、組込みLDAPサーバーからデータをエクスポートしてインポートできます。管理コンソールでデータをエクスポートおよびインポートするには、各セキュリティ・プロバイダの「移行」ページを使用します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・プロバイダからのデータのエクスポートに関する項およびセキュリティ・プロバイダへのデータのインポートに関する項を参照してください。
警告: 管理コンソールの「移行」タブを使用してセキュリティ・データをエクスポートすると、ターゲット・ディレクトリ内の拡張子.dat の既存ファイルはすべて削除されます。セキュリティ・データは、必ず空のディレクトリにエクスポートするようにしてください。 |
この節では、LDAPブラウザを使用して、組込みLDAPサーバーに格納されているデータをエクスポートおよびインポートする方法について説明します。表9-1に、組込みLDAPサーバーの階層におけるデータの格納場所をまとめます。
表9-1 組込み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サーバーからセキュリティ・データをエクスポートするには:
コマンド・プロンプトに次のコマンドを入力して、LDAPブラウザ/エディタを起動します。
lbe.sh
エクスポートするデータを指定します(たとえば、ユーザーをエクスポートするにはou=people,ou=
myrealm
,dc=
mydomain
と指定します)。
「LDIF」>「エクスポート」オプションを選択します。
「すべての子をエクスポートする」を選択します。
データのエクスポート先ファイルの名前を指定します。
LDAPブラウザ/エディタを使用して組込みLDAPサーバーにセキュリティ・データをインポートするには:
コマンド・プロンプトに次のコマンドを入力して、LDAPブラウザを起動します。
lbe.sh
インポートするデータを指定します(たとえば、ユーザーをインポートするにはou=people,ou=
myrealm
,dc=
mydomain
と指定します)。
LDAPブラウザ/エディタで、「LDIF」>「インポート」オプションを選択します。
「更新/追加」を選択します。
データをインポートするファイルの名前を指定します。
組込みLDAPサーバーはIETFの「LDAP Access Control Model for LDAPv3」をサポートしています。この節では、そのアクセス制御を組込みLDAPサーバーの内部に実装する方法について説明します。これらのルールは、標準で想定されているようにディレクトリ内のエントリに直接適用することも、アクセス制御ファイル(acls.prop
)を編集して構成および管理することもできます。
注意: 組込みLDAPサーバーのデフォルトの動作では、WebLogic ServerのAdminアカウントからのアクセスのみが許可されます。WebLogicセキュリティ・プロバイダでは、Adminアカウントのみを使用して組込みLDAPサーバーにアクセスします。外部LDAPブラウザから組込みLDAPサーバーにアクセスする予定がない場合やAdminアカウントのみを使用する予定の場合、acls.prop ファイルの編集は不要なので、この項の情報は無視して構いません。 |
組込みLDAPサーバーが保持するアクセス制御ファイル(acls.prop
)には、LDAPディレクトリ全体のアクセス制御リスト(ACL)の完全なリストが含まれています。アクセス制御ファイルの各行には、アクセス制御ルールが1つずつ含まれています。アクセス制御ルールは以下の要素で構成されています。
ルールを適用するLDAPディレクトリ内の場所。「アクセス制御の場所」を参照してください。
その場所の内部でルールを適用する範囲。「アクセス制御のスコープ」を参照してください。
アクセス権(付与または拒否)。「アクセス権」を参照してください。
パーミッション(付与または拒否)。「属性のパーミッション」および「エントリのパーミッション」を参照してください。
ルールを適用する属性。「属性タイプ」を参照してください。
アクセスを付与または拒否するサブジェクト。「サブジェクト・タイプ」を参照してください。
例9-1に、アクセス制御ファイルのサンプルを示します。
例9-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)ですが、アクセス制御ルールをディレクトリ全体に適用する場合は、acls.prop
ファイルで特定の場所のroot
を指定できます。
LDAPサーバー上でアクセスまたは変更されるエントリが、アクセス制御ルールの場所に一致しないか下位ディレクトリに存在しない場合、指定されたアクセス制御ルールはそれ以上評価されません。
以下のアクセス制御のスコープが定義されています。
エントリ - エントリのスコープを持つACLは、LDAPディレクトリ内のエントリが、アクセス制御ルールの場所と同じDNを共有する場合にのみ評価されます。このようなルールは、単一のエントリに、同列または下位のエントリよりも重要な情報が含まれる場合に有用です。
サブツリー - サブツリーのスコープは、LDAPディレクトリ内のエントリが、このアクセス制御の場所と同じ、またはこのアクセス制御の場所で終わる場合に評価されます。このスコープでは、その場所のエントリとすべての下位エントリが保護されます。
ディレクトリ内のエントリが、競合するアクセス制御ルールの対象となっている場合(たとえば、あるルールが「エントリ」のルールで、別のルールが「サブツリー」のルールである場合)、「エントリ」のルールが「サブツリー」のルールよりも優先されます。
アクセス権はオブジェクト全体またはオブジェクトの属性に適用されます。アクセスは付与または拒否されます。アクセス制御ルールを作成または更新するときに、grant
またはdeny
のアクションを使用できます。
LDAPのアクセス権はそれぞれが分離しています。ある権限に別の権限が含まれることはありません。権限では実行できるLDAP操作のタイプを指定します。
表9-2で示される権限は、属性を含むアクションに適用されます。
表9-2 属性の権限
権限 | 説明 |
---|---|
|
属性を読み込みます。付与される場合、読み込みまたは検索操作で、属性と値を返すことが許可されます。 |
|
属性を変更または追加します。付与される場合、変更操作で属性と値の追加が許可されます。 |
|
属性を変更または削除します。付与される場合、変更操作で属性と値の削除が許可されます。 |
|
指定された属性を持つエントリを検索します。付与される場合、属性と値が検索操作の対象となることが許可されます。 |
|
属性値を比較します。付与される場合、属性と値が比較操作の対象となることが許可されます。 |
|
このエントリの下の新しいLDAPエントリに属性を作成します。 |
m
権限は、オブジェクトを作成するときにオブジェクトに配置されるすべての属性に対して必須です。変更操作でw
およびo
権限が使用されるのと同様に、m
権限は追加操作で使用されます。w
およびo
権限は追加操作とは無関係で、m
権限は変更操作とは無関係です。新しいオブジェクトはまだ存在していないため、オブジェクトの作成に必要なaおよびm
権限は、新しいオブジェクトの親に付与されている必要があります。この要件は、変更対象のオブジェクトに付与する必要のあるw
およびo
権限とは異なります。エントリに新しい子を追加するために必要な権限と、同じエントリの既存の子を変更するために必要な権限が競合しないように、m
権限はw
およびo
権限とは別個で固有のものになっています。変更操作で値を置き換えるには、ユーザーはw
権限とo
権限の両方を持つ必要があります。
表9-3で示される権限は、LDAPエントリ全体に適用されます。
表9-3 エントリの権限
権限 | 説明 |
---|---|
|
このLDAPエントリの下にエントリを追加します。付与される場合、DITサブジェクト内にエントリを作成して、作成時に新しいエントリに配置されるすべての属性と値を制御することが許可されます。エントリを追加するには、少なくとも必須の属性を追加する権限も付与されなければなりません。 |
|
このエントリを削除します。付与される場合、エントリ内の属性の制御に関係なく、DITからエントリを削除することが許可されます。 |
|
エントリとすべての下位エントリを新しい場所にエクスポートします。 付与される場合は、エントリとその下位エントリ(存在する場合)のエクスポートが許可されます。つまり、エクスポート先に適した許可を付与するという前提で、エントリを現在の場所から削除して新しい場所に配置します。 最後のRDNを変更する場合は、現在の場所で エントリまたはその下位エントリをエクスポートする際に、エントリに含まれる属性(RDN属性を含む)に必須の権限はありません。操作によって新しい属性値が追加されたり、RDNの変更の結果として属性値が削除されたりする場合でも、このことが当てはまります。 |
|
エントリと下位エントリを指定された場所からインポートします。 付与される場合、エントリとその下位エントリ(存在する場合)のインポートが許可されます。つまり、新しい場所に適した権限が付与される場合、エントリをある場所から削除して指定された場所に配置します。 エントリまたはその下位エントリをインポートする際に、エントリに含まれる属性(RDN属性を含む)に必須の権限はありません。操作によって新しい属性値が追加されたり、RDNの変更の結果として属性値が削除されたりする場合でも、このことが当てはまります。 |
|
LDAPディレクトリのDNを変更します。エントリの名前を新しいRDNに変更する(下位エントリのDNも結果として変更される)場合は、Rename権限を付与する必要があります。上位のエントリの名前を変更しない場合、付与は十分です。 エントリの名前を変更する際に、エントリに含まれる属性(RDN属性を含む)に必須の権限はありません。操作によって新しい属性値が追加されたり、RDNの変更の結果として属性値が削除されたりする場合でも、このことが当てはまります。 |
|
エントリのDNを参照します。付与される場合、ディレクトリ操作を使用してエントリにアクセスすることが許可されます。この操作では、エントリの名前は明示的に提供されません。 |
|
操作の結果にエントリのDNを公開することが許可されます。付与される場合、操作の結果にエントリの識別名を公開することが許可されます。 |
アクセス制御ルールが適用される属性タイプは、必要な場合にACLにリストする必要があります。以下のキーワードが使用されます。
entry
- 権限がオブジェクト全体に適用されることを示します。オブジェクトの削除や子オブジェクトの追加などのアクションを意味します。
all
- 権限がエントリのすべての属性に適用されることを示します。
ACL内でキーワードall
と別の属性の両方が指定されている場合、属性に対する限定性の高い権限が、all
キーワードで指定される限定性の低い権限をオーバーライドします。
アクセス制御ルールは、様々なサブジェクト・タイプと関連付けることができます。アクセス制御ルールのサブジェクトによって、現在接続しているセッションにアクセス制御ルールが適用されるかどうかが決まります。
以下のサブジェクト・タイプが定義されます。
authzID
- サブジェクト定義の一部として指定できる単一のユーザーに適用されます。ユーザーのIDは、LDAPディレクトリ内で通常DNとして定義されます。
Group
- 以下のいずれかのオブジェクト・クラスで指定されるユーザーのグループに適用されます。
groupOfUniqueNames
groupOfNames
groupOfUniqueURLs
1番目と2番目のタイプのグループにはユーザーのリストが含まれます。3番目のタイプでは、定義された基準に基づいてユーザーが自動的にグループに分類されます。
Subtree
- LDAPディレクトリ・ツリー内のサブジェクトとすべての下位エントリの一部として指定されるDNに適用されます。
IP Address
- 特定のインターネット・アドレスに適用されます。このサブジェクト・タイプは、すべてのアクセスがプロキシ・サーバーまたは他のサーバーを経由しなければならない場合に便利です。特定のホストにのみ適用され、範囲やサブネットには適用されません。
Public
- 認証されるかどうかにかかわらず、ディレクトリに接続するすべての対象に適用されます。
This
- アクセスされるエントリのDNに一致するDNを持つユーザーに適用されます。
エントリ内の情報に対するクライアント・アクセスを付与または拒否するかどうかの決定は、アクセス制御ルールや保護されるエントリに関連する様々な要因に基づいて行われます。意思決定プロセスの過程には、以下のような指針となる原則があります。
限定性の高いルールが限定性の低いルールをオーバーライドします(たとえば、ACL内の個々のユーザー・エントリは、グループ・エントリに優先します)。
ルールの限定性に関係なく競合が解消されない場合は、ルールのサブジェクトによって適用すべきルールが決まります。IP Address
サブジェクトに基づくルールが最優先され、その次に、特定のAuthzID
またはThis
サブジェクトに適用されるルールが続きます。次に優先されるのは、Group
サブジェクトに適用されるルールです。優先度が最も低いのは、Subtree
およびPublic
サブジェクトに適用されるルールです。
ACLに競合する値がある場合、拒否の方が付与よりも優先されます。
アクセス制御情報がない場合は、デフォルトで拒否されます。また、エントリのスコープはサブツリーのスコープに優先します。
任意のセキュリティ・レルムがデフォルト認証、認可、資格証明マッピングまたはロール・マッピング・プロバイダを使用する場合、次のディレクトリ・ツリーの最新バックアップを保持する必要があります:
domain_name/servers/adminServer/data/ldap
前述のディレクトリでは、domain_name
はドメインのルート・ディレクトリ、adminServer
は、管理サーバーがランタイム・セキュリティ・データを保存するディレクトリとなります。組込みLDAPサーバー・データのバックアップの詳細は、次のトピックを参照してください。
『Oracle WebLogic Serverサーバーの起動と停止の管理』のLDAPリポジトリのバックアップに関する項
Oracle WebLogic Server管理コンソール・ヘルプの組込みLDAPサーバーのバックアップの構成に関する項を参照してください。
組込みLDAPサーバー・ファイルが破損または使用不能の場合、管理サーバーはNumberFormatException
を生成して起動できません。このような状況はほとんど起こりませんが、ディスク容量がいっぱいなため組込みLDAPファイルが無効な状態になる場合には発生する可能性があります。
組込みLDAPサーバー・ファイルが使用不能な状態から復元するには、次の手順を実行します。
次のディレクトリを変更します。
domain_name/servers/adminServer/data
組込みLDAPサーバー・ファイルの名前を、次の例のように変更します。
mv ldap ldap.old
ファイル名を変更し、ファイルを完全には削除しないことによって、分析や今後のデータ・リカバリ用にファイルが使用できる状態になります。
管理サーバーを起動します。
管理サーバーが起動すると、新しい組込みLDAPサーバー・ファイルが作成されます。
WebLogicドメインの作成時から追加されたデータを新しい組込みLDAPサーバーに復元します。
組込みLDAPサーバーのバックアップを構成済の場合は、それをインポートすることによってバックアップされたデータを復元できます。詳細は、「組込みLDAPサーバー内の情報のエクスポートおよびインポート」を参照してください。