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

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

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

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

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

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

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

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

Active Directoryサーバー・オペレーティング・システムの最小バージョン要件は、Microsoft Windows Server 2012です。この最小サポート対象バージョンは、Microsoftで以前のリリースがサポートされなくなると更新されます。

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

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

ノート:

エンタープライズ・ユーザー・セキュリティ(EUS)は、Oracle AI Database 26aiで非推奨になりました。

集中管理ユーザー(CMU)の使用に移行することをお薦めします。この機能を使用すると、データベースに対するエンタープライズ・ユーザー認証および認可のためにディレクトリ・サービスを介在させることなく、Microsoft Active Directoryに直接接続できます。Oracle Databaseがクラウドにある場合は、クラウド・アイデンティティ・プロバイダとの新しい統合のいずれかに移行することも選択できます。

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

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

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

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

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

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

6.1.2 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による集中管理ユーザーの概要

6.1.3 集中管理ユーザーと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による集中管理ユーザーの概要

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

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

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

  • パスワード認証

  • Kerberos認証

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

関連トピック

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

6.1.5 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による集中管理ユーザーの概要

6.1.6 集中管理ユーザーに対する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による集中管理ユーザーの概要

6.1.7 データベース・リンクによる集中管理ユーザー

CMUでは、固定されたユーザー・データベース・リンクと接続ユーザー・データベース・リンクの両方がサポートされますが、現在のユーザーのデータベース・リンクはサポートされません。

CMU-Active Directoryユーザーが固定されたユーザー・データベース・リンクを使用するための特別な要件はありません。パスワード、Kerberos、またはPKI認証を使用するCMU-Active Directoryユーザーは、通常のデータベース・ユーザーと同様に固定されたユーザー・データベース・リンクを使用できます。Kerberos認証は、データベース・リンクを使用したOracle Databaseの強力な認証でも機能します。詳細は、My Oracle SupportのNote 1370327.1を参照してください。

CMU-Active Directoryユーザーが接続ユーザー・データベース・リンクを使用するために、パスワード認証のみがサポートされています。ソース・データベースとターゲット・データベースの両方をCMU-Active Directoryで構成して、同じActive Directoryユーザーがパスワード認証を使用して両方のデータベースにログインできるようにする必要があります。

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

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

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

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

6.2.1 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の統合の構成

6.2.2 Microsoft Active Directoryへの接続

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

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

6.2.2.1 ステップ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ユーザーのプロパティ)権限、および(Active DirectoryユーザーのorclCommonAttributeプロパティの)Control Access権限です。このアカウントに対して作成するユーザー・パスワードは、Oracleパスワード複雑度ファンクションが設定されている場合にOracleユーザー・パスワードが従う必要のあるルールに従っていないことに注意してください。
  1. ユーザー・アカウントの作成およびユーザー・アカウントへの権限の付与のための管理権限がある管理者として、Microsoft Active DirectoryのWindowsドメインコントローラにログインします。
  2. Oracleサービス・ディレクトリ・ユーザー・アカウントをActive Directoryユーザーとして作成します。
    ディレクトリにサービス・ユーザー・アカウントを作成します。Active Directoryユーザーが使用するWindowsドメインに応じて、サービス・ユーザー・アカウントを作成する場所を選択できます。次のガイドラインに従ってください。

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

    • Active Directoryユーザーが複数のWindowsドメインに存在する場合は、他のすべてのドメインに信頼されているドメインに、このサービス・ユーザー・アカウントを作成します。

      • 選択したドメインは、他のすべてのドメインに信頼されている必要があります。

      • サービス・ユーザーは、これらすべてのWindowsドメインにバインドできる必要があり、これらすべてのWindowsドメイン内のActive Directoryユーザーのプロパティに、付与されている権限でアクセスできる必要があります。

      • 他のすべてのドメインは、信頼できるドメインからのサービス・ユーザーのアクセスを可能にするために、TLS/SSL経由の単純なバインドをサポートしている必要があります。

      • 他のすべてのドメインの管理者は、信頼できるドメインからサービス・ユーザー・アカウントに、必要な最小権限を付与する必要があります。

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

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

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

ノート:

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

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

  1. 最新バージョンのopwdintg.exe (Oracleパスワード統合)ユーティリティにアクセスします。
    • My Oracle Supportアカウントがある場合: My Oracle Supportで自分のアカウントにログインし、ドキュメントID 2462012.1を検索します。この場所からopwdintg.exeをダウンロードします。これが最新のバージョンです。
    • My Oracle Supportアカウントがない場合: ドキュメントID 2462012.1から最新バージョンのopwdintg.exeをダウンロードできるように、My Oracle Supportアカウントに登録します。
  2. 安全なコピー方法(sftpなど)を使用して、opwdintg.exeを各Windowsドメイン・コントローラの一時ディレクトリ(C:\tempなど)にコピーします。
  3. Active Directory管理者として各Windowsドメイン・コントローラに接続します。
    現在、opwdintg.exeユーティリティには英語版のWindows OSが必要です。
  4. Windows OSの言語設定が英語であることを確認してください。
  5. 各Windowsドメイン・コントローラでopwdintg.exeユーティリティを実行します。
    新しいopwdintg.exeを使用して更新されたパスワード・フィルタを再インストールする場合は、ドメイン・コントローラを再起動する必要があります。
    opwdintg.exeユーティリティを実行するには、次のいずれかの方法を使用します。
    • Windowsエクスプローラを開き、opwdintg.exeユーティリティをダブルクリックします。
    • Windowsのコマンド・プロンプトを開き、次のステップを実行します。
      1. opwdintg.exeユーティリティがあるディレクトリに移動します。たとえば:
        cd c:\temp
      2. 次のコマンドを入力して、コマンドラインからユーティリティを実行します。 
        .\opwdintg.exe
  6. 次のプロンプトに対して入力します:
    • ADスキーマを拡張しますか。[はい/いいえ]:Yesと入力します。

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

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

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

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

      • このステップでは、次の3つのベリファイア・グループを作成します。これらのグループがすでに存在する場合は、エラーが表示されますが、これらのエラーは無視できます。これらのベリファイア・グループは、インストールされているADユーザー・フォルダから移動することも、ユーザー・オブジェクトのこのフォルダ構造の外に移動することもできます。

        • ORA_VFR_MD5は、Oracle AI 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と入力します。
6.2.2.3 ステップ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の集中管理ユーザーを構成することもできます。
6.2.2.4 ステップ4: dsi.oraまたはldap.oraファイルの作成

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

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

6.2.2.4.1 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を使用することをお薦めします。

CDB内のすべてのコンテナ(CDBルート、アプリケーション・ルート、アプリケーション、PDB)が同じActive Directoryサーバーに接続する場合、dsi.oraとウォレット・ファイルの単一セットを使用し、ディレクトリ・オブジェクトを使用して、Active Directoryサーバーに接続する必要があるすべてのコンテナからその場所を指すことができます。このように、同じdsi.oraファイルとウォレット・ファイルのセットを複数保持する必要はありません。ldap.oraファイルを使用して、すべてのコンテナを単一のActive Directoryサーバーに接続することもできます。これは、dsi.oraが存在しない場合、各コンテナが共通の場所でldap.oraを検索するためです。ただし、各コンテナはコンテナ固有の場所でのみウォレットを検索します。

6.2.2.4.2 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 AI Databaseでは次の順序でそのファイルが検索されます:

  1. PDBについては、データベース・プロパティCMU_WALLETがディレクトリ・オブジェクトに設定されている場合、Oracle AI Databaseは、このディレクトリ・オブジェクトで指定された場所のパスを検索します。
  2. WALLET_LOCATION設定がsqlnet.oraファイルに含まれていると、ルート・コンテナの場合は、Oracleによって、sqlnet.ora内で指定されている場所が検索されます。PDBの場合は、Oracleによって、WALLET_LOCATION_specified_in_sqlnet.ora/pdb_guidディレクトリ内の、PDBごとのウォレット・ロケーションにおいてそれが検索されます。

    パラメータWALLET_LOCATIONは、Oracle DatabaseサーバーのOracle AI Database 26aiでの使用は非推奨です。Oracle AI Databaseクライアントでの使用は非推奨ではありません。

  3. WALLET_LOCATION設定がsqlnet.oraファイルに含まれていない場合、Oracle AI Databaseはデフォルトのウォレット・ロケーションを検索します。
  4. Oracle AI Databaseがウォレット・ロケーションでdsi.oraを検出できない場合、Oracle AI Databaseは次の順序で検索します。これらは、Oracle AI 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ごとのデータベース・プロパティで指定されたウォレット・ロケーションに配置されます。(個々のPDBでCMU_WALLETを設定します。CDBルートでCMU_WALLETを設定することもできます。ただし、CDBルートでCMU_WALLETを設定すると、ルート・コンテナのみに対して有効になり、CDB全体に対しては有効になりません。) 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 AI 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ファイルへの変更はすぐに有効になり、データベースを再起動する必要はありません。ウォレットへの変更はすぐに有効になります。

6.2.2.4.3 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)

      高可用性およびフェイルオーバー構成のActive Directoryドメイン・サーバーは、CMUを使用して構成できます。次のいずれかの方法で、高可用性およびフェイルオーバーのActive Directoryドメイン・サーバーを構成できます。

      • Active Directoryドメイン・サーバーの前にロードバランサを使用する
      • 各Active Directoryドメイン・サーバーをリスト内のホスト名またはIPアドレス別に一覧表示する
      • 異なるActive Directoryドメイン・サーバーを返すドメイン名を使用する

      ロード・バランサの使用は、特にActive Directoryドメイン・サーバーに対してすでに使用している場合にお薦めの選択肢です。ロード・バランサを使用すると、dsi.oraファイルに変更を加えなくても、ロード・バランサの背後にあるActive Directoryドメイン・サーバーを管理および追加できます。Active Directoryドメイン・サーバーのリストを指定すると、より高速で低コストになりますが、Active Directoryドメイン・サーバーと結び付けるため、変更(新規または削除されたサーバー)をdsi.oraに反映する必要があります。ドメイン名を使用すると、高可用性およびフェイルオーバーが提供されますが、理想的な解決策ではありません。DNSは、毎回同じサーバーではなく、異なるサーバーを返すことが必要になります。CMUは、ドメイン名検索から返された最初のサーバーを試し、それが失敗すると認証は失敗します。ただし、ドメイン名を使用すると、dsi.oraでサーバーのリストを指定しなくても、異なるActive Directoryドメイン・サーバーを使用できるようになります。

    • 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
6.2.2.4.4 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と同じディレクトリには指定できません。

ノート:

パラメータWALLET_LOCATIONは、Oracle DatabaseサーバーのOracle AI Database 26aiでの使用は非推奨です。Oracle Databaseクライアントまたはリスナーでの使用は非推奨ではありません。

Oracle Databaseサーバーには、WALLET_LOCATIONを使用するかわりにWALLET_ROOTシステム・パラメータを使用することをお薦めします。

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で設定する必要があります。

6.2.2.4.5 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
6.2.2.5 ステップ5: セキュアな接続のためのActive Directory証明書のリクエスト

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

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

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

  1. 証明書テキスト・ファイル(AD_CA_Root_cert.txtなど)をActive Directoryサーバーから一時ディレクトリ(ローカル・ホストの/tmpなど)にコピーします。
    Active Directory証明書は、テキスト(BASE64)またはバイナリ(DER)のいずれかの形式になります。Active Directoryドメイン・サーバーから証明書を取得する方法(およびActive Directoryドメイン・サーバーを構成する方法)の詳細は、「データベース・リリース18c以降のリリース用に集中管理されたユーザーを構成する方法」というタイトルのMy Oracle Supportノートを参照してください(ドキュメントID 2462012.1)。
    ウォレット・ロケーションが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に配置することもできます。

    ノート:

    パラメータWALLET_LOCATIONは、Oracle DatabaseサーバーのOracle AI Database 26aiでの使用は非推奨です。Oracle Databaseクライアントまたはリスナーでの使用は非推奨ではありません。

    Oracle Databaseサーバーには、WALLET_LOCATIONを使用するかわりにWALLET_ROOTシステム・パラメータを使用することをお薦めします。

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

    (Oracle AI Database 26ai以降、mkstoreはorapkiを優先して非推奨になりました。)

  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が指定されている場合、Active Directory証明書をPDB固有のウォレットの場所(つまり、PDBごとのWALLET_LOCATION_specified_in_sqlnet.ora/pdb_guid)に追加する必要があります。Active Directory証明書をWALLET_LOCATION_specified_in_sqlnet.oraに追加することもできます。ただし、これはルート・コンテナのみに対して有効になり、CDB全体に対しては有効になりません。

  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

    ウォレットへの変更はすぐに有効になり、データベースの再起動は必要ありません。

6.2.2.7 ステップ7: Microsoft Active Directory接続の構成

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

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

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

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

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

ノート:

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

パラメータWALLET_LOCATIONは、Oracle DatabaseサーバーのOracle AI Database 26aiでの使用は非推奨です。Oracle Databaseクライアントまたはリスナーでの使用は非推奨ではありません。
6.2.2.7.2 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
6.2.2.7.3 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. 「終了」をクリックします。
6.2.2.7.4 Database Configuration Assistantのサイレント・モードを使用したアクセスの構成

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

  1. 統合に使用されるOracle AI Databaseが含まれるホストにログインします。
  2. 正しい場所に正しいコンテンツを使用してldap.oraが作成されていることを確認してください。
  3. sqlnet.oraファイルにWALLET_LOCATIONパラメータが指定されていないことを確認します。
    パラメータWALLET_LOCATIONは、Oracle AI DatabaseサーバーのOracle AI Database 26aiでの使用は非推奨です。Oracle AI Databaseクライアントでの使用は非推奨ではありません。
  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
6.2.2.8 ステップ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
6.2.2.9 ステップ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

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

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

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

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

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

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

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

パスワード認証を構成するには、パスワード・フィルタをデプロイし、ユーザー属性を追加することによって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グループから削除されると生成されなくなります。

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

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

  1. Oracle AI Databaseのパスワード・フィルタをデプロイし、Active Directoryスキーマを拡張します。

    最新バージョンのopwdintg.exe (Oracleパスワード統合)ユーティリティにアクセスします。opwdintg.exeは、My Oracle SupportのドキュメントID 2462012.1からダウンロードできます。

    このユーティリティは、Active Directoryにパスワード・フィルタをインストールし、Oracleパスワード・ベリファイアを保持するActive Directoryスキーマを拡張して、Active Directoryパスワード・ベリファイア・グループを作成します。WebDAV、11Gおよび12Cパスワード・ベリファイアを使用してクライアントに接続すると、パスワード・フィルタにより、Microsoft Active Directoryのユーザー・アカウントをOracle AI Databaseで認証できます。
    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 AI 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 AI Database WebDAVクライアントを介してユーザーを認証する必要がある場合、ユーザーはORA_VFR_MD5グループのメンバーである必要があります。

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

  2. データベース・パスワード・ファイルをバージョン12.2に更新します。
    Active Directoryユーザーが管理権限でOracle AI Databaseにログインする必要がある場合は、データベース・パスワード・ファイルをバージョン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
6.3.1.3 パスワード認証を使用したOracle Databaseへのログイン

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

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

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

パスワードに@や_などの特殊文字が含まれ、CONNECT行にパスワードを入力する場合は、パスワードを二重引用符で囲みます。セキュリティを強化するために、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

6.3.2 集中管理ユーザーに対するプロキシ認証の構成

プロキシ認証により、集中管理ユーザーは、アプリケーションのメンテナンスなどのタスクのためにデータベース・スキーマにプロキシできます。

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

6.3.2.1 集中管理ユーザーに対するプロキシ認証について

集中管理ユーザーは、プロキシ認証を使用してOracle Databaseに接続できます。

プロキシ認証は、通常、実際のユーザーを認証し、アプリケーションを管理するためにスキーマ権限およびロールを含むデータベース・スキーマの使用をユーザーに認可するために使用されます。アプリケーション・スキーマ・パスワードの共有などの代替方法は、安全でないものとみなされ、どの実際のユーザーがアクションを実行したかを監査できません。

たとえば、アプリケーション・データベース管理者である名前付き集中管理ユーザーが資格証明を使用して認証し、データベース・スキーマ・ユーザー(hrappなど)にプロキシできる環境でのユースケースが考えられます。この認証により、Active Directoryセキュリティ管理者は、アプリケーションのメンテナンスを実行するためにhrapp権限およびロールをユーザーhrappとして使用できますが、認証には集中管理ユーザー資格証明を使用します。アプリケーション管理者は、データベースにサインインし、アプリケーション・スキーマにプロキシしてこのスキーマを管理できます。

パスワード認証のためのプロキシ認証を構成できます。

6.3.2.2 集中管理ユーザーに対するプロキシ認証の構成

集中管理ユーザーのプロキシ認証を構成するには、このユーザーがすでにグローバル・スキーマへのマッピング(排他的マッピングまたは共有マッピング)を持っている必要があります。集中管理ユーザーがプロキシする別のデータベース・スキーマも使用可能になっている必要があります。

このタイプのユーザーがあることを確認したら、データベース・ユーザー・アカウントを変更して、集中管理ユーザーがそのユーザーに対してプロキシできるようにします。
  1. ALTER USERシステム権限を持つユーザーとして、Oracle Databaseインスタンスにログインします。
  2. ローカル・データベース・ユーザー・アカウントにプロキシする権限を集中管理ユーザーに付与します。
    集中管理ユーザーはコマンドで参照できないため、(集中管理ユーザーにマップした)データベース・グローバル・ユーザーとターゲット・データベース・ユーザーの間にプロキシを作成する必要があります。
    次の例では、hrappはプロキシ先のデータベース・スキーマで、peterfitch_schemaはユーザーpeterfitchに排他的にマップされるデータベース・グローバル・ユーザーです。 
    ALTER USER hrapp GRANT CONNECT THROUGH peterfitch_schema;
この段階で、集中管理ユーザーはプロキシを使用してデータベース・インスタンスにログインできます。たとえば、パスワード・ベリファイアを使用して接続するには、次のようにします。
CONNECT peterfitch[hrapp]@connect_string
Enter password: password
6.3.2.3 集中管理ユーザー・プロキシ認証の検証

パスワード認証のための集中管理ユーザー・プロキシ構成を検証できます。

  1. CREATE USERおよびALTER USERシステム権限を持つユーザーとして、Oracle Databaseインスタンスにログインします。
  2. 集中管理ユーザーとして接続し、SHOW USERおよびSELECT SYS_CONTEXTコマンドを実行します。
    たとえば、データベース・ユーザーhrappにプロキシするときに、集中管理ユーザーpeterfitchのプロキシ認証を確認するとします。ここに示す様々なタイプの認証方法を使用してデータベースに接続することが必要になりますが、実行したコマンドの出力はすべてのタイプで同じになります。
    CONNECT peterfitch[hrapp]/password\!@connect_string
SHOW USER;
--The output should be "USER is HRAPP"
SELECT SYS_CONTEXT('USERENV','AUTHENTICATION_METHOD') FROM DUAL;
--The output should be "PASSWORD_GLOBAL"
SELECT SYS_CONTEXT('USERENV','PROXY_USER') FROM DUAL;
--The output should be "PETERFITCH_SCHEMA"
SELECT SYS_CONTEXT('USERENV','CURRENT_USER') FROM DUAL;
--The output should be "HRAPP"

6.3.3 集中管理ユーザー用の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ユーザーまたはグループにマップされたグローバル・ユーザーを使用します。

関連トピック

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

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

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

CMUでのKerberos認証ではMicrosoft Active Directory-Active Directory Kerberosサーバーを使用する必要がありますが、PKI認証では、Microsoft Active Directory-Active Directoryのサービスのみでなくサード・パーティCAサービスを使用できます。

ノート:

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

関連トピック

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

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

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

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

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

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

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つだけです。

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

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

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

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共有スキーマに割り当てられます。

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

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

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

  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で認可されます。

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

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

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';

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

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

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';

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

6.4.6 管理ユーザーの構成

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

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

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

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

新しい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管理権限を持つ新しいデータベース共有スキーマに割り当てられます。

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

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

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

  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ユーザーのみが割り当てられていても、これらの管理アカウントにも共有スキーマを使用する方法です。

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

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

集中管理ユーザーを構成および認可した後、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

関連トピック

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

6.5 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ユーザー・アカウントに対するパスワード推測攻撃が効果的に回避されます。

ノート:

Oracleでは、Active Directoryのデフォルト・ドメイン・ポリシーのみをサポートしており、ファイングレイン・パスワード・ポリシーはサポートしていません。たとえば、デフォルトのドメイン・ポリシーでパスワードの有効期限が設定されているが、ファイングレイン・パスワード・ポリシーの有効期限が短い場合、CMUをActive Directoryとともに使用してOracleデータベースにアクセスするActive Directoryユーザーには、デフォルトのドメイン・ポリシーでのパスワードの有効期限のみが適用されます。

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

6.6 Oracle Autonomous Databaseを使用した集中管理ユーザーの構成

集中管理ユーザー(CMU)をOracle Autonomous Databaseにデプロイできます。

CMUをOracle Autonomous Databaseにデプロイする手順は、Oracle Autonomous AI Database Serverlessの使用の「Autonomous DatabaseでのMicrosoft Active Directoryの使用」を参照してください。

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

6.7 集中管理ユーザーのトラブルシューティング

Oracleには、Microsoft Active DirectoryユーザーがOracleデータベースにログインしようとしたときに発生する可能性のある一般的なエラーのトラブルシューティングに役立つエラー・メッセージが用意されています。

  • ORA-01017接続エラー
    Oracle DatabaseおよびMicrosoft Active Directoryでの特殊文字の許容方法の違いにより、「ORA-01017: ユーザー名/パスワードが無効です。ログオンは拒否されました」エラーが生成されます。
  • ORA-28274接続エラー
    Active DirectoryスキーマまたはOracleサービス・ディレクトリに問題が発生し、ORA-28274: ユーザー・ニックネームに対応するORACLEパスワード属性が存在しませんというエラーが生成されます。
  • ORA-28276接続エラー
    orclCommonAttribute属性が正しく設定されていない場合、ORA-28276: ORACLEパスワード属性が無効ですというエラーが発生することがあります。
  • ORA-28300接続エラー
    Oracleサービス・ディレクトリに権限の問題が発生し、ORA-28030: LDAPディレクトリ・サービスのユーザー・エントリの読取り権限がありませんというエラーが生成されます。
  • トレース・ファイルによるCMU接続エラーの診断
    トレース設定gdsiは、集中管理ユーザー(CMU)接続エラーを追跡します。

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

6.7.1 ORA-01017接続エラー

Oracle DatabaseおよびMicrosoft Active Directoryでの特殊文字の許容方法の違いにより、「ORA-01017: ユーザー名/パスワードが無効です。ログオンは拒否されました」エラーが生成されます。

集中管理ユーザー(CMU)が作成するユーザー名とパスワードは、Oracle Databaseのユーザー名とパスワードのルールとは異なる作成ルールに従っています。ORA-01017エラーの問題を修正するには、Active Directoryユーザーのユーザー名とパスワードを二重引用符で囲みます。たとえば、ユーザー名がpeter fitch、パスワードがILoveMySalads@_home!であり、Oracleサービス・ユーザーとドメインが同じActive Directoryユーザーの場合、次のログインが機能します。 

CONNECT "peter fitch"/"ILoveMySalads@_home!"@orcl

Active DirectoryユーザーのドメインがOracleサービス・ユーザーとは異なる場合、Windowsドメイン(この場合はEXAMPLE)をユーザー名に含める必要があります。 

CONNECT "EXAMPLE\peter fitch"/"ILoveMySalads@_home!"@orcl

CONNECT "EXAMPLE\peter fitch"@orcl
Enter password: password

Enter passwordプロンプトに入力するパスワードが22文字の場合、ILoveMySalads@_home!パスワードは20文字と2つの二重引用符の分の2文字になります。

親トピック: 集中管理ユーザーのトラブルシューティング

6.7.2 ORA-28274接続エラー

Active DirectoryスキーマまたはOracleサービス・ディレクトリに問題が発生し、ORA-28274: ユーザー・ニックネームに対応するORACLEパスワード属性が存在しませんというエラーが生成されます。

Active Directoryスキーマが拡張されていないか、正しく移入されていません。かわりに、Oracleサービス・ディレクトリ・ユーザーにOracleデータベースにログインしようとするユーザーのorclCommonAttribute属性へのアクセスに必要な権限がありません。

この問題を解決するには:

  • 解決策1:
    1. opwdintg.exeを実行し、Active DirectoryのドメインにすべてのWindowsドメイン・コントローラのパスワード・フィルタをインストールします。
    2. 各Windowsドメイン・コントローラ・サーバーを再起動します。各Windowsドメイン・コントローラはパスワード・フィルタのインストール後に再起動する必要があります。そうしない場合、パスワード・フィルタがWindowsドメイン・コントローラで機能しません。
    3. Active Directoryユーザーを適切なORA_VFRグループに割り当てます。
    4. Active Directoryでユーザー・パスワードをリセットします。
    5. ldapsearchを実行して、パスワードが生成されていることを確認します。
  • 解決策2:
    1. Oracleサービス・ディレクトリ・ユーザー・アカウントに、データベースにアクセスしようとするActive Directoryユーザーのプロパティへのアクセス権である、Read PropertiesおよびWrite lockoutTimeを付与します。
    2. Active DirectoryユーザーのorclCommonAttributeにControl Accessの権限を設定します。

関連トピック

親トピック: 集中管理ユーザーのトラブルシューティング

6.7.3 ORA-28276接続エラー

orclCommonAttribute属性が正しく設定されていない場合、ORA-28276: ORACLEパスワード属性が無効ですというエラーが発生することがあります。

たとえば:

SQL> connect "myad\dev"@orcl_db
Enter password: password

ERROR:
ORA-28276: Invalid ORACLE password attribute.

このエラーはorclCommonAttribute属性によってユーザー・パスワードが正しく移入されなかった場合に発生します。たとえば: 

$ ldapsearch -h <AD_Server> -p 389 -D "cn=oracleservice,cn=users,dc=myad,dc=example,dc=com" -w **** -U 2 -W "file:wallet_path" 
-P password -b "dc=myad,dc=example,dc=com" -s sub "(sAMAccountName=def*)" 
dn orclCommonAttributeCN=def,CN=Users,DC=myad,DC=example,DC=com

orclCommonAttribute=

この問題を解決するには:

  1. opwdintg.exeを実行し、Active DirectoryのドメインにすべてのWindowsドメイン・コントローラのパスワード・フィルタをインストールします。
  2. 各Windowsドメイン・コントローラ・サーバーを再起動します。各Windowsドメイン・コントローラはパスワード・フィルタのインストール後に再起動する必要があります。そうしない場合、パスワード・フィルタがWindowsドメイン・コントローラで機能しません。
  3. Active Directoryユーザーを適切なORA_VFRグループに割り当てます。
  4. Active Directoryでユーザー・パスワードをリセットします。
  5. ldapsearchを実行して、パスワードが生成されていることを確認します。

親トピック: 集中管理ユーザーのトラブルシューティング

6.7.4 ORA-28300接続エラー

Oracleサービス・ディレクトリに権限の問題が発生し、ORA-28030: LDAPディレクトリ・サービスのユーザー・エントリの読取り権限がありませんというエラーが生成されます。

このエラーはCMUトレースを使用して追跡できます。たとえば:

2023-03-27 19:51:55.0 - KZLG_ERR: failed to modify user status Insufficient access
2023-03-27 17:57:27.0 - KZLG_ERR: LDAPERR=50, OER=28300

この問題(および権限)を修正するには:

  1. Oracleサービス・ディレクトリ・ユーザー・アカウントに、データベースにアクセスしようとするActive Directoryユーザーのプロパティへのアクセス権である、Read PropertiesおよびWrite lockoutTimeを付与します。
  2. Active DirectoryユーザーのorclCommonAttributeにControl Accessの権限を設定します。

関連トピック

親トピック: 集中管理ユーザーのトラブルシューティング

6.7.5 トレース・ファイルを使用したCMU接続エラーの診断

トレース設定gdsiは、集中管理ユーザー(CMU)の接続エラーを追跡します。

ALTER SYSTEM権限およびSYSDBA管理者権限を持つユーザーの場合、このトレース・イベントを次のように有効にできます。 

ALTER SYSTEM SET EVENTS='TRACE[GDSI] DISK LOW';

Active Directoryユーザーがログインを試行し、ログインに失敗した場合は、トレース・ファイルを含むディレクトリに移動し、接続エラーについてこれらのファイルをgrepします。 

grep -i kzlg *.trc

その後、詳細情報を含むトレース・ファイルを収集し、確認できます。

トレースを無効にするには、次のコマンドを入力します。 

ALTER SYSTEM SET EVENTS='TRACE[GDSI] OFF';

親トピック: 集中管理ユーザーのトラブルシューティング