6 Microsoft Active Directoryによる集中管理ユーザーの構成
Oracle Databaseでは、中間ディレクトリまたはOracle Enterprise User Securityを使用せずにデータベースでMicrosoft Active Directoryユーザーを直接認証および認可できます。
- Microsoft Active Directoryによる集中管理ユーザーの概要
集中管理ユーザー(CMU)によりMicrosoft Active Directoryとのシンプルな統合が実現し、ユーザーの集中化された認証と認可が可能になります。 - Oracle DatabaseとMicrosoft Active Directoryの統合の構成
Microsoft Active Directoryを使用してユーザーを認証および認可するには、OracleデータベースからActive Directoryへの接続を構成する必要があります。 - 集中管理ユーザーの認証の構成
パスワード認証、Kerberos認証、または公開キー・インフラストラクチャ(PKI)認証を構成できます。 - 集中管理ユーザーの認可の構成
集中管理ユーザーにより、Active DirectoryユーザーがOracleデータベースにアクセスするための認可を管理できます。 - 一元管理ユーザーのトラブルシューティング
Oracleには、Microsoft Active DirectoryユーザーがOracleデータベースにログインしようとしたときに発生する可能性のある一般的なエラーのトラブルシューティングに役立つエラー・メッセージが表示されます。 - Microsoft Active Directoryのアカウント・ポリシーとOracle Databaseの統合
Oracle DatabaseとMicrosoft Active Directoryの統合の一部として、Active DirectoryユーザーがOracleデータベースにログインするときに、Oracle DatabaseによりActive Directoryのアカウント・ポリシーが適用されます。 - Oracle Autonomous Databaseを使用した集中管理ユーザーの構成
集中管理ユーザー(CMU)をOracle Autonomous Databaseにデプロイできます。 - 一元管理ユーザーのトラブルシューティング
Oracleには、Microsoft Active DirectoryユーザーがOracleデータベースにログインしようとしたときに発生する可能性のある一般的なエラーのトラブルシューティングに役立つエラー・メッセージが表示されます。
親トピック: ユーザー認証および認可の管理
6.1 Microsoft Active Directoryによる集中管理ユーザーの概要
集中管理ユーザー(CMU)によりMicrosoft Active Directoryとのシンプルな統合が実現し、ユーザーの集中化された認証と認可が可能になります。
- Oracle DatabaseとMicrosoft Active Directoryの統合について
集中管理ユーザーによりMicrosoft Active Directoryとのシンプルな統合が実現し、ユーザーの集中化された認証と認可が可能になります。 - Microsoft Active Directoryによる集中管理ユーザーのしくみ
この統合は、Microsoft Active DirectoryのユーザーおよびグループがOracleデータベース・ユーザーおよびロールに直接マッピングされることで機能します。 - 集中管理ユーザーとMicrosoft Active Directoryによるアーキテクチャ
Active DirectoryアーキテクチャのCMUでは、Oracle DatabaseユーザーおよびロールをActive Directoryで管理できます。 - サポートされている認証方式
Oracle DatabaseとMicrosoft Active Directoryの統合では、3つの一般的な認証方式がサポートされています。 - Microsoft Active Directoryによる集中管理ユーザーでサポートされるユーザー
Active DirectoryのCMUにより、排他的にマップされるユーザー、共有スキーマにマップされるユーザー、管理ユーザーがサポートされます。 - 集中管理ユーザーに対するOracleマルチテナント・オプションの影響
プラガブル・データベース(PDB)のマルチテナント・データベース・ユーザーは中央のMicrosoft Active Directoryに接続でき、また必要に応じて、個々のPDB内のユーザーは異なるMicrosoft Active Directoryに接続できます。 - データベース・リンクによる集中管理ユーザー
CMUでは、固定されたユーザー・データベース・リンクと接続ユーザー・データベース・リンクの両方がサポートされますが、現在のユーザーのデータベース・リンクはサポートされません。
6.1.1 Oracle DatabaseとMicrosoft Active Directoryの統合について
集中管理ユーザーによりMicrosoft Active Directoryとのシンプルな統合が実現し、ユーザーの集中化された認証と認可が可能になります。
Active Directoryサーバー・オペレーティング・システムの最小バージョン要件は、Microsoft Windows Server 2012です。この最小サポート対象バージョンは、Microsoftで以前のリリースがサポートされなくなると更新されます。
この統合により、組織は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との統合が必要なユーザー。
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ユーザーに割り当てられている権限およびロールを更新できます。
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ユーザーおよびグループの認証、ユーザー管理、アカウント・ポリシー、およびグループの割当てを制御できます。
6.1.4 サポートされている認証方式
Oracle DatabaseとMicrosoft Active Directoryの統合では、3種類の一般的な認証方式がサポートされています。
これらの認証方法は次のとおりです。
-
パスワード認証
-
Kerberos認証
-
公開キー・インフラストラクチャ(PKI)認証(証明書ベースの認証)
関連トピック
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ユーザーに付与するには、データベース・ユーザー・アカウントにシステム管理権限がすでに付与されているデータベース・ユーザーに、(排他的または共有スキーマを使用して)ディレクトリ・ユーザーをマップする必要があります。
関連トピック
6.1.6 集中管理ユーザーに対するOracleマルチテナント・オプションの影響
プラガブル・データベース(PDB)のマルチテナント・データベース・ユーザーは中央のMicrosoft Active Directoryに接続でき、また必要に応じて、個々のPDB内のユーザーは異なるMicrosoft Active Directoryに接続できます。
マルチテナント・データベースのすべてのPDBおよびルート・コンテナでは、共有構成を持つことができます。これにより、CDB全体が単一のActive Directoryサーバーに対してユーザーを認証および認可し、1つのWindowsドメインで複数のActive Directoryサーバー、または信頼できるWindowsドメイン内の複数のActive Directoryサーバーを、共有構成に基づいて認証および認可できます。あるいは、個々のPDBでは、個々の構成に基づいて、同じWindowsドメイン内または異なる(信頼できる、または信頼できない) Windowsドメイン内の異なる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ユーザーがパスワード認証を使用して両方のデータベースにログインできるようにする必要があります。
6.2 Oracle DatabaseとMicrosoft Active Directoryの統合の構成
Microsoft Active Directoryを使用してユーザーを認証および認可するには、OracleデータベースからActive Directoryへの接続を構成する必要があります。
- Oracle DatabaseとMicrosoft Active Directoryの接続の構成について
この接続を構成する前に、Microsoft Active Directoryのインストールと構成が完了している必要があります。 - Microsoft Active Directoryへの接続
Oracleデータベースの作成中にMicrosoft Active Directory接続を構成するか、または既存のOracleデータベースとの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データベースが接続することを意味します。
6.2.2 Microsoft Active Directoryへの接続
Oracleデータベースの作成中にMicrosoft Active Directory接続を構成するか、または既存のOracleデータベースとのMicrosoft Active Directoryの接続を構成できます。
- ステップ1: Microsoft Active DirectoryでのOracleサービス・ディレクトリ・ユーザー・アカウントの作成および権限の付与
Oracleサービス・ディレクトリ・ユーザー・アカウントは、Oracle DatabaseとLDAPディレクトリ・サービスとの相互作用に使用されます。 - ステップ2: パスワード認証のためにパスワード・フィルタをインストールしてMicrosoft Active Directoryスキーマを拡張
Active DirectoryサーバーでOracleopwdintg.exe
実行可能ファイルを使用すると、パスワード・フィルタをインストールし、Active Directoryスキーマを拡張できます。 - ステップ3: Oracle Databaseソフトウェアのインストール(必要な場合)
この操作をまだ実行していない場合は、Oracle Universal Installer(OUI)を使用してOracleソフトウェアをインストールします。 - ステップ4: dsi.oraまたはldap.oraファイルの作成
dsi.ora
ファイルとldap.ora
ファイルには、Active Directory用の集中管理ユーザーの接続を指定します。 - ステップ5: セキュアな接続のためのActive Directory証明書のリクエスト
dsi.ora
またはldap.ora
ファイルの構成が完了したら、セキュアな接続のためのMicrosoft Active DirectoryとOracle Databaseの証明書を準備します。 - ステップ6: セキュアな接続のためのウォレットの作成
Active Directory証明書をコピーすると、それをOracleウォレットに追加できるようになります。 - ステップ7: Microsoft Active Directory接続の構成
次に、これまでの設定を使用してデータベースをActive Directoryに接続します。 - ステップ8: Oracleウォレットの確認
orapki
ユーティリティでは、このデータベースのウォレットが正常に作成されたことを確認できます。 - ステップ9: 統合のテスト
統合をテストするには、ORACLE_HOME
、ORACLE_BASE
およびORACLE_SID
環境変数を設定し、LDAPのパラメータ設定を確認する必要があります。
6.2.2.1 ステップ1: Microsoft Active DirectoryでのOracleサービス・ディレクトリ・ユーザー・アカウントの作成および権限の付与
Oracleサービス・ディレクトリ・ユーザー・アカウントは、Oracle DatabaseとLDAPディレクトリ・サービス間の相互作用に使用されます。
Read properties
権限であり、Active Directoryユーザーによってデータベース・パスワード認証が使用される場合は、Write lockoutTime
(Active Directoryユーザーのプロパティ)権限、および(Active DirectoryユーザーのorclCommonAttribute
プロパティの)Control Access
権限です。
6.2.2.2 ステップ2: パスワード認証のためにパスワード・フィルタをインストールしてMicrosoft Active Directoryスキーマを拡張
Active DirectoryサーバーでOracle opwdintg.exe
実行可能ファイルを使用してパスワード・フィルタをインストールし、Active Directoryスキーマを拡張できます。
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
プロパティへのアクセスを拒否する必要があります。
6.2.2.3 ステップ3: Oracle Databaseソフトウェアのインストール(必要な場合)
この操作をまだ実行していない場合は、Oracle Universal Installer (OUI)を使用してOracleソフトウェアをインストールします。
- 使用しているプラットフォームのOracle Databaseインストレーション・ガイドの手順に従って、Oracleソフトウェアをインストールします。
6.2.2.4 ステップ4: dsi.oraまたはldap.oraファイルの作成
dsi.ora
ファイルとldap.ora
ファイルには、Active Directory用の集中管理ユーザーの接続を指定します。
- dsi.oraファイルとldap.oraファイルの比較
dsi.ora
とldap.ora
の使用方法は、他のサービスでldap.ora
をどのように使用するかによって異なります。 - dsi.oraファイルの使用について
dsi.ora
ファイルを使用して、集中管理ユーザーのActive Directoryサーバーを指定します。 - dsi.oraファイルの作成
dsi.ora
構成ファイルには、集中管理ユーザーのActive Directoryサーバーを検出するための情報を設定します。 - ldap.oraファイルの使用について
ldap.ora
ファイルを使用して、集中管理ユーザー用のActive Directoryサーバーを指定できます。 - ldap.oraファイルの作成
このステップでは、ldap.ora
がネット・ネーミング・サービスに使用されておらず、集中管理ユーザーの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
を使用することをお薦めします。
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 Databaseでは次の順序で検索されます。
WALLET_LOCATION
設定がsqlnet.ora
ファイルに含まれている場合、非マルチテナント・データベースまたはマルチテナント・データベースのルート・コンテナについて、Oracleは、sqlnet.ora
で指定された場所を検索します。マルチテナント・データベースのPDBの場合、Oracleは、WALLET_LOCATION_specified_in_sqlnet.ora/pdb_guid
ディレクトリにあるPDBごとのウォレットの場所で検索します。WALLET_LOCATION
設定がsqlnet.ora
ファイルに含まれていない場合、Oracle Databaseはデフォルトのウォレット・ロケーションを検索します。- Oracle Databaseがウォレット・ロケーションで
dsi.ora
を検出できない場合、Oracle Databaseは次の順序で検索します。これらは、Oracle Databaseがldap.ora
ファイルを検索する場所と同じです。$LDAP_ADMIN
環境変数設定$ORACLE_HOME/ldap/admin
ディレクトリ$TNS_ADMIN
環境変数設定$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ごとにdsi.ora
ファイルを指定できます。PDB固有のdsi.ora
は、その1つのPDBの共有dsi.ora
またはldap.ora
の共通設定をオーバーライドします。異なるPDBが、CMU用の異なるActive Directoryサーバーに接続できます。個々のPDBのdsi.ora
ファイルは、そのPDBのウォレットと同じディレクトリにあります。
sqlnet.ora
ファイルのWALLET_LOCATION
パラメータが設定されている場合、個々のPDBのdsi.ora
ファイルは、WALLET_LOCATION_specified_in_sqlnet.ora/pdb_guid/
ディレクトリのPDBごとのウォレットにあります。
sqlnet.ora
ファイルのWALLET_LOCATION
パラメータが設定されていない場合、マルチテナント・データベース内の個々のコンテナのデフォルトのウォレットの場所は、$ORACLE_BASE/admin/db_unique_name/pdb_guid/wallet/
ディレクトリです。各PDBでデフォルトのウォレット・ロケーションを使用するには、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;
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
の内容を変更した場合は、データベース・インスタンスを再起動するか次のDDLを再実行して、dsi.ora
内の更新された内容を有効にする必要があります。
ALTER SYSTEM SET LDAP_DIRECTORY_ACCESS = 'PASSWORD';
マルチテナント環境では、CDBルートではなく各PDBで、LDAP_DIRECTORY_ACCESS
パラメータを設定する必要があります。
6.2.2.4.3 dsi.oraファイルの作成
dsi.ora
構成ファイルには、集中管理ユーザーのActive Directoryサーバーを検出するための情報を設定します。
dsi.ora
構成ファイルを使用するには:
- Oracleデータベースが存在するホストにログインします。
dsi.ora
ファイルの検索順序に基づいて、dsi.ora
ファイルを使用するディレクトリを選択します。(関連トピックを参照してください。)このディレクトリが存在しない場合は、作成します。次に、このディレクトリに移動してdsi.ora
ファイルを作成します。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
と同じディレクトリには指定できません。
ldap.oraの検索順序
ldap.ora
ファイルを作成すると、Oracle Databaseでは次の順序で検索されます。
-
$LDAP_ADMIN
環境変数設定 -
$ORACLE_HOME/ldap/admin
ディレクトリ -
$TNS_ADMIN
環境変数設定 -
$ORACLE_HOME/network/admin
ディレクトリ
ldap.oraの内容の変更
データベースの起動後にldap.ora
の内容を変更した場合は、データベース・インスタンスを再起動するか次のDDLを再実行して、ldap.ora
内の更新された内容を有効にする必要があります。
ALTER SYSTEM SET LDAP_DIRECTORY_ACCESS = 'PASSWORD';
マルチテナント環境では、CDBルートではなく各PDBで、LDAP_DIRECTORY_ACCESS
パラメータを設定します。
6.2.2.5 ステップ5: セキュアな接続のためのActive Directory証明書のリクエスト
dsi.ora
またはldap.ora
ファイルの構成が完了したら、セキュアな接続のためのMicrosoft Active DirectoryとOracle Databaseの証明書を準備します。
- Active Directory管理者からActive Directory証明書をリクエストします。
6.2.2.7 ステップ7: Microsoft Active Directory接続の構成
次に、これまでの設定を使用してデータベースをActive Directoryに接続します。
- Microsoft Active Directory接続の構成について
Microsoft Active Directory接続を構成するには、データベースでパラメータを設定するか、DBCAを使用します。 - Databaseのシステム・パラメータを使用した手動のアクセスの構成
LDAP固有のOracle Databaseのシステム・パラメータを使用して、Active Directoryサービス接続を手動で構成できます。 - Database Configuration Assistant GUIを使用したアクセスの構成
Oracle Database Configuration Assistant (DBCA)は、LDAP接続構成を完了し、ウォレットを自動的に作成して、使用するActive Directory証明書を格納します。DBCAは、ldap.ora
がCMU-ActiveDirectory用に構成されている場合にのみ動作します。 - Database Configuration Assistantのサイレント・モードを使用したアクセスの構成
ldap.ora
(dsi.ora
ではない)が正しい場所に作成され、適切に構成されている場合、DBCAサイレント・モードで、Microsoft Active DirectoryとOracle Databaseの統合のために新しいデータベースを作成または既存のデータベースを変更できます。
6.2.2.7.1 Microsoft Active Directory接続の構成について
Microsoft Active Directory接続を構成するには、データベースでパラメータを設定するか、DBCAを使用します。
DBCAでは、集中管理ユーザー用に構成されたldap.ora
のみが認識され、推奨されたデフォルトの場所にのみウォレットが作成されます。デフォルトのウォレット・ロケーションを使用するには、sqlnet.ora
にWALLET_LOCATION
を設定しないでください。
ノート:
CMU-Active Directoryにはdsi.ora
を使用することをお薦めします。
6.2.2.7.2 Databaseシステム・パラメータを使用した手動アクセスの構成
LDAP固有のOracle Databaseのシステム・パラメータを使用して、Active Directoryサービス接続を手動で構成できます。
SYSDBA
管理権限でログインし、次のように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用に構成されている場合にのみ動作します。
ldap.ora
ファイル(dsi.ora
ではなく)を使用していることを前提としています。データベース・ソフトウェアをまだインストールしていない場合は、Oracle Universal Installer (OUI)を使用してソフトウェアをインストールできます。その後、DBCAを使用してデータベースを作成すると同時に、Active Directoryの集中管理ユーザーの接続を構成できます。
6.3 集中管理ユーザーの認証の構成
パスワード認証、Kerberos認証または公開キー・インフラストラクチャ(PKI)認証を構成できます。
- 集中管理ユーザーに対するパスワード認証の構成
集中管理ユーザーに対するパスワード認証の構成では、Active Directoryでパスワード・フィルタを使用して、Oracle Databaseのパスワード・ベリファイアをActive Directoryに生成および格納する必要があります。 - 集中管理ユーザー用のKerberos認証の構成
Kerberos認証を使用する予定の場合は、Microsoft Active Directoryに統合するOracle DatabaseでKerberosを構成する必要があります。 - 集中管理ユーザーのPKI証明書を使用した認証の構成
集中管理ユーザーの認証にPKI証明書を使用する予定の場合は、Microsoft Active Directoryと統合されるOracleデータベースでTransport Layer Securityを構成する必要があります。
6.3.1 集中管理ユーザーに対するパスワード認証の構成
集中管理ユーザーに対するパスワード認証の構成では、Active Directoryでパスワード・フィルタを使用して、Oracle Databaseのパスワード・ベリファイアをActive Directoryに生成および格納する必要があります。
- 集中管理ユーザーに対するパスワード認証の構成について
パスワード認証を構成するには、パスワード・フィルタをデプロイし、ユーザー属性を追加することによってActive Directoryスキーマを拡張し、Active Directoryで異なるバージョンのパスワード・ベリファイアを生成するためのグループを作成する必要があります。 - 集中管理ユーザーのパスワード認証の構成
Active Directoryサーバーでパスワード認証構成を実行する必要があり、Active Directoryユーザーが管理権限でOracleデータベースにログインする必要がある場合は、Oracleデータベースでもパスワード認証構成を実行する必要があります。 - パスワード認証を使用したOracle Databaseへのログイン
パスワード認証を使用する場合、集中管理ユーザーにはデータベースへのログイン方法の選択肢があります。
親トピック:集中管理ユーザーの認証の構成
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データベースにログインする必要がある場合は、Oracleデータベースでもパスワード認証構成を実行する必要があります。
6.3.1.3 パスワード認証を使用したOracle Databaseへのログイン
パスワード認証を使用する場合、集中管理ユーザーにはデータベースへのログイン方法の選択肢があります。
Active Directoryユーザーがパスワード認証を使用している場合にActive Directoryに接続するように構成されているデータベースにログインするには、次のログオン・ユーザー名構文を使用できます。
sqlplus /nolog connect "Windows_domain\Active_Directory_user_name"@tnsname_of_database Password: password
次の接続では、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 集中管理ユーザー用のKerberos認証の構成
Kerberos認証を使用する予定の場合は、Microsoft Active Directoryと統合するOracleデータベースでKerberosを構成する必要があります。
ノート:
Active DirectoryユーザーのKerberos UPNとして外部で識別されるデータベース・ユーザーは作成しません。かわりに、Active Directoryユーザーまたはグループにマップされたグローバル・ユーザーを使用します。6.3.3 集中管理ユーザーの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を使用して組織でユーザーを追加、変更、または削除するときには、組織のすべてのデータベースからユーザーを追加、変更または削除する必要はありません。
- 集中管理ユーザーの認可の構成について
Active Directory内のデータベースに対するユーザー認可を管理できます。 - 共有データベース・グローバル・ユーザーへのディレクトリ・グループのマッピング
データベースのほとんどのユーザーは、ディレクトリ・グループのメンバーシップを介して共有グローバル・データベース・ユーザー(スキーマ)にマップされます。 - グローバル・ロールへのディレクトリ・グループのマッピング
ディレクトリ・グループにデータベース・グローバル・ロールをマップすると、そのメンバーにはログイン・スキーマを介して付与された権限およびロールを超える権限およびロールが付与されます。 - データベース・グローバル・ユーザーへのディレクトリ・ユーザーの排他的マッピング
Microsoft Active DirectoryユーザーをOracleデータベース・グローバル・ユーザーに排他的にマップできます。 - ユーザー・マッピング定義の変更または移行
ALTER USER
文を使用して、Active Directoryユーザーからデータベース・グローバル・ユーザーへのマッピングを更新できます。 - 管理ユーザーの構成
管理ユーザーは、過去と同様に機能しますが、共有スキーマを使用している場合、CMUを使用すると集中的な認証および認可によって制御できます。 - 集中管理ユーザー・ログオン情報の確認
集中管理ユーザーを構成および認可した後、Oracleデータベース側で一連のSQL問合せを実行して、ユーザー・ログオン情報を検証できます。
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 共有データベース・グローバル・ユーザーへのディレクトリ・グループのマッピング
データベースのほとんどのユーザーは、ディレクトリ・グループのメンバーシップを介して共有グローバル・データベース・ユーザー(スキーマ)にマップされます。
CREATE USER
およびALTER USER
権限が必要です。この構成は、パスワード認証、Kerberos認証、および公開キー・インフラストラクチャ(PKI)認証方式を使用するユーザーが使用できます。
samAccountName
)およびエンタープライズ・アイデンティティ(DN)は、データベース内で追跡および監査されます。
親トピック: 集中管理ユーザーの認可の構成
6.4.3 グローバル・ロールへのディレクトリ・グループのマッピング
ディレクトリ・グループにデータベース・グローバル・ロールをマップすると、そのメンバーにはログイン・スキーマを介して付与された権限およびロールを超える権限およびロールが付与されます。
親トピック: 集中管理ユーザーの認可の構成
6.4.4 データベース・グローバル・ユーザーへのディレクトリ・ユーザーの排他的マッピング
Microsoft Active DirectoryユーザーをOracle Databaseグローバル・ユーザーに排他的にマッピングできます。
CREATE USER
およびALTER USER
権限が必要です。この構成は、パスワード認証、Kerberos認証、および公開キー・インフラストラクチャ(PKI)認証方式を使用するユーザーが使用できます。
親トピック: 集中管理ユーザーの認可の構成
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)でそのユーザーを識別する必要があります。
親トピック: 集中管理ユーザーの認可の構成
6.4.6 管理ユーザーの構成
管理ユーザーは、過去と同様に機能しますが、共有スキーマを使用している場合、CMUを使用すると集中的な認証および認可によって制御できます。
- 共有アクセス・アカウントを使用したデータベース管理ユーザーの構成
共有アカウントを使用すると、組織で採用、異動、離職があるときに複数データベースのデータベース管理者の管理が簡略化されます。 - 排他的マッピングを使用したデータベース管理ユーザーの構成
データベース管理者を、データベース内の排他スキーマにマップすることもできます。
親トピック: 集中管理ユーザーの認可の構成
6.4.6.1 共有アクセス・アカウントを使用したデータベース管理ユーザーの構成
共有アカウントを使用すると、組織で採用、異動、離職があるときに複数データベースのデータベース管理者の管理が簡略化されます。
ad_dba_backup_users
グループに追加されているすべてのActive Directoryユーザーが、SYSBACKUP
管理権限を持つ新しいデータベース共有スキーマに割り当てられます。
親トピック: 管理ユーザーの構成
6.4.6.2 排他的マッピングを使用したデータベース管理ユーザーの構成
データベース管理者を、データベース内の排他スキーマにマップすることもできます。
親トピック: 管理ユーザーの構成
6.4.7 集中管理ユーザー・ログオン情報の確認
集中管理ユーザーを構成および認可した後、Oracleデータベース側で一連のSQL問合せを実行して、ユーザー・ログオン情報を検証できます。
親トピック: 集中管理ユーザーの認可の構成
6.5 集中管理ユーザーのトラブルシューティング
Oracleには、Microsoft Active DirectoryユーザーがOracleデータベースにログインしようとしたときに発生する可能性のある一般的なエラーのトラブルシューティングに役立つエラー・メッセージが用意されています。
- ORA-28276接続エラー
orclCommonAttribute
属性が正しく設定されていない場合、ORA-28276: ORACLEパスワード属性が無効です
というエラーが発生することがあります。 - ORA-01017接続エラー
Oracle DatabaseおよびMicrosoft Active Directoryでの特殊文字の許容方法の違いにより、「ORA-01017: ユーザー名/パスワードが無効です。ログオンは拒否されました」
エラーが生成されます。 - ORA-28274接続エラー
Active DirectoryスキーマまたはOracleサービス・ディレクトリに問題が発生し、ORA-28274: ユーザー・ニックネームに対応するORACLEパスワード属性が存在しません
というエラーが生成されます。 - ORA-28300接続エラー
Oracleサービス・ディレクトリに権限の問題が発生し、ORA-28030: LDAPディレクトリ・サービスのユーザー・エントリの読取り権限がありません
というエラーが生成されます。 - トレース・ファイルによるCMU接続エラーの診断
トレース設定gdsi
は、集中管理ユーザー(CMU)接続エラーを追跡します。
6.5.1 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=
この問題を解決するには:
opwdintg.exe
を実行し、Active DirectoryのドメインにすべてのWindowsドメイン・コントローラのパスワード・フィルタをインストールします。- 各Windowsドメイン・コントローラ・サーバーを再起動します。各Windowsドメイン・コントローラはパスワード・フィルタのインストール後に再起動する必要があります。そうしない場合、パスワード・フィルタがWindowsドメイン・コントローラで機能しません。
- Active Directoryユーザーを適切な
ORA_VFR
グループに割り当てます。 - Active Directoryでユーザー・パスワードをリセットします。
ldapsearch
を実行して、パスワードが生成されていることを確認します。
親トピック: 集中管理ユーザーのトラブルシューティング
6.5.2 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.5.3 ORA-28274接続エラー
Active DirectoryスキーマまたはOracleサービス・ディレクトリに問題が発生し、ORA-28274: ユーザー・ニックネームに対応するORACLEパスワード属性が存在しません
というエラーが生成されます。
Active Directoryスキーマが拡張されていないか、正しく移入されていません。かわりに、Oracleサービス・ディレクトリ・ユーザーにOracleデータベースにログインしようとするユーザーのorclCommonAttribute
属性へのアクセスに必要な権限がありません。
この問題を解決するには:
- 解決策1:
opwdintg.exe
を実行し、Active DirectoryのドメインにすべてのWindowsドメイン・コントローラのパスワード・フィルタをインストールします。- 各Windowsドメイン・コントローラ・サーバーを再起動します。各Windowsドメイン・コントローラはパスワード・フィルタのインストール後に再起動する必要があります。そうしない場合、パスワード・フィルタがWindowsドメイン・コントローラで機能しません。
- Active Directoryユーザーを適切な
ORA_VFR
グループに割り当てます。 - Active Directoryでユーザー・パスワードをリセットします。
ldapsearch
を実行して、パスワードが生成されていることを確認します。
- 解決策2:
- Oracleサービス・ディレクトリ・ユーザー・アカウントに、データベースにアクセスしようとするActive Directoryユーザーのプロパティへのアクセス権である、
Read Properties
およびWrite lockoutTime
を付与します。 - Active Directoryユーザーの
orclCommonAttribute
にControl Access
の権限を設定します。
- Oracleサービス・ディレクトリ・ユーザー・アカウントに、データベースにアクセスしようとするActive Directoryユーザーのプロパティへのアクセス権である、
6.5.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
この問題(および権限)を修正するには:
- Oracleサービス・ディレクトリ・ユーザー・アカウントに、データベースにアクセスしようとするActive Directoryユーザーのプロパティへのアクセス権である、
Read Properties
およびWrite lockoutTime
を付与します。 - Active Directoryユーザーの
orclCommonAttribute
にControl Access
の権限を設定します。
6.5.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';
親トピック: 集中管理ユーザーのトラブルシューティング
6.6 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ユーザーには、デフォルトのドメイン・ポリシーでのパスワードの有効期限のみが適用されます。6.7 Oracle Autonomous Databaseを使用した集中管理ユーザーの構成
集中管理ユーザー(CMU)をOracle Autonomous Databaseにデプロイできます。
CMUをOracle Autonomous Databaseにデプロイする手順は、Oracle Autonomous Database Serverlessの使用のMicrosoft Active DirectoryとAutonomous Databaseとの併用を参照してください。
6.8 集中管理ユーザーのトラブルシューティング
Oracleには、Microsoft Active DirectoryユーザーがOracleデータベースにログインしようとしたときに発生する可能性のある一般的なエラーのトラブルシューティングに役立つエラー・メッセージが用意されています。
- ORA-28276接続エラー
orclCommonAttribute
属性が正しく設定されていない場合、ORA-28276: ORACLEパスワード属性が無効です
というエラーが発生することがあります。 - ORA-01017接続エラー
Oracle DatabaseおよびMicrosoft Active Directoryでの特殊文字の許容方法の違いにより、「ORA-01017: ユーザー名/パスワードが無効です。ログオンは拒否されました」
エラーが生成されます。 - ORA-28274接続エラー
Active DirectoryスキーマまたはOracleサービス・ディレクトリに問題が発生し、ORA-28274: ユーザー・ニックネームに対応するORACLEパスワード属性が存在しません
というエラーが生成されます。 - ORA-28300接続エラー
Oracleサービス・ディレクトリに権限の問題が発生し、ORA-28030: LDAPディレクトリ・サービスのユーザー・エントリの読取り権限がありません
というエラーが生成されます。 - トレース・ファイルによるCMU接続エラーの診断
トレース設定gdsi
は、集中管理ユーザー(CMU)接続エラーを追跡します。
6.8.1 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=
この問題を解決するには:
opwdintg.exe
を実行し、Active DirectoryのドメインにすべてのWindowsドメイン・コントローラのパスワード・フィルタをインストールします。- 各Windowsドメイン・コントローラ・サーバーを再起動します。各Windowsドメイン・コントローラはパスワード・フィルタのインストール後に再起動する必要があります。そうしない場合、パスワード・フィルタがWindowsドメイン・コントローラで機能しません。
- Active Directoryユーザーを適切な
ORA_VFR
グループに割り当てます。 - Active Directoryでユーザー・パスワードをリセットします。
ldapsearch
を実行して、パスワードが生成されていることを確認します。
親トピック: 集中管理ユーザーのトラブルシューティング
6.8.2 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.8.3 ORA-28274接続エラー
Active DirectoryスキーマまたはOracleサービス・ディレクトリに問題が発生し、ORA-28274: ユーザー・ニックネームに対応するORACLEパスワード属性が存在しません
というエラーが生成されます。
Active Directoryスキーマが拡張されていないか、正しく移入されていません。かわりに、Oracleサービス・ディレクトリ・ユーザーにOracleデータベースにログインしようとするユーザーのorclCommonAttribute
属性へのアクセスに必要な権限がありません。
この問題を解決するには:
- 解決策1:
opwdintg.exe
を実行し、Active DirectoryのドメインにすべてのWindowsドメイン・コントローラのパスワード・フィルタをインストールします。- 各Windowsドメイン・コントローラ・サーバーを再起動します。各Windowsドメイン・コントローラはパスワード・フィルタのインストール後に再起動する必要があります。そうしない場合、パスワード・フィルタがWindowsドメイン・コントローラで機能しません。
- Active Directoryユーザーを適切な
ORA_VFR
グループに割り当てます。 - Active Directoryでユーザー・パスワードをリセットします。
ldapsearch
を実行して、パスワードが生成されていることを確認します。
- 解決策2:
- Oracleサービス・ディレクトリ・ユーザー・アカウントに、データベースにアクセスしようとするActive Directoryユーザーのプロパティへのアクセス権である、
Read Properties
およびWrite lockoutTime
を付与します。 - Active Directoryユーザーの
orclCommonAttribute
にControl Access
の権限を設定します。
- Oracleサービス・ディレクトリ・ユーザー・アカウントに、データベースにアクセスしようとするActive Directoryユーザーのプロパティへのアクセス権である、
6.8.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
この問題(および権限)を修正するには:
- Oracleサービス・ディレクトリ・ユーザー・アカウントに、データベースにアクセスしようとするActive Directoryユーザーのプロパティへのアクセス権である、
Read Properties
およびWrite lockoutTime
を付与します。 - Active Directoryユーザーの
orclCommonAttribute
にControl Access
の権限を設定します。
6.8.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';
親トピック: 集中管理ユーザーのトラブルシューティング