1. Verify if another external authentication scheme is enabled on your database, and disable it.

   You can continue with CMU-AD configuration on top of Kerberos to provide CMU-AD Kerberos authentication for Microsoft Active Directory users.

   See Kerberos Authentication for CMU with Microsoft Active Directory for more information.

2. Upload the CMU configuration files, including the database wallet file, cwallet.sso and the CMU configuration file, dsi.ora to your Object Store. This step depends on the Object Store you use.

   The dsi.ora configuration file contains the information to find the Active Directory servers.

   If you are using Oracle Cloud Infrastructure Object Store, see Putting Data into Object Storage for details on uploading files.

3. Run DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION procedure and pass in a location URI with the params JSON argument. You must place the configuration files cwallet.sso and dsi.ora in the Object Storage location specified in the location_uri parameter.

   For example:

   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 recommends that you store the CMU configuration files in a private bucket in your Object Store.

   In this example, namespace-string is the Oracle Cloud Infrastructure object storage namespace and bucketname is the bucket name. See Understanding Object Storage Namespaces for more information.

   The credential_name you use in this step is the credentials to access the Object Store.

   Creating a credential to access Oracle Cloud Infrastructure Object Store is not required if you enable resource principal credentials. See Use Resource Principal to Access Oracle Cloud Infrastructure Resources for more information.

   If the location_uri is a pre-authenticated URL or a pre-signed URL, then supplying a credential_name is not required.

   The procedure creates a directory object named CMU_WALLET_DIR in your database and copies the CMU configuration files from the Object Store location to the directory object. This procedure also sets the database property CMU_WALLET to the value 'CMU_WALLET_DIR' and sets the LDAP_DIRECTORY_ACCESS parameter value to the value PASSWORD to enable access from the Autonomous Database instance to Active Directory.

4. After you enable CMU authentication, remove the CMU configuration files including the database wallet cwallet.sso and the CMU configuration file dsi.ora from Object Store. You can use local Object Store methods to remove these files or use DBMS_CLOUD.DELETE_OBJECT to delete the files from Object Store.
5. When Active Directory servers are on a private endpoint, perform additional configuration steps to provide access to the private endpoint.
   1. Set the database property ROUTE_OUTBOUND_CONNECTIONS to the value 'PRIVATE_ENDPOINT'.

      See Enhanced Security for Outbound Connections with Private Endpoints for more information.

   2. Validate that the CMU-AD configuration file dsi.ora includes host names. When ROUTE_OUTBOUND_CONNECTIONS is set to 'PRIVATE_TARGET', IP addresses cannot be specified in dsi.ora.

1. Enable Kerberos in your Autonomous Database instance using Microsoft Active Directory Kerberos server.

   Only Microsoft Active Directory Kerberos servers are supported for Kerberos when you configure Kerberos authentication with CMU-AD.

   1. To enable Kerberos authentication for your Autonomous Database, you must obtain the Kerberos configuration files: krb.conf and the service key table file v5srvtab.

      To generate these files when you configure Kerberos authentication with CMU-AD you need the server host name. You can obtain the value of the server host from the attribute PUBLIC_DOMAIN_NAME in the CLOUD_IDENTITY column of V$PDBS. This value is different from the Fully Qualified Domain Name (FQDN) for a database on a private endpoint.

      Use the following command to obtain the server host name:

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

      You can use a command such as the following to generate the service key table file:

      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

      For example:

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

      For more information on these files and steps required to obtain them, see Configuring Kerberos Authentication.

   2. Copy the Kerberos configuration files krb.conf and v5srvtab to a bucket in your Object Store.

      This step differs depending on the Object Store you use.

      If you are using Oracle Cloud Infrastructure Object Store, see Putting Data into Object Storage for details on uploading files.

   3. Run DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION to enable Kerberos external authentication.

      For example:

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

      Note
      
      Oracle recommends that you store the Kerberos configuration files in a private bucket in your Object Store.

      In this example, namespace-string is the Oracle Cloud Infrastructure object storage namespace and bucketname is the bucket name. See Understanding Object Storage Namespaces for more information.

      The credential_name you use in this step is the credentials for the Object Store.

      See Enable Kerberos Authentication on Autonomous Database for more information.

   4. Confirm that Kerberos is configured and enabled.

      SELECT property_value FROM database_properties 
            WHERE property_name='KERBEROS_DIRECTORY';

2. Enable and configure CMU-AD on Autonomous Database.
   1. Upload the CMU configuration files, including the database wallet file, cwallet.sso and the CMU configuration file, dsi.ora to your Object Store.

      You upload the cwallet.sso so that the CMU-AD configuration has the credentials for the Autonomous Database instance to connect to the Active Directory service account.

      The dsi.ora configuration file contains the information to find the Active Directory servers.

      This step differs depending on the Object Store you use.

      If you are using Oracle Cloud Infrastructure Object Store, see Putting Data into Object Storage for details on uploading files.

   2. Run the DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION procedure and pass in a location URI with the params JSON argument. You must place the configuration files cwallet.sso and dsi.ora in the Object Storage location specified in the location_uri parameter.

      For example:

      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 recommends that you store the CMU configuration files in a private bucket in your Object Store.

      In this example, namespace-string is the Oracle Cloud Infrastructure object storage namespace and bucketname is the bucket name. See Understanding Object Storage Namespaces for more information.

      The credential_name you use in this step is the credentials to access the Object Store.

      Creating a credential to access Oracle Cloud Infrastructure Object Store is not required if you enable resource principal credentials. See Use Resource Principal to Access Oracle Cloud Infrastructure Resources for more information.

      If the location_uri is a pre-authenticated URL or a pre-signed URL, then supplying a credential_name is not required.

      See Prerequisites to Configure CMU with Microsoft Active Directory on Autonomous Database for more information.

   3. Confirm that CMU-AD is configured and enabled.

      SELECT property_value FROM database_properties
            WHERE property_name='CMU_WALLET';

3. After completing Step 1 and Step 2, verify that the configuration of Kerberos authentication with CMU-AD is complete.
   1. Login to the Autonomous Database instance as an Active Directory user so that SYS_CONTEXT information populated in your USERENV.
   2. Query the SYS_CONTEXT USERENV.

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

   When you have Kerberos authentication configured and enabled without CMU-AD, this query returns: KERBEROS. See Configure Kerberos Authentication with Autonomous Database for more information.

   When you have CMU-AD authentication configured without Kerberos, this query returns: PASSWORD_GLOBAL. See Prerequisites to Configure CMU with Microsoft Active Directory on Autonomous Database for more information.

To add Active Directory roles, map the database global roles to Active Directory groups with CREATE ROLE or ALTER ROLE statements (and include the IDENTIFIED GLOBALLY AS clause).

1. Log in as the ADMIN user to the database that is configured to use Active Directory (the ADMIN user has the CREATE ROLE and ALTER ROLE system privileges that you need for these steps).
2. Set the database authorization for Autonomous Database roles with CREATE ROLE or ALTER ROLE statement. Include the IDENTIFIED GLOBALLY AS clause and specify the DN of an Active Directory group.

   Use the following syntax to map a directory user group to a database global role:

   CREATE ROLE global_role IDENTIFIED GLOBALLY AS 
        'DN_of_an_AD_GROUP_of_WHICH_the_AD_USER_IS_a_MEMBER';

   For example:

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

   In this example all members of the widget_sales_group are authorized with the database role widget_sales_role when they log in to the database.

3. Use GRANT statements to grant the required privileges or other roles to the global role.

   For example:

   GRANT CREATE SESSION TO WIDGET_SALES_ROLE;
   GRANT DWROLE TO WIDGET_SALES_ROLE;

   DWROLE is a predefined role that has common privileges defined. See Manage User Privileges on Autonomous Database - Connecting with a Client Tool for information on setting common privileges for Autonomous Database users.

4. If you want to make an existing database role to be associated with an Active Directory group, then use ALTER ROLE statement to alter the existing database role to map the role to an Active Directory group.

   Use the following syntax to alter an existing database role to map it to an Active Directory group:

   ALTER ROLE existing_database_role 
      IDENTIFIED GLOBALLY AS 'DN_of_an_AD_GROUP_of_WHICH_the_AD_USER_IS_a_MEMBER';

5. If you want to create additional global role mappings for other Active Directory groups, follow these steps for each Active Directory group.

To add Active Directory users to access a database, map database global users to Active Directory groups or users with CREATE USER or ALTER USER statements (with IDENTIFIED GLOBALLY AS clause).

1. Log in as the ADMIN user to the database that is configured to use Active Directory (the ADMIN user has the required CREATE USER and ALTER USER system privileges that you need for these steps).
2. Set database authorization for Autonomous Database users with CREATE USER or ALTER USER statements and include the IDENTIFIED GLOBALLY AS clause, specifying the DN of an Active Directory user or group.

   Use the following syntax to map a directory user to a database global user:

   CREATE USER global_user IDENTIFIED GLOBALLY AS 'DN_of_an_AD_USER';

   Use the following syntax to map a directory group to a database global user:

   CREATE USER global_user IDENTIFIED GLOBALLY AS
       'DN_of_an_AD_GROUP_of_WHICH_the_AD_USER_IS_a_MEMBER';

   For example, to map a directory group named widget_sales_group in the sales organization unit of the production.example.com domain to a shared database global user named WIDGET_SALES:

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

   This creates a shared global user mapping. The mapping, with global user widget_sales, is effective for all users in the Active Directory group. Thus, anyone in the widget_sales_group can log in to the database using their Active Directory credentials (through the shared mapping of the widget_sales global user).

3. If you want Active Directory users to use an existing database user, own its schema, and own its existing data, then use ALTER USER to alter an existing database user to map the user to an Active Directory group or user.

   • Use the following syntax to alter an existing database user to map it to an Active Directory user:

     ALTER USER existing_database_user IDENTIFIED GLOBALLY AS 'DN_of_an_AD_USER';

   • Use the following syntax to alter an existing database user to map it to an Active Directory group:

     ALTER USER existing_database_user 
          IDENTIFIED GLOBALLY AS 'DN_of_an_AD_GROUP_of_WHICH_the_AD_USER_IS_a_MEMBER';

4. If you want to create additional global user mappings for other Active Directory groups or users, follow these steps for each Active Directory group or user.

After the ADMIN user completes the CMU Active Directory configuration steps and creates global roles and global users, users log in to the database using their Active Directory username and password.

1. To log in to the database using an Active Directory username and password, connect as follows:

   CONNECT "AD_DOMAIN\AD_USERNAME"/AD_USER_PASSWORD@TNS_ALIAS_OF_THE_AUTONOMOUS_DATABASE;

   For example:

   CONNECT "production\pfitch"/password@adbname_medium;

   You need to include double quotes when the Active Directory domain is included along with the username, as with this example: "production\pfitch".

   In this example, the Active Directory username is pfitch in domain production. The Active Directory user is a member of widget_sales_group group which is identified by its DN 'CN=widget_sales_group,OU=sales,DC=production,DC=example,DC=com'.

When users log in to the database using their Active Directory username and password, you can verify and audit the user activity.

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

To remove Active Directory users and roles from Autonomous Databases, use standard database commands. This does not remove the related Active Directory users or groups that were mapped from the dropped database users or roles.

1. Log in to the database that is configured to use Active Directory as a user who has been granted the DROP USER or DROP ROLE system privilege.
2. Drop the global users or the global roles that are mapped to Active Directory groups or users with DROP USER or DROP ROLE statement.
   See Remove Users on Autonomous Database for more information.

Describes the steps to remove the CMU configuration from your Autonomous Database (and disable the LDAP access from your Autonomous Database to Active Directory).

1. Connect to the Autonomous Database as the ADMIN user.
2. Use the DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATION to disable CMU authentication.
   Note
   
   To run this procedure you must be logged in as ADMIN user or have the EXECUTE privilege on DBMS_CLOUD_ADMIN.

   For example:

   BEGIN   
      DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATION;
   END;
   /

   This disables CMU authentication on your Autonomous Database instance.