1. Connect to the Autonomous Database as the ADMIN user.
2. Verify if another external authentication scheme is enabled on your database, and disable it.
   Note
   
   You can continue with CMU-AD configuration on top of Kerberos to provide CMU-AD Kerberos authentication for Microsoft Active Directory users.
3. 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.

4. On your Autonomous Database, create a new directory object or choose an existing directory object. This is the directory where you store the wallet and the configuration file for connecting to Active Directory:

   For example:

   CREATE OR REPLACE DIRECTORY cmu_wallet_dir AS 'cmu_wallet';

   Use the following SQL statement to query the file system directory path of the directory object:

   SELECT DIRECTORY_PATH FROM DBA_DIRECTORIES WHERE 
      DIRECTORY_NAME='directory_object_name';

   For example:

   SELECT DIRECTORY_PATH FROM DBA_DIRECTORIES WHERE 
      DIRECTORY_NAME='CMU_WALLET_DIR';
   
   
   DIRECTORY_PATH
   ----------------------------------------------------------------------------
   /file_system_directory_path_example/cmu_wallet

   Note
   
   The directory object name in the query must be upper case as its case was not preserved when the directory object was created.

   If you want to preserve case for the directory object name then you need to include its name in double quotes. For example:

   CREATE OR REPLACE DIRECTORY "CMU_wallet_dir" AS 'cmu_wallet';

5. Use DBMS_CLOUD.GET_OBJECT to copy the CMU configuration files, the database wallet cwallet.sso and dsi.ora, from your Object Store to the directory that you created or chose in the step 4 above.

   For example, use DBMS_CLOUD.GET_OBJECT to copy the files from Object Store to CMU_WALLET_DIR as follows:

   BEGIN
      DBMS_CLOUD.GET_OBJECT(
         credential_name => 'DEF_CRED_NAME',
         object_uri => 'https://objectstorage.us-phoenix-1.oraclecloud.com/n/namespace-string/b/bucketname/o/cwallet.sso',
         directory_name => 'CMU_WALLET_DIR');
      DBMS_CLOUD.GET_OBJECT(
         credential_name => 'DEF_CRED_NAME',
         object_uri => 'https://objectstorage.us-phoenix-1.oraclecloud.com/n/namespace-string/b/bucketname/o/dsi.ora',
         directory_name => 'CMU_WALLET_DIR');
   END;
   /

   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.

   See GET_OBJECT Procedure for more information.

   Use the following SQL statement to query the files copied to the directory.

   SELECT * FROM DBMS_CLOUD.LIST_FILES('directory_object_name');

   For example:

   SELECT * FROM DBMS_CLOUD.LIST_FILES('CMU_WALLET_DIR');

   Note that the directory object name in this query must be upper case as its case was not preserved when the directory object was created.

6. Enable CMU-AD in your Autonomous Database using the DBMS_CLOUD_ADMIN package.
   Note
   
   Replace the directory names in the below example with those chosen for your environment. Ensure you are logged in as the ADMIN user before running this command.

   BEGIN
     DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION(
       type     => 'CMU',
       params   => JSON_OBJECT('directory_name' value 'CMU_WALLET_DIR')
     ); 
   END;
   / 

7. To maintain security, 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.
   See DELETE_OBJECT Procedure for more information on DBMS_CLOUD.DELETE_OBJECT.

1. Connect to the Autonomous Database as the ADMIN user.
2. Verify if another external authentication scheme is enabled on your database, and disable it using the following SQL command.

   BEGIN
     DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATION;
   END;
   /

3. CMU-AD needs your Active Directory connection wallet cwallet.sso and the dsi.ora files on a local file system on your Autonomous Exadata VM Cluster (AVMC). You can achieve this by hosting these files in Oracle Object Store service on Oracle Cloud Infrastructure and then copying them locally using the DBMS_CLOUD package. You can find this process with detailed steps and examples in Configure CMU with Microsoft Active Directory on Autonomous Database.
4. If hosting cwallet.sso and dsi.ora in cloud storage is not possible, you may use an Network File System (NFS) share in your data center to host these files, and then move them to a database directory under the Database File System (DBFS). To do so, you must first attach a locally available NFS share to the Autonomous Database directory object as demonstrated below:
   1. Create a Database directory in your Autonomous Database instance using the following SQL command from your SQL client:

      create or replace directory TMPFSSDIR as 'tmpfssdir';
      

   2. Mount your NFS share to this directory using the DBMS_CLOUD_ADMIN package available in Autonomous Database.

      Tip:

      You may need to work with your network or storage administrator to make an NFS share available.

      BEGIN
        DBMS_CLOUD_ADMIN.attach_file_system(
          file_system_name => <some_name_you_assign>,
          file_system_location => <your_nfs_fs_path>,
          directory_name => <tmpfssdir_created_above>,
          description => ‘Any_desc_you_like_to_give’
        );
      END

      For example:

      BEGIN 
        DBMS_CLOUD_ADMIN.attach_file_system(
          file_system_name => 'AD-FSS',
          file_system_location => acme.com:/nfs/mount1',
          directory_name => 'TMPFSSDIR',
          description => ‘nfs to host AD files’
        );
      END;

5. To avoid a dependency on the NFS share for the cwallet.sso and dsi.ora files to be available to CMU, move them to a local file system folder using a database directory mapping. Since Autonomous Database restricts access to the local file system, create a copy procedure using utl_file as demonstrated below:
   1. Create a Database directory in your Autonomous Database instance using the following SQL command from your SQL client:

      CREATE OR REPLACE DIRECTORY cmu_wallet_dir AS 'cmu_wallet';

   2. Check the directory path of the above created directory using the following SQL command:

      SELECT DIRECTORY_PATH 
      FROM DBA_DIRECTORIES 
      WHERE DIRECTORY_NAME ='CMU_WALLET_DIR';

      Note
      
      The directory object name must be in upper case in the query, as its case was not preserved while creating the directory object.
   3. Copy dsi.ora and cwallet.sso from the NFS directory to the local CMU Wallet directory using the UTL_FILE utility.
      For example:
      Create a stored procedure called copyfile as shown below:

      CREATE OR REPLACE PROCEDURE copyfile(
        in_loc_dir IN VARCHAR2,
        in_filename IN VARCHAR2,
        out_loc_dir IN VARCHAR2,
        out_filename IN VARCHAR2
      )
      IS
        in_file UTL_FILE.file_type;
        out_file UTL_FILE.file_type;
        buffer_size CONSTANT INTEGER := 32767;
        buffer RAW (32767);
        buffer_length INTEGER; 
      BEGIN
        in_file := UTL_FILE.fopen (in_loc_dir, in_filename, 'rb', buffer_size);
        out_file := UTL_FILE.fopen (out_loc_dir, out_filename, 'wb', buffer_size);
        UTL_FILE.get_raw (in_file, buffer, buffer_size);
        buffer_length := UTL_RAW.LENGTH (buffer);
      
        WHILE buffer_length > 0
        LOOP 
          UTL_FILE.put_raw (out_file, buffer, TRUE);
      
          IF buffer_length = buffer_size
            THEN
              UTL_FILE.get_raw (in_file, buffer, buffer_size);
              buffer_length := UTL_RAW.LENGTH (buffer);
            ELSE
              buffer_length := 0;
            END IF;
        END LOOP;
      
        UTL_FILE.fclose (in_file);
        UTL_FILE.fclose (out_file);
      EXCEPTION
        WHEN NO_DATA_FOUND
        THEN
          UTL_FILE.fclose (in_file);
          UTL_FILE.fclose (out_file);
      END;
      / 

      Compile the copyfile stored procedure. Once successfully compiled, run the copyfile procedure once each to copy dsi.ora and cwallet.sso from the NFS directory to the local CMU Wallet directory, as demonstrated below:

      EXEC copyfile('TMPFSSDIR','dsi.ora','CMU_WALLET_DIR','dsi.ora');

      EXEC copyfile('TMPFSSDIR','cwallet.sso','CMU_WALLET_DIR','cwallet.sso');

   4. Run the following SQL query to validate if the files are copied to the local CMU Wallet directory successfully.

      SELECT * FROM DBMS_CLOUD.LIST_FILES('CMU_WALLET_DIR');

6. Using the following command, detach the NFS share since you do not need it for CMU-AD after the files are copied to the local directory.

   exec DBMS_CLOUD_ADMIN.detach_file_system(file_system_name => <FILE_SYSTEM_NAME>);

7. Enable CMU-AD in your Autonomous Database using the DBMS_CLOUD_ADMIN package.
   Note
   
   Replace the directory names in the below example with those chosen for your environment. Ensure you are logged in as the ADMIN user before running this command.

   BEGIN
     DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION(
       type     => 'CMU',
       params   => JSON_OBJECT('directory_name' value 'CMU_WALLET_DIR')
     ); 
   END;
   / 

8. Validate by querying the property value of the database property CMU_WALLET as shown below.

   SELECT PROPERTY_VALUE
   FROM DATABASE_PROPERTIES
   WHERE PROPERTY_NAME = 'CMU_WALLET';

   For Example:

   SELECT PROPERTY_VALUE
   FROM DATABASE_PROPERTIES
   WHERE PROPERTY_NAME='CMU_WALLET';
   
   PROPERTY_VALUE
   --------------
   CMU_WALLET_DIR

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 Database User Privileges 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 an Autonomous 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 Autonomous Database using their Active Directory username and password.

1. To log in to the Autonomous 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 Autonomous 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 Database Users 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.

The following limitations apply to CMU with Active Directory on Autonomous Database:

• Only "password authentication" and Kerberos is supported for CMU with Autonomous Database. When you are using CMU authentication with Autonomous Database, other authentication methods such as Azure AD, OCI IAM, and PKI are not supported.

• Oracle Application Express and Database Actions is not supported for Active Directory users with Autonomous Database.