1. データベースで別の外部認証スキームが有効になっているかどうかを確認し、無効にします。

   Kerberos上でCMU-AD構成を続行して、Microsoft Active DirectoryユーザーにCMU-AD Kerberos認証を提供できます。

   詳細は、Microsoft Active Directoryを使用したCMUのKerberos認証を参照してください。

2. CMU構成ファイル(データベース・ウォレット・ファイルcwallet.ssoおよびCMU構成ファイルdsi.oraを含む)をオブジェクト・ストアにアップロードします。このステップは、使用するオブジェクト・ストアによって異なります。

   dsi.ora構成ファイルには、Active Directoryサーバーを検出するための情報が含まれています。

   Oracle Cloud Infrastructure Object Storeを使用している場合は、オブジェクト・ストレージへのデータの配置を参照して、ファイルのアップロードの詳細を確認してください。

3. DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATIONプロシージャを実行し、params JSON引数を使用して場所URIを渡します。構成ファイルcwallet.ssoおよびdsi.oraは、location_uriパラメータで指定されたオブジェクト・ストレージの場所に配置する必要があります。

   たとえば:

   BEGIN
      DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION(
          type     => 'CMU',
          params   => JSON_OBJECT('location_uri' value 'https://objectstorage.us-phoenix-1.oraclecloud.com/n/namespace-string/b/bucketname/o',
                                  'credential_name' value 'my_credential_name')
      );
   END;
   /

   Oracleでは、オブジェクト・ストアのプライベート・バケットにCMU構成ファイルを格納することをお薦めします。

   この例では、namespace-stringはOracle Cloud Infrastructureオブジェクト・ストレージ・ネームスペースで、bucketnameはバケット名です。詳細は、オブジェクト・ストレージ・ネームスペースの理解を参照してください。

   このステップで使用するcredential_nameは、オブジェクト・ストアにアクセスするための資格証明です。

   リソース・プリンシパル資格証明を有効にする場合、Oracle Cloud Infrastructureオブジェクト・ストアにアクセスするための資格証明の作成は必要ありません。詳細は、リソース・プリンシパルを使用したOracle Cloud Infrastructureリソースへのアクセスを参照してください。

   location_uriが事前認証済URLまたは事前署名済URLの場合、credential_nameを指定する必要はありません。

   このプロシージャは、データベースにCMU_WALLET_DIRという名前のディレクトリ・オブジェクトを作成し、オブジェクト・ストアの場所からディレクトリ・オブジェクトにCMU構成ファイルをコピーします。また、このプロシージャは、データベース・プロパティCMU_WALLETを値'CMU_WALLET_DIR'に設定し、LDAP_DIRECTORY_ACCESSパラメータ値を値PASSWORDに設定して、Autonomous DatabaseインスタンスからActive Directoryへのアクセスを有効にします。

4. CMU認証を有効にした後、データベース・ウォレットcwallet.ssoおよびCMU構成ファイルdsi.oraを含むCMU構成ファイルをオブジェクト・ストアから削除します。ローカル・オブジェクト・ストア・メソッドを使用してこれらのファイルを削除するか、DBMS_CLOUD.DELETE_OBJECTを使用してオブジェクト・ストアからファイルを削除できます。
5. Active Directoryサーバーがプライベート・エンドポイント上にある場合は、追加の構成ステップを実行して、プライベート・エンドポイントへのアクセスを提供します。
   1. データベース・プロパティROUTE_OUTBOUND_CONNECTIONSを値'PRIVATE_ENDPOINT'に設定します。

      詳細は、プライベート・エンドポイントを使用したアウトバウンド接続のセキュリティの強化を参照してください。

   2. CMU-AD構成ファイルdsi.oraにホスト名が含まれていることを確認します。ROUTE_OUTBOUND_CONNECTIONSが'PRIVATE_TARGET'に設定されている場合、IPアドレスはdsi.oraで指定できません。

1. Microsoft Active Directory Kerberosサーバーを使用して、Autonomous DatabaseインスタンスでKerberosを有効にします。

   CMU-ADでKerberos認証を構成する場合、Microsoft Active Directory KerberosサーバーのみがKerberosでサポートされます。

   1. Autonomous DatabaseでKerberos認証を有効にするには、Kerberos構成ファイル(krb.conf)およびサービス・キー表ファイル(v5srvtab)を取得しておく必要があります。

      CMU-ADを使用して Kerberos認証を構成するときにこれらのファイルを生成するには、サーバーのホスト名が必要です。サーバー・ホストの値は、V$PDBSのCLOUD_IDENTITY列の属性PUBLIC_DOMAIN_NAMEから取得できます。この値は、プライベート・エンドポイント上のデータベースの完全修飾ドメイン名(FQDN)とは異なります。

      サーバーのホスト名を取得するには、次のコマンドを使用します。

      SELECT guid ||'/'|| json_value(cloud_identity, '$.PUBLIC_DOMAIN_NAME')
          "KSERVICE/KINSTANCE" FROM v$pdbs;

      次のようなコマンドを使用して、サービス・キー表ファイルを生成できます。

      ktpass -princ ORACLE/DATABASE_SERVER_HOST_NAME.DATABASE_SERVER_HOST_DOMAIN@ACTIVE_DIRECTORY_DEFAULT_DOMAIN
                       -pass ACTIVE_DIRECTORY_PASSWORD 
                       -mapuser DATABASE_SERVER_HOST_NAME 
                       -crypto ALL 
                       -ptype KRB5_NT_PRINCIPAL 
                       -out database.keytab

      たとえば:

      ktpass -princ ORACLE/user.example.com@example.com 
                       -pass password -mapuser dbexamplekrb 
                       -crypto ALL -ptype KRB5_NT_PRINCIPAL -out database.keytab

      これらのファイルおよびそれらを取得するステップの詳細は、Kerberos認証の構成に関する項を参照してください。

   2. Kerberos構成ファイルkrb.confおよびv5srvtabをオブジェクト・ストアのバケットにコピーします。

      このステップは、使用するオブジェクト・ストアによって異なります。

      Oracle Cloud Infrastructure Object Storeを使用している場合は、オブジェクト・ストレージへのデータの配置を参照して、ファイルのアップロードの詳細を確認してください。

   3. DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATIONを実行して、Kerberos外部認証を有効にします。

      たとえば:

      BEGIN
         DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION(
             type     => 'KERBEROS',
             params   => JSON_OBJECT('location_uri' value 'https://objectstorage.us-phoenix-1.oraclecloud.com/n/namespace-string/b/bucketname/o',
                                     'credential_name' value 'my_credential_name')
         );
      END;
      /

      ノート
      
      Oracleでは、Kerberos構成ファイルをオブジェクト・ストアのプライベート・バケットに格納することをお薦めします。

      この例では、namespace-stringはOracle Cloud Infrastructureオブジェクト・ストレージ・ネームスペースで、bucketnameはバケット名です。詳細は、オブジェクト・ストレージ・ネームスペースの理解を参照してください。

      このステップで使用するcredential_nameは、オブジェクト・ストアの資格証明です。

      詳細は、Autonomous DatabaseでのKerberos認証の有効化を参照してください。

   4. Kerberosが構成され、有効になっていることを確認します。

      SELECT property_value FROM database_properties 
            WHERE property_name='KERBEROS_DIRECTORY';

2. Autonomous DatabaseでCMU-ADを有効化および構成します。
   1. CMU構成ファイル(データベース・ウォレット・ファイルcwallet.ssoおよびCMU構成ファイルdsi.oraを含む)をオブジェクト・ストアにアップロードします。

      cwallet.ssoをアップロードして、CMU-AD構成にActive Directoryサービス・アカウントに接続するためのAutonomous Databaseインスタンスの資格証明があるようにします。

      dsi.ora構成ファイルには、Active Directoryサーバーを検出するための情報が含まれています。

      このステップは、使用するオブジェクト・ストアによって異なります。

      Oracle Cloud Infrastructure Object Storeを使用している場合は、オブジェクト・ストレージへのデータの配置を参照して、ファイルのアップロードの詳細を確認してください。

   2. DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATIONプロシージャを実行し、params JSON引数を使用して場所URIを渡します。構成ファイルcwallet.ssoおよびdsi.oraは、location_uriパラメータで指定されたオブジェクト・ストレージの場所に配置する必要があります。

      たとえば:

      BEGIN
         DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION(
             type     => 'CMU',
             params   => JSON_OBJECT('location_uri' value 'https://objectstorage.us-phoenix-1.oraclecloud.com/n/namespace-string/b/bucketname/o',
                                     'credential_name' value 'my_credential_name')
         );
      END;
      /

      Oracleでは、オブジェクト・ストアのプライベート・バケットにCMU構成ファイルを格納することをお薦めします。

      この例では、namespace-stringはOracle Cloud Infrastructureオブジェクト・ストレージ・ネームスペースで、bucketnameはバケット名です。詳細は、オブジェクト・ストレージ・ネームスペースの理解を参照してください。

      このステップで使用するcredential_nameは、オブジェクト・ストアにアクセスするための資格証明です。

      リソース・プリンシパル資格証明を有効にする場合、Oracle Cloud Infrastructureオブジェクト・ストアにアクセスするための資格証明の作成は必要ありません。詳細は、リソース・プリンシパルを使用したOracle Cloud Infrastructureリソースへのアクセスを参照してください。

      location_uriが事前認証済URLまたは事前署名済URLの場合、credential_nameを指定する必要はありません。

      詳細は、Autonomous DatabaseでのMicrosoft Active Directoryを使用したCMUの構成の前提条件を参照してください。

   3. CMU-ADが構成され、有効になっていることを確認します。

      SELECT property_value FROM database_properties
            WHERE property_name='CMU_WALLET';

3. ステップ1およびステップ2を完了した後、CMU-ADを使用したKerberos認証の構成が完了していることを確認します。
   1. SYS_CONTEXT情報がUSERENVに移入されるように、Active DirectoryユーザーとしてAutonomous Databaseインスタンスにログインします。
   2. SYS_CONTEXT USERENVを問い合せます。

      SELECT SYS_CONTEXT('USERENV','AUTHENTICATION_METHOD') FROM DUAL;
      
      SYS_CONTEXT('USERENV','AUTHENTICATION_METHOD')                                 
      --------------------------------------------------------------------------------
      KERBEROS_GLOBAL

   CMU-ADを使用せずにKerberos認証を構成して有効にした場合、この問合せはKERBEROSを返します。詳細は、Autonomous DatabaseでのKerberos認証の構成を参照してください。

   Kerberosを使用せずにCMU-AD認証を構成した場合、この問合せはPASSWORD_GLOBALを返します。詳細は、Autonomous DatabaseでのMicrosoft Active Directoryを使用したCMUの構成の前提条件を参照してください。

Active Directoryロールを追加するには、CREATE ROLE文またはALTER ROLE文を使用して(また、IDENTIFIED GLOBALLY AS句も含めて)データベース・グローバル・ロールをActive Directoryグループにマップします。

1. ADMINユーザーとして、Active Directoryを使用するように構成されたデータベースにログインします(ADMINユーザーには、これらのステップに必要なCREATE ROLEおよびALTER ROLEシステム権限があります)。
2. CREATE ROLE文またはALTER ROLE文を使用して、Autonomous Databaseロールにデータベース認可を設定します。IDENTIFIED GLOBALLY AS句を含めて、Active DirectoryグループのDNを指定します。

   次の構文を使用して、ディレクトリ・ユーザー・グループをデータベース・グローバル・ロールにマップします:

   CREATE ROLE global_role IDENTIFIED GLOBALLY AS 
        'DN_of_an_AD_GROUP_of_WHICH_the_AD_USER_IS_a_MEMBER';

   たとえば:

   CREATE ROLE widget_sales_role IDENTIFIED GLOBALLY AS
        'CN=widget_sales_group,OU=sales,DC=production,DC=example,DC=com';

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

3. GRANT文を使用して、必要な権限やその他のロールをグローバル・ロールに付与します。

   たとえば:

   GRANT CREATE SESSION TO WIDGET_SALES_ROLE;
   GRANT DWROLE TO WIDGET_SALES_ROLE;

   DWROLEは、共通権限が定義されている事前定義済ロールです。See Manage User Privileges on Autonomous Database - Connecting with a Client Tool for information on setting common privileges for Autonomous Database users.

4. 既存のデータベース・ロールをActive Directoryグループに関連付ける場合は、ALTER ROLE文を使用して既存のデータベース・ロールを変更し、そのロールをActive Directoryグループにマップします。

   次の構文を使用して、既存のデータベース・ロールを変更し、それをActive Directoryグループにマップします:

   ALTER ROLE existing_database_role 
      IDENTIFIED GLOBALLY AS 'DN_of_an_AD_GROUP_of_WHICH_the_AD_USER_IS_a_MEMBER';

5. 他のActive Directoryグループに追加のグローバル・ロール・マッピングを作成する場合は、Active Directoryグループごとにこれらのステップに従います。

データベースにアクセスするためにActive Directoryユーザーを追加するには、データベース・グローバル・ユーザーを(IDENTIFIED GLOBALLY AS句も含めて)CREATE USER文またはALTER USER文を使用して、Active Directoryグループまたはユーザーにマップします。

1. ADMINユーザーとして、Active Directoryを使用するように構成されたデータベースにログインします(ADMINユーザーには、これらのステップに必要なCREATE USERおよびALTER USERシステム権限があります)。
2. CREATE USERまたはALTER USER文でIDENTIFIED GLOBALLY AS句も含めてAutonomous Databaseユーザーのデータベース認可を設定し、Active DirectoryのユーザーまたはグループのDNを指定します。

   次の構文を使用して、ディレクトリ・ユーザーをデータベース・グローバル・ユーザーにマップします:

   CREATE USER global_user IDENTIFIED GLOBALLY AS 'DN_of_an_AD_USER';

   次の構文を使用して、ディレクトリ・グループをデータベース・グローバル・ユーザーにマップします:

   CREATE USER global_user IDENTIFIED GLOBALLY AS
       'DN_of_an_AD_GROUP_of_WHICH_the_AD_USER_IS_a_MEMBER';

   たとえば、production.example.comドメインのsales組織単位のwidget_sales_groupという名前のディレクトリ・グループを、WIDGET_SALESという名前の共有データベース・グローバル・ユーザーにマップするには:

   CREATE USER widget_sales IDENTIFIED GLOBALLY AS
        'CN=widget_sales_group,OU=sales,DC=production,DC=example,DC=com';
   

   これにより、共有グローバル・ユーザー・マッピングが作成されます。グローバル・ユーザーwidget_salesを使用するマッピングは、Active Directoryグループ内のすべてのユーザーに対して有効です。したがって、widget_sales_groupのメンバーは、(widget_salesグローバル・ユーザーの共有マッピングを介して) Active Directory資格証明を使用してデータベースにログインできます。

3. Active Directoryユーザーが既存のデータベース・ユーザーを使用し、各自のスキーマを所有し、その既存のデータを所有できるようにするには、ALTER USERを使用して既存のデータベース・ユーザーを変更し、そのユーザーをActive Directoryグループまたはユーザーにマップします。

   • 次の構文を使用して、既存のデータベース・ユーザーを変更してActive Directoryユーザーにマップします:

     ALTER USER existing_database_user IDENTIFIED GLOBALLY AS 'DN_of_an_AD_USER';

   • 次の構文を使用して、既存のデータベース・ユーザーを変更してActive Directoryグループにマップします:

     ALTER USER existing_database_user 
          IDENTIFIED GLOBALLY AS 'DN_of_an_AD_GROUP_of_WHICH_the_AD_USER_IS_a_MEMBER';

4. 他のActive Directoryグループまたはユーザーに追加のグローバル・ユーザー・マッピングを作成する場合は、Active Directoryのグループまたはユーザーごとにこれらのステップに従います。

ADMINユーザーがCMU Active Directory構成ステップを完了し、グローバル・ロールおよびグローバル・サービスを作成した後、ユーザーはActive Directoryのユーザー名およびパスワードを使用してデータベースにログインします。

1. Active Directoryのユーザー名およびパスワードを使用してデータベースにログインするには、次のように接続します:

   CONNECT "AD_DOMAIN\AD_USERNAME"/AD_USER_PASSWORD@TNS_ALIAS_OF_THE_AUTONOMOUS_DATABASE;

   たとえば:

   CONNECT "production\pfitch"/password@adbname_medium;

   次の例のように、Active Directoryドメインをユーザー名とともに指定する場合は、二重引用符で囲む必要があります: "production\pfitch"。

   この例では、ドメインproductionのActive Directoryユーザー名は、pfitchです。Active Directoryユーザーは、そのDN 'CN=widget_sales_group,OU=sales,DC=production,DC=example,DC=com'で指定されたwidget_sales_groupグループのメンバーです。

ユーザーがActive Directoryのユーザー名およびパスワードを使用してデータベースにログインすると、これらのユーザーのアクティビティを検証および監査できるようになります。

CONNECT "production\pfitch"/password@exampleadb_medium;

SHOW USER;

USER is "WIDGET_SALES"

SELECT SYS_CONTEXT('USERENV', 'ENTERPRISE_IDENTITY') FROM DUAL;

SQL> 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', 'AUTHENTICATED_IDENTITY') FROM DUAL;

SQL> SELECT SYS_CONTEXT('USERENV', 'AUTHENTICATED_IDENTITY') FROM DUAL;

SYS_CONTEXT('USERENV','AUTHENTICATED_IDENTITY')
----------------------------------------------------------------------
production\pfitch

Autonomous DatabaseからActive Directoryのユーザーおよびロールを削除するには、標準のデータベース・コマンドを使用します。これを行っても、削除したデータベース・ユーザーまたはロールからマップされていた関連するActive Directoryのユーザーまたはグループは削除されません。

1. DROP USERまたはDROP ROLEシステム権限を付与されたユーザーとして、Active Directoryを使用するように構成されたデータベースにログインします。
2. DROP USERまたはDROP ROLE文を使用して、Active Directoryのグループまたはユーザーにマップされたグローバル・ユーザーまたはグローバル・ロールを削除します。
   詳細は、「Autonomous Databaseでのユーザーの削除」を参照してください。

Autonomous DatabaseからCMU構成を削除する(および、Autonomous DatabaseからActive DirectoryへのLDAPアクセスを無効にする)ステップについて説明します。

1. ADMINユーザーとしてAutonomous Databaseに接続します。
2. DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATIONを使用して、CMU認証を無効にします。
   ノート
   
   このプロシージャを実行するには、ADMINユーザーとしてログインするか、DBMS_CLOUD_ADMINに対するEXECUTE権限を持っている必要があります。

   たとえば:

   BEGIN   
      DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATION;
   END;
   /

   これにより、Autonomous DatabaseインスタンスでのCMU認証が無効になります。