| Oracle® Fusion Middleware Oracle Enterprise Data Qualityの保護 12c (12.2.1.2.0) E88270-01 |
|
 前 |
 次 |
この章では、WeblogicおよびOPSSを使用したLDAPとの統合について説明します。次の項が含まれます:
WebLogicドメインには、1つ以上のセキュリティ・レルムを含めることができます。各レルムでは、セキュリティ構成、ユーザーおよびグループを定義します。一度にアクティブにできるレルムは1つのみで、通常は追加のレルムを作成する利点はありません。WebLogicドメインのデフォルト・レルムの名前は、'myrealm'です。
各レルムには、複数のセキュリティ・プロバイダが含まれます。プロバイダは、ユーザー認証やユーザー・ストアを処理するオーセンティケータであるか、X.509証明書やSAMLトークンなど、リクエストに埋め込まれたデータからユーザー・アイデンティティを特定できるアイデンティティ・アサータです。OAM統合で使用されるOracle Access Managerアイデンティティ・アサータは、B.4項「WebLogic構成」で説明します。
デフォルト・セキュリティ・レルムには、1つのオーセンティケータと2つのアイデンティティ・アサータが含まれます。
DefaultAuthenticatorは、内部WebLogicストアのユーザーを処理します。
各オーセンティケータ・プロバイダには、制御フラグ設定があります。このフラグにより、ユーザーの認証においてプロバイダが果たす役割が決定されます。使用可能なフラグ値は4つありますが、重要なものは次の2つです。
REQUIRED: プロセス全体が完了するためには、このプロバイダの認証が成功する必要があります。
SUFFICIENT: 他のオーセンティケータにREQUIRED制御フラグがないかぎり、このプロバイダの認証が成功すると、プロセス全体が成功します。
DefaultAuthenticatorは、制御フラグがREQUIREDに設定されて事前構成されているため、LDAP認証プロバイダが構成されていても成功する必要があります。LDAPサポートの構成プロセスの一環として、この値をSUFFICIENTに変更します。
プロバイダの順序も重要です。複数のオーセンティケータが有効化され、適切な制御フラグで構成されている場合、オーセンティケータのいずれかによってサポートされるユーザーは、WebLogic管理コンソールにログインできます。ただし、EDQは、リストの最初のオーセンティケータのみにアクセスでき、リストでそれより下位のオーセンティケータのユーザーは、認識されません。したがって、LDAPオーセンティケータを追加する場合、それをリストの一番上に移動することが重要です。これも後で説明します。
この項には、前提条件およびWebLogicの構成手順が含まれます。
構成プロセスを開始する前に、次の情報を収集する必要があります。
使用しているLDAPサーバーのタイプ。WebLogicには、Microsoft Active Directory、OpenLDAP、Oracle Internet Directoryなど、複数のタイプのLDAPサーバーに応じたオーセンティケータがあります。直接サポートされないサーバー(AD-LDSなど)で使用できる汎用のLDAPオーセンティケータもあります。
LDAPサーバーのホスト名およびポート。現在の環境に高可用性対応のサーバーが複数含まれる場合、構成内で複数のホストを使用できます。デフォルトのLDAPポートは389です。
接続して検索を実行できるLDAPユーザーのアイデンティティおよびパスワード。ユーザー・アイデンティティは、通常、完全な識別名(DN)ですが、Active Directoryでは短縮形式も使用できます。
ユーザーとグループを検出できるLDAPツリー(ベースDN)内の場所。
ログイン時にユーザーを識別するユーザー・レコードのLDAP属性。ほとんどのLDAPユーザー・スキーマには標準のユーザー名属性がありますが、組織ではそれ以外のものを使用できます。
グループを識別するグループ・レコードのLDAP属性。ほとんどのインストールで、これは共通名(cn)というグループになります。
EDQを操作するすべてのユーザーが含まれるLDAPグループの名前。グループは、EDQの問題の割当てなどに表示されるユーザーのリストをフィルタするために使用されます。このフィルタがないと、LDAPサーバーのすべてのユーザーが表示されるため、一般的には推奨されません。
この項の残りでは、Active Directoryとの統合に関する詳細な手順について説明します。この手順は、他のタイプのLDAPサーバーとほぼ同じです。初期構成ではSSLを使用しません。
手順の説明では、次の設定を使用します。
Active Directoryドメイン: EXAMPLE.COM
ドメイン・コントローラ(LDAPサーバー): dc1.example.com。デフォルトの非SSLのポート389が使用されます。
LDAPユーザー: cn=netuser,cn=users,dc=example,dc=com。このユーザーのADユーザー名が'netuser'であるとすると、netuser@example.comまたはexample\netuserも使用できます。
ユーザー・ベースDN: dc=example,dc=com。ここでのベースとは、完全なLDAPツリーのルートです。すべてのユーザーがサブツリーに含まれる場合、cn=users,dc=example,dc=comなどを使用できます。
グループ・ベースDN: dc=example,dc=com。同様に、適切な場合はサブツリーを使用できます。
ユーザー名属性: sAMAccountName。これは、短いログイン名を格納する標準のAD属性です。「Active Directoryユーザーとコンピュータ」アプリケーションで、これはWindows 2000より前のログイン名として表示されます。
グループ名属性: cn
すべてのEDQユーザー・グループ: edqusers
|
注意: WebLogic管理サーバーが実行されていることを確認します。構成を開始する前にEDQ管理対象サーバーを停止することをお薦めします。 |
WebLogicを構成するには、次の手順を実行します。
管理コンソールにログインし、「セキュリティ・レルム」のmyrealmに移動して「プロバイダ」タブをクリックします。「新規」をクリックして、新しいプロバイダを追加します。ADなどの名前を入力し、「ActiveDirectoryAuthenticator」を選択します。
「OK」をクリックします。構成されていない新しいプロバイダがリストの一番下に追加されます。アラートにより、変更を反映するために管理サーバーを再起動する必要があることが示されます。この段階ではこれは必要ありません。構成が完了したときにサーバーを再起動してください。
新しいプロバイダをクリックし、「構成」画面で制御フラグを「SUFFICIENT」に変更します。
「保存」をクリックして「プロバイダ固有」タブを選択します。ここでLDAPサーバーの情報を入力します。「接続」領域で、LDAPサーバー、ポート、ユーザー(プリンシパル)およびパスワード(資格証明)を入力します。「SSLの有効化」チェック・ボックスは選択しません。
「ユーザー」領域で、「ユーザー・ベースDN」を入力し、「名前指定によるユーザー・フィルタ」および「ユーザー名属性」フィールドで'cn'をユーザー名属性に置き換えます。
「グループ」領域で、「グループ・ベースDN」を入力し、グループ名属性として'cn'を使用していない場合は「名前指定によるグループ・フィルタ」で'cn'を置き換えます。
残りのセクションの変更は不要です。構成を保存するには、「保存」をクリックします。
プロバイダのリストに戻り(セキュリティ・レルム/myrealm、「プロバイダ」タブ)、「DefaultAuthenticator」をクリックします。「制御フラグ」を「SUFFICIENT」に変更して「保存」をクリックします。
プロバイダ・リストに戻り、「並替え」をクリックします。「AD」を選択し、矢印を使用してそれをリストの一番上に移動します。
「OK」をクリックして並替えを確認します。
プロバイダ・リストで、ADプロバイダが最初に表示されます。これにより、EDQがActive Directoryに対して認証可能になります。
管理サーバーを再起動して再度ログインします。「セキュリティ・レルム」のmyrealmに移動して、「ユーザーとグループ」タブをクリックします。Active Directoryからロードされたユーザーとグループが表示されます。これらが表示されない場合、管理サーバーのログでエラーを調査し、構成を再確認してください。
「ユーザーとグループ」タブの表示が極端に遅く、ログにサイズ制限エラーが記録された場合、次のようになります。
<Administration Console encountered the following error: java.lang.RuntimeException: netscape.ldap.LDAPException: error result (4); Sizelimit exceeded
この場合、Active Directoryのユーザーの数が多すぎて、管理コンソールに表示できません。EDQでこれが問題になることはありませんが、ADの「プロバイダ固有」タブにある「すべてのユーザーのフィルタ」フィールドにLDAP検索フィルタを入力して、その数を削減できます。
この項では、EDQの構成手順について説明します。
EDQユーザーを含むグループを定義するには、次の手順を実行します。
EDQドメインをホストするサーバーにログインし、EDQの'local'構成ディレクトリに移動します。
これは、DOMAIN_HOME/config/fmwconfig/edq/oedq.local.homeにあります。
ローカル・セキュリティ・ディレクトリを作成し、このディレクトリにデフォルトのログイン構成をコピーします。
$ mkdir security $ cp ../oedq.home/security/login.properties security/
security/login.propertiesで新しいローカル構成を編集し、次の行を追加します。
opss.prof.defaultusergroup = edqusers
login.propertiesの事前定義されたグループ・マッピングによって、外部管理者グループがEDQ管理者グループにマップされます。これは、内部WebLogicユーザー・ストアを使用する場合には有効なマッピングです(内部管理者グループには、標準の'weblogic'管理コンソール・ユーザーが含まれるため)。
ただし、Active Directoryの管理者グループには、ドメイン・レベルの管理者が含まれており、このグループのユーザーはEDQを使用または管理しない可能性があります。EDQ Webコンソールを使用して外部EDQ関連グループから別のグループ・マッピングを追加するには、管理者としてEDQにログインする必要があります。これは、Active Directory管理者が使用できる場合にのみ、事前定義されたデフォルトのグループ・マッピングで可能です。他のユーザーがEDQ管理者になることを許可するには、次の2つのアプローチがあります。
事前定義されたマッピングを編集します。
ローカルのlogin.propertiesを編集し、xgmap行を変更して別のLDAPグループをEDQ管理者グループにマップします。たとえば、EDQ管理ユーザーを含めるためにActive Directoryで'edqadmins'というグループが作成されている場合、次のように行を編集します。
opss.xgmap = edqadmins -> Administrators
内部レルムを有効にします。
ローカルのlogin.propertiesを編集して次のようにrealms行を変更します。
realms = internal, opss
これにより、EDQ内部ユーザー・ストアが有効になり、ユーザー'dnadmin'としてログインし、Webコンソールを使用して必要な外部グループ・マッピングを設定できます。マッピングが完了したら、内部レルムを再度無効にすることができます。
これらの変更が完了したら、EDQ管理対象サーバーを起動してActive Directoryユーザーとしてログインできます。アプリケーション・ログインに成功するには、外部グループ・マッピングを完了させて必要な権限を付与する必要があることに注意してください。
大規模な組織のLDAPストアには、数千に及ぶ別個のグループが含まれることがあり、追加フィルタがなければ、EDQ Webコンソールの外部グループのマッピング・リストにすべて表示されます。グループ・リストを管理可能なサイズにフィルタするには、LDAPグループ・フィルタをlogin.propertiesに追加します。
フィルタを追加する前に、ローカル構成領域に必ずこれのコピーを作成してください。フィルタを追加するには、次の行を編集して追加します。
opss.prof.groupfilter = LDAPGROUPFILTER
ここで、LDAPGROUPFILTERは、グループを選択するためのLDAPスタイルのフィルタです。フィルタでは、LDAP固有の属性のかわりに汎用のOPSS属性名を使用します。'name'を使用して、グループの名前を示します。フィルタでは、事前定義されたマッピングで使用されるすべてのグループを戻す必要があります。
EXAMPLE.COM設定では、EDQで使用されるすべてのグループが接頭辞'edq'で始まるため、フィルタは次のようになります。
opss.prof.groupfilter = (name=edq*)
SSLを使用してLDAPサーバーへの接続を保護する場合、LDAPプロバイダの「プロバイダ固有」タブにある「SSLの有効化」チェック・ボックスを選択して、SSLポート(通常は636)を入力します。
|
注意: WebLogicの現在のバージョンでは、初期構成後に「プロバイダ固有」ページに変更を加える場合、LDAPパスワードを再度入力する必要があります。元のパスワードは不明瞭化されますが、このバージョンはその後保存されます。 |
次に、WebLogicからLDAPサーバーへの正常な接続を有効にして、ユーザーとグループのリストを表示し、LDAPユーザーとしてWebLogicにログインできるようにするには、LDAPサーバー証明書またはルートCAを、WebLogicの実行に使用されるJREのトラスト・ストアに追加する必要があります。Java keytoolコマンドを使用して、JREのcacertsファイルを更新します。keytoolのドキュメントは次の場所にあります。
https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html
現状で、WebLogic認証のためにEDQで使用されるOPSSライブラリは、cacertsストアを使用しません。かわりに、新しいキーストアを作成する必要があります。EDQ管理対象サーバーは停止しますが、管理サーバーは実行を継続します。WebLogicが実行されているサーバーにログインし、次の環境変数を設定します。
JAVA_HOME=java install location WL_HOME=WLSHOME/wlserver ORACLE_HOME=WLSHOME
その後、次を実行します。
$ WLSHOME/oracle_common/bin/libovdconfig.sh -host HOST -port PORT -userName weblogic -domainPath DOMAIN_HOME -createKeystore
ここで、WLSHOMEはWebLogicのインストール・ディレクトリ、HOSTは管理サーバーが実行されているホストの名前、PORTは管理ポート(通常は7001)、DOMAIN_HOMEはWebLogicドメインの場所です。
このコマンドにより、weblogicユーザーのパスワードと、新しいキーストアのパスワードの入力を求められます。これは任意に指定できます。
正常に完了すると、新しいキーストアが次の場所に作成されます。
DOMAIN_HOME/config/fmwconfig/ovd/default/keystores/adapters.jks
Java keytoolを使用して、サーバーまたはCA証明書を新規作成したキーストアに追加します。
$ keytool -import -keystore DOMAIN_HOME/config/fmwconfig/ovd/default/keystores/adapters.jks -alias ALIAS -file CERTFILE
証明書を指定するキーストアでALIASを置き換え、証明書ファイルの場所でCERTFILEを置き換えます。
このコマンドにより、キーストア・パスワードの入力を求められます(キーストアの作成時に指定したパスワードを入力します)。
EDQ管理対象サーバーを再起動すると、LDAPユーザーはログインすることができます。WebLogicとLDAP間のトラフィックは、SSLで保護されます。
