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は、オブジェクト・ストアにアクセスするための資格証明です。

   Creating a credential to access Oracle Cloud Infrastructure Object Store is not required if you enable resource principal credentials.詳細は、リソース・プリンシパルを使用した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認証を有効にした後、データベース・ウォレットを含むCMU構成ファイルcwallet.ssoおよびCMU構成ファイルdsi.oraをオブジェクト・ストアから削除します。ローカル・オブジェクト・ストア・メソッドを使用してこれらのファイルを削除するか、DBMS_CLOUD.DELETE_OBJECTを使用してオブジェクト・ストアからファイルを削除できます。
5. Active Directoryサーバーがプライベート・エンドポイント上にある場合は、追加の構成ステップを実行して、プライベート・エンドポイントへのアクセスを提供します。
   1. データベース・プロパティROUTE_OUTBOUND_CONNECTIONSを値'PRIVATE_ENDPOINT'に設定します。

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

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

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

   CMU-ADでKerberos認証を構成する場合、KerberosではMicrosoft Active Directory 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をオブジェクト・ストアにアップロードします。

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

      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は、オブジェクト・ストアにアクセスするための資格証明です。

      Creating a credential to access Oracle Cloud Infrastructure Object Store is not required if you enable resource principal credentials.詳細は、リソース・プリンシパルを使用したOracle Cloud Infrastructureリソースへのアクセスを参照してください。

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

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

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

      SELECT property_value FROM database_properties
            WHERE property_name='CMU_WALLET';

3. ステップ1およびステップ2を完了したら、CMU-ADによるKerberos認証の構成が完了していることを確認します。
   1. Active DirectoryユーザーとしてAutonomous Databaseインスタンスにログインし、USERENVにSYS_CONTEXT情報が移入されるようにします。
   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でCMUをMicrosoft Active Directoryで構成するための前提条件を参照してください。

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は、共通権限が定義されている事前定義済ロールです。Autonomous Databaseユーザーの共通権限の設定の詳細は、Autonomous Databaseでのユーザー権限の管理- クライアント・ツールを使用した接続を参照してください。

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ユーザーを追加してデータベースにアクセスするには、CREATE USERまたはALTER USER文を(IDENTIFIED GLOBALLY AS句とともに)使用して、データベース・グローバル・ユーザーを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認証が無効になります。