プライマリ・コンテンツに移動
Oracle® Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド
12c (12.2.1)
E70043-01
  目次へ移動
目次
前
前 		 次
次		  

3 代替認証プロバイダの使用

この章では、デフォルトのOracle WebLogic Server LDAPディレクトリではなく代替ディレクトリ・サーバーを認証に使用するように、Oracle Business Intelligenceを構成する方法を説明します。また、Oracle Internet Directory、Active Directoryおよびその他の認証プロバイダを使用するようにOracle Business Intelligenceを設定する方法や、OID LDAPまたはデータベースをポリシー・ストアおよび資格証明ストアとして使用する方法についても説明します。


注意:

セキュリティ設定手順の詳細なリストは、第1.7項「Oracle Business Intelligenceのセキュリティを設定するための詳細な手順」を参照してください。

この章には次の項が含まれます:

3.1 概要

代替認証プロバイダを使用する場合、通常はプロバイダ・ベンダーが提供する管理ツールを使用してユーザーおよびグループを設定します。これらのユーザーおよびグループをBIサービス・インスタンスで定義されたアプリケーション・ロールに割り当てることができます。アプリケーション・ロールへのユーザーおよびグループの割当ての詳細は、第2.4項「Fusion Middleware Controlの使用によるアプリケーション・ロールおよびアプリケーション・ポリシーの管理」を参照してください。

セキュリティ・モデルのその他の領域を管理するには、引き続き、他のOracle Business Intelligenceツール(Oracle BI管理ツール、Fusion Middleware Control、プレゼンテーション・サービスの「管理」ページなど)を使用します。

現在サポートされている、Oracle Business Intelligenceで使用できる認証プロバイダおよびディレクトリ・サーバーのリストを表示するには、「新しい認証プロバイダの作成」ページの「タイプ」リストで認証プロバイダを選択します。詳細は、「システム要件と動作要件」を参照してください。

1つ以上のサポートされている認証プロバイダを複数構成できます。詳細は、第3.4項「代替認証プロバイダを使用するためのOracle Business Intelligenceの構成」を参照してください。

デフォルトのWebLogic LDAPサーバー以外のディレクトリ・サーバーを使用している場合は、Oracle WebLogic Server管理コンソールに、他のディレクトリ・サーバーのユーザーおよびグループを表示できます。ただし、使用しているディレクトリ・サーバーのインタフェースでユーザーおよびグループを管理する必要があります。たとえば、Oracle Internet Directory (OID LDAP)を使用している場合、OIDコンソールを使用して、ユーザーおよびグループの作成と編集を行う必要があります。

3.2 代替認証プロバイダを構成するための大まかな手順

代替認証プロバイダを構成するには:

  1. 外部アイデンティティ・ストアにOracle Business Intelligenceで使用するためのすべてのユーザーおよびグループ設定があることを確認します。

    詳細は、第3.3項「代替認証プロバイダのグループおよびユーザーの設定」を参照してください。

  2. 第3.4項「代替認証プロバイダを使用するためのOracle Business Intelligenceの構成」の説明に従って、必要な認証プロバイダを構成します。

  3. myrealmの「ユーザーとグループ」タブに移動し、代替認証プロバイダのユーザーおよびグループが正しく表示されていることを確認します。ユーザーおよびグループが正しく表示されていたら、次のステップに進みます。正しく表示されていない場合は、構成を設定しなおし、再度表示を試みます。

  4. Fusion Middleware Controlを使用して、アプリケーション・ロールを新しいアイデンティティ・ストアの対応するグループ(エンタープライズ・ロール)に割り当てます。

    詳細は、第2.4.4.2項「アプリケーション・ロールのメンバーの追加または削除」を参照してください。

3.3 代替認証プロバイダのグループおよびユーザーの設定

代替認証プロバイダを使用する前に、適切なグループおよびユーザーを構成する必要があります。BIサービス・インスタンス内のアプリケーション・ロールに関連付けます。Oracle Business Intelligenceでは特定のユーザーまたはグループを必要としないため、本番環境の企業のアイデンティティ・ストア(Oracle Internet Directory (OID)など)は組織に関連するユーザーおよびグループが通常すでに含まれています。ただし、サンプル・アプリケーションLiteまたは初期アプリケーションに基づく簡単なシステムの設定方法の例は、第2.2項「ユーザー、グループおよびアプリケーション・ロールのセキュリティ設定の例」を参照してください。

代替認証プロバイダでユーザーおよびグループを設定するには:

  1. BIサービス・インスタンスのアプリケーション・ロールと類似した代替認証プロバイダのグループを作成します。例(サンプル・アプリケーションの使用):

    BIServiceAdministrators、BIContentAuthors、BIConsumers

  2. 代替認証プロバイダで、ステップ1のグループに対応するユーザーを作成します。例:

    BISERVICEADMIN、BICONTENTAUTHOR、BICONSUMER

  3. 代替認証プロバイダで、ユーザーをそれぞれのグループに割り当てます。

    たとえば、BISERVICEADMINユーザーをBIServiceAdministratorsグループに割り当てます。

  4. 代替認証プロバイダで、BIContentAuthorsグループをBIConsumersグループの一部にします。

    このグループ化により、BIContentAuthorsはBIConsumersの権限を継承できます。

3.4 代替認証プロバイダを使用するためのOracle Business Intelligenceの構成

この項では、Oracle Business Intelligenceを構成してデフォルトのOracle WebLogic Server LDAPディレクトリのかわりに1つ以上の認証プロバイダを使用する方法について説明し、次のトピックが含まれます。


注意:

単一のLDAPアイデンティティ・ストアにユーザーおよびグループを格納することで十分です。ただし、拡張インストールの場合、複数のLDAPアイデンティティ・ストアまたはデータベース・アイデンティティ・ストアのユーザーが必要になる場合があります。'アイデンティティ・ストアの仮想化'というメカニズムを使用してこれらを有効化します(第3.4.6項「Fusion Middleware Controlを使用したアイデンティティ・ストアの仮想化の構成」を参照)。


注意:

この項では特定の認証プロバイダの設定について説明します。ただし、他の認証プロバイダを構成するための汎用ガイドとしてもご利用いただけます。

3.4.1 認証プロバイダとしてのOracle Internet Directoryの再構成

この手順では、Oracle Internet Directory (OID LDAP)を使用するよう、Oracle Business Intelligenceインストールを再構成する方法を示します。

認証プロバイダとしてOID LDAPを再構成するには:

  1. Oracle WebLogic Server管理コンソールにログインし、「チェンジ・センター」で「ロックして編集」をクリックします。

    詳細は、第1.6.1項「Oracle WebLogic Server管理コンソールの使用」を参照してください。

    wls01.gifの説明が続きます
    「wls01.gif」の説明

  2. 左ペインで「セキュリティ・レルム」を選択し、「myrealm」をクリックします。

    デフォルトのセキュリティ・レルムはmyrealmという名前です。

  3. 「プロバイダ」タブを表示し、「認証」サブタブを表示します。

    wls03.gifの説明が続きます
    「wls03.gif」の説明

  4. 「新規」をクリックし、「新しい認証プロバイダの作成」ページを起動します。

    wls04.gifの説明が続きます
    「wls04.gif」の説明

  5. 「新しい認証プロバイダの作成」ページで、次のように値を入力します。

    • 名前: 認証プロバイダの名前を入力します。例: MyOIDDirectory。

    • タイプ: リストから、「OracleInternetDirectoryAuthenticator」を選択します。

    • 「OK」をクリックし、変更を保存して、新しい認証プロバイダで更新された認証プロバイダ・リストを表示します。

      wls07.gifの説明が続きます
      「wls07.gif」の説明

  6. 「認証プロバイダ」表の「名前」列で「MyOIDDirectory」をクリックし、「設定」ページを表示します。

    wls08.gifの説明が続きます
    「wls08.gif」の説明

  7. 「構成」→「共通」タブを表示し、「制御フラグ」リストで「SUFFICIENT」を選択して「保存」をクリックします。

    詳細は、第3.4.8項「JAAS制御フラグ・オプションの設定」を参照してください。

    wls05.gifの説明が続きます
    「wls05.gif」の説明

  8. 「プロバイダ固有」タブを表示します。

    wls09.gifの説明が続きます
    「wls09.gif」の説明

  9. 「プロバイダ固有」タブを使用して、次の値を指定します。

    セクション名 フィールド名 説明
    接続 ホスト Oracle Internet Directoryサーバーのホスト名。
    接続 ポート Oracle Internet Directoryサーバーがリスニングしているポート番号。
    接続 プリンシパル Oracle Internet Directoryサーバーへの接続に使用されるOracle Internet Directoryユーザーの識別名(DN)。例: cn=OIDUser、cn=users、dc=us、dc=mycompany、dc=com。
    接続 資格証明 プリンシパルとして入力されたOracle Internet Directoryユーザーのパスワード。
    グループ グループ・ベースDN グループを含むOracle Internet Directoryサーバー・ツリーのベース識別名(DN)。
    ユーザー ユーザー・ベースDN ユーザーを含むOracle Internet Directoryサーバー・ツリーのベース識別名(DN)。
    ユーザー すべてのユーザーのフィルタ LDAP検索フィルタ。詳細は、「詳細」をクリックします。

    これはActive Directory認証のデフォルト値であるため、ここを空白のままにします。

    「すべてのユーザーのフィルタ」に追加するフィルタがすべてのユーザー検索に追加されることに注意してください。
    ユーザー 名前指定によるユーザー・フィルタ LDAP検索フィルタ。詳細は、「詳細」をクリックします。
    ユーザー ユーザー名属性 認証に使用する属性(cn、uid、mailなど)。たとえば、ユーザーの電子メール・アドレスを使用して認証を行うには、この値をmailに設定します。

    注意: 第3.4.3.1項「ユーザー名属性の構成」の説明のとおり、ここで指定する値は、認証プロバイダで使用しているユーザー名属性と一致する必要があります。

    図3-1は、「プロバイダ固有」タブのユーザー領域を示しています。

    図3-1 「プロバイダ固有」タブ - ユーザー領域

    図3-1の説明が続きます
    「図3-1 「プロバイダ固有」タブ - ユーザー領域」の説明

    Oracle WebLogic Serverでの認証プロバイダの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』を参照してください。

  10. (オプション)ユーザー名属性またはグループ名属性がOracle Internet Directoryの'cn'以外の値に構成されている場合、Oracle WebLogic Server管理コンソールの対応する値を変更する必要があります。

    詳細は、第3.4.3項「アイデンティティ・ストアでのユーザーおよびグループ名属性の構成」を参照してください。


    注意:

    WebLogicで提供されているLDAP認証プロバイダ(OracleInternetDirectoryAuthenticatorおよびActiveDirectoryAuthenticatorを含む)は通常、'cn'をユーザー名およびグループ名の属性として使用するようにデフォルトで設定されています。ユーザー名に対して代替属性('uid'や'mail'など)の使用が必要になることはよくありますが、別のグループ名属性の使用が必要になることはあまり一般的ではありません。

  11. 「保存」をクリックします。

  12. 次の手順を実行し、DefaultAuthenticatorの「制御フラグ」を設定します。

    1. メインの「myrealmの設定」ページで、「プロバイダ」タブ→「認証」サブタブを表示し、「DefaultAuthenticator」を選択して、その構成ページを表示します。

    2. 「構成」→「共通」タブを表示し、「制御フラグ」リストで「SUFFICIENT」を選択します。

      詳細は、第3.4.8項「JAAS制御フラグ・オプションの設定」を参照してください。

    3. 「保存」をクリックします。

  13. 次の手順に従ってプロバイダを並べ替えます。

    1. メインの「myrealmの設定」ページで「プロバイダ」タブを表示し、「認証」サブタブを表示します。wls07.gifの説明が続きます
      「wls07.gif」の説明

    2. 「並替え」をクリックし、「認証プロバイダの並替え」ページを表示します。

    3. 「MyOIDDirectory」を選択し、矢印ボタンを使用してこれをリストの最初に移動し、「OK」をクリックします。

      wls11.gifの説明が続きます
      「wls11.gif」の説明

    4. 「OK」をクリックして変更内容を保存します。

      並べ替えた順序で認証プロバイダが表示されます。

      oid23_crop.gifの説明が続きます
      「oid23_crop.gif」の説明

  14. 「保存」をクリックします。

  15. チェンジ・センターで、変更のアクティブ化をクリックします。

  16. Oracle WebLogic Serverを再起動します。

3.4.2 認証プロバイダとしてのMicrosoft Active Directoryの再構成

この手順は、Microsoft Active Directoryを使用するよう、Oracle Business Intelligenceインストールを再構成する方法を示します。

この項のデータ例では、内部ユーザー用にOracle Business IntelligenceのSSOを設定するXYZ Corporationという架空の企業を使用します。

この例では、次の情報が使用されます。

  • Active Directoryドメイン

    XYZ Corporationには、xyzcorp.comというActive Directoryドメインがあり、このドメインはすべての内部ユーザーを認証します。この企業ネットワークにログインすると、ログイン先はこのActive Directoryドメインになります。ドメイン・コントローラはaddc.xyzcorp.comで、これによってActive Directoryドメインが制御されます。

  • Oracle BI EE WebLogicドメイン

    XYZ Corporationでは、bieesvr1.xyz2.comというネットワーク・サーバー・ドメインに、bi(デフォルト名)というWebLogicドメインがインストールされています。

  • システム管理者およびテスト・ユーザー

    次のシステム管理者およびドメイン・ユーザーが構成のテストを行います。

    • システム管理者ユーザー

      Jo Smith (login=jsmith、hostname=xyz1.xyzcorp.com)

    • ドメイン・ユーザー

      Bob Jones (login=bjones hostname=xyz47.xyzcorp.com)

認証プロバイダとしてActive Directoryを再構成するには:

  1. Oracle WebLogic Server管理コンソールにログインし、「チェンジ・センター」で「ロックして編集」をクリックします。

    詳細は、第1.6.1項「Oracle WebLogic Server管理コンソールの使用」を参照してください。

    wls01.gifの説明が続きます
    「wls01.gif」の説明

  2. 左ペインで「セキュリティ・レルム」を選択し、「myrealm」をクリックします。

    デフォルトのセキュリティ・レルムはmyrealmという名前です。

  3. 「プロバイダ」タブを表示し、「認証」サブタブを表示します。

    wls03.gifの説明が続きます
    「wls03.gif」の説明

  4. 「新規」をクリックし、「新しい認証プロバイダの作成」ページを起動します。

    このスクリーンショットまたは図については、周囲のテキストで説明しています。

  5. 「新しい認証プロバイダの作成」ページで、次のように値を入力します。

    • 名前: 認証プロバイダの名前を入力します。例: ADAuthenticator。

    • タイプ: リストから、「ActiveDirectoryAuthenticator」を選択します。

    • 「OK」をクリックし、変更を保存して、新しい認証プロバイダで更新された認証プロバイダ・リストを表示します。

      このスクリーンショットまたは図については、周囲のテキストで説明しています。

  6. 「名前」列で「DefaultAuthenticator」をクリックし、「設定」ページを表示します。

  7. 「共通認証プロバイダ設定」ページで、「制御フラグ」を「REQUIRED」から「SUFFICIENT」に変更し、「保存」をクリックします。

    詳細は、第3.4.8項「JAAS制御フラグ・オプションの設定」を参照してください。

  8. 認証プロバイダの表の「名前」列で「ADDirectory」をクリックし、「設定」ページを表示します。

  9. 「構成」→「共通」タブを表示し、「制御フラグ」リストで「SUFFICIENT」を選択して「保存」をクリックします。

    このスクリーンショットまたは図については、周囲のテキストで説明しています。

  10. 「プロバイダ固有」タブを表示し、Active Directory LDAP認証ストアへの接続に適用するオプションにアクセスします。

  11. 「プロバイダ固有」タブを使用して、次の値を指定します。

    セクション名 フィールド名 説明
    接続 ホスト Active Directoryサーバーaddc.xyzcorp.comの名前。
    接続 ポート Active Directoryサーバーがリスニングしているポート番号(389)。
    接続 プリンシパル LDAPユーザーの情報を取得する際、Active Directoryに接続するユーザーのLDAP DN。例: cn=jsmith、cn=users、dc=us、dc=xyzcorp、dc=com。
    接続 資格証明/資格証明の確認 プリンシパルのパスワード(welcome1など)。
    グループ グループ・ベースDN AD内でグループの検索に使用するLDAP問合せ。

    注意: このパスの下に定義されているグループのみをWebLogicに表示できます。

    (CN=Builtin、DC=xyzcorp、DC=com)
    ユーザー ユーザー・ベースDN AD内でユーザーの検索に使用するLDAP問合せ。CN=Users、DC=xyzcorp、DC=com
    ユーザー ユーザー名属性 AD内でユーザー名の指定に使用する属性。デフォルト値はcnです。

    ユーザー名に別の属性を使用するようにActive Directoryが構成されていることがわかっている場合以外は、この値を変更しないでください。変更する場合は、第3.4.3.1項「ユーザー名属性の構成」を参照してください。
    ユーザー すべてのユーザーのフィルタ LDAP検索フィルタ。詳細は、「詳細」をクリックします。
    ユーザー 名前指定によるユーザー・フィルタ LDAP検索フィルタ。AD内でデフォルトで空白です。詳細は、「詳細」をクリックします。
    ユーザー ユーザー・オブジェクト・クラス ユーザーの名前。
    ユーザー 取得したユーザー名をプリンシパルとして使用する LDAPサーバーから取得されるユーザー名が、サブジェクトのプリンシパルとして使用されるかどうかを指定します。詳細は、「詳細」をクリックします。

    大文字小文字を統一できるので、このチェック・ボックスは選択することをお薦めします。たとえば、LDAPユーザー名がJSmithである場合、jsmith (小文字のみ)でログインした場合でも、プリンシパルはJSmith (大文字小文字混合)になります。これはつまり、グループを間接的に介すのではなく、ユーザーに直接付与されるアプリケーション・ロール・メンバーシップが認証時に一貫して適用されるということです。

    Oracle WebLogic Serverでの認証プロバイダの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』を参照してください。

  12. (オプション)ユーザー名属性またはグループ名属性がMicrosoft Active Directoryの'cn'以外の値に構成されている場合、Oracle WebLogic Server管理コンソールの対応する値を変更する必要があります。

    詳細は、第3.4.3項「アイデンティティ・ストアでのユーザーおよびグループ名属性の構成」を参照してください。


    注意:

    WebLogicで提供されているLDAP認証プロバイダ(OracleInternetDirectoryAuthenticatorおよびActiveDirectoryAuthenticatorを含む)は通常、'cn'をユーザー名およびグループ名の属性として使用するようにデフォルトで設定されています。ユーザー名に対して代替属性('uid'や'mail'など)の使用が必要になることはよくありますが、別のグループ名属性の使用が必要になることはあまり一般的ではありません。

  13. 「保存」をクリックします。

  14. メインの「myrealmの設定」ページで「プロバイダ」タブを表示し、「認証」サブタブを表示します。

  15. 「並替え」をクリックし、「認証プロバイダの並替え」ページを表示します。

  16. 「ADDirectory」を選択し、矢印ボタンを使用してこれをリストの最初に移動し、「OK」をクリックします。

  17. チェンジ・センターで、変更のアクティブ化をクリックします。

  18. Oracle WebLogic Serverを再起動します。

3.4.3 アイデンティティ・ストアでのユーザーおよびグループ名属性の構成

OracleInternetDirectoryAuthenticatorおよびActiveDirectoryAuthenticatorを含め、WebLogicで提供されているLDAP認証プロバイダは通常、'cn'をユーザー名およびグループ名の属性として使用するようにデフォルトで設定されています。ユーザー名に対して代替属性('uid'や'mail'など)の使用が必要になることはよくありますが、別のグループ名属性の使用が必要になることはあまり一般的ではありません。この項では、両属性の再構成の方法について説明します。

このトピックには、次の項が含まれています。

3.4.3.1 ユーザー名属性の構成

この項では、mailをユーザー名属性として使用するためなど、OracleInternetDirectoryAuthenticatorを再構成する方法について説明します。

図3-2に、値mailで構成された「ユーザー名属性」を示します。

図3-2 例: 「プロバイダ固有」タブ - ユーザー属性

図3-2の説明が続きます
「図3-2 例: 「プロバイダ固有」タブ - ユーザー属性」の説明

代替認証プロバイダのUserNameAttributeは、通常、cnの値に設定されています。このように設定されていない場合、AllUsersFilterおよびUserFromNameFilterの設定が表3-1のとおり正しく構成されていることを確認する必要があります。表3-1は、デフォルトの設定(cnの値を使用)および、必要となる新しい設定(属性AnOtherUserAttributeで新しい値を使用)を示しています。

表3-1 ユーザー名属性の変更

属性名 デフォルト設定 必要となる新しい設定

UserNameAttribute

cn

AnOtherUserAttribute

AllUsersFilter

(&(cn=*)(objectclass=person))

(&(AnOtherUserAttribute =*)(objectclass=person))

UserFromNameFilter

(&(cn=%u)(objectclass=person))

(&(AnOtherUserAttribute =%u)(objectclass=person))

「プロバイダ固有」タブで、表3-1を使用して変更を行います(AnOtherGroupAttribute設定を独自の値で置換します)。「プロバイダ固有」タブの表示方法の詳細は、第3.4項「代替認証プロバイダを使用するためのOracle Business Intelligenceの構成」を参照してください。

3.4.3.2 グループ名属性の構成

この項では、cn以外のグループ名を使用するために、ActiveDirectoryAuthenticatorを再構成する方法について説明します。

図3-3に、グループ設定を示します。

図3-3 例: 「プロバイダ固有」タブ - グループ属性

図3-3の説明が続きます
「図3-3 例: 「プロバイダ固有」タブ - グループ属性」の説明

たとえば、アクティブ・ディレクトリ・サーバーのグループ名がデフォルト値"cn"以外の値に設定されている場合、変更する必要があります。この値を変更する場合、表3-2に示すとおり、AllGroupsFilterおよびGroupFromNameFilterの値も変更する必要があります(例は、AnOtherGroupAttributeという属性に保存されているグループ名を示しています)。

表3-2 グループ名属性の変更

属性名 デフォルト設定 必要となる新しい設定

StaticGroupNameAttribute/DynamicGroupNameAttribute

cn

AnOtherGroupAttribute

AllGroupsFilter

(&(cn=*)(objectclass=person))

(&(AnOtherGroupAttribute =*)(objectclass=person))

GroupFromNameFilter

(&(cn=%u)(objectclass=person))

(&(AnOtherGroupAttribute =%u)(objectclass=person))

「プロバイダ固有」タブで、表3-2を使用して変更を行います(AnOtherGroupAttribute設定を独自の値で置換します)。「プロバイダ固有」タブの表示方法の詳細は、第3.4.2項「認証プロバイダとしてのMicrosoft Active Directoryの再構成」を参照してください。

3.4.4 認証プロバイダとしてのLDAPの構成とデータベースへのグループの格納

この項では、LDAPアイデンティティ・ストアに対して認証を行うようにOracle Business Intelligenceを構成し、グループ情報をデータベースに格納する方法について説明します。この項の例では、Oracle Internet Directory (OID LDAP)およびサンプル・データベース・スキーマを使用します。ただし、OID LDAPをLDAPアイデンティティ・ストアとして使用したり、サンプルと同じデータベース・スキーマを使用したりする必要はありません。

Oracle Business Intelligenceでは、この方法の使用を可能にする、BISQLGroupProviderというWebLogic Server用の認証プロバイダが提供されます。この認証プロバイダでは、エンド・ユーザーの資格証明は認証されませんが、データベース表に保持された外部のグループ・メンバーシップを認証済ユーザーのIDに提供できます。

この項には次のトピックが含まれます:

3.4.4.1 前提条件

この項の説明に従ってLDAP認証の構成を試みる前に、次の前提条件を満たす必要があります。

  • Oracle Business Intelligence Enterprise Editionリリース12.2.1.0 (またはそれ以降)がインストールされ、稼動している必要があります。

  • Oracle BI EE 12.2.1.0システムにすべての関連するパッチを適用する必要があります。

  • 必要なグループを含む1つ以上の表が格納された適切なデータベース・スキーマ、およびそれらのグループをLDAPによって認証されるユーザーの名前にマップするマッピング表が稼動していて、Oracle BI EEが稼動するWebLogic Serverからアクセスできる必要があります。

  • ユーザーを格納するアイデンティティ・ストアとして使用するために、サポートされているLDAPサーバーが構成に含まれている必要があります。

  • Oracle Business Intelligenceからアプリケーション・ロールのメンバーにコンテンツを配信する必要がある場合、次の制約が適用されます。

    • ペアにできるのは、単一のLDAP認証プロバイダと単一のBISQLGroupProviderのみです。

      複数のLDAP認証プロバイダを構成し、BISQLGroupProviderからグループ・メンバーシップを取得する必要がある場合、コンテンツをアプリケーション・ロールのすべてのメンバーに配信できません。この構成では、Oracle BIデリバーでユーザーおよびグループ・メンバーシップに基づいてアプリケーション・ロールのメンバーシップを解決できません。

    • 複数のアイデンティティ・ストアで同じグループは定義できません。

      LDAPおよびデータベース・グループ表の両方で同じ名前のグループを使用できません。これを行った場合、Oracle BIデリバーによって呼び出されるセキュリティ・コードでアプリケーション・ロールのメンバーシップを解決できなくなります。

3.4.4.2 グループおよびグループ・メンバーのサンプル・スキーマの作成

ここで説明するサンプル・スキーマは意図的に単純化されており、スキーマを使用するようOracle Business Intelligenceを構成する方法についてのみ説明します。

サンプル・スキーマの名前はACME_BI_GROUPSで、2つの表と1つのビューで構成されます。外部グループのリストが定義されるGROUPS表、GROUPMEMBERS表、プライマリ・アイデンティティ・ストア内に存在するユーザーのグループ・メンバーシップが記述されるGROUPMEMBERS_VWビューです。

図3-4と同じ表(またはビュー)を定義することの利点は、BISQLGroupProviderの構成で、表3-3に概説されたデフォルトのSQLを使用できることです。

図3-4には、表GROUPSおよびGROUPMEMBERSと、ビューGROUPMEMBERS_VWが示されています。

図3-4 グループおよびグループ・メンバーのサンプル・スキーマ

周囲のテキストで図3-4を説明しています。

LDAPストア内のユーザーを、データベース表のグループにログイン名でマップする必要があります。図3-4では、GROUPMEMBERS表のG_MEMBERの値が、LDAP認証プロバイダに指定されているように、ログインに使用されるLDAP属性の値(uid、cn、mailなど)と一致する必要があります。たとえば、ログイン属性がmailのときに、データベース・グループをuidでマップしないようにする必要があります。GROUPMEMBERS表とGROUPS表間の外部結合を使用してGROUPMEMBERS_VWビューを作成します。

3.4.4.3 Oracle WebLogic Server管理コンソールの使用によるデータ・ソースおよびBISQLGroupProviderの構成

Oracle WebLogic Server管理コンソールを使用して、データ・ソースとBISQLGroupProviderを次のように構成します。

3.4.4.3.1 Oracle WebLogic Serverの使用によるプライマリ・アイデンティティ・ストアとしてのOracle Internet Directoryの構成

リンク先の手順に従って、ユーザー移入をOID LDAPに対して認証するようにWebLogicを構成できます。

詳細は、第3.4.1項「認証プロバイダとしてのOracle Internet Directoryの再構成」を参照してください。


注意:

このタスクの手順に従うときに、OID LDAP認証プロバイダの「プロバイダ固有」構成ページに表示される「ユーザー・ベースDN」および「ユーザー名属性」の値をメモしておいてください。これらの値は、後の手順で必要になります。詳細は、第3.4.4.4.3項「グループ情報を取得するためのデータベース・アダプタの構成」を参照してください。

3.4.4.3.2 BISQLGroupProviderのインストール

BISQLGroupProvider認証プロバイダを構成する前に、まず認証プロバイダが格納されたJARファイルbi-sql-group-provider.jarをインストールする必要があります。ファイルは次の場所にあります。

ORACLE_HOME/bi/plugins/security/bi-sql-group-provider.jar

ファイルを次の場所にコピーする必要があります。

ORACLE_HOME/wlserver/server/lib/mbeantypes

ファイルを指定された場所にコピーした後、管理サーバーを再起動して、使用可能な認証プロバイダのリストに新しいプロバイダが表示されるようにする必要があります。


注意:

エンタープライズ・インストールを実行してクラスタ環境を作成した場合、そのインストールでは、スケールが拡大された管理対象サーバーを再起動できません。これは、bi-sql-group-provider.jarファイルが使用できないためです。インストール中にこの状況が発生した場合は、JARファイルを正しい場所にコピーし、インストーラで「再試行」をクリックします。

3.4.4.3.3 Oracle WebLogic Server管理コンソールの使用によるデータ・ソースの構成

Oracle WebLogic Server管理コンソールを使用してデータ・ソースを構成するには:

  1. Oracle WebLogic Server管理コンソールにログインし、「チェンジ・センター」で「ロックして編集」をクリックします。

    詳細は、第1.6.1項「Oracle WebLogic Server管理コンソールの使用」を参照してください。

  2. 左ペインで「サービス」をクリックし、「データ・ソース」をクリックします。

  3. データ・ソースの概要ページで「新規」をクリックし、「汎用データ・ソース」を選択します。

  4. 「JDBCデータ・ソースのプロパティ」ページで、次のプロパティの値を入力または選択します。

    • 名前: たとえば、BIDatabaseGroupDSと入力します。

      基礎となる構成ファイル(config.xml)およびOracle WebLogic Server管理コンソール全体で、このデータ・ソースを参照するときに必ず使用される名前。

    • JNDI名: たとえば、jdbc/BIDatabaseGroupDSと入力します。

      このJDBCデータ・ソースのバインド先のJNDIパス。

    • データベース・タイプ: たとえば、「Oracle」を選択します。

      接続先のデータベースのDBMS。

  5. 「次へ」をクリックします。

  6. 「データベース・ドライバ」ドロップダウン・リストからデータベース・ドライバを選択します。

    たとえば、Oracleのサービス接続用ドライバ(Thin)、バージョン9.0.1以降を選択します。


    注意:

    Oracleデータベースを使用している場合は、Oracleのサービス接続用ドライバ(Thin)、リリース9.0.1以降を選択します。

  7. 「次へ」をクリックします。

  8. 「次へ」をクリックします。

  9. 「 接続プロパティ 」ページで、次のプロパティの値を入力します。

    • データベース名: たとえば、ora11gと入力します。

      接続先のデータベースの名前。

    • ホスト名: たとえば、mymachine.example.comと入力します。

      データベースのホストとなるサーバーのDNS名またはIPアドレス。


      注意:

      クラスタを使用する場合は、localhostを使用しないでください。

    • Port: たとえば、1521と入力します。

      データベース・サーバーが接続リクエストをリスニングするポート。

    • データベース・ユーザー名

      一般には、第3.4.4.2項で定義される表のスキーマ所有者。

      たとえば、MYUSERと入力します。

    • 「パスワード」/「パスワードの確認」

      「データベース・ユーザー名」用のデータベース・パスワード。

      たとえば、mypasswordと入力します。

  10. 「次へ」をクリックします。

  11. ページの内容が正しいことを確認して、「構成のテスト」をクリックします。

  12. 「次へ」をクリックします。

  13. 「ターゲットの選択」ページで、デプロイ先のデータ・ソースのサーバーまたはクラスタを選択します。

    管理サーバーおよび管理対象サーバーをターゲットとして選択する必要があります。次に例を示します。

    • 「サーバー」ペイン:

      「AdminServer」オプションを選択します。

    • 「クラスタ」ペイン:

      「bi_server1」チェック・ボックスを選択し、クラスタにデプロイします(この操作は簡易インストールには適用されません)。

  14. 「終了」をクリックします。

  15. チェンジ・センターで、変更のアクティブ化をクリックします。


注意:

この例で使用するデータベースの名前はBIDatabaseGroupDSです。

3.4.4.3.4 Oracle WebLogic Server管理コンソールの使用によるBISQLGroupProvider SQL認証プロバイダの構成

このタスクでは、第3.4.4.2項「グループおよびグループ・メンバーのサンプル・スキーマの作成」で概説した例の表の構造を使用し、BIDatabaseGroupDSデータ・ソースに対してBISQLGroupProviderを作成する方法について説明します。構造が例と異なる場合は、使用するSQL文(表や列名)の変更が必要になる可能性があります。


注意:

データベースにはユーザーに関連付けられるグループが格納されるのみであるため、データベースに対する認証はありません。認証はLDAPに対して発生し、Oracle WebLogic Server管理コンソールでBISQLGroupProviderによってグループがアプリケーション・ロールに割り当てられたときに、データベースが公開されます。

Oracle WebLogic Server管理コンソールを使用してBISQLGroupProvider SQL認証プロバイダを構成するには:

  1. Oracle WebLogic Server管理コンソールにWebLogic管理者としてログインし、チェンジ・センターで「ロックして編集」をクリックします。

    詳細は、第1.6.1項「Oracle WebLogic Server管理コンソールの使用」を参照してください。

    wls01.gifの説明が続きます
    「wls01.gif」の説明

  2. 左ペインで「セキュリティ・レルム」を選択し、「myrealm」をクリックします。

    デフォルトのセキュリティ・レルムはmyrealmという名前です。

  3. 「プロバイダ」タブを表示し、「認証」サブタブを表示します。

    wls03.gifの説明が続きます
    「wls03.gif」の説明

  4. 「新規」をクリックし、「新しい認証プロバイダの作成」ページを起動します。

    このスクリーンショットまたは図については、周囲のテキストで説明しています。

  5. 「新しい認証プロバイダの作成」ページで、次のように値を入力します。

    • 名前: 認証プロバイダの名前を入力します。たとえば、MySQLGroupProviderと入力します。

    • タイプ: リストから、「BISQLGroupProvider」を選択します。

    • 「OK」をクリックし、変更を保存して、新しい認証プロバイダで更新された認証プロバイダ・リストを表示します。

      このスクリーンショットまたは図については、周囲のテキストで説明しています。

  6. 認証プロバイダの表の「名前」列で「MySQLGroupProvider」をクリックし、「設定」ページを表示します。

  7. 「プロバイダ固有」タブを表示して、データベース表に対して問合せおよび認証を行うために使用するSQL文を指定します。

  8. 「データ・ソース名」を指定します。これはデータ・ソース名ではなく、JNDI名である必要があります。たとえば、jdbc/BIDatabaseGroupDSです。

    表3-3は、第3.4.4.2項で概説したサンプル・スキーマのSQL文を示しています。

    表3-3 サンプル・スキーマのSQL文

    問合せ SQL 注意

    SQL - グループのリスト

    SELECT G_NAME FROM GROUPS WHERE G_NAME LIKE ?

    ワイルドカードに一致するグループ名を取得するためのSQL文。このSQL文にはグループ名のパラメータが1つ必要です。一致したグループを格納したresultSetが戻されます。

    SQL - グループが存在するかどうか

    SELECT G_NAME FROM GROUPS WHERE G_NAME = ?

    グループをルックアップするためのSQL文。このSQL文にはグループ名のパラメータが1つ必要です。グループを含む最大1つのレコードを格納したresultSetを返します。

    SQL - メンバーかどうか

    SELECT G_MEMBER FROM GROUPMEMBERS WHERE G_NAME = ?AND G_MEMBER = ?

    グループのメンバーをルックアップするためのSQL文。このSQL文には2つのパラメータ(グループ名とメンバーまたはグループ名)が必要です。一致するグループ名を格納したresultSetが戻されます。

    SQL - メンバー・グループのリスト

    SELECT G_NAME FROM GROUPMEMBERS WHERE G_MEMBER = ?

    ユーザーまたはグループが属しているグループをルックアップするためのSQL文。このSQL文にはユーザー名またはグループ名のパラメータが1つ必要です。一致するグループの名前を格納したresultSetを戻します。

    SQL - グループの説明の取得(「サポートされている説明」が有効な場合)

    SELECT G_DESCRIPTION FROM GROUPS WHERE G_NAME = ?

    グループの説明を取得するためのSQL文。「サポートされている説明」が有効になっている場合にのみ有効です。このSQL文にはグループ名のパラメータが1つ必要です。グループの説明を含む最大1つのレコードを格納したresultSetが戻されます。


    注意:

    異なる表構造を使用する場合は、これらのSQL文(表および列の名前)を独自のスキーマに合せて変更する必要がある場合があります。また疑問符(?)を、(ユーザー名やグループ名をハードコードするかわりに)ランタイム問合せのプレースホルダとして維持する必要もあります。

    Oracle WebLogic Serverでの認証プロバイダの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』を参照してください。

  9. 必要なすべてのSQL文を、使用する認証プロバイダに入力します。

    SQLでは大/小文字が区別されます。

  10. 「保存」をクリックします。

  11. 次の手順に従って認証プロバイダを並べ替えます。

    1. 「プロバイダ」タブを表示します。

    2. 「並替え」をクリックし、「認証プロバイダの並替え」ページを表示します。

    3. 「BISQLGroupProvider」を選択し、矢印ボタンを使用してこれをリストの最初に移動します。

    4. 「OK」をクリックして変更内容を保存します。

  12. 次の手順を実行し、BISQLGroupProviderの「制御フラグ」設定を構成します。

    1. メインの「myrealmの設定」ページで、「プロバイダ」タブ→「認証」サブタブを表示し、「BISQLGroupProvider」を選択して、その構成ページを表示します。

    2. 「構成」→「共通」タブを表示し、「制御フラグ」リストで「OPTIONAL」を選択します。

      詳細は、第3.4.8項「JAAS制御フラグ・オプションの設定」を参照してください。

    3. 「保存」をクリックします。

  13. チェンジ・センターで、変更のアクティブ化をクリックします。

  14. (管理サーバーが再起動したらFusion Middleware Controlを使用して) Oracle Business Intelligenceコンポーネント、Oracle WebLogic Serverおよび管理対象サーバーを再起動します。


注意:

「ユーザーとグループ」タブをチェックして、データベースのユーザーとグループが表示されていることを確認します。

3.4.4.4 仮想アイデンティティ・ストアの構成

仮想アイデンティティ・ストアを次のように構成します。

3.4.4.4.1 アイデンティティ・ストアの構成による仮想化の有効化

アイデンティティ・ストアを構成して仮想化を有効にすることにより、アイデンティティ・ストア・サービスで複数のアイデンティティ・ストアを使用できるようになり、ユーザー・プロファイル情報を様々な認証プロバイダ(アイデンティティ・ストア)に分散できます。

詳細は、第3.4.6項「Fusion Middleware Controlを使用したアイデンティティ・ストアの仮想化の構成」を参照してください。

3.4.4.4.2 LDAPに対するSSLの構成

SSL(一方向SSLのみ)で通信するためにLDAP認証プロバイダを構成した場合、仮想化(libOVD)機能で使用される追加キーストアに、該当するLDAPサーバーのルート証明書を配置する必要があります。

詳細は、第5.14.2項「複数認証プロバイダ使用時のSSLの構成」を参照してください。

3.4.4.4.3 グループ情報を取得するためのデータベース・アダプタの構成

LDAPサーバーのように表示されるようデータベース・アダプタを構成します。これにより、仮想アイデンティティ・ストア・プロバイダは、そのデータベース・アダプタを使用してグループ情報をデータベースから取得できます。

グループ情報を取得するようデータベース・アダプタを構成するには:

このタスクは、データベース表をアイデンティティ・ストアとして使用し、グループをマップする方法を指定する、アダプタ・テンプレートを編集して適用する方法を示しています。

  1. bi_sql_groups_adapter_template.xmlという名前のファイルを作成します。

    このファイルは、GROUPMEMBERS_VWビューから仮想LDAPストアへのマッピングを記述します。このビューでは外部結合を使用して、複数の表のフィールドをデータベース・アダプタで参照できるようにします。

  2. ファイルに次の内容が含まれていることを確認します。


    注意:

    次の太字で示しているセクションは、独自の表と列の属性がLDAPサーバーの属性と一致するように変更する必要があります。ここに示す例は、第3.4.4項全体で使用するサンプル・スキーマのものです。


    注意:

    要素: <param name="ReplaceAttribute" value="uniquemember={cn=%uniquemember%,cn=users,dc=oracle,dc=com}"/>の場合

    これはメイン認証プロバイダのユーザー属性およびルート・ユーザーDNと一致する必要があります。たとえば、デフォルトの認証プロバイダの場合は次のとおりです。

    uid=%uniquemember%,ou=people,ou=myrealm,dc=bifoundation_domain

    		 

    <?xml version = '1.0' encoding = 'UTF-8'?>
<adapters schvers="303" version="1" xmlns="http://www.octetstring.com/schemas/Adapters" xmlns:adapters="http://www.w3.org/2001/XMLSchema-instance">
   <dataBase id="directoryType" version="0">
      <root>%ROOT%</root>
      <active>true</active>
      <serverType>directoryType</serverType>
      <routing>
         <critical>true</critical>
         <priority>50</priority>
         <inclusionFilter/>
         <exclusionFilter/>
         <plugin/>
         <retrieve/>
         <store/>
         <visible>Yes</visible>
         <levels>-1</levels>
         <bind>true</bind>
         <bind-adapters/>
         <views/>
         <dnpattern/>
      </routing>
      <pluginChains xmlns="http://xmlns.oracle.com/iam/management/ovd/config/plugins">
         <plugins>
            <plugin>
               <name>VirtualAttribute</name>
               <class>oracle.ods.virtualization.engine.chain.plugins.virtualattr.VirtualAttributePlugin</class>
               <initParams>
                  <param name="ReplaceAttribute" value="uniquemember={cn=%uniquemember%,cn=users,dc=oracle,dc=com}"/>
               </initParams>
            </plugin>
         </plugins>
         <default>
            <plugin name="VirtualAttribute"/>
         </default>
         <add/>
         <bind/>
         <delete/>
         <get/>
         <modify/>
         <rename/>
      </pluginChains>
      <driver>oracle.jdbc.driver.OracleDriver</driver>
      <url>%URL%</url>
      <user>%USER%</user>
      <password>%PASSWORD%</password>
      <ignoreObjectClassOnModify>false</ignoreObjectClassOnModify>
      <includeInheritedObjectClasses>true</includeInheritedObjectClasses>
      <maxConnections>10</maxConnections>
      <mapping>
         <joins/>
         <objectClass name="groupofuniquenames" rdn="cn">
            <attribute ldap="cn" table="GROUPMEMBERS_VW" field="G_NAME" type=""/>
            <attribute ldap="description" table="GROUPMEMBERS_VW" field="G_NAME" type=""/>
            <attribute ldap="uniquemember" table="GROUPMEMBERS_VW" field="G_MEMBER" type=""/>
         </objectClass>
      </mapping>
      <useCaseInsensitiveSearch>true</useCaseInsensitiveSearch>
      <connectionWaitTimeout>10</connectionWaitTimeout>
      <oracleNetConnectTimeout>0</oracleNetConnectTimeout>
      <validateConnection>false</validateConnection>
   </dataBase>
</adapters>

  3. 次の要素について、太字で示した適切なセクションをカスタマイズします。

    • ReplaceAttribute

      グループで一意のメンバーを定義する方法を指定します(%uniquemember%は、ユーザーがグループのメンバーかどうかをルックアップする際の実行時に渡される値のプレースホルダ)

      この要素について変更する唯一の点は、ユーザーのルートの指定です。概念的には、libovdadapterconfigスクリプトをステップ10で実行する際にユーザー移入のルートとして指定するものにデフォルトで一致する必要があります。

    • groupofuniquenenames

      グループ属性がデータベース・フィールドにどのようにマップされるかを指定します。

      次の属性をマップする必要があります。

      • cn (グループの一意の名前にマップする)

      • uniquemember (データベース・スキーマのユーザー/グループ・マッピング表におけるユーザーの一意の名前にマップする

      次の属性のマップはオプションです。

      • descriptionはオプション(ただし明らかに有用な情報です)

      その他の属性は、ユーザーは構成できません。

  4. アダプタ・ファイルを次のフォルダにコピーします。

    ORACLE_HOME/oracle_common/modules/oracle.ovd/templates/

  5. 次の場所でコマンド・プロンプトまたはターミナルを開きます。

    ORACLE_HOME/oracle_common/bin

  6. 次の環境変数のように設定されていることを確認します。

    • ORACLE_HOME=oraclehome

    • WL_HOME=ORACLE_HOME/wlserver/

    • JAVA_HOME=ORACLE_HOME/jdk/jre

  7. libovdadapterconfigスクリプトを実行し、テンプレート・ファイルからデータベース・アダプタを作成します。次に構文を示します。

    libovdadapterconfig -adapterName <name of adapter> -adapterTemplate <name (NOT including path) of template file which defines adapater> -host localhost -port <Admin Server port> -userName <user id of account which has administrative privileges in the domain> -domainPath <path to the BI domain> -dataStore DB -root <nominal specification of a pseudo-LDAP query to treat as the "root" of this adapter - must match that specified in template for adapter 2 above> -contextName default -dataSourceJNDIName <JNDI name for DataSource which points at the database being mapped>

    例:

    ./libovdadapterconfig.sh -adapterName biSQLGroupAdapter -adapterTemplate bi_sql_groups_adapter_template.xml -host localhost -port 7001 -userName weblogic -domainPath /opt/oracle_bi/user_projects/domains/bifoundation_domain/ -dataStore DB -root cn=users,dc=oracle,dc=com -contextName default -dataSourceJNDIName jdbc/BIDatabaseGroupDS

    注意:

    dataSourceJNDINameは単なるDS名ではなく、JNDI名である必要があります。


    注意:

    rootパラメータの値は、アダプタ・テンプレートの<param name="replaceattribute"要素に指定されたroot dnと一致する必要があります。たとえば、デフォルトの認証プロバイダにユーザーが指定されている場合、rootは通常ou=people, ou=myrealm, dc=bifoundation_domainに設定されます。

    スクリプトはエラーなしで終了する必要があります。

  8. WebLogic管理サーバーおよび管理対象サーバーを再起動します。


    注意:

    WebLogicを起動するときに次の警告が表示されますが、これは無視できます。「警告: BISQLGroupsProvider: 接続プールが使用できません。」

    これで、データベースに格納された資格証明を使用して、WebLogicおよびOracle Business Intelligenceにログインできるはずです。

3.4.4.5 アプリケーション・ロールへのデータベース・グループの追加による構成のテスト

アプリケーション・ロールにデータベース・グループを追加することによって構成をテストするには:

  1. Fusion Middleware Controlにログインし、ページの左側にあるナビゲーション・メニューでWebLogicドメインを開き、bifoundation_domainを開きます。

    詳細は、第1.6.2項「Oracle Fusion Middleware Controlの使用」を参照してください。

  2. 「bifoundation_domain」を右クリックして「セキュリティ」→「アプリケーション・ロール」を選択し、「アプリケーション・ロール構成」ページを表示します。

  3. LDAPユーザーを含むデータベース・グループを、ユーザーに現在アクセス権が付与されていない、いずれかのアプリケーション・ロール(BIServiceAdministratorなど)に追加します。

  4. アプリケーション・ロールに新しく追加されたグループのメンバーであるユーザーとして、Oracle Business Intelligenceにログインします。

    ページの右上に、「<user id>としてログイン」というテキストが表示されます。

  5. ユーザーIDをクリックしてドロップダウン・メニューを表示します。

  6. メニューから「マイ・アカウント」を選択します。

  7. 「ロールおよびカタログ・グループ」タブを表示し、ユーザーに新しいアプリケーション・ロールが割り当てられていることを確認します。

3.4.4.6 アダプタのエラーの修正

既存のデータベース・アダプタは修正しないでください。アダプタの作成で使用するテンプレートやlibovdadapterコマンドでエラーが発生した場合は、アダプタを削除してから再作成する必要があります。

詳細は、第3.4.5.6項「アダプタの削除および再作成によるデータベース・アダプタ・エラーの修正」を参照してください。

3.4.5 認証プロバイダとしてのデータベースの構成

この項では、SQLAuthenticatorおよび仮想アイデンティティ・ストア・データベース・アダプタを使用することで、データベースを認証プロバイダとして使用するようにOracle Business Intelligenceを構成する方法について説明します。この項の内容は次のとおりです。

3.4.5.1 概要と前提条件

ユーザー・ロールとプロファイル情報は、データベースをLDAPサーバーのように表示できるアダプタを使用してデータベースに格納できます。仮想アイデンティティ・ストア・プロバイダは、このデータベース・アダプタを介してユーザー・プロファイル情報をデータベースから取得できます。

ここで説明するデータベース認証の方法は、リリース11.1.1.5 (またはそれ以降)でのみ使用可能です。それ以前のリリースでは初期化ブロックを使用する必要があります。

このトピックでは、SQLAuthenticatorおよび仮想アイデンティティ・ストア・プロバイダ(データベース・アダプタを含む)を使用するようにOracle Business Intelligenceを構成する方法について説明します。両方とも適切なデータベース・スキーマに対して実行します。ここに示す例は説明のためのものであり、実際のデータベース・スキーマに、ここで説明するサンプルと同じ値を指定してはいけません。

この手順は、ユーザーをデータベース・スキーマに対して認証する必要がある場合に使用します。認証に優先されるアイデンティティ・ストアは、Oracle Internet Directory (OID LDAP)などのLDAPディレクトリ・サービスです。

ここで説明するデータベース認証のアプローチには、それぞれにユーザーおよびパスワードを格納する2つのデータベース列が必要です。データベース・ユーザー・アカウントには基づきません。

Oracle Business Intelligence Enterprise Editionリリース11.1.1.5、11.1.1.6および11.1.1.7(またはそれ以降)がインストールされ、稼働している必要があります。ただし、リリース11.1.1.5および11.1.1.6の場合、Oracle Fusion Middlewareパッチ13826887も適用する必要があります。詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイドのOracle Business Intelligenceシステムのパッチ適用に関する項を参照してください。

3.4.5.2 ユーザーおよびグループのサンプル・スキーマの作成

実際には、以前のOracle BI EEインストールで使用しているユーザー独自のスキーマを使用することになります。ここで説明するサンプル・スキーマは意図的に単純化されており、スキーマを使用するようシステムを構成する方法についてのみ説明します。


注意:

認証に必要なユーザー、資格証明およびグループを含むデータベース・スキーマは、Oracle BI EEが稼動するWebLogic Serverからアクセスできる必要があります。

図3-5には、表USERS、USER_VW、GROUPMEMBERS、GROUPSおよびGROUPMEMBERS_VWが示されており、USER_VWはUSERS表のビューであり、GROUPMEMBERS_VWはGROUPMEMBERS表とGROUPS表を結合したビューです。

図3-5 ユーザーおよびグループのサンプル・スキーマ

周囲のテキストで図3-5を説明しています。

ユーザーまたはグループの情報が複数の表に存在する場合は、USER_VWを削除し、各種情報の表について1つのビューを作成する必要があります。

GROUPS表での外部結合とGROUPMEMBERS表での内部結合を使用してGROUPMEMBERS表とGROUPS表のビュー(GROUPMEMBERS_VWなど)を作成し、ユーザーが割り当てられていない場合でもFusion Middleware Controlでグループを確認できるようにします。図3-5に示すビューをデータベース・アダプタに渡すには、第3.4.5.4.2項「データベース・アダプタの構成」に示す構成を実行する必要があります。

3.4.5.3 Oracle WebLogic Server管理コンソールの使用によるデータ・ソースとSQL認証プロバイダの構成

Oracle WebLogic Server管理コンソールを使用して、データ・ソースとSQL認証プロバイダを次のように構成します。

3.4.5.3.1 Oracle WebLogic Server管理コンソールの使用によるデータ・ソースの構成

Oracle WebLogic Server管理コンソールを使用してデータ・ソースを構成するには:

  1. Oracle WebLogic Server管理コンソールにログインし、「チェンジ・センター」で「ロックして編集」をクリックします。

    詳細は、第1.6.1項「Oracle WebLogic Server管理コンソールの使用」を参照してください。

  2. 左ペインで「サービス」をクリックし、「データ・ソース」をクリックします。

  3. データ・ソースの概要ページで「新規」をクリックし、「汎用データ・ソース」を選択します。

  4. 「JDBCデータ・ソースのプロパティ」ページで、次のプロパティの値を入力または選択します。

    • 名前: たとえば、UserGroupDSと入力します。

      基礎となる構成ファイル(config.xml)および管理コンソール全体で、このデータ・ソースを参照するときに必ず使用される名前。

    • JNDI名: たとえば、jdbc/User GroupDSと入力します。

      このJDBCデータ・ソースのバインド先のJNDIパス。

    • データベース・タイプ: たとえば、「Oracle」を選択します。

      接続先のデータベースのDBMS。

  5. 「次へ」をクリックします。

  6. 「データベース・ドライバ」ドロップダウン・リストからデータベース・ドライバを選択します。

    たとえば、Oracleのサービス接続用ドライバ(Thin)、リリース9.0.1以降を選択します。

  7. 「次へ」をクリックします。

  8. 「次へ」をクリックします。

  9. 「 接続プロパティ 」ページで、次のプロパティの値を入力します。

    • データベース名: たとえば、ora12cと入力します

      接続先のデータベースの名前。

    • ホスト名: たとえば、mymachine.example.comと入力します。

      データベースのホストとなるサーバーのDNS名またはIPアドレス。

    • Port: たとえば、1521と入力します。

      データベース・サーバーが接続リクエストをリスニングするポート。

    • データベース・ユーザー名

      一般には、第3.4.5.2項で定義される表のスキーマ所有者。

    • 「パスワード」/「パスワードの確認」

      「データベース・ユーザー名」用のデータベース・パスワード。

  10. 「次へ」をクリックします。

  11. ページの内容が正しいことを確認して、「構成のテスト」をクリックします。

  12. 「次へ」をクリックします。

  13. 「ターゲットの選択」ページで、データ・ソースのデプロイ先となるサーバーまたはクラスタを選択します。

    管理サーバーおよび管理対象サーバーをターゲットとして選択する必要があります。次に例を示します。

    • 「サーバー」ペイン:

      「AdminServer」チェック・ボックスを選択します。

    • 「クラスタ」ペイン:

      「bi_server1」オプションを選択します。

  14. 「終了」をクリックします。

  15. チェンジ・センターで、変更のアクティブ化をクリックします。

  16. システムを再起動します。

3.4.5.3.2 Oracle WebLogic Server管理コンソールの使用によるSQL認証プロバイダの構成

このタスクを実行することで、適切な権限を付与されたユーザーが、WebLogicデータベース認証プロバイダを使用してOracle WebLogic Server管理コンソールにログインできるようになります。

Oracle WebLogic Server管理コンソールを使用してSQL認証プロバイダを構成するには:

  1. Oracle WebLogic Server管理コンソールにログインし、「チェンジ・センター」で「ロックして編集」をクリックします。

    詳細は、第1.6.1項「Oracle WebLogic Server管理コンソールの使用」を参照してください。

    wls01.gifの説明が続きます
    「wls01.gif」の説明

  2. 左ペインで「セキュリティ・レルム」を選択し、「myrealm」をクリックします。

    デフォルトのセキュリティ・レルムはmyrealmという名前です。

  3. 「プロバイダ」タブを表示し、「認証」サブタブを表示します。

    wls03.gifの説明が続きます
    「wls03.gif」の説明

  4. 「新規」をクリックし、「新しい認証プロバイダの作成」ページを起動します。

    このスクリーンショットまたは図については、周囲のテキストで説明しています。

  5. 「新しい認証プロバイダの作成」ページで、次のように値を入力します。

    • 名前: 認証プロバイダの名前を入力します。たとえば、UserGroupDBAuthenticatorと入力します。

    • タイプ: リストから、「ReadOnlySQLAuthenticator」を選択します。

      これにより読取り専用のSQL認証プロバイダが作成され、WebLogicからデータベースに書き戻されることはありません。

    • 「OK」をクリックし、変更を保存して、新しい認証プロバイダで更新された認証プロバイダ・リストを表示します。

      このスクリーンショットまたは図については、周囲のテキストで説明しています。

  6. 認証プロバイダの表の「名前」列で「UserGroupDBAuthenticator」をクリックし、「設定」ページを表示します。

  7. 「プロバイダ固有」タブを表示し、「データ・ソース名」に、第3.4.5.3.1項で作成したデータ・ソースの名前を入力します。

    たとえば、UserGroupDSです。

  8. 「プロバイダ固有」タブで、データベース表に対して問合せおよび認証を行うために使用するSQL文を指定します。

    表3-4は、第3.4.5.2項で概説したサンプル・スキーマのSQL文を示しています

    表3-4 サンプル・スキーマのSQL文

    問合せ SQL 注意

    SQL - ユーザー・パスワードの取得(認証に使用)

    SELECT U_PASSWORD FROM USERS WHERE U_NAME = ?

    ユーザーのパスワードをルックアップするためのSQL文。このSQL文にはユーザー名のパラメータが1つ必要です。パスワードを含む最大1つのレコードを格納したresultSetが戻されます。

    SQL - ユーザーが存在するかどうか

    SELECT U_NAME FROM USERS WHERE U_NAME = ?

    ユーザーをルックアップするためのSQL文。このSQL文にはユーザー名のパラメータが1つ必要です。ユーザーを含む最大1つのレコードを格納したresultSetが戻されます。

    SQL - ユーザーのリスト

    SELECT U_NAME FROM USERS WHERE U_NAME LIKE ?

    特定のワイルドカード検索に一致するユーザーを取得するためのSQL文。このSQL文にはユーザー名のパラメータが1つ必要です。一致したユーザー名を格納したresultSetが戻されます。

    SQL - グループのリスト

    SELECT G_NAME FROM GROUPS WHERE G_NAME LIKE ?

    ワイルドカードに一致するグループ名を取得するためのSQL文。このSQL文にはグループ名のパラメータが1つ必要です。一致したグループを格納したresultSetが戻されます。

    SQL - グループが存在するかどうか

    SELECT G_NAME FROM GROUPS WHERE G_NAME = ?

    グループをルックアップするためのSQL文。このSQL文にはグループ名のパラメータが1つ必要です。グループを含む最大1つのレコードを格納したresultSetを返します。

    SQL - メンバーかどうか

    SELECT G_MEMBER FROM GROUPMEMBERS WHERE G_NAME=?AND G_MEMBER LIKE ?

    グループのメンバーをルックアップするためのSQL文。このSQL文には2つのパラメータ(グループ名とメンバーまたはグループ名)が必要です。resultSetを返します。

    SQL - メンバー・グループのリスト

    SELECT G_NAME FROM GROUPMEMBERS WHERE G_MEMBER = ?

    ユーザーまたはグループが属しているグループをルックアップするためのSQL文。このSQL文にはユーザー名またはグループ名のパラメータが1つ必要です。一致するグループの名前を格納したresultSetを戻します。

    SQL - ユーザーの説明の取得(「サポートされている説明」が有効な場合)

    SELECT U_DESCRIPTION FROM USERS WHERE U_NAME = ?

    特定のユーザーの説明を取得するためのSQL文。このSQL文にはユーザー名のパラメータが1つ必要です。ユーザーの説明を含む最大1つのレコードを格納したresultSetが戻されます。

    SQL - グループの説明の取得(「サポートされている説明」が有効な場合)

    SELECT G_DESCRIPTION FROM GROUPS WHERE G_NAME = ?

    グループの説明を取得するためのSQL文。「サポートされている説明」が有効になっている場合にのみ有効です。このSQL文にはグループ名のパラメータが1つ必要です。グループの説明を含む最大1つのレコードを格納したresultSetが戻されます。


    注意:

    異なる表構造を使用する場合は、これらのSQL文(表および列の名前)を独自のスキーマに合せて変更する必要がある場合があります。また疑問符(?)を、(ユーザー名やグループ名をハードコードするかわりに)ランタイム問合せのプレースホルダとして維持する必要もあります。

    Oracle WebLogic Serverでの認証プロバイダの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』を参照してください。

  9. 必要なすべてのSQL文を、使用する認証プロバイダに入力します。

    SQLでは大/小文字が区別されます。

  10. パスワード列がプレーンテキストの場合(つまり、「SQL - ユーザー・パスワードの取得」列に対して返された問合せの結果がハッシュ化/暗号化されていない場合)、「プレーンテキスト・パスワードの有効化」オプションを選択します。

    「プレーンテキスト・パスワードの有効化」オプションが選択されていない場合、SQLAuthenticatorではSHA-1(デフォルトの暗号化アルゴリズム)を使用してパスワードがハッシュされていると想定されます。サポートされる暗号化アルゴリズムの詳細は、ベースSQLAuthenticator Mbean PasswordAlgorithm属性に関するドキュメントを参照してください。

  11. 「保存」をクリックします。

  12. 次の手順を実行し、デフォルト認証プロバイダの「制御フラグ」設定を構成します。

    1. メインの「myrealmの設定」ページで、「プロバイダ」タブ→「認証」サブタブを表示し、「DefaultAuthenticator」を選択して、その構成ページを表示します。

    2. 「構成」→「共通」タブを表示し、「制御フラグ」リストで「SUFFICIENT」を選択します。

      詳細は、第3.4.8項「JAAS制御フラグ・オプションの設定」を参照してください。

    3. 「保存」をクリックします。

  13. 次の手順に従って認証プロバイダを並べ替えます。

    1. 「プロバイダ」タブを表示します。

    2. 「並替え」をクリックし、「認証プロバイダの並替え」ページを表示します。

    3. 「UserGroupDBAuthenticator」を選択し、矢印ボタンを使用してこれをリストの最初に移動します。

    4. 「OK」をクリックして変更内容を保存します。

  14. チェンジ・センターで、変更のアクティブ化をクリックします。

  15. (管理サーバーが再起動したらFusion Middleware Controlを使用して) Oracle Business Intelligenceコンポーネント、Oracle WebLogic Serverおよび管理対象サーバーを再起動します。

  16. 信頼できるシステム・ユーザーの資格証明をポイントするように資格証明ストアの資格証明を置換して、このシステム・ユーザーがデータベースに存在することを確認するには、第3.5項「BIシステム・ユーザーの資格証明のリセット」の説明に従います。

    資格証明は、構成しようとしている認証対象のデータベース・テーブルで指定されている適切なユーザー・アカウントのものである必要があります。


    注意:

    第3.5項のOracle WebLogic Server管理コンソールのスクリーンショットには、データベース構成手順を完了するまでは表示されないドメイン内のユーザーが示されています。


注意:

「ユーザーとグループ」タブをチェックして、データベースのユーザーとグループが表示されていることを確認します。

3.4.5.4 仮想アイデンティティ・ストアの構成

仮想アイデンティティ・ストアを次のように構成します。

3.4.5.4.1 アイデンティティ・ストアの構成による仮想化の有効化

アイデンティティ・ストアを構成して仮想化を有効にする必要があります。これにより、アイデンティティ・ストア・サービスで複数のアイデンティティ・ストアを使用できるようになり、ユーザー・プロファイル情報を様々な認証プロバイダ(アイデンティティ・ストア)に分散できます。

詳細は、第3.4.6項「Fusion Middleware Controlを使用したアイデンティティ・ストアの仮想化の構成」を参照してください。

3.4.5.4.2 データベース・アダプタの構成

LDAPサーバーのようにデータベースが表示されるようデータベース・アダプタを構成します。これにより、仮想アイデンティティ・ストア・プロバイダは、そのデータベース・アダプタを使用してユーザー・プロファイル情報をデータベースから取得できます。

データベース・アダプタを構成するには:

このタスクは、データベース表をアイデンティティ・ストアとして使用する方法を指定する、アダプタ・テンプレートを編集して適用する方法を示しています。

  1. adapter_template_usergroup1.xmlという名前のファイルを作成します。

    このファイルは、ユーザー表から仮想LDAPストアへのマッピングを記述します。

  2. ファイルに次の内容が含まれていることを確認します。


    注意:

    太字で示しているセクションは、独自の表の列がLDAPサーバー内の属性と一致するように変更する必要があります。ここに示す例は、第3.4.5項全体で使用するサンプル・スキーマを対象としたものです。    		 

    <?xml version = '1.0' encoding = 'UTF-8'?>
<adapters schvers="303" version="1" xmlns="http://www.octetstring.com/schemas/Adapters" xmlns:adapters="http://www.w3.org/2001/XMLSchema-instance">
   <dataBase id="directoryType" version="0">
      <root>%ROOT%</root>
      <active>true</active>
      <serverType>directoryType</serverType>
      <routing>
         <critical>true</critical>
         <priority>50</priority>
         <inclusionFilter/>
         <exclusionFilter/>
         <plugin/>
         <retrieve/>
         <store/>
         <visible>Yes</visible>
         <levels>-1</levels>
         <bind>true</bind>
         <bind-adapters/>
         <views/>
         <dnpattern/>
      </routing>
      <pluginChains xmlns="http://xmlns.oracle.com/iam/management/ovd/config/plugins">
         <plugins>
            <plugin>
               <name>DBGUID</name>
               <class>oracle.ods.virtualization.engine.chain.plugins.dbguid.DBGuidPlugin</class>
               <initParams>
                  <param name="guidAtribute" value="orclguid"/>
               </initParams>
            </plugin>
         </plugins>
         <default>
            <plugin name="DBGUID"/>
         </default>
         <add/>
         <bind/>
         <delete/>
         <get/>
         <modify/>
         <rename/>
      </pluginChains>
      <driver>oracle.jdbc.driver.OracleDriver</driver>
      <url>%URL%</url>
      <user>%USER%</user>
      <password>%PASSWORD%</password>
      <ignoreObjectClassOnModify>false</ignoreObjectClassOnModify>
      <includeInheritedObjectClasses>true</includeInheritedObjectClasses>
      <maxConnections>10</maxConnections>
      <mapping>
         <joins/>
         <objectClass name="person" rdn="cn">
            <attribute ldap="cn" table="USER_VW" field="U_NAME" type=""/>
            <attribute ldap="uid" table="USER_VW" field="U_NAME" type=""/>
            <attribute ldap="usernameattr" table="USER_VW" field="U_NAME" type=""/>
            <attribute ldap="loginid" table="USER_VW" field="U_NAME" type=""/>
            <attribute ldap="description" table="USER_VW" field="U_NAME" type=""/>
            <attribute ldap="orclguid" table="USER_VW" field="orclguid" type=""/>
         </objectClass>
      </mapping>
      <useCaseInsensitiveSearch>true</useCaseInsensitiveSearch>
      <connectionWaitTimeout>10</connectionWaitTimeout>
      <oracleNetConnectTimeout>0</oracleNetConnectTimeout>
      <validateConnection>false</validateConnection>
   </dataBase>
</adapters>

    この例でカスタマイズが必要なのは太字で示しているセクションのみですが、その要素は、仮想LDAPスキーマで使用されている属性/クラスを、それらに対応するデータベースの列と一致させることでマップする必要があります。この仮想スキーマはWebLogicの組込みLDAPの仮想スキーマと同じであり、表3-5に示す任意の属性にデータベース列をマップできます。

    表3-5 データベース列にマップする属性の例

    属性 例

    description

    John Doe

    cn

    john.doe

    uid

    john.doe

    sn

    Doe

    userpassword

    welcome1

    displayName

    John Doe

    employeeNumber

    12345

    employeeType

    Regular

    givenName

    John

    homePhone

    650-555-1212

    mail

    john.doe@example.com

    title

    マネージャ

    manager

    uid=mary.jones,ou=people,ou=myrealm,dc=wc_domain

    preferredLanguage

    en

    departmentNumber

    ツール

    facsimiletelephonenumber

    650-555-1200

    mobile

    650-500-1200

    pager

    650-400-1200

    telephoneNumber

    650-506-1212

    postaladdress

    200 Oracle Parkway

    l

    Redwood Shores

    homepostaladdress

    123 Main St., Anytown 12345

  3. 最初の外側の要素(<objectClass name="person" rdn="cn">)を使用して、LDAPオブジェクト・クラスpersonのマッピングを宣言します。

    cn属性はRDN(相対識別名)として使用されます。次にサブ要素で、どのLDAP属性をデータベースのどの表および列にマップするのかを宣言します。たとえば、「<attribute ldap="uid" table="USERS" field="USER_ID" type=""/>」の行では、USER_VW表のUSER_IDフィールドを、標準のLDAP属性であるuid (つまり、ユーザーごとに一意のユーザーID)にマップします。

    次に、同じ方法を使用してグループをマップします。

  4. adapter_template_usergroup2.xmlという名前のファイルを作成します。

    このファイルは、グループ表から仮想LDAPストアへのマッピングを記述します。

  5. 次の内容をファイルに追加します。

    太字で示したセクションをカスタマイズして、ユーザー独自の表にある列と一致させる必要があります。ここに示すサンプルの内容は、この例全体で使用するサンプル・スキーマに一致します。

    <?xml version = '1.0' encoding = 'UTF-8'?>
<adapters schvers="303" version="1" xmlns="http://www.octetstring.com/schemas/Adapters" xmlns:adapters="http://www.w3.org/2001/XMLSchema-instance">
    <dataBase id="directoryType" version="0">
      <root>%ROOT%</root>
      <active>true</active>
      <serverType>directoryType</serverType>
      <routing>
         <critical>true</critical>
         <priority>50</priority>
         <inclusionFilter/>
         <exclusionFilter/>
         <plugin/>
         <retrieve/>
         <store/>
         <visible>Yes</visible>
         <levels>-1</levels>
         <bind>true</bind>
         <bind-adapters/>
         <views/>
         <dnpattern/>
      </routing>
      <pluginChains xmlns="http://xmlns.oracle.com/iam/management/ovd/config/plugins">
         <plugins>
            <plugin>
               <name>VirtualAttribute</name>
               <class>oracle.ods.virtualization.engine.chain.plugins.virtualattr.VirtualAttributePlugin</class>
               <initParams>
                  <param name="ReplaceAttribute" value="uniquemember={cn=%uniquemember%,cn=users,dc=oracle,dc=com}"/>
               </initParams>
            </plugin>
         </plugins>
         <default>
            <plugin name="VirtualAttribute"/>
         </default>
         <add/>
         <bind/>
         <delete/>
         <get/>
         <modify/>
         <rename/>
      </pluginChains>
      <driver>oracle.jdbc.driver.OracleDriver</driver>
      <url>%URL%</url>
      <user>%USER%</user>
      <password>%PASSWORD%</password>
      <ignoreObjectClassOnModify>false</ignoreObjectClassOnModify>
      <includeInheritedObjectClasses>true</includeInheritedObjectClasses>
      <maxConnections>10</maxConnections>
      <mapping>
         <joins/>
         <objectClass name="groupofuniquenames" rdn="cn">
            <attribute ldap="cn" table="GROUPMEMBERS_VW" field="G_NAME" type=""/>
            <attribute ldap="description" table="GROUPMEMBERS_VW" field="G_NAME type=""/>
            <attribute ldap="uniquemember" table="GROUPMEMBERS_VW" field="G_MEMBER" type=""/>
            <attribute ldap="orclguid" table="GROUPMEMBERS_VW" field="G_NAME" type=""/>
         </objectClass>
      </mapping>
      <useCaseInsensitiveSearch>true</useCaseInsensitiveSearch>
      <connectionWaitTimeout>10</connectionWaitTimeout>
      <oracleNetConnectTimeout>0</oracleNetConnectTimeout>
      <validateConnection>false</validateConnection>
   </dataBase>
</adapters>

  6. 次の要素について、太字で示した適切なセクションをカスタマイズします。

    • ReplaceAttribute

      グループで一意のメンバーを定義する方法を指定します(%uniquemember%は、ユーザーがグループのメンバーかどうかをルックアップする際の実行時に渡される値のプレースホルダ)

      この要素について変更する唯一の点は、ユーザーのルートの指定です。概念的には、libovdadapterconfigスクリプトをステップ10で実行する際にユーザー移入のルートとして指定するものにデフォルトで一致する必要があります。

    • groupofuniquenames

      ユーザー同様、グループ属性をデータベース・フィールドにマップする方法を指定します。この属性は、Weblogicの組込みLDAPのデフォルトに対応します。

      次の属性をマップする必要があります。

      • cn (グループの一意の名前にマップする)

      • uniquemember (データベース・スキーマのユーザー/グループ・マッピング表におけるユーザーの一意の名前にマップする)

      • orclguid (データベース・スキーマで利用可能な場合は一意のIDにマップする)

      次の属性のマップはオプションです。

      • descriptionはオプション(ただし明らかに有用な情報です)

      その他の属性は、ユーザーは構成できません。

  7. 2つのアダプタ・ファイルを次のフォルダにコピーします。

    ORACLE_HOME/oracle_common/modules/oracle.ovd/templates/

  8. 次の場所でコマンド・プロンプトまたはターミナルを開きます。

    ORACLE_HOME/oracle_common/bin

  9. 次の環境変数のように設定されていることを確認します。

    • ORACLE_HOME=ORACLE_HOME/oraclehome

    • WL_HOME=ORACLE_HOME/wlserver

    • JAVA_HOME=ORACLE_HOME/jdk/jre

  10. libovdadapterconfigスクリプトを実行し、テンプレート・ファイルから2つのアダプタをそれぞれ作成します。次に構文を示します。

    libovdadapterconfig -adapterName <name of adapter> -adapterTemplate <name (NOT including path) of template file which defines adapter> -host localhost -port <Admin Server port> -userName <user id of account which has administrative privileges in the domain> -domainPath <path to the BI domain> -dataStore DB -root <nominal specification of a pseudo-LDAP query to treat as the "root" of this adapter - must match that specified in template for adapter 2 above> -contextName default -dataSourceJNDIName <JNDI name for DataSource which points at the database being mapped>

    例:

    ./libovdadapterconfig.sh -adapterName userGroupAdapter1 -adapterTemplate adapter_template_usergroup1.xml -host localhost -port 7001 -userName weblogic -domainPath /opt/oracle_bi/user_projects/domains/bifoundation_domain/ -dataStore DB -root cn=users,dc=oracle,dc=com -contextName default -dataSourceJNDIName jdbc/UserGroupDS

./libovdadapterconfig.sh -adapterName userGroupAdapter2 -adapterTemplate adapter_template_usergroup2.xml -host localhost -port 7001 -userName weblogic -domainPath /opt/oracle_bi/user_projects/domains/bifoundation_domain/ -dataStore DB -root cn=users,dc=oracle,dc=com -contextName default -dataSourceJNDIName jdbc/UserGroupDS

    スクリプトはエラーなしで終了する必要があります。

  11. WebLogic管理サーバーおよび管理対象サーバーを再起動します。

    これで、データベースに格納された資格証明を使用して、WebLogicおよびOracle Business Intelligenceにログインできるはずです。

3.4.5.5 SQL認証プロバイダのトラブルシューティング

この項では、SQL認証プロバイダのトラブルシューティング情報を示します。この項の内容は次のとおりです。

3.4.5.5.1 Oracle WebLogic Server管理コンソールの使用によるグローバルAdminロールへのユーザーの追加

データベース・ユーザーを使用してOracle Business Intelligenceにログインできない場合に役立つ診断テストとして、そのユーザーがWebLogicにログインできるかどうかを確認することがあります。WebLogicコンテナ認証を利用する他のアプリケーションがWebLogic Server上にない場合は、ユーザーを(一時的に) WebLogicのグローバルAdminロールに追加し、そのユーザーがOracle WebLogic Server管理コンソールにログインできるかどうかを確認することで、SQLAuthenticatorが正しく動作していることをテストします。

Oracle WebLogic Server管理コンソールを使用してグローバルAdminロールにユーザーを追加するには:

  1. Oracle WebLogic Server管理コンソールにログインし、「チェンジ・センター」で「ロックして編集」をクリックします。

    詳細は、第1.6.1項「Oracle WebLogic Server管理コンソールの使用」を参照してください。

  2. 左ペインで「セキュリティ・レルム」を選択し、「myrealm」をクリックします。

    デフォルトのセキュリティ・レルムはmyrealmという名前です。

  3. 「ロールとポリシー」タブを表示し、「レルム・ロール」サブタブを表示します。

    このスクリーンショットについては、前後の説明を参照してください。

  4. ロールのリストでプラス記号をクリックして「グローバル・ロール」→「ロール」を展開し、Adminロールの「ロール条件の表示」リンクをクリックします。

  5. 指定されている条件が、直接、または所属するグループに基づいて、ユーザーに一致することを確認します。

    たとえば、条件にはUser=myadminaccountやGroup=Administratorsなどがあります。

  6. 変更したら、「保存」をクリックします。

    変更はただちに適用されます。

  7. これで、問題のユーザーがOracle WebLogic Server管理コンソール(http://<bi server address>:<AdminServer Port>/console)にログインできるかどうかを確認できます(例: http://example.com:9500/console)。

    ユーザーがコンソールにログインできるがOracle Business Intelligenceにログインできない場合、SQLAuthenticatorは正しく動作していますが、アイデンティティ・ストア・サービスに問題がある可能性があります。第3.4.6項「Fusion Middleware Controlを使用したアイデンティティ・ストアの仮想化の構成」でvirtualize=trueとOPTIMIZE_SEARCH=trueプロパティが指定してあることを確認し、第3.4.5.4.2項「データベース・アダプタの構成」でDBAdapterテンプレートが正しいことを確認します。

3.4.5.5.2 SQLAuthenticatorに対する正しくないデータ・ソース名の指定

SQLAuthenticatorのデータ・ソース・フィールドに正しくない名前を指定した場合、次のようなエラーが管理サーバーおよび管理対象サーバーのログ・ファイルに記録されます。

Caused by: javax.security.auth.login.FailedLoginException: [Security:090761]Authentication failed for user jsmith java.sql.SQLException: [Security:090788]"Problem with DataSource/ConnectionPool configuration, verify DataSource name wrongdsname is correct and Pool configurations are correct"
      at weblogic.security.providers.authentication.shared.DBMSAtnLoginModuleI
mpl.login(DBMSAtnLoginModuleImpl.java:318)

第3.4.5.3.1項「Oracle WebLogic Server管理コンソールの使用によるデータ・ソースの構成」で示した例のとおり、データ・ソース名を使用します。

3.4.5.5.3 正しくないSQL問合せ

SQLAuthenticatorを構成するときに指定するSQL問合せの構文が正しいこと、および正しい表を参照していることを確認します。たとえば、パスワード問合せに正しくない表名が指定されると、次のエラーがAdministration Server.logファイルに記録されます。

####<Jul 7, 2011 4:03:27 PM BST> <Error> <Security> <gbr20020> <AdminServer> <[ACTIVE] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <de7dd0dc53f3d0ed:e0ce69e:131007c1afe:-8000-00000000000007fa> <1310051007798> <BEA-000000> <[Security:090759]A SQLException occurred while retrieving password information
java.sql.SQLSyntaxErrorException: ORA-00942: table or view does not exist
     at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:457)
     at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:405)
     at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:889)
     at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:476)

3.4.5.6 アダプタの削除および再作成によるデータベース・アダプタ・エラーの修正

既存のデータベース・アダプタは修正しないでください。アダプタの作成で使用するテンプレートやlibovdadapterコマンドでエラーが発生した場合は、次の手順を使用してアダプタを削除してから、再作成する必要があります。

アダプタを削除および再作成してデータベース・アダプタ・エラーを修正するには:

  1. WLSTスクリプトを実行して、WLSコンソールにログインします。

    例:

    ORACLE_HOME/oracle_common/common/bin/wlst.sh (UNIX)

    ORACLE_HOME\oracle_common\common\bin\wlst.cmd (Windows)

  2. 次の構文を使用して管理サーバーに接続します。

    connect ('<WLS admin user name>','<WLS admin password>','t3://<admin server host>:<admin server port>')

    例:

    connect('weblogic','weblogic','t3://myserver:9500')

  3. 次の構文を使用して、適切に構成されていないアダプタを削除します。

    deleteAdapter(adapterName='<AdapterName>')

    例:

    deleteAdapter(adapterName='userGroupAdapter2')

  4. exit()コマンドを使用してWLSTコンソールを終了し、第3.4.5.4.2項「データベース・アダプタの構成」の手順に従って適切な設定でアダプタを再作成します。

3.4.6 Fusion Middleware Controlを使用したアイデンティティ・ストアの仮想化の構成

この項では、Fusion Middleware Controlを使用して、アイデンティティ・ストアの仮想化を使用するためにOracle Business Intelligenceを構成する方法について説明します。

Fusion Middleware Controlを使用してアイデンティティ・ストアの仮想化を構成するには:

SSLでLDAPと通信している場合(一方向SSLのみ)は、第5.14.2項「複数認証プロバイダ使用時のSSLの構成」を参照してください。

詳細は、次の項を参照してください。

  1. (オプション)サポートされている認証プロバイダがまだ構成されていない場合は、第3.4項の説明に従って構成します。

  2. Fusion Middleware Controlにログインします。

    詳細は、第1.6.2項「Oracle Fusion Middleware Controlの使用」を参照してください。

  3. ナビゲーション・ペインから「WebLogicドメイン」フォルダを展開し、「bi」を選択します。

  4. 「bi」を右クリックして「セキュリティ」→「セキュリティ・プロバイダ構成」を選択し、「セキュリティ・プロバイダ構成」ページを表示します。

    このスクリーンショットについては、前後の説明を参照してください。

  5. 「セキュリティ・ストア・プロバイダ」および「アイデンティティ・ストア・プロバイダ」を開き、「構成」をクリックして、「アイデンティティ・ストア構成」ページを表示します。

    このスクリーンショットについては、前後の説明を参照してください。

  6. 「カスタム・プロパティ」領域で「追加」オプションを使用し、次のカスタム・プロパティを追加します。

    • プロパティ名=virtualize

      値=true

    • プロパティ名=OPTIMIZE_SEARCH

      値=true


    注意:

    プロパティ名virtualizeは小文字である必要があり、OPTIMIZE_SEARCHは大文字である必要があります。


    注意:

    複数の認証プロバイダを使用している場合は、第3.4項「代替認証プロバイダを使用するためのOracle Business Intelligenceの構成」に移動して、「制御フラグ」設定を次にように構成します。

    • 各ユーザーが1つの認証プロバイダのみを使用する場合

      すべての認証プロバイダで「制御フラグ」の値を「SUFFICIENT」に設定します。

    • ユーザーが複数の認証プロバイダを使用する場合

      すべての認証プロバイダで「制御フラグ」の値を「OPTIONAL」に設定します。

      たとえば、ユーザーのグループのメンバーシップが複数の認証プロバイダ間で共有される場合です。

  7. 「OK」をクリックして変更を保存します。

  8. 管理サーバーおよび管理対象サーバーを再起動します。

3.4.7 1つの認証プロバイダが失敗した場合でも別の認証プロバイダからOracle Business Intelligenceにログインできるように複数の認証プロバイダを構成する

複数の認証プロバイダを使用するようにOracle Business Intelligenceを構成している場合で、1つの認証プロバイダが使用できなくなれば、他の認証プロバイダを使用するユーザーもOracle Business Intelligenceにログインできなくなります。この項では、1つの認証プロバイダが失敗した場合に、他の認証プロバイダを使用するユーザーはOracle Business Intelligenceにログインできるように認証プロバイダを構成する方法について説明します。詳細は、第3.4.6項「Fusion Middleware Controlを使用したアイデンティティ・ストアの仮想化の構成」を参照してください。

1つの認証プロバイダが使用不可になったためにログインできない場合、次のエラー・メッセージが表示されます。

Unable to Sign In
An error occurred during authentication.
Try again later or contact your system administrator

1つの認証プロバイダ(構成されている複数の認証プロバイダのうちの1つ)が使用不可になっている可能性があり、これがクリティカルな認証プロバイダでない場合、次の手順により、ユーザーは他の認証プロバイダからOracle Business Intelligenceにログインできるようになります。

1つの認証プロバイダが失敗した場合でも、他の認証プロバイダからOracle Business Intelligenceにログインできるように複数の認証プロバイダを構成するには:

  1. ファイルadapters.os_xmlを編集のために開きます。

    たとえば、Windows上では、このファイルは次の場所にあります。

    ORACLE_HOME\user_projects\domains\bi\config\fmwconfig\ovd\default

  2. ファイルから次の要素を見つけます。

    <critical>true</critical>>

    adapters.os_xmlファイル内で、クリティカルでない各認証プロバイダについて、<critical>要素の値をfalseに変更します。

    <critical>false</critical>

  3. ファイルを保存して閉じます。

  4. WebLogic管理サーバーと管理対象サーバーを再起動します。

3.4.8 JAAS制御フラグ・オプションの設定

複数の認証プロバイダを構成する際、各プロバイダのJAAS制御フラグを使用して、ログイン・シーケンスでの認証プロバイダの扱いを制御します。JAAS制御フラグはOracle WebLogic Server管理コンソールで設定できます。詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプでJAAS制御フラグの設定に関する項を参照してください。WebLogic Scripting ToolやJava Management Extensions (JMX) APIを使用しても、認証プロバイダに対してJAAS制御フラグを設定できます。

認証プロバイダの制御フラグの属性を設定すると、認証プロバイダの実行順序が決まります。制御フラグ属性に使用可能な値は次のとおりです。

  • REQUIRED - このLoginModuleは成功する必要があります。失敗した場合でも、認証は、構成された認証プロバイダのLoginModulesリストの下位方向へ進みます。この設定がデフォルトです。

  • REQUISITE - このLoginModuleは成功する必要があります。他の認証プロバイダが構成されていて、このLoginModuleが成功した場合、認証はLoginModulesリストを下位方向へ進みます。それ以外の場合は、制御がアプリケーションに戻ります。

  • SUFFICIENT - このLoginModuleは成功する必要はありません。成功した場合、制御はアプリケーションに戻ります。失敗した場合、他の認証プロバイダが構成されていれば、認証はLoginModuleリストを下位方向に進みます。

  • OPTIONAL - このLoginModuleは成功でも失敗でもかまいません。ただし、JAAS制御フラグがOPTIONALに設定されたセキュリティ・レルムですべての認証プロバイダが構成されている場合は、ユーザーは構成されたいずれかのプロバイダの認証テストに合格する必要があります。

既存のセキュリティ・レルムに認証プロバイダを追加した場合、制御フラグはデフォルトでOPTIONALに設定されます。各認証プロバイダが認証シーケンスで適切に動作するよう、必要に応じて制御フラグの設定と認証プロバイダの順序を変更します。

3.4.9 認証プロバイダとしての単一のLDAP認証プロバイダの構成

このトピックでは、デフォルトのWebLogic Server LDAP認証プロバイダを無効にして、単一のLDAP認証プロバイダを使用するようOracle Business Intelligenceを再構成する方法を説明します。

Oracle Business Intelligenceをインストールすると、システムは自動的に、デフォルトの認証プロバイダとしてWebLogic Server LDAPを使用するように構成されます。インストール・プロセスでは、WebLogic Server LDAPで必要なユーザーおよびグループが自動的に生成されます。ただし、独自のLDAPディレクトリ(Oracle Internet Directoryなど)があり、それをデフォルトの認証プロバイダとして使用することも、WebLogic Serverのデフォルト認証プロバイダを無効にすることもできます。単一ソースの認証プロバイダを持つことにより、ユーザー名およびパスワードを複数の認証ソースから取得しないようにすることができます。複数の認証ソースから取得すると、複数の攻撃点が生じたり、認可されていないユーザーの侵入が可能になる場合があります。

このトピックには、次の項が含まれています。

3.4.9.1 唯一の認証プロバイダとしてのOracle Internet Directory LDAP認証の構成

この項に示す例はOracle Internet Directory (OID LDAP)を構成するためのものですが、若干変更を加えることによって、他のLDAP認証プロバイダに簡単に適用できます。

唯一の認証プロバイダとしてOracle Internet DirectoryのLDAP認証を構成するには:

3.4.9.1.1 タスク1 - バックアップおよびリカバリの有効化

WebLogic Server LDAPのデフォルトの認証メソッドを無効にするプロセスを開始する前に、まずシステムをバックアップすることを強くお薦めします。バックアップしないと、構成時に間違えた場合に、システムからロックアウトされたり、システムを再起動できなくなることがあります。

再構成フェーズでバックアップおよびリカバリを有効にするには、ORACLE_HOME\user_projects\domains\bi\configディレクトリにあるconfig.xmlファイルのコピーをとります。

変更を行う際は、このファイルのコピーを保持しておくことをお薦めします。

3.4.9.1.2 タスク2 - WebLogic Serverおよび代替認証プロバイダを使用するためのシステムの構成

デフォルトのWebLogic Server認証プロバイダを削除し、代替LDAPソース(OID LDAPなど)を使用するには、WebLogic Serverと代替メソッドの両方を使用するようにシステムを構成する必要があります。詳細は、第3.4項「代替認証プロバイダを使用するためのOracle Business Intelligenceの構成」を参照してください。WebLogic Server LDAPユーザー(デフォルトの認証プロバイダ)と新しい代替LDAPユーザーがともにOracle Business Intelligenceにアクセスできるように構成されている状態から開始します。

WebLogic Server LDAPユーザーとしてもOID LDAPユーザーとしてもログオンできるようにシステムを構成したら、次の各タスクの説明のとおり、WebLogic Serverのデフォルト認証プロバイダを削除する手順に進みます。

3.4.9.1.3 タスク3 - OID LDAPでの必須ユーザーの特定または作成

表3-6に示す必須ユーザーが、WebLogic Server LDAPからOID LDAPに移行されていることを確認する必要があります。

表3-6 OID LDAPでの必須ユーザー

標準のWebLogic Serverユーザー OID LDAPで新たに必要とされるユーザー

LCMManager,User

OID_LCMManagerUser (任意の既存OID LDAPユーザーにできます)

例: weblogic

OID_Weblogic (任意の既存OID LDAPユーザーにできます)

OracleSystemUser

OracleSystemUser (このユーザーはOID LDAPにおいてこの名前で存在する必要があります - OWSMの固定要件)

インストール時に次の3つのユーザーが作成されます。

  • Weblogic (またはインストール時またはアップグレード時に指定される項目、異なる場合があります)。

    この管理者ユーザーはインストール時に作成されます(weblogicと呼ばれることもありますが、任意の名前でかまいません)。OID LDAPで同等のユーザーを特定または作成する必要がありますが、このユーザーはAdministratorsというグループの一部である必要がある任意の名前でかまいません。

  • OracleSystemUser

    このユーザーは、(Oracle Web Services Manager (OWSM)で)特にグローバル・ロール・マッピングのために必要です。このユーザーは、OID LDAPでこの名前で作成する必要があります。

3.4.9.1.4 タスク4 - WebLogicコンソールでのOID LDAPグループとグローバル・ロールとの関連付け

表3-7に示すグローバル・ロール・マッピングを、OID LDAPで構成する必要があります。

表3-7 WebLogic管理コンソールでのグローバル・ロール・マッピング

グローバル・ロール 現在のWebLogic Serverグループ 新たに必要とされるOID LDAPグループ

Admin

Administrators

OID_Administrators

AdminChannelUsers

AdminChannelUsers

OID_AdminChannelUsers

AppTester

AppTesters

OID_AppTesters

CrossDomainConnector

CrossDomainConnectors

OID_CrossDomainConnectors

Deployer

Deployers

OID_Deployers

Monitor

Monitors

OID_Monitors

Operator

Operators

OID_Operators

OracleSystemRole

OracleSystemGroup

OracleSystemGroup (固定要件)

デフォルトのWebLogic Server認証プロバイダを無効にする前に、(WebLogic Server管理コンソールに表示されている)表3-7のグローバル・ロールと、置換OID LDAPグループを関連付ける必要があります。

Oracle WebLogic Server管理コンソールでOID LDAPグループとグローバル・ロールを関連付けるには:

  1. Oracle WebLogic Server管理コンソールにログインし、「チェンジ・センター」で「ロックして編集」をクリックします。

    詳細は、第1.6.1項「Oracle WebLogic Server管理コンソールの使用」を参照してください。

  2. 左ペインで「セキュリティ・レルム」を選択し、「myrealm」をクリックします。

    デフォルトのセキュリティ・レルムはmyrealmという名前です。

  3. 「レルム・ロール」をクリックします。

  4. 「グローバル・ロール」をクリックし、「ロール」を開きます。

    グローバル・ロールを表示しているWLSコンソールのレルム・ロール

  5. 次のように、各ロールに対し、新しい条件を追加します。


    注意:

    AnonymousおよびOracle Systemロールには、新しい条件を追加しないでください。どちらも変更されないままになることがあります。

    1. 「ロール条件の表示」をクリックします。

    2. 「述部リスト」ドロップダウンからグループを選択します。

    3. 表3-7の新たに関連付けられるOID LDAPグループを入力します。

      たとえば、AdminロールをOID_Administratorsロールに関連付けます。

      OIDロールにマッピングされるAdminグローバル・ロール

      注意:

      デフォルトのWebLogic Server認証を正常に無効にしたら、ここに戻って古いWebLogic Serverグループを削除できます(たとえばここでは、グループAdministratorsを削除します)。詳細は、タスク8 - WebLogic Serverロールの削除」を参照してください。

    4. 変更内容を保存します。

3.4.9.1.5 タスク5 - OID LDAPでのユーザーからグループへのメンバーシップの設定

OID LDAPで新しいユーザーおよびグループを作成し、WebLogic Server LDAPで自動的に作成されたユーザーおよびグループをレプリケートしたので、次に、これらのユーザーおよびグループが、OID LDAPにおいても、表3-8に示すとおり正しいグループ・メンバーシップを持っていることを確認する必要があります。

表3-8 OID LDAPで必要なユーザーからグループへのメンバーシップ

新しいOID LDAPユーザー メンバーとなる新しいOID LDAPグループ

OID_Weblogic

OID_Administrators

OID_BIServiceAdministrators

OracleSystemUser

注意: この名前のユーザーがOID LDAPに存在する必要があります。

OracleSystemGroup

注意: この名前のグループがOID LDAPに存在する必要があります。


注意:

表3-8に示すユーザーとグループのメンバーシップを実現するには、OID LDAPサーバーを更新できる適切なアクセス権を持つか、別の担当者がかわりにグループのメンバーシップを更新できる必要があります。

3.4.9.1.6 タスク6 - デフォルトの認証プロバイダの削除

これでデフォルトの認証プロバイダを削除する準備が整いました。

デフォルトの認証プロバイダを削除するには:

まずLDAPソースにマップするLDAP認証プロバイダを作成しておく必要があります(詳細は、タスク2 - WebLogic Serverおよび代替認証プロバイダを使用するためのシステムの構成を参照)。

  1. Oracle WebLogic Server管理コンソールで、「制御フラグ」を「SUFFICIENT」から「REQUIRED」に変更します。

    詳細は、第3.4.8項「JAAS制御フラグ・オプションの設定」を参照してください。

    OIDに対する制御フラグのRequiredへの変更

  2. 変更を保存します。

  3. 他の認証プロバイダを削除し、OID LDAP認証プロバイダが単一ソースとなるようにします。

    これでOIDプロバイダが単一ソースとなりました。
3.4.9.1.7 タスク7 - BIサービスの再起動

これでBIサービスを再起動する準備が整いました。インストール時に作成したWebLogic Server管理ユーザーは削除され、すべてのユーザーが単一OIDソースに存在するため、新しいOID管理者ユーザー(OID_Weblogicなど)を使用する必要があります。OID管理ユーザーには、WebLogicを起動するために十分な権限が必要です(グローバルAdminロールによって付与されます)。


注意:

オンラインで管理ツールにログインする際は、リポジトリ・パスワードとともにOID LDAPユーザーとパスワード(OID_Weblogicなど)を指定する必要があります。

3.4.9.1.8 タスク8 - WebLogic Serverロールの削除

すべて正常に機能している場合、このタスクを完了させます。


注意:

この手順を実行する前に、config.xmlをバックアップしてください(タスク1 - バックアップおよびリカバリの有効化を参照)

自動的に作成されたすべてのWebLogic ServerロールをOR句から削除するには:

  1. グローバル・ロールを編集します。

    詳細は、タスク4 - WebLogicコンソールでのOID LDAPグループとグローバル・ロールとの関連付けを参照してください。

  2. 自動的に作成されたすべてのWebLogic ServerロールをOR句から削除します。

    例:

    • Admin

    • AdminChannelUsers

    • AppTester

    • CrossDomainConnector

    • Deployer

    • Monitor

    • Operator

  3. 変更内容を保存します。

3.4.9.1.9 タスク9 - 代替認証メソッドの停止

Oracle Business Intelligenceでは、様々な形式の認証方式を一括適用できます。望ましい機能にも思えますが、セキュリティ上のリスクも伴います。単一ソースの認証を実装するには、初期化ブロックを使用する認証メソッドをメタデータ・リポジトリから削除する必要があります。

すべての初期化ブロック認証アクセスを停止するには:

Oracle BI管理ツールを使用して、初期化ブロックを介したアクセスを停止します。正常な認証を行うにはユーザー名が必要です。初期化ブロックでは、USERという特殊なシステム・セッション変数を使用してユーザー名を移入します。

  1. メタデータ・リポジトリからシステム変数USERを削除します。

  2. メタデータ・リポジトリの初期化ブロックで「認証のために必要」チェック・ボックスが選択されていないことを確認します。

  3. システム・セッション変数PROXYおよびPROXYLEVELを設定するメタデータ・リポジトリの初期化ブロックが、ユーザーにセキュリティの無視を許可していないことを確認します。

    システム変数PROXYおよびPROXYLEVELは、一度接続されたユーザーが他のユーザーのセキュリティ・プロファイルでそのユーザーになりすますことを許可します。このメソッドは、偽装されたユーザー・アカウントの方が低い権限を持っている場合は受け入れられますが、このアカウントの方が高い権限を持っている場合はセキュリティの問題となる可能性があります。

注意: 初期化ブロックを無効にする場合、依存する初期化ブロックも無効になります。

これで、初期化ブロック認証を使用して試みられるアクセスは成功しなくなります。ただし、すべての初期化ブロックをチェックする必要があります。

3.4.9.2 トラブルシューティング

単一ソースとしてOracle Internet Directory LDAP認証を構成すると、次のエラーが発生する場合があります。

<クリティカル> <WebLogicServer> <BEA-000386> <サーバー・サブシステムに障害が発生しました。

理由: weblogic.security.SecurityInitializationException: ユーザー<oidweblogic>はサーバーの起動を許可されていません。ユーザーがサーバーを起動できなくなるようにサーバーのポリシーが変更されていることが考えられます。管理ユーザー・アカウントでサーバーを再起動するか、システム管理者に連絡してサーバーのポリシー定義を更新してください。

解決方法

新しいWebLogic OID LDAP管理者(oidweblogic)としてシステムを再起動した場合に、ロックアウトされ、メッセージが表示された場合は、oidweblogicユーザーに十分な権限がなかったことが原因です。oidweblogicユーザーにはグローバルAdminロールが必要です。これにより、OID LDAP Administratorグループに所属することが可能になります。この問題を解決するには、BIServiceAdministratorsグループ(またはOID LDAPの同等グループ)をグローバルAdminロールに追加します。


注意:

以前の作業構成をリストアするには、最新の更新されたバージョンのconfig.xmlファイルを、構成を変更する前に作成しておいたバックアップ・バージョンに置き換える必要があります(詳細は、タスク1 - バックアップおよびリカバリの有効化を参照)。

バックアップ・バージョンのconfig.xmlファイルのリストアを完了するには、OID LDAPユーザーではなく、元のWebLogic管理者ユーザーとしてOracle Business Intelligenceを再起動します。

3.5 BIシステム・ユーザーの資格証明のリセット

11gではBISystemUserというユーザーが組込みWebLogic LDAPで作成されましたが、12cではこのユーザーは存在せず、単一の資格証明で置き換えられています。この資格証明は、BIドメイン作成時にセキュアに生成されたランダム値が入力され、資格証明ストアに格納されます。この資格証明のユーザー名またはパスワードをリセットする必要がある場合は常に、次の手順を実行します。

BIシステム・ユーザーの資格証明をリセットするには:

  1. Fusion Middleware Controlのターゲット・ナビゲーション・ペインからファームを開き、「WebLogicドメイン」を開いて「bi」を選択します。

    • 「WebLogicドメイン」メニューで、「セキュリティ」→「資格証明」を選択します。

    • 「oracle.bi.system」 資格証明マップを開き、「system.user」 を選択して「編集」をクリックします。

      bisystem_cred.gifの説明が続きます
      図「bisystem_cred.gif」の説明

    • 「キーの編集」ダイアログで、必要に応じてユーザー名またはパスワードを更新します。これらの値がアイデンティティ・ストアのユーザーの資格証明と一致しないことを確認します。

      「キーの編集」ダイアログでのBISystemUser資格証明の入力。

    • 「OK」をクリックします。

  2. システムを再起動します

  前
前 		 次
次
  目次へ移動
目次