1. セキュリティ・ガイド
  2. ユーザー認証および認可の管理
  3. Microsoft Active Directoryによる集中管理ユーザーの構成

6 Microsoft Active Directoryによる集中管理ユーザーの構成

Oracle Databaseでは、中間ディレクトリまたはOracle Enterprise User Securityを使用せずにデータベースでMicrosoft Active Directoryユーザーを直接認証および認可できます。

親トピック: ユーザー認証および認可の管理 

Microsoft Active Directoryによる集中管理ユーザーの概要

集中管理ユーザー(CMU)によりMicrosoft Active Directoryとのシンプルな統合が実現し、ユーザーの集中化された認証と認可が可能になります。

親トピック: Microsoft Active Directoryによる集中管理ユーザーの構成

Oracle DatabaseとMicrosoft Active Directoryの統合について

集中管理ユーザーによりMicrosoft Active Directoryとのシンプルな統合が実現し、ユーザーの集中化された認証と認可が可能になります。

Active Directoryサーバー・オペレーティング・システムの最小バージョン要件は、Microsoft Windows Server 2008 R2です。

この統合により、組織はActive Directoryを使用して、1つのディレクトリとその他の情報技術サービスを使用して、複数のOracleデータベースでユーザーとロールを一元的に管理できます。Active Directoryユーザーは、Active Directoryに格納されている資格証明を使用してOracle Databaseに対する認証を実行できます。Active Directoryユーザーは、Active Directoryグループを使用して、データベース・ユーザー(スキーマ)およびロールに関連付けることもできます。Microsoft Active Directoryのユーザーは、排他または共有Oracle Databaseユーザー(スキーマ)にマップし、ディレクトリのグループ・メンバーシップを介してデータベース・ロールに関連付けることができます。ユーザーのログイン時に、Oracle DatabaseはActive Directoryのアカウント・ポリシー(パスワードの有効期限やロックアウトされるまでの指定されたログイン失敗回数など)を受け入れます。

Oracle Database 18cリリース1 (18.1)より前では、データベース・ユーザーの認証および認可をActive Directoryと統合できるように、Oracle Enterprise User Securityを構成し、Oracle Internet Directory(またはOracle Universal Directory)をインストールして構成していました。このアーキテクチャは現在でも使用可能であり、今後はOracleエンタープライズ・ドメインおよび信頼できるデータベース間の現在のユーザー・データベース・リンク、複雑なエンタープライズ・ロールを使用し、データベース・アクセス権限とロールの監査を1箇所で行う必要があるユーザーによって使用が継続されます。

ほとんどの組織には、これらの複雑な要件はありません。かわりに、Active Directoryで集中管理ユーザー(CMU)を使用できます。この統合は、一元的なアイデンティティ管理ソリューションとしてActive Directoryを使用する組織を対象として設計されています。 Oracle Netネーミング・サービスは、従来と同様にディレクトリ・サービスと連携します。

組織は、Active DirectoryのCMUでKerberos、PKIまたはパスワード認証を使用できます。Active DirectoryのCMUの使用には、現在サポートされているOracle Databaseクライアントとの下位互換性があります。これは、パスワード認証にLDAPバインド操作が使用されていないため、パスワード・ベリファイアを格納するには、Active Directoryスキーマを拡張し、Active DirectoryにOracleフィルタを追加する必要があることを意味します。KerberosまたはPKIを使用している組織では、フィルタの追加もActive Directoryスキーマの拡張も行う必要はありません。

Oracle DatabaseとActive Directoryの統合は、次のタイプのユーザーにとって特に役に立ちます。

  • 現在Kerberosや公開キー・インフラストラクチャ(PKI)などの厳密認証を使用しているユーザー。これらのユーザーはすでに一元的なアイデンティティ管理システムを使用しています。

  • Oracle Enterprise User Security、Oracle Internet Directory、Oracle Unified Directory、Oracle Virtual Directoryを現在使用しており、Active Directoryとの統合が必要なユーザー。

親トピック: Microsoft Active Directoryによる集中管理ユーザーの概要

Microsoft Active Directoryによる集中管理ユーザーのしくみ

この統合は、Microsoft Active DirectoryのユーザーおよびグループがOracleデータベース・ユーザーおよびロールに直接マッピングされることで機能します。

Active Directory統合とOracle Database CMUが機能するためには、Oracleデータベースが、Active Directoryでこのデータベースのために作成されたサービス・アカウントにログインできる必要があります。ユーザーがデータベースにログインするときに、データベースはこのサービス・アカウントを使用してActive Directoryに対しユーザーとグループの情報を問い合せます。このActive Directoryサービス・アカウントには、ユーザーおよびグループ情報の問合せに必要な権限がすべて付与されている必要があり、またActive Directoryでパスワード・ポリシーに関連する更新(ログイン失敗回数、ログイン失敗回数のクリアなど)を書き込むことができる必要があります。ユーザーは、パスワード、Kerberos、またはPKIを使用して認証し、排他スキーマまたは共有スキーマのいずれかに割り当てることができます。共有スキーマへのActive Directoryユーザーのマッピングは、共有スキーマにマップされているActive Directoryグループへのユーザーの関連付けによって決定します。Active Directoryグループは、データベース・グローバル・ロールにもマップできます。Active Directoryセキュリティ管理者は、共有データベース・グローバル・ユーザー(スキーマ)またはデータベース・グローバル・ロール(あるいはその両方)にマップされたグループにユーザーを割り当てることができるため、データベースでActive Directoryユーザーに割り当てられている権限およびロールを更新できます。

親トピック: Microsoft Active Directoryによる集中管理ユーザーの概要

集中管理ユーザーとMicrosoft Active Directoryによるアーキテクチャ

Active DirectoryアーキテクチャのCMUでは、Oracle DatabaseユーザーおよびロールをActive Directoryで管理できます。

次の図は、Oracle Database CMU機能を示しています。この図では、ユーザーがアプリケーションから管理者以外のユーザーまたは管理ユーザーとして、パスワード、Kerberosまたは公開キー・インフラストラクチャ(PKI)認証を使用してOracleデータベースに接続します。Active Directoryへのデータベース接続により、これらのユーザーおよびロールをActive Directoryのユーザーおよびグループにマップできます。パスワード認証を使用する予定がある場合は、Active DirectoryにOracleフィルタをインストールする必要があります。Oracle提供のユーティリティを使用して、必要に応じて個々のユーザーに対してOracleパスワード・ベリファイアを生成するOracleフィルタをインストールできます。また、このユーティリティを使用して、Oracleパスワード・ベリファイアを保持するためにActive Directoryスキーマを拡張できます。Oracle Database集中管理ユーザーにより、Active Directory管理者は、Oracle DatabaseユーザーおよびロールにマップされているActive Directoryユーザーおよびグループの認証、ユーザー管理、アカウント・ポリシー、およびグループの割当てを制御できます。


dbseg_pb_001b.epsの説明が続きます
図dbseg_pb_001b.epsの説明

親トピック: Microsoft Active Directoryによる集中管理ユーザーの概要

サポートされている認証方式

Oracle DatabaseとMicrosoft Active Directoryの統合では、3種類の一般的な認証方式がサポートされています。

これらの認証方法は次のとおりです。

  • パスワード認証

  • Kerberos認証

  • 公開キー・インフラストラクチャ(PKI)認証(証明書ベースの認証)

関連トピック

親トピック: Microsoft Active Directoryによる集中管理ユーザーの概要

Microsoft Active Directoryによる集中管理ユーザーでサポートされているユーザー

Active DirectoryのCMUにより、排他的にマップされるユーザー、共有スキーマにマップされるユーザー、管理ユーザーがサポートされます。

これらのユーザーは次のとおりです。

  • 共有スキーマを使用してOracleデータベースにアクセスするディレクトリ・ユーザー。

    このタイプのディレクトリ・ユーザーは、共有スキーマ(データベース・ユーザー)にマップされるディレクトリ・グループの一部となることで、データベース内の共有スキーマに接続できます。共有スキーマを使用すると、Active Directoryで集中的なデータベース・ユーザー管理が可能になります。排他スキーマ(次で説明)を使用するよりも推奨されるベスト・プラクティスです。スキーマに関連付けられているユーザーが1人(たとえば、データベース・バックアップを担当する管理者)のみであっても、関連するすべてのデータベースで変更するのではなく、Active Directoryでのみ変更すればいいので、別のバックアップ管理者の追加や既存の管理者の削除も、容易に管理することができます。

    ユーザーには、Active Directory内のグループにマップされているグローバル・ロールを使用して、各自のタスクに適した追加権限が付与されます。この設計では、ユーザーは組織内で各自のタスクを変更し、Active Directory内の新しいグループを介して新しいデータベース権限を持つことができます。

    Active Directoryユーザーが、同じデータベース上の異なる共有スキーマにマップされるActive Directoryで、誤って(または故意に)複数グループのメンバーになっている可能性があります。そのユーザーに、データベース・スキーマへの排他的マッピングもある可能性があります。ログイン時に、ユーザーに複数のスキーマ・マッピングがありえる場合は、次の優先順位ルールが適用されます。

    • ユーザーに排他的マッピングが存在する場合、そのマッピングは他の共有マッピングより優先されます。

    • 1人のユーザーに複数の共有スキーマ・マッピングが存在する場合、スキーマID (USER_ID)が最も低い共有ユーザー・マッピングが優先されます。

    予期しないスキーマ・マッピングが発生しないように、ユーザーごとに可能なマッピングは1つにすることをお薦めします。

  • 排他的にマップされたグローバル・ユーザー(2層および3層アプリケーションの標準Oracle Databaseユーザー)、またはデータベース内で権限が直接付与されているユーザー。

    グローバル・ロールを使用してこれらのユーザーに権限を付与することをお薦めします。このタイプの権限付与では、ユーザーの権限およびロールを集中管理することで認可管理が容易になり、ユーザーの権限およびロールを更新するために各データベースにログインする必要がありません。

  • 管理者権限SYSDBA、SYSOPER、SYSBACKUP、SYSDG、SYSKMおよびSYSRACを持つ管理グローバル・ユーザー。

    グローバル・ロールを介してこれらの管理権限を付与することはできません。これらの管理権限をActive Directoryユーザーに付与するには、データベース・ユーザー・アカウントにシステム管理権限がすでに付与されているデータベース・ユーザーに、(排他的または共有スキーマを使用して)ディレクトリ・ユーザーをマップする必要があります。

関連トピック

親トピック: Microsoft Active Directoryによる集中管理ユーザーの概要

集中管理ユーザーに対するOracleマルチテナント・オプションの影響

PDBユーザーは、中央のMicrosoft Active Directory、または異なるMicrosoft Active Directoryに接続できます。

すべてのPDBおよびルート・コンテナで1つの構成を共有できます。これにより、CDB全体で、共有されている構成に基づいて、単一のActive Directoryサーバー、1つのWindowsドメイン内の複数のActive Directoryサーバー、または信頼できるWindowsドメイン内の複数のActive Directoryサーバーに対して、ユーザーを認証および認可できます。あるいは、個々のPDBでは、個々の構成に基づいて、同じWindowsドメイン内または異なる(信頼できる、または信頼できない) Windowsドメイン内の異なるActive Directoryサーバーに対してユーザーを認証および認可できます。

親トピック: Microsoft Active Directoryによる集中管理ユーザーの概要

Oracle DatabaseとMicrosoft Active Directoryの統合の構成

Microsoft Active Directoryを使用してユーザーを認証および認可するには、OracleデータベースからActive Directoryへの接続を構成する必要があります。

親トピック: Microsoft Active Directoryによる集中管理ユーザーの構成

Oracle DatabaseとMicrosoft Active Directory接続の構成について

この接続を構成する前に、Microsoft Active Directoryのインストールと構成が完了している必要があります。

Active DirectoryでOracleサービス・ディレクトリ・ユーザーを作成し、Active DirectoryへのOracle Database接続を構成した後、認証のタイプに基づいて、パスワード、Kerberos、または公開キー・インフラストラクチャ(PKI)認証に対応してデータベースとActive Directoryを構成する必要があります。データベース・ユーザーとグローバル・ロールをActive Directoryユーザーおよびグループにマッピングする前に、Active Directoryユーザーおよびグループが作成されていることを確認する必要があります。CREATE USER、CREATE ROLE、ALTER USER、ALTER ROLEのSQL文をGLOBALLY句とともに使用して、データベース・ユーザーとグローバル・ロールをActive Directoryユーザーおよびグループにマップします。Active Directoryシステム管理者は、要件に対応するためにActive Directoryユーザーからなる新しいActive Directoryグループを設定する必要があります。

Active Directoryシステム管理者は、SASLバインドの有無にかかわらずActive Directory接続を設定します。Oracle Databaseは、自動的にActive Directory接続をまずSASLバインドで試行し、失敗した場合はSASLバインドなしで試行しますが、引き続きTLSで保護されます。これは、Microsoft Active Directory管理者がActive DirectoryでSASL設定をどのように構成しているかにかかわらず、SASLバインドが成功しなかった場合でもOracleデータベースが接続することを意味します。

親トピック: Oracle DatabaseとMicrosoft Active Directoryの統合の構成

Microsoft Active Directoryへの接続

Oracleデータベースの作成中にMicrosoft Active Directory接続を構成するか、または既存のOracleデータベースとのMicrosoft Active Directoryの接続を構成できます。

親トピック: Oracle DatabaseとMicrosoft Active Directoryの統合の構成

ステップ1: Microsoft Active DirectoryでのOracleサービス・ディレクトリ・ユーザー・アカウントの作成

Oracleサービス・ディレクトリ・ユーザー・アカウントは、Oracle DatabaseとLDAPディレクトリ・サービス間の相互作用に使用されます。

Oracleサービス・ディレクトリ・ユーザー・アカウントは、Oracle DatabaseとLDAPディレクトリ・サービス間の相互作用の他に、Kerberosにも使用できます。
このアカウントは、Active DirectoryにログインしてActive Directoryのユーザーおよびグループ情報を問い合せる場合、ログインの成功または失敗を更新する場合、Kerberosが構成されているときにKerberos認証を更新する場合に、Oracle Databaseが使用するActive Directoryアカウントです。このアカウントに必要な最低限の権限は、(データベースにログインするActive Directoryユーザーの) Read properties権限であり、Active Directoryユーザーによってデータベース・パスワード認証が使用される場合は、Write lockoutTime (Active Directoryユーザーのプロパティ)権限です。
  1. アカウントを作成して権限を付与できる権限を持つユーザーとして、Microsoft Active Directoryにログインします。
  2. Oracleサービス・ディレクトリ・ユーザー・アカウントをActive Directoryユーザーとして作成します。
    理想的には、ルート・ディレクトリに管理対象サービス・アカウントを作成します。ユーザーが使用するドメインによっては、このアカウントを子ドメインに作成することもできます。子ドメインのサービス・アカウントは、他の信頼できるドメインのユーザーを認証できます。次のガイドラインに従ってください。

    • すべてのActive Directoryユーザーが1つのドメインに配置されている場合、そのドメインでこのアカウントを作成します。このようにすると、パフォーマンスが向上します。

    • 次の場合は、Windows Active Directoryルート・ドメインでこのアカウントを作成します。

      • Active Directoryユーザーが、異なるドメインにある場合。

      • Active Directoryに複数のWindowsドメインがあるため、CMUが複数のドメインをサポートできる場合。

  3. Oracleサービス・ディレクトリ・ユーザー・アカウントに、Active Directoryの(データベースにログインするActive Directoryユーザーの) Read properties権限と、Write lockoutTime (パスワード認証を使用するActive Directoryユーザーのプロパティ)権限を付与します。
ステップ2: パスワード認証のためにパスワード・フィルタをインストールしてMicrosoft Active Directoryスキーマを拡張

Active DirectoryサーバーでOracle opwdintg.exe実行可能ファイルを使用してパスワード・フィルタをインストールし、Active Directoryスキーマを拡張できます。

認証方法がKerberosまたはSSLの場合、このステップを実行する必要はありません。opwdintg.exe実行可能ファイルは、Oracleパスワード・フィルタをインストールしてActive Directoryスキーマを拡張し、Active DirectoryでOracle Databaseのパスワード認証を可能にするActive Directoryグループを作成します。このプロシージャは、ユーザー・アカウントのActive DirectoryスキーマにorclCommonAttribute属性を追加します。

ノート:

Oracleデータベースへのログインにパスワード認証を使用する必要がある場合、ドメインのすべてのWindowsドメイン・コントローラにOracleパスワード・フィルタをインストールして、このドメインのActive DirectoryユーザーにOracleパスワード・ベリファイアが生成されるようにする必要があります。

また、orclCommonAttributeはActive DirectoryユーザーのOracleパスワード・ベリファイアを格納することに注意してください。この属性は、他のOracle製品またはエンタープライズ・ユーザー・セキュリティなどの機能によるパスワード認証にも使用されます。セキュリティを考慮して、Oracleサービス・ディレクトリ・ユーザー以外は、全員orclCommonAttribute属性にアクセスすることを拒否する必要があります。

  1. Oracleデータベース・サーバー・ソフトウェアをインストールした後、$ORACLE_HOME/binディレクトリに移動します。
  2. opwdintg.exe (Oracle Password Integration)ユーティリティを探します。
  3. 安全なコピー方法(sftpなど)を使用して、opwdintg.exeを各Windowsドメイン・コントローラの一時ディレクトリ(C:\tempなど)にコピーします。
  4. Active Directory管理者としてWindowsコンピュータに接続します。
    現在、opwdintg.exeユーティリティには英語版のWindows OSが必要です。
  5. Windows OSの言語設定が英語であることを確認してください。
  6. 各Windowsドメイン・コントローラでopwdintg.exeユーティリティを実行します。
    opwdintg.exeユーティリティを実行するには、次のいずれかの方法を使用します。
    • Windowsエクスプローラを開き、opwdintg.exeユーティリティをダブルクリックします。
    • Windowsのコマンド・プロンプトを開き、次のステップを実行します。
      1. opwdintg.exeユーティリティがあるディレクトリに移動します。例:
        cd c:\temp
      2. 次のコマンドを入力して、コマンドラインからユーティリティを実行します。 
        .\opwdintg.exe
  7. 次のプロンプトに対して入力します:
    • ADスキーマを拡張しますか。[はい/いいえ]:Yesと入力します。

      Active Directoryスキーマを拡張するには、Windows OSの言語設定を英語にする必要があります。

    • このドメインのスキーマ拡張は永続的です。続行しますか。[はい/いいえ]: Yesと入力します。

      次のことに注意してください。

      • Active Directoryスキーマを拡張できるのは1回のみです。再度スキーマを拡張しようとすると、エラー・メッセージが表示されますが、このエラーは無視できます。

      • このステップでは、次の3つのベリファイア・グループを作成します。これらのグループがすでに存在する場合は、エラーが表示されますが、これらのエラーは無視できます。

        • ORA_VFR_MD5は、Oracle Database WebDAVクライアントを使用する場合に必要です。

        • ORA_VFR_11Gにより、Oracle Database 11Gパスワード・ベリファイア機能の使用が有効になります。

        • ORA_VFR_12Cにより、Oracle Database 12Cパスワード・ベリファイアの使用が有効になります。

      • Active Directoryスキーマをバックアップしていない場合、いったん拡張するとActive Directoryスキーマ拡張を元に戻すことはできません。

      次の2つのプロンプトは、パスワード・フィルタがインストール済かどうかによって異なります。

    • Found password filter installed already.削除しますか。[はい/いいえ]: パスワード・フィルタがすでにインストールされている場合、このプロンプトが表示されます。ほとんどの場合、フィルタを削除しないようにNoと入力します。

      Yesと入力してパスワード・フィルタを削除する場合は、opwdintg.exeを再実行して、これらのプロンプトの完了後にパスワード・フィルタを再インストールする必要があります。そうせずにコンピュータを再起動すると、Active Directoryユーザーがパスワードを変更したときにパスワード・ベリファイアが生成されません。

    • Oracleパスワード・フィルタをインストールしますか。[はい/いいえ]: パスワード・フィルタがまだインストールされていない場合、このプロンプトが表示されます。「Yes」を入力します。
    • この変更にはマシンの再起動が必要です。今すぐ再起動しますか。[はい/いいえ]: Yesと入力します。
ステップ3: Oracle Databaseソフトウェアのインストール(必要な場合)

この操作をまだ実行していない場合は、Oracle Universal Installer (OUI)を使用してOracleソフトウェアをインストールします。

データベース全体ではなく、Oracle Databaseソフトウェアをインストールすることのみが必要です。Oracleデータベース・ソフトウェアをインストールすると、Database Configuration Assistant (DBCA)を使用して、データベースの作成時にActive Directoryの集中管理ユーザーを構成できます。データベースの作成後にDBCAを使用して、または手動で、Active Directoryの集中管理ユーザーを構成することもできます。
  • 使用しているプラットフォームのOracle Databaseインストレーション・ガイドの手順に従って、Oracleソフトウェアをインストールします。
Oracleデータベース・ソフトウェアをインストールした後、DBCAを使用して、データベースの作成時にActive Directoryの集中管理ユーザーを構成できます。データベースの作成後にDBCAを使用して、または手動で、Active Directoryの集中管理ユーザーを構成することもできます。
ステップ4: dsi.oraまたはldap.oraファイルの作成

dsi.oraファイルとldap.oraファイルには、Active Directory用の集中管理ユーザーの接続を指定します。

親トピック: Microsoft Active Directoryへの接続

dsi.oraファイルとldap.oraファイルの比較

dsi.oraとldap.oraの使用方法は、他のサービスでldap.oraをどのように使用するかによって異なります。

dsi.oraファイルには、Active Directory用の集中管理ユーザーの接続を指定します。ldap.oraファイルには、Active Directoryサーバーへの接続も指定できます。ただし、各PDBに独自のldap.oraを設定することはできず、また、ldap.oraはネット・ネーミング・サービスなど他のサービスですでに使用されている(または将来使用される)可能性があるため、集中管理ユーザーに対してはdsi.oraを使用することをお薦めします。

dsi.oraファイルの使用について

dsi.oraファイルを使用して、集中管理ユーザーのActive Directoryサーバーを指定します。

Active Directoryサーバーを識別するには、dsi.oraファイルを手動で作成する必要があります。dsi.oraファイルには、ldap.oraファイルを配置できるのと同じ場所にある場合に、すべてのプラガブル・データベースのActive Directory接続情報を指定します。PDB固有のウォレット・ロケーションにあるdsi.oraファイルは、そのPDBのみのメインのdsi.oraファイルより優先されます。

ノート:

ネーミング・サービスにldap.oraを使用している場合は、Active Directory構成のCMUに対しldap.oraを変更しないでください。CMU-Active Directoryの構成には、dsi.oraのみを使用してください。

dsi.oraの配置

$ORACLE_HOMEの下でなく、$ORACLE_BASEの下の書き込み可能なファイルのディレクトリを使用することをお薦めします。Oracle Database18c以降、オプションで$ORACLE_HOMEディレクトリを読取り専用に設定できます。したがって、dsi.oraファイルを$ORACLE_HOME外のディレクトリに置いて、将来のリリースのdsi.ora構成に対応する必要があります。

dsi.oraの検索順序

dsi.oraファイルを作成すると、Oracle Databaseでは次の順序で検索されます。

  1. PDBでは、データベース・プロパティCMU_WALLETがディレクトリ・オブジェクトに設定されている場合、Oracle Databaseはそのディレクトリ・オブジェクトによって指定された場所のパスでこのプロパティを検索します。
  2. WALLET_LOCATION設定がsqlnet.oraファイルに含まれていると、ルート・コンテナの場合は、Oracleによって、sqlnet.ora内で指定されている場所が検索されます。PDBの場合は、Oracleによって、WALLET_LOCATION_specified_in_sqlnet.ora/pdb_guidディレクトリ内の、PDBごとのウォレット・ロケーションにおいてそれが検索されます。
  3. WALLET_LOCATION設定がsqlnet.oraファイルに含まれていない場合、Oracle Databaseはデフォルトのウォレット・ロケーションを検索します。
  4. Oracle Databaseがウォレット・ロケーションでdsi.oraを検出できない場合、Oracle Databaseは次の順序で検索します。これらは、Oracle Databaseがldap.oraファイルを検索する場所と同じです。
    1. $LDAP_ADMIN環境変数設定
    2. $ORACLE_HOME/ldap/adminディレクトリ
    3. $TNS_ADMIN環境変数設定
    4. $ORACLE_HOME/network/adminディレクトリ

dsi.oraを使用する場合

集中管理ユーザーのActive Directoryサーバーの識別には、dsi.oraのみを使用することをお薦めします。dsi.oraとldap.oraの両方がActive Directoryの集中管理ユーザー用に同じデータベース内に構成されていて、両方が同じディレクトリにある場合、dsi.oraはldap.oraファイルより優先されます。異なるディレクトリに配置されている場合、前述した場所の優先順位リストで最初に検出されたディレクトリを使用して、Active Directoryサーバーが検索されます。最初に検出されたdsi.oraまたはldap.oraのディレクトリ・サーバー・タイプがActive Directoryでない場合、集中管理ユーザーは有効になりません。

マルチテナント環境でのdsi.oraの使用

PDBごとのCMU_WALLETデータベース・プロパティをディレクトリ・オブジェクトに設定すると、個々のPDBのdsi.oraファイルは、このPDBごとのデータベース・プロパティで指定されたウォレット・ロケーションに配置されます。(CDBルートではなく、個々のPDBでCMU_WALLETを設定します。)CMU_WALLETプロパティは、WALLET_LOCATION設定よりも優先されます。

CMU_WALLETデータベース・プロパティが設定されておらず、sqlnet.oraファイル内のWALLET_LOCATIONパラメータが設定されている場合は、個々のPDBのdsi.oraファイルが、WALLET_LOCATION_specified_in_sqlnet.ora/pdb_guid/ディレクトリ内の、PDBごとのウォレットに配置されます。

CMU_WALLETデータベース・プロパテもsqlnet.oraファイル内のWALLET_LOCATIONパラメータも設定されていない場合、個々のコンテナのデフォルトのウォレット・ロケーションは、$ORACLE_BASE/admin/db_unique_name/pdb_guid/wallet/ディレクトリとなります。各PDBでデフォルトのウォレット・ロケーションを使用する場合は、CMU_WALLETデータベース・プロパティを設定しないでください。また、sqlnet.oraにWALLET_LOCATIONを設定しないでください。

db_unique_nameを検索するには、CDBルートに接続して次の問合せを実行します。 

SELECT DB_UNIQUE_NAME FROM V$DATABASE;

CDBルートからpdb_guidを検索するには、次の問合せを実行します。 

SELECT PDB_NAME,GUID FROM DBA_PDBS;

CMU_WALLETデータベース・プロパティがdsi.oraファイルに与える影響

CMU_WALLETデータベース・プロパティをディレクトリ・オブジェクトに設定すると、個々のPDBのdsi.oraファイルは、このPDBごとのデータベース・プロパティで指定されたウォレット・ロケーションに配置されます。データベース・プロパティは、PDBがオープンされている場合にのみ有効であることに注意してください。データベース・プロパティおよび関連するディレクトリ・オブジェクトの検索はオープンしているPDBに依存するため、これは、管理権限を持つActive Directoryユーザーが、CMU_WALLETデータベース・プロパティで指定された構成に基づいてアイドル状態のPDBを起動できないことを意味します。

たとえば、CMU_WALLETを使用してウォレット・ロケーションを設定するとします。PDBの作成時にPATH_PREFIX句を指定しなかった場合は、絶対パスを使用してディレクトリ・オブジェクトを作成し、次にPDBでCMU_WALLETデータベース・プロパティを設定する必要があります。例: 

CREATE OR REPLACE DIRECTORY example_dir AS '/u01/app/oracle/pdb1/cmu/wallet';
ALTER DATABASE PROPERTY SET CMU_WALLET='EXAMPLE_DIR';

これにより、Oracle Databaseは、ディレクトリ・パス/u01/app/oracle/pdb1/cmu/wallet/で指定されているウォレット・ロケーションにあるdsi.oraファイルを検索できます。

PDBの作成時にPATH_PREFIX句を指定した場合、相対パスを使用してディレクトリ・オブジェクトを作成し、PDBでCMU_WALLETデータベース・プロパティを設定する必要があります。例: 

CREATE OR REPLACE DIRECTORY example_dir AS 'cmu/wallet';
ALTER DATABASE PROPERTY SET CMU_WALLET='EXAMPLE_DIR';

ディレクトリ・オブジェクト名(example_dir)が二重引用符で囲まれていない場合、CREATE OR REPLACE DIRECTORY文では大/小文字が区別されず、小文字でもかまいません。ただし、これをALTER DATABASE PROPERTY SET CMU_WALLET文で使用する場合、対応するディレクトリ・オブジェクト名は大文字である必要があります。

データベース・プロパティCMU_WALLETによって設定されたウォレット・ロケーションを検索するには、次のSQL文を実行します。 

SELECT DIRECTORY_PATH FROM DBA_DIRECTORIES WHERE DIRECTORY_NAME = (SELECT PROPERTY_VALUE FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME='CMU_WALLET');

データベース・プロパティCMU_WALLETによって指定されたウォレット・ロケーションを設定解除するには、次の文を実行します。 

ALTER DATABASE PROPERTY REMOVE CMU_WALLET;

sqlnet.oraのWALLET_LOCATIONパラメータがdsi.oraに与える影響

sqlnet.oraにWALLET_LOCATIONパラメータを設定する場合、または設定しない場合、次の効果があります。

  • WALLET_LOCATIONがsqlnet.oraに設定されていない場合、$ORACLE_BASE/admin/db_unique_name/walletディレクトリにあるCDBルート・コンテナのデフォルトのウォレット・ディレクトリにdsi.oraを配置することもできます。ただし、CDBルート・コンテナはCDBデータベース全体ではなくActive Directoryにのみ接続します。
  • WALLET_LOCATIONがsqlnet.oraに設定されている場合は、そのウォレットの場所にdsi.oraを配置でき、また、CDBルート・コンテナはCDBデータベース全体ではなくActive Directoryにのみ接続します。
dsi.oraファイルの作成

dsi.ora構成ファイルには、集中管理ユーザーのActive Directoryサーバーを検出するための情報を設定します。

dsi.ora構成ファイルを使用するには:
  1. Oracleデータベースが存在するホストにログインします。
  2. dsi.oraファイルの検索順序に基づいて、dsi.oraファイルを使用するディレクトリを選択します。(関連トピックを参照してください。)このディレクトリが存在しない場合は、作成します。次に、このディレクトリに移動してdsi.oraファイルを作成します。
  3. dsi.oraファイルに次のパラメータを追加します。
    • DSI_DIRECTORY_SERVERS、Active Directoryサーバーのホストおよびポート番号と代替ディレクトリ・サーバーを指定します。ディレクトリ・サーバー名は完全修飾名である必要があります。複数のWindowsドメインを使用する場合は、ここに複数のActive Directoryサーバーを設定することもできます。例:
      DSI_DIRECTORY_SERVERS = (AD-server.production.examplecorp.com:389:636, sparky.production.examplecorp.com:389:636)
    • DSI_DEFAULT_ADMIN_CONTEXT、Active Directoryユーザーおよびグループが配置されている検索ベースを設定します。このパラメータはオプションです。デフォルトでは、Active Directoryのユーザーおよびグループは、Active Directoryのデフォルト・ネーミング・コンテキストで検出されます。このパラメータを設定しないことをお薦めします。このパラメータは、Active Directoryユーザーおよびグループの検索範囲を制限する場合にのみ設定します。例:
      DSI_DEFAULT_ADMIN_CONTEXT = "OU=sales,DC=production,DC=examplecorp,DC=com"
    • DSI_DIRECTORY_SERVER_TYPE、Active Directoryサーバー・アクセスを決定します。これはActive DirectoryのADに設定する必要があります。この値は大文字で入力してください。
      DSI_DIRECTORY_SERVER_TYPE = AD
ldap.oraファイルの使用について

ldap.oraファイルを使用して、集中管理ユーザー用のActive Directoryサーバーを指定できます。

ネット・ネーミング・サービスなど別の目的ですでにldap.oraファイルを使用している場合は、dsi.oraファイルを使用して、ユーザー認証および認可に使用するActive Directoryに接続するように集中管理ユーザーを構成する必要があります。Active Directoryがすでにネット・ネーミング・サービスに使用されている場合でも、集中管理ユーザーのActive Directoryサーバーを識別するために、dsi.oraファイルを作成し、使用する必要があります。データベースが現在、別のサービスにldap.oraを使用していない場合でも、今後ネット・ネーミング・サービスにldap.oraを使用する場合はdsi.oraを使用することをお薦めします。

ldap.oraがネーミング・サービスに使用されている場合は、ldap.oraを変更しないでください。CMU-Active Directoryの構成には、dsi.oraのみを使用してください。

ldap.oraを使用する利点

ldap.oraを使用する利点は、DBCAグラフィカル・インタフェースまたはDBCAサイレント・モードを使用してActive Directoryサーバーへの接続の構成を完了できることです。dsi.oraを使用する場合、Active Directoryへの接続の構成を完了するステップを個別に実行する必要があります。

ldap.oraの配置

通常、ldap.oraファイルは$ORACLE_HOME/network/adminディレクトリに格納されます。WALLET_LOCATIONが$ORACLE_HOME/network/adminに設定されていないかぎり、ldap.oraファイルは通常、sqlnet.oraファイルで指定されているWALLET_LOCATIONと同じディレクトリには指定できません。

ldap.oraの検索順序

ldap.oraファイルを作成すると、Oracle Databaseでは次の順序で検索されます。

  1. $LDAP_ADMIN環境変数設定

  2. $ORACLE_HOME/ldap/adminディレクトリ

  3. $TNS_ADMIN環境変数設定

  4. $ORACLE_HOME/network/adminディレクトリ

ldap.oraの内容の変更

データベースの起動後にldap.oraの内容を変更した場合は、データベース・インスタンスを再起動するか次のDDLを再実行して、ldap.ora内の更新された内容を有効にする必要があります。 

ALTER SYSTEM SET LDAP_DIRECTORY_ACCESS = 'PASSWORD';

LDAP_DIRECTORY_ACCESSパラメータは、CDBルートではなく各PDBで設定する必要があります。

ldap.oraファイルの作成

このステップでは、ldap.oraがネット・ネーミング・サービスに使用されておらず、集中管理ユーザーのActive Directoryとの接続を設定するために使用できると想定しています。

  1. Oracleデータベースが存在するホストにログインします。
  2. ldap.oraファイルの検索順序に基づいて、ldap.oraファイルを使用するディレクトリを選択します。(関連トピックを参照してください。)このディレクトリが存在しない場合は、作成します。次に、このディレクトリに移動してldap.oraファイルを作成します。
  3. ldap.oraファイルが存在しない場合、テキスト・エディタを使用して作成します。
    ldap.oraファイルが存在する場合は、このファイルのバックアップを作成してから、ldap.oraを開きます。
  4. ldap.oraファイルに次のパラメータを追加します。
    • DIRECTORY_SERVERS、Active Directoryサーバーのホストおよびポート番号と代替ディレクトリ・サーバーを指定します。複数のWindowsドメインを使用する場合は、ここに複数のActive Directoryサーバーを設定することもできます。ディレクトリ・サーバー名は完全修飾名である必要があります。例: 
      DIRECTORY_SERVERS = (AD-server.production.examplecorp.com:389:636, sparky.production.examplecorp.com:389:636)
    • DEFAULT_ADMIN_CONTEXT、Active Directoryユーザーおよびグループが配置されている検索ベースを設定します。このパラメータはオプションです。デフォルトでは、Active Directoryのユーザーおよびグループは、Active Directoryのデフォルト・ネーミング・コンテキストで検出されます。このパラメータを設定しないことをお薦めします。このパラメータは、Active Directoryユーザーおよびグループの検索範囲を制限する場合にのみ設定します。例:
      DEFAULT_ADMIN_CONTEXT = "OU=sales,DC=production,DC=examplecorp,DC=com"
    • DIRECTORY_SERVER_TYPE、LDAPサーバー・アクセスを決定します。これはActive DirectoryのADに設定する必要があります。この値は大文字で入力してください。
      DIRECTORY_SERVER_TYPE = AD
ステップ5: セキュアな接続のためのActive Directory証明書のリクエスト

dsi.oraまたはldap.oraファイルの構成が完了したら、セキュアな接続のためのMicrosoft Active DirectoryとOracle Databaseの証明書を準備します。

  • Active Directory管理者からActive Directory証明書をリクエストします。
ステップ6: セキュアな接続のためのウォレットの作成

Active Directory証明書をコピーすると、それをOracleウォレットに追加できるようになります。

  1. 証明書テキスト・ファイル(AD_CA_Root_cert.txtなど)をActive Directoryサーバーから一時ディレクトリ(ローカル・ホストの/tmpなど)にコピーします。
    ウォレット・ロケーションがCMU_WALLETデータベース・プロパティで指定されておらず、sqlnet.oraファイルでも指定されていない場合、データベースはこの順序で次の場所でウォレットを検索します。ディレクトリの場所を作成する必要があります。
    CDBルート・コンテナの場合:
    1. $ORACLE_BASE/admin/db_unique_name/wallet/
    2. $ORACLE_HOME/admin/db_unique_name/wallet/

    PDBの場合:

    1. $ORACLE_BASE/admin/db_unique_name/pdb_guid/wallet/
    2. $ORACLE_HOME/admin/db_unique_name/pdb_guid/wallet/
    コンテナごとに、ウォレット・ファイルを$ORACLE_BASEの下のデフォルトのウォレット・ロケーション、つまり$ORACLE_BASE/admin/db_unique_name/pdb_guid/wallet/ディレクトリに配置することをお薦めします。
    db_unique_nameを検索するには、CDBルートに接続して次の問合せを実行します。
    SELECT DB_UNIQUE_NAME FROM V$DATABASE;

    CDBルートからpdb_guidを検索するには、次の問合せを実行します。 

    SELECT PDB_NAME,GUID FROM DBA_PDBS;

    ウォレット・ロケーションの指定にCMU_WALLETデータベース・プロパティを使用している場合、指定したウォレットの場所は個々のPDB用です。

    sqlnet.oraを使用してウォレット・ロケーションを指定する場合、指定されているウォレット・ロケーションはルート・コンテナ用です。各PDBでは、そのウォレットはWALLET_LOCATION_specified_in_sqlnet.ora/pdb_guidにあります。個々のPDB dsi.oraをWALLET_LOCATION_specified_in_sqlnet.ora/pdb_guidに配置することもできます。

  2. 新規ウォレットの作成
    次のコマンドは、指定したパスに自動ログイン・ウォレットを作成します。
    orapki wallet create -wallet wallet_location -auto_login
Enter password: password
  3. Active Directory (最初のステップで作成)で検索を実行するためのOracleサービス・ディレクトリ・ユーザー・アカウントのユーザー名でウォレットにエントリを作成します。
    例: 
    mkstore -wrl wallet_location -createEntry ORACLE.SECURITY.USERNAME oracle
  4. Oracleサービス・ディレクトリ・ユーザー・アカウントのDNを使用してウォレットにエントリを作成します。
    例:
    mkstore -wrl wallet_location -createEntry ORACLE.SECURITY.DN cn=oracle,cn=users,dc=production,dc=examplecorp,dc=com

    この例では、DNSドメインがproduction.examplecorp.comであることをDNが示しています。Windowsドメイン名は単にproductionです。

  5. Oracleサービス・ディレクトリ・ユーザー・アカウントのユーザー・パスワード資格証明を使用してウォレットにエントリを作成します。
    例:
    mkstore -wrl wallet_location -createEntry ORACLE.SECURITY.PASSWORD password
  6. 証明書をウォレットに追加します。Active Directory管理者から受信したActive Directory証明書を使用します。
    例:
    orapki wallet add -wallet wallet_location -cert /tmp/AD_CA_Root_cert.txt -trusted_cert

    sqlnet.ora内でWALLET_LOCATIONが指定されている場合は、ルート用または個々のPDB用の、sqlnet.ora内で指定されているこのウォレットに、必ずActive Directory証明書を追加する必要があります。異なるPDBで同じActive DirectoryルートCA証明書を使用する場合は、その証明書をこのウォレットに1回のみ追加します。

  7. 資格証明を検証します。
    例:
    orapki wallet display -wallet wallet_location
    出力は次のようになります。
    Requested Certificates: 
User Certificates: 
Oracle Secret Store entries: 
ORACLE.SECURITY.DN 
ORACLE.SECURITY.PASSWORD 
ORACLE.SECURITY.USERNAME 
Trusted Certificates: 
Subject: CN=ADSVR,DC=production,DC=examplecorp,DC=com

    WALLET_LOCATION_specified_in_sqlnet.ora/pdb_guidの場合、出力は次のようになります。 

    Requested Certificates:
User Certificates:
Oracle Secret Store entries:
ORACLE.SECURITY.DN
ORACLE.SECURITY.PASSWORD
ORACLE.SECURITY.USERNAME
Trusted Certificates:
ステップ7: Microsoft Active Directory接続の構成

次に、これまでの設定を使用してデータベースをActive Directoryに接続します。

親トピック: Microsoft Active Directoryへの接続

Microsoft Active Directory接続の構成について

Microsoft Active Directory接続を構成するには、データベースでパラメータを設定するか、DBCAを使用します。

DBCAでは、集中管理ユーザー用に構成されたldap.oraのみが認識され、推奨されたデフォルトの場所にのみウォレットが作成されます。デフォルトのウォレット・ロケーションを使用するには、PDBのCMU_WALLETデータベース・プロパティを設定しないでください。また、sqlnet.oraにWALLET_LOCATIONを設定しないでください。

ノート:

CMU-Active Directoryにはdsi.oraを使用することをお薦めします。

Databaseシステム・パラメータを使用した手動アクセスの構成

LDAP固有のOracle Databaseのシステム・パラメータを使用して、Active Directoryサービス接続を手動で構成できます。

  1. dsi.oraファイルまたはldap.oraファイルを作成し、ウォレットを作成したことを確認します。
  2. ALTER SYSTEMシステム権限があるユーザーとして適切なPDBにログインします。
    例: 
    sqlplus sec_admin@pdb_name
Enter password: password

    CDB内の使用可能なPDBを確認するには、CDBルート・コンテナにログインし、DBA_PDBSデータ・ディクショナリ・ビューのPDB_NAME列を問い合せます。現在のコンテナを確認するには、show con_nameコマンドを実行します。

  3. LDAPディレクトリ・アクセスのタイプを決定するLDAP_DIRECTORY_ACCESSパラメータを変更します。

    CDBルートではなく各PDBでLDAP_DIRECTORY_ACCESSを設定します。CDBルートでこのパラメータを設定すると、ルートにのみ適用され、PDBには適用されません。

    有効な値はPASSWORDおよびNONE (接続を無効化する場合)です。PASSWORDにはActive Directoryサーバー証明書が必要であり、ウォレットを作成する場合は、Oracle用のActive Directoryサービス・ユーザー・アカウントの資格証明を含める必要があります。

    例:
    ALTER SYSTEM SET LDAP_DIRECTORY_ACCESS = 'PASSWORD';

    spfileまたはinit.oraファイルでこのパラメータを設定することもできます(init.oraファイルが使用される場合)。その後、データベースを再起動します。

  4. LDAP_DIRECTORY_SYSAUTHパラメータをYESに設定して、Active Directoryの管理ユーザーがSYSDBA、SYSOPER、SYSBACKUP、SYSDG、SYSKMまたはSYSRAC管理権限を使用してOracle Databaseにログインできるようにします。
    CDBルートではなく各PDBでLDAP_DIRECTORY_SYSAUTHを設定します。CDBルートでこのパラメータを設定すると、ルートにのみ適用され、PDBには適用されません。
    このパラメータをNOに設定すると、Active Directoryの集中管理ユーザーは、これらの権限でOracleデータベースにログインできません。 
    ALTER SYSTEM SET LDAP_DIRECTORY_SYSAUTH = YES SCOPE=SPFILE ;

    spfileまたはinit.oraファイルでこのパラメータを設定することもできます(init.oraファイルが使用される場合)。その後、データベースを再起動します。

  5. SYSDBA管理権限があるユーザーとしてルートに接続します。
  6. PDBをクローズしてから再度オープンします。
    ALTER PLUGGABLE DATABASE pdb_name CLOSE IMMEDIATE;
ALTER PLUGGABLE DATABASE pdb_name OPEN;
PDBを再度オープンした後は、SYSDBA管理権限でPDBにログインし、LDAPパラメータ設定を次のように確認できます。
show parameter ldap
Database Configuration Assistant GUIを使用したアクセスの構成

Oracle Database Configuration Assistant (DBCA)は、LDAP接続構成を完了し、ウォレットを自動的に作成して、使用するActive Directory証明書を格納します。DBCAは、ldap.oraがCMU-ActiveDirectory用に構成されている場合にのみ動作します。

この手順では、Oracleソフトウェアがすでにインストールされており、集中管理ユーザーのActive Directoryサーバーを識別するためにldap.oraファイル(dsi.oraではなく)を使用していることを前提としています。データベース・ソフトウェアをまだインストールしていない場合は、Oracle Universal Installer (OUI)を使用してソフトウェアをインストールできます。その後、DBCAを使用してデータベースを作成すると同時に、Active Directoryの集中管理ユーザーの接続を構成できます。
  1. Oracle Databaseソフトウェアがインストールされているホストに、管理権限を持つユーザーとしてログインします。
  2. DBCAを起動します。
    デフォルトでは、DBCAユーティリティは$ORACLE_HOME/binディレクトリにあります。
    例:
    cd $ORACLE_HOME/bin
./dbca
  3. 「ネットワーク構成」オプション(またはデータベースの作成時にネットワーク構成オプションに進んだ場合)を選択します。
    「ネットワーク構成詳細の指定」ウィンドウが表示されます。「ディレクトリ・サービス統合」領域が表示されない場合、ldap.oraファイルが正しく構成されていません。以前に設定したldap.ora構成を確認し、ファイルを修正したら、DBCAを再実行してください。
  4. 「ディレクトリ・サービス統合」領域で、次の手順を実行します。
    • 「サービス・ユーザー名」フィールドに、Oracleサービス・ディレクトリ・ユーザー・アカウントの名前を入力します。
    • 「パスワード」フィールドに、Oracleサービス・ディレクトリ・ユーザー・アカウントのパスワードを入力します。
    • 「サービス・ユーザーDN」フィールドに、Oracleサービス・ディレクトリ・ユーザー・アカウントのDNを入力します。DNはActive DirectoryサーバーからまたはActive Directoryシステム管理者から直接取得できます。
    • 「アクセス・タイプ」では、リストから認証タイプを選択します(「PASSWORD」など)。(この設定により、LDAP_DIRECTORY_ACCESSパラメータが設定されます。)必要に応じて、「管理権限の認証を許可」チェックボックスを選択し、Active Directoryユーザーが管理権限(SYSDBA、SYSOPER、SYSBACKUPなど)を使用してデータベース・スキーマを認証および使用できるようにします。そうしないと、Active Directoryの集中管理ユーザーは、管理権限でデータベースにログインできません。(この設定はLDAP_DIRECTORY_SYSAUTHパラメータに対応しています。)
    • 「証明書ファイルの場所」フィールドにActive Directory証明書のパスを指定します。マルチテナント環境では、DBCAがデータベース・インスタンス接続用のActive Directory接続を認識および設定します。別のActive DirectoryサーバーをPDBに接続する場合は、PDB接続を手動で構成する必要があります。
    • 「ウォレット・パスワード」および「パスワードの確認」フィールドに、Oracleサービス・ディレクトリ・ユーザー・アカウントの証明書および資格証明を格納するOracleウォレットのパスワードを入力し、確認のためもう一度入力します。その後、DBCAはサービス・ディレクトリ・ユーザー・アカウントを自動的に検証し、ウォレットを作成してユーザー資格証明を格納し、証明書をインポートします。
  5. 「終了」ページになるまで、「次」をクリックします。
  6. 「終了」をクリックします。
Database Configuration Assistantのサイレント・モードを使用したアクセスの構成

ldap.ora (dsi.oraではない)が正しい場所に作成され、適切に構成されている場合、DBCAサイレント・モードで、Microsoft Active DirectoryとOracle Databaseの統合のために新しいデータベースを作成または既存のデータベースを変更できます。

  1. 統合に使用されるOracleデータベースが含まれるホストにログインします。
  2. 正しい場所に正しいコンテンツを使用してldap.oraが作成されていることを確認してください。
  3. sqlnet.oraファイルにWALLET_LOCATIONパラメータが指定されていないことを確認します。
  4. サイレント・モードでDatabase Configuration Assistant(DBCA)を実行します。

    CDBのルート・コンテナを構成するには、次のようにします。

    cd $ORACLE_HOME/bin

./dbca -silent -configureDatabase -sourceDB db_name
-registerWithDirService true
-dirServiceUser oracle
-dirServiceUserName cn=oracle,cn=users,dc=production,dc=examplecorp,dc=com
-dirServicePassword service_user_password
-ldapDirectoryAccessType PASSWORD
-useSYSAuthForLDAPAccess true
-dirServiceCertificatePath /tmp/AD_CA_Root_cert.txt
-walletPassword wallet_password

    CDBでプラガブル・データベースを構成するには、次のようにします。

    cd $ORACLE_HOME/bin

./dbca -silent -configurePluggableDatabase -pdbName pdb_name -sourceDB db_name
-registerWithDirService true
-dirServiceUser oracle
-dirServiceUserName cn=oracle,cn=users,dc=production,dc=examplecorp,dc=com
-dirServicePassword service_user_password
-dirServiceCertificatePath /tmp/AD_CA_Root_cert.txt
-walletPassword wallet_password
ステップ8: Oracleウォレットの確認

orapkiユーティリティでは、このデータベースのウォレットが正常に作成されたことを確認できます。

  1. データベースが統合に使用されるホストにログインします。
  2. ウォレットを含むディレクトリに移動します。
    PDBのCMU_WALLETデータベース・プロパティが設定されておらず、WALLET_LOCATIONがsqlnet.oraに設定されていない場合、デフォルトのウォレット・ロケーションは次のようになります。

    ウォレット・ロケーションは、次のいずれかのディレクトリです。

    • CDBルートの場合、ウォレット・ロケーションは $ORACLE_BASE/admin/db_unique_name/wallet/ディレクトリです。
    • PDBの場合、ウォレット・ロケーションは$ORACLE_BASE/admin/db_unique_name/pdb_guid/wallet/ディレクトリです。
  3. コマンドラインで、次のコマンドを入力します。

    ls -ltr wallet_location (walletディレクトリにウォレット・ファイルが含まれていることを確認するため)

    例:

    $ ls -ltr $ORACLE_BASE/admin/db_unique_name/pdb_guid/wallet/
total 12
-rw------- 1 creator_user creator_group 1597 Nov 27 22:47 cwallet.sso
-rw------- 1 creator_user creator_group 1552 Nov 27 22:47 ewallet.p12
-rw-rw-r-- 1 creator_user creator_group 86   Nov 27 22:48 dsi.ora

    orapki wallet display -wallet wallet_location (Oracleシークレット・ストアのエントリを検索するため)

    出力には次のエントリが含まれている必要があります。 

    Requested Certificates: 
User Certificates: 
Oracle Secret Store entries: 
ORACLE.SECURITY.DN 
ORACLE.SECURITY.PASSWORD 
ORACLE.SECURITY.USERNAME 
Trusted Certificates: 
Subject: CN=ADSVR,DC=production,DC=examplecorp,DC=com
ステップ9: 統合のテスト

統合をテストするには、ORACLE_HOME、ORACLE_BASE,およびORACLE_SID環境変数を設定してから、LDAPパラメータの設定を確認する必要があります。

  1. データベースが統合に使用されるホストにログインします。
  2. ORACLE_HOME、ORACLE_BASEおよびORACLE_SID環境変数を設定します。
    例:
    export ORACLE_HOME=/app/product/18.1/dbhome_1
export ORACLE_BASE=/app
export ORACLE_SID=sales_db
  3. SYSDBA管理権限があるユーザーとしてPDBにログインします。
    例:
    sqlplus sec_admin@pdb_name as sysdba
Enter password: password

    CDB内の使用可能なPDBを確認するには、CDBルート・コンテナにログインし、DBA_PDBSデータ・ディクショナリ・ビューのPDB_NAME列を問い合せます。現在のコンテナを確認するには、show con_nameコマンドを実行します。

  4. 次のようにLDAPパラメータの設定を確認します。
    show parameter ldap

    出力は次のようになります。

    NAME                          TYPE       VALUE
---------------------------   ---------  -----------------
ldap_directory_access         string     PASSWORD 
ldap_directory_sysauth        string     YES

集中管理ユーザーの認証の構成

パスワード認証、Kerberos認証または公開キー・インフラストラクチャ(PKI)認証を構成できます。

親トピック: Microsoft Active Directoryによる集中管理ユーザーの構成

集中管理ユーザーに対するパスワード認証の構成

集中管理ユーザーに対するパスワード認証の構成では、Active Directoryでパスワード・フィルタを使用して、Oracle Databaseのパスワード・ベリファイアをActive Directoryに生成および格納する必要があります。

親トピック:集中管理ユーザーの認証の構成

集中管理ユーザーに対するパスワード認証の構成について

パスワード認証を構成するには、パスワード・フィルタをデプロイし、ユーザー属性を追加することによってActive Directoryスキーマを拡張し、Active Directoryで異なるバージョンのパスワード・ベリファイアを生成するためのグループを作成する必要があります。

Active Directoryユーザーが管理権限を使用してOracle Databaseにログインするには、Oracle Databaseでパスワード・ファイルも設定する必要があります。

パスワード認証の場合、Oracle DatabaseはActive Directoryで認証するためにldapbindコマンドを介してActive Directoryユーザーのパスワードを渡さないため、Oracleフィルタをインストールし、Active Directoryスキーマを拡張する必要があります。Active DirectoryにインストールするOracleフィルタにより、Active Directoryユーザーがパスワードを更新するときにOracle固有のパスワード・ベリファイアが作成されます。Oracleフィルタは、最初のインストール時には必要なOracleパスワード・ベリファイアをすべて生成するわけではありません。ユーザーがActive Directoryパスワードを変更したときに、そのユーザーのOracleパスワード・ベリファイアのみを生成します。

(サイトで必要な場合に)下位互換性を維持するため、Oracleフィルタでは、リリース11g、12c、および18cのOracle Databaseクライアントで機能するパスワード・ベリファイアを生成できます。Oracleパスワード・フィルタは、ORA_VFR_MD5 (WebDAVの場合)、ORA_VFR_11G (リリース11gの場合)およびORA_VFR_12C (リリース12cおよび18cの場合)という名前のActive Directoryグループを使用して、生成するOracle Databaseパスワード・ベリファイアを決定します。グループ・メンバー・ユーザーに対してOracleパスワード・ベリファイアを生成するには、Active Directoryで空のグループを作成する必要があります。これらは、Active Directoryユーザー用に生成される特定のベリファイアを指定する個別のグループです。たとえば、10人のディレクトリ・ユーザーが、Oracle Databaseリリース18cおよび12cクライアントとのみ通信する、新たに作成されたOracle Databaseリリース18cデータベースにログインする必要がある場合、Active DirectoryグループORA_VFR_12Cは10人のActive Directoryユーザーがメンバーになります。この10人のActive DirectoryユーザーがActive Directoryでパスワードを変更すると、Oracleフィルタではこれらのユーザーの12cベリファイアのみが生成されます(18cのベリファイアは12cのベリファイアと同じ)。Active DirectoryユーザーがOracleデータベースにログインする必要がもうない場合、Active Directoryユーザー用に生成されたOracleパスワード・ベリファイアをクリアするには、ORA_VFRグループからユーザーを削除し、このユーザーのパスワードを再設定します(またはパスワードの変更が必要)。このユーザーのorclCommonAttribute属性を手動でクリアすることもできます。Oracleパスワード・ベリファイアは、ユーザーがORA_VFRグループから削除されると生成されなくなります。

集中管理ユーザーのパスワード認証の構成

Active Directoryサーバーでパスワード認証構成を実行する必要があり、Active Directoryユーザーが管理権限でOracleデータベースにログインする必要がある場合は、Oracleデータベースでもパスワード認証構成を実行する必要があります。

  1. Oracle Databaseのパスワード・フィルタをデプロイし、Active Directoryスキーマを拡張します。
    このタスクを実行するためのユーティリティ・ツールopwdintg.exeは、$ORACLE_HOME/binにあります。このユーティリティは、Active Directoryにパスワード・フィルタをインストールし、Oracleパスワード・ベリファイアを保持するActive Directoryスキーマを拡張して、Active Directoryパスワード・ベリファイア・グループを作成します。WebDAV、11Gおよび12Cパスワード・ベリファイアを使用してクライアントに接続すると、パスワード・フィルタにより、Microsoft Active Directoryのユーザー・アカウントをOracleデータベースで認証できます。
    1. opwdintg.exe実行可能ファイルをデプロイするには、このファイルをActive Directoryサーバーにコピーし、Active Directory管理者にopwdintg.exeユーティリティ・ツールを実行させます。
    2. ユーザー・グループを作成および管理する権限を持つユーザーとして、Microsoft Active Directoryにログインします。
    3. パスワード・ベリファイアのユーザー・グループORA_VFR_MD5、ORA_VFR_11GおよびORA_VFR_12Cを確認します。これらのグループが存在しない場合は、opwdintg.exeユーティリティ・ツールを再実行します。
    4. 次のガイドラインに従い、Oracle Databaseを使用するMicrosoft Active Directoryユーザーをこれらのグループに追加します。

      • クライアントまたはサーバーのいずれかでのみOracle Databaseリリース12c認証が許可される場合、ユーザーをORA_VFR_12Cグループに追加します。(Oracle Databaseリリース18cでは、Oracle Databaseリリース12cと同じベリファイアが使用されます)。

      • クライアントとサーバーの両方でOracle Databaseリリース12cより低い認証のみが許可される場合(つまり、Oracle Databaseリリース11gまたは12.1.0.1クライアントを使用している場合)、ユーザーをORA_VFR_11G グループに追加します。

      • Oracle Database WebDAVクライアントを介してユーザーを認証する必要がある場合、ユーザーはORA_VFR_MD5グループのメンバーである必要があります。

      この構成により、Oracle Databaseパスワード・ベリファイアの生成を詳細に制御できます。必要なユーザーに必要なベリファイアのみが生成されます。たとえば、Microsoft Active DirectoryユーザーpfitchがORA_VFR_12CおよびORA_VFR_11Gグループに追加されると、12Cと11Gの両方のベリファイアがpfitchに対して生成されます。これにより、Oracle Databaseリリース11gクライアントに対し、可能な場合には最もセキュアかつ強力なベリファイアが選択されますが、それ以外の場合は11Gベリファイアが選択されます。

  2. データベース・パスワード・ファイルをバージョン12.2に更新します。
    Active Directoryユーザーが管理権限でOracleデータベースにログインする必要がある場合は、データベース・パスワード・ファイルをバージョン12.2に更新します。
    1. 管理者権限を持つユーザーとして、Microsoft Active Directory接続に使用するデータベースが存在するホストにログインします。
    2. $ORACLE_HOME/dbsディレクトリに移動します。
    3. ORAPWDユーティリティを実行して、フォーマットを12.2に設定します。
      例:
      orapwd FILE='/app/oracle/product/18.1/db_1/dbs/orapwdb181' FORMAT=12.2

      この設定により、SYSOPOERやSYSBACKUPなどの様々な管理権限をグローバル・ユーザーに付与できます。

    4. ALTER SYSTEM権限を持つユーザーとして、データベース・インスタンスにログインします。
    5. spfileまたはinit.oraファイルでLDAP_DIRECTORY_SYSAUTHパラメータがYESに設定されていることを確認します。
    6. REMOTE_LOGIN_PASSWORDFILEパラメータをspfileまたはinit.oraファイルでEXCLUSIVEに設定します。
    7. SYSDBA管理権限があるユーザーとしてルートに接続します。
    8. データベース・インスタンスを再起動します。
      • CDBから: 次の内容を入力します。
        SHUTDOWN IMMEDIATE
STARTUP
      • PDBから: 次の内容を入力します。
        ALTER PLUGGABLE DATABASE pdb_name CLOSE IMMEDIATE;
ALTER PLUGGABLE DATABASE pdb_name OPEN;

        CDB内の使用可能なPDBを確認するには、CDBルート・コンテナにログインし、DBA_PDBSデータ・ディクショナリ・ビューのPDB_NAME列を問い合せます。現在のコンテナを確認するには、show con_nameコマンドを実行します。 

      SHUTDOWN IMMEDIATE
STARTUP
パスワード認証を使用したOracle Databaseへのログイン

パスワード認証を使用する場合、集中管理ユーザーにはデータベースへのログイン方法の選択肢があります。

Active Directoryユーザーがパスワード認証を使用している場合にActive Directoryに接続するように構成されているデータベースにログインするには、次のログオン・ユーザー名構文を使用できます。

sqlplus /nolog 
connect "Windows_domain\Active_Directory_user_name"@tnsname_of_database 
Password: password

tnsnames.oraファイル内のTNS別名は、マルチテナント・データベースのPDBに対応しています。次の接続では、Windowsドメイン名がproductionであると想定しています。 

connect "production\pfitch"@inst1

Active Directoryユーザーが、データベース・ウォレットで構成されたOracleサービス・ディレクトリ・ユーザー・アカウントと同じActive Directoryドメインにある場合、Active Directoryユーザーは、このユーザー名(samAccountName)を使用してデータベースに直接ログオンできます。 

sqlplus samAccountName@tnsname_of_database
Enter password: password

例:

connect pfitch@instl
Enter password: password

または、ユーザーはActive DirectoryのWindowsユーザー・ログオン名をDNSドメイン名とともに使用することもできます。

connect "Active_Directory_user_name@Windows_DNS_domain_name"@tnsname_of_database 
Password: password

例:

connect "pfitch@production.examplecorp.com"@inst1

集中管理ユーザー用のKerberos認証の構成

Kerberos認証を使用する予定の場合は、Microsoft Active Directoryと統合するOracleデータベースでKerberosを構成する必要があります。

CMU-Active DirectoryはMicrosoft Active Directory Kerberosサーバーのみをサポートします。その他の非Active Directory Kerberosサーバーは、CMU-Active Directoryではサポートされていません。

ノート:

Active DirectoryユーザーのKerberos UPNとして外部で識別されるデータベース・ユーザーは作成しません。かわりに、Active Directoryユーザーまたはグループにマップされたグローバル・ユーザーを使用します。

関連トピック

親トピック:集中管理ユーザーの認証の構成

集中管理ユーザーのPKI証明書を使用した認証の構成

集中管理ユーザーの認証にPKI証明書を使用する予定の場合は、Microsoft Active Directoryと統合されるOracleデータベースでSecure Sockets Layerを構成する必要があります。

ノート:

Active Directoryユーザー証明書は、Secure Sockets Layer認証を構成する際に使用します。ただし、Active Directoryユーザー証明書のDNとして外部で識別されるデータベース・ユーザーは作成しません。かわりに、Active Directoryユーザーまたはグループにマップされたグローバル・ユーザーを使用します。

関連トピック

親トピック:集中管理ユーザーの認証の構成

集中管理ユーザーの認可の構成

集中管理ユーザーにより、Active DirectoryユーザーがOracleデータベースにアクセスするための認可を管理できます。

Active Directoryを使用して組織でユーザーを追加、変更、または削除するときには、組織のすべてのデータベースからユーザーを追加、変更または削除する必要はありません。

親トピック: Microsoft Active Directoryによる集中管理ユーザーの構成

集中管理ユーザーの認可の構成について

Active Directory内のデータベースに対するユーザー認可を管理できます。

ほとんどのOracle Databaseユーザーは、共有データベース・スキーマ(ユーザー)にマップされます。そのため、ディレクトリ・ユーザーが採用されるときや、社内でジョブが変わるとき、あるいは離職するときに各Oracleデータベースで実行する必要がある作業が最小限に抑えられます。ディレクトリ・ユーザーは、Oracleデータベース・グローバル・ユーザー(スキーマ)にマップされたActive Directoryグループに割り当てられます。ユーザーがデータベースにログインすると、データベースがActive Directoryを問い合せ、そのユーザーがメンバーになっているグループを検索します。デプロイメントが共有スキーマを使用している場合、いずれかのグループが共有データベース・スキーマにマップされ、ユーザーはそのデータベース・スキーマに割り当てられます。ユーザーは、データベース・スキーマに付与されたロールと権限を所持します。複数のユーザーが同じ共有データベース・スキーマに割り当てられるため、最小限のロールと権限のセットのみを共有スキーマに付与する必要があります。場合によっては、共有スキーマに権限およびロールを付与しないでください。ユーザーには、データベース・グローバル・ロールを介して適切なロールとスキーマのセットが割り当てられます。グローバル・ロールはActive Directoryグループにマップされます。このように、同じデータベース共有スキーマにマップされている場合でも、異なるユーザーが異なるロールおよび権限を持つことができます。新しく採用されたユーザーは、共有スキーマにマップされたActive Directoryグループに割り当てられたうえで、タスクを完了するために必要な追加のロールと権限を取得するために、グローバル・ロールにマップされた1つ以上の追加グループに割り当てられます。共有スキーマとグローバル・ロールを組み合せると、データベース操作に対する変更を最小限にして、集中的な認可管理が可能になります。データベースは最初に、適切なActive Directoryグループにマップされている共有スキーマとグローバル・ロールのセットでプロビジョニングされる必要がありますが、ユーザー認可管理はActive Directory内で発生する可能性があります。

Active Directoryユーザーは、データベース・グローバル・ユーザーに排他的にマップすることもできます。これには、Active Directoryユーザーに直接マップされているデータベースで新しいユーザーが必要です。新しいユーザーと離職するユーザーには、メンバーである各データベースの更新が必要です。

SYSOPERやSYSBACKUPなどの管理権限を必要とするActive Directoryユーザーに、グローバル・ロールを介してこれらを付与することはできません。管理権限は、ロールではなくスキーマにのみ付与できます。ただし、管理権限のある場合でも、共有スキーマを使用してユーザー認可管理を容易にできます。SYSOPER権限で共有スキーマを使用すると、データベースに新しいユーザー・スキーマを作成しなくても、SYSOPERを使用してスキーマにマップされたActive Directoryグループに、新しいユーザーを簡単に追加できます。共有スキーマに1人のユーザーしか割り当てられていない場合でも、一元的に管理できます。

グローバル・ロールを使用してユーザーに権限およびロールを付与する場合、セッションで有効にできるロールの最大数は150であることに注意してください。

認可でサポートされているグローバル・ユーザー・マッピングのタイプを次に示します。

  • 共有グローバル・ユーザーのマッピング。ディレクトリ・ユーザーは、共有スキーマへのディレクトリ・グループのマッピングを介して、共有データベース・スキーマ(ユーザー)に割り当てられます。グループのメンバーであるディレクトリ・ユーザーはこの共有スキーマを介してデータベースに接続できます。共有スキーマを使用すると、Active Directoryでユーザー認可を集中管理できます。

  • 排他的なグローバル・ユーザー・マッピングでは、専用データベース・ユーザーがディレクトリ・ユーザーに排他的にマップされます。共有データベース・スキーマほど一般的ではありませんが、このユーザーは、2層または3層アプリケーションのスキーマ・ユーザーまたはSQL*Plusを使用して、直接データベース・アクセスのために作成されています。 認可の管理を容易にするため、グローバル・ロールを介してこれらのユーザーにデータベース権限を付与することをお薦めします。 ただし、Oracleデータベースでこれらのユーザーに権限を直接付与することもできますが、これはお薦めしません。 これは、2層および3層アプリケーションではグローバル・ユーザーをデータベース・スキーマとして使用でき、グローバル・ユーザーはスキーマ・オブジェクトに対し所有者として完全なデータベース権限を持つためです。

ディレクトリ・ユーザーが複数のグループのメンバーであるのは一般的です。ただし、共有スキーマにマップする必要があるのは、これらのグループのうち1つだけです。

親トピック: 集中管理ユーザーの認可の構成

共有データベース・グローバル・ユーザーへのディレクトリ・グループのマッピング

データベースのほとんどのユーザーは、ディレクトリ・グループのメンバーシップを介して共有グローバル・データベース・ユーザー(スキーマ)にマップされます。

Active Directoryグループは、データベース・グローバル・ユーザーをマップする前に作成する必要があります。ユーザーがデータベースにログインするには、いつでもActive Directoryユーザーをグループに追加できます。データベース側でこれらのマッピングを実行するには、CREATE USERおよびALTER USER権限が必要です。この構成は、パスワード認証、Kerberos認証、および公開キー・インフラストラクチャ(PKI)認証方式を使用するユーザーが使用できます。
アプリケーションに対して同じデータベース・スキーマを共有するユーザーをActive Directoryグループに割り当てることができます。共有Oracle Databaseグローバル・ユーザー(共有スキーマ)がActive Directoryグループにマップされます。これにより、このグループのすべてのActive Directoryユーザーは、その共有グローバル・ユーザー・アカウントを使用してデータベースにログインできます。データベース・グローバル・ユーザー・アカウントはグループ・メンバーにより共有されますが、Active Directoryユーザーの認証済アイデンティティ(WindowsドメインとユーザーのsamAccountName)およびエンタープライズ・アイデンティティ(DN)は、データベース内で追跡および監査されます。
  1. CREATE USERまたはALTER USERシステム権限が付与されたユーザーとして、データベース・インスタンスにログインします。
  2. Active DirectoryグループのDNを指定するIDENTIFIED GLOBALLY AS句を使用してCREATE USERまたはALTER USER文を実行します。
    たとえば、production.examplecorp.comドメインのsales組織単位のwidget_sales_groupというディレクトリ・グループを、WIDGET_SALESという名前の共有データベース・グローバル・ユーザーにマップするには、次のようにします。
    CREATE USER widget_sales IDENTIFIED GLOBALLY AS
'CN=widget_sales_group,OU=sales,DC=production,DC=examplecorp,DC=com';
    widget_sales_groupのすべてのメンバーは、データベースにログインするときにwidget_sales共有スキーマに割り当てられます。

親トピック: 集中管理ユーザーの認可の構成

グローバル・ロールへのディレクトリ・グループのマッピング

ディレクトリ・グループにデータベース・グローバル・ロールをマップすると、そのメンバーにはログイン・スキーマを介して付与された権限およびロールを超える権限およびロールが付与されます。

  1. CREATE ROLEまたはALTER ROLEシステム権限が付与されたユーザーとして、データベース・インスタンスにログインします。
  2. Active DirectoryグループのDNを指定するIDENTIFIED GLOBALLY AS句を使用してCREATE ROLEまたはALTER ROLE文を実行します。
    たとえば、production.examplecorp.comドメインのsales組織単位のwidget_sales_groupという名前のディレクトリ・ユーザー・グループを、データベース・グローバル・ロールWIDGET_SALES_ROLEにマップするには、次のようにします。 
    CREATE ROLE widget_sales_role IDENTIFIED GLOBALLY AS
'CN=widget_sales_group,OU=sales,DC=production,DC=examplecorp,DC=com';

    C##WIDGET_SALES_ROLEという共通ロールを作成するには、次のようにします。 

    CREATE ROLE c##widget_sales_role IDENTIFIED GLOBALLY AS
'CN=widget_sales_group,OU=sales,DC=production,DC=examplecorp,DC=com'  
CONTAINER = ALL;

    widget_sales_groupのすべてのメンバーは、データベースにログインするときにデータベース・ロールwidget_sales_roleで認可されます。

親トピック: 集中管理ユーザーの認可の構成

データベース・グローバル・ユーザーへのディレクトリ・ユーザーの排他的マッピング

Microsoft Active DirectoryユーザーをOracle Databaseグローバル・ユーザーに排他的にマッピングできます。

この構成はOracle Database側のみで実行し、Active Directory側では実行しません。これらのマッピングを実行するには、CREATE USERおよびALTER USER権限が必要です。この構成は、パスワード認証、Kerberos認証、および公開キー・インフラストラクチャ(PKI)認証方式を使用するユーザーが使用できます。
  1. CREATE USERまたはALTER USERシステム権限が付与されたユーザーとして、データベース・インスタンスにログインします。
  2. Active DirectoryユーザーのDNを指定するIDENTIFIED GLOBALLY AS句を使用してCREATE USERまたはALTER USER文を実行します。
    たとえば、production.examplecorp.comドメインのsales組織単位のPeter Fitch (samAccountNameはpfitch)という名前の既存のActive Directoryユーザーを、PETER_FITCHという名前のデータベース・グローバル・ユーザーにマップするには、次のようにします。
    CREATE USER peter_fitch IDENTIFIED GLOBALLY AS
'CN=Peter Fitch,OU=sales,DC=production,DC=examplecorp,DC=com';

親トピック: 集中管理ユーザーの認可の構成

ユーザー・マッピング定義の変更または移行

ALTER USER文を使用して、Active Directoryユーザーからデータベース・グローバル・ユーザーへのマッピングを更新できます。

更新できるユーザーは、CREATE USER文の句IDENTIFIED BY password、IDENTIFIED EXTERNALLYまたはIDENTIFIED GLOBALLYのいずれかを使用してアカウントが作成されているユーザーです。これは、CUを使用してユーザーを移行するときに便利です。たとえば、Kerberosに対して外部認証されるデータベース・ユーザーは、ユーザー・プリンシパル名(UPN)で識別されます。Kerberos認証でCMUを使用するためにユーザーを移行するには、ALTER USER文を実行してグローバル・ユーザーを宣言し、Active Directory識別名(DN)でそのユーザーを識別する必要があります。
  1. ALTER USERシステム権限が付与されたユーザーとして、データベース・インスタンスにログインします。
  2. IDENTIFIED GLOBALLY AS句を指定してALTER USER文を実行します。
    例:
    ALTER USER peter_fitch IDENTIFIED GLOBALLY AS
'CN=Peter Fitch,OU=sales,DC=production,DC=examplecorp,DC=com';

親トピック: 集中管理ユーザーの認可の構成

管理ユーザーの構成

管理ユーザーは、過去と同様に機能しますが、共有スキーマを使用している場合、CMUを使用すると集中的な認証および認可によって制御できます。

親トピック: 集中管理ユーザーの認可の構成

共有アクセス・アカウントを使用したデータベース管理ユーザーの構成

共有アカウントを使用すると、組織で採用、異動、離職があるときに複数データベースのデータベース管理者の管理が簡略化されます。

新しいOracle データベース・アカウントを作成せずに、Active Directoryグループを使用して複数のデータベースで共有アカウントに新しいデータベース管理者を割り当てることができます。
  1. 現在のデータベース・インスタンスのパスワード・ファイルが12.2形式であることを確認してください。
    orapwd file=pwd_file FORMAT=12.2
Enter password for SYS: password
  2. Active DirectoryでActive Directoryグループを作成します(ad_dba_backup_usersという名前のデータベース管理者バックアップ・ユーザー・グループなど)。
  3. Oracle Databaseで、グローバル・ユーザー(共有スキーマなど)を作成し(db_dba_backup_global_userなど)、このユーザーをActive Directory ad_dba_backup_usersグループにマップします。
  4. グローバル・ユーザーdb_dba_backup_global_userにSYSBACKUP管理権限を付与します。
この段階では、Active Directoryのad_dba_backup_usersグループに追加されているすべてのActive Directoryユーザーが、SYSBACKUP管理権限を持つ新しいデータベース共有スキーマに割り当てられます。

親トピック: 管理ユーザーの構成

排他的マッピングを使用したデータベース管理ユーザーの構成

データベース管理者を、データベース内の排他スキーマにマップすることもできます。

  1. 現在のデータベース・インスタンスのパスワード・ファイルが12.2形式であることを確認してください。
    orapwd file=pwd_file FORMAT=12.2
Enter password for SYS: password
  2. ユーザーの作成と他のユーザーへの管理権限の付与を実行できるユーザーとして、データベース・インスタンスにログインします。
  3. データベース・グローバル・ユーザーを作成します。
    例:
    CREATE USER peter_fitch IDENTIFIED GLOBALLY AS
'CN=Peter Fitch,OU=sales,DC=production,DC=examplecorp,DC=com';
  4. 管理権限をこのユーザーに付与します。
    たとえば、SYSKM管理権限をユーザーに付与するには次のようにします。
    GRANT SYSKM TO peter_fitch;
アカウントの保守作業の量と、データベースとActive Directoryの両方におけるマッピングの点から、より集中化された手法は、場合によっては共有データベース・アカウントに1人のActive Directoryユーザーのみが割り当てられていても、これらの管理アカウントにも共有スキーマを使用する方法です。

親トピック: 管理ユーザーの構成

集中管理ユーザー・ログオン情報の確認

集中管理ユーザーを構成および認可した後、Oracleデータベース側で一連のSQL問合せを実行して、ユーザー・ログオン情報を検証できます。

  1. 先ほど構成し認可したActive Directoryから、集中管理ユーザーとしてCDBまたはPDBにログインします。
    たとえば、データベース・インスタンスinst1に、Windowsドメインproductionのエンタープライズ・ユーザーpfitchとしてログインするには、次のようにします。
    sqlplus /nolog
connect "production\pfitch"@inst1
Enter password: password
  2. マップされたグローバル・ユーザーを検証します。
    マップされたグローバル・ユーザーは、集中管理ユーザー認可を持つデータベース・ユーザー・アカウントです。ユーザーPETER_FITCHはActive Directoryユーザーpfitchの排他的マッピングを持つグローバル・ユーザーとみなされ、ユーザーWIDGET_SALESは、pfitchがメンバーであるActive Directoryグループwidget_sales_groupの共有マッピングを持つグローバル・ユーザーとみなされます。グローバル・ユーザー・アカウントには独自のスキーマがあります。 
    SHOW USER;

    排他的マッピングであるか共有マッピングであるかに応じて、次のような出力が表示されます。

    USER is "PETER_FITCH"

    または

    USER is "WIDGET_SALES"
  3. 集中管理ユーザーに付与されたロールを確認します。
    SELECT ROLE FROM SESSION_ROLES ORDER BY ROLE;

    次のような出力が表示されます。

    ROLE
----------------------------------------------------------------------
WIDGET_SALES_ROLE
...
  4. 次の問合せを実行して、このデータベース・セッションで使用されている現在のスキーマのSYS_CONTEXTネームスペース値、現在のユーザー名、セッション・ユーザー名、認証方式、認証済アイデンティティ、エンタープライズ・アイデンティティ、識別タイプおよびLDAPサーバー・タイプを確認します。
    • このデータベース・セッションで使用されている現在のスキーマを確認します。データベース・スキーマは、含まれているオブジェクトを識別するオブジェクト・コンテナです。現在のスキーマは、このデータベース・セッションのオブジェクト名解決のデフォルト・コンテナです。 
      SELECT SYS_CONTEXT('USERENV', 'CURRENT_SCHEMA') FROM DUAL;

      排他的マッピングであるか共有マッピングであるかに応じて、次のような出力が表示されます。 

      SYS_CONTEXT('USERENV','CURRENT_SCHEMA')
----------------------------------------------------------------------
PETER_FITCH

      または

      SYS_CONTEXT('USERENV','CURRENT_SCHEMA')
----------------------------------------------------------------------
WIDGET_SALES
    • 現行ユーザーを確認します。この場合、現行ユーザーは現行スキーマと同じです。 
      SELECT SYS_CONTEXT('USERENV', 'CURRENT_USER') FROM DUAL;

      排他的マッピングであるか共有マッピングであるかに応じて、次のような出力が表示されます。

      SYS_CONTEXT('USERENV','CURRENT_USER')
----------------------------------------------------------------------
PETER_FITCH

      または

      SYS_CONTEXT('USERENV','CURRENT_USER')
----------------------------------------------------------------------
WIDGET_SALES
    • セッション・ユーザーを確認します。
      SELECT SYS_CONTEXT('USERENV', 'SESSION_USER') FROM DUAL;

      排他的マッピングであるか共有マッピングであるかに応じて、次のような出力が表示されます。

      SYS_CONTEXT('USERENV','SESSION_USER')
----------------------------------------------------------------------
PETER_FITCH

      または

      SYS_CONTEXT('USERENV','SESSION_USER')
----------------------------------------------------------------------
WIDGET_SALES
    • 認証方式を確認します。 
      SELECT SYS_CONTEXT('USERENV', 'AUTHENTICATION_METHOD') FROM DUAL;

      次のような出力が表示されます。 

      SYS_CONTEXT('USERENV','AUTHENTICATION_METHOD')
----------------------------------------------------------------------
PASSWORD_GLOBAL
    • エンタープライズ・ユーザーの認証済アイデンティティを確認します。このユーザーがデータベースにログオンしたときに、Active Directory認証済ユーザー・アイデンティティが取得されて監査されます。
      SELECT SYS_CONTEXT('USERENV', 'AUTHENTICATED_IDENTITY') FROM DUAL;

      次のような出力が表示されます。 

      SYS_CONTEXT('USERENV','AUTHENTICATED_IDENTITY')
----------------------------------------------------------------------
production\pfitch
    • 集中管理ユーザーのエンタープライズ・アイデンティティを確認します。 
      SELECT SYS_CONTEXT('USERENV', 'ENTERPRISE_IDENTITY') FROM DUAL;

      次のような出力が表示されます。 

      SYS_CONTEXT('USERENV','ENTERPRISE_IDENTITY')
----------------------------------------------------------------------
cn=Peter Fitch,ou=sales,dc=production,dc=examplecorp,dc=com
    • 識別タイプを確認します。 
      SELECT SYS_CONTEXT('USERENV', 'IDENTIFICATION_TYPE') FROM DUAL

      排他的マッピングであるか共有マッピングであるかに応じて、次のような出力が表示されます。

      SYS_CONTEXT('USERENV','IDENTIFICATION_TYPE')
----------------------------------------------------------------------
GLOBAL EXCLUSIVE

      または

      SYS_CONTEXT('USERENV','IDENTIFICATION_TYPE')
----------------------------------------------------------------------
GLOBAL SHARED
    • LDAPサーバー・タイプを確認します。
      SELECT SYS_CONTEXT('USERENV', 'LDAP_SERVER_TYPE') FROM DUAL;

      次のような出力結果が表示されます。この場合、LDAPサーバー・タイプはActive Directoryです。 

      SYS_CONTEXT('USERENV','LDAP_SERVER_TYPE')
----------------------------------------------------------------------
AD

関連トピック

親トピック: 集中管理ユーザーの認可の構成

Microsoft Active Directoryのアカウント・ポリシーとのOracle Databaseの統合

Oracle DatabaseとMicrosoft Active Directoryの統合の一部として、Oracle Databaseでは、Active DirectoryユーザーがOracle DatabaseにログインするときにActive Directoryアカウント・ポリシーが適用されます。

Active Directoryアカウント・ポリシー設定は、パスワード・ポリシー、アカウント・ロックアウト・ポリシーおよびKerberosポリシーを対象とします。Oracle Databaseでは、Active Directoryの集中管理ユーザーのすべてのアカウント・ポリシーが適用されます。たとえば、Oracleでは、「パスワードの有効期限切れ」、「パスワードの変更が必要」、「ロック・アウトされたアカウント」または「無効なアカウント」などのアカウント・ステータスを持つActive Directoryユーザーはデータベースにログインできなくなります。Kerberos認証を使用している場合、Oracleでは、Kerberosチケットが期限切れになっているActive Directoryユーザーは、データベースにログインできなくなります。パスワード認証を使用している場合、Active Directoryユーザー・アカウントは、不正なパスワードを使用してOracleデータベースにログインしようとして指定した回数連続して失敗すると、指定した期間Active Directoryでロックアウトされます。アカウント・ロックアウト・ポリシーを適用すると、Active Directoryユーザー・アカウントに対するパスワード推測攻撃が効果的に回避されます。

親トピック: Microsoft Active Directoryによる集中管理ユーザーの構成