Configure Kerberos Authentication with Autonomous Database

Describes how to configure Kerberos to authenticate Oracle Autonomous Database users.

• About Kerberos Authentication
  You can configure Oracle Autonomous Database to use Kerberos network authentication protocol to authenticate database users. Kerberos is a strong network authentication protocol. It uses secret-key cryptography to enable strong authentication by providing user-to-server authentication.
• Components of the Kerberos Authentication System
  Provides an overview of the Kerberos authentication system.
• Enable Kerberos Authentication on Autonomous Database
  Shows the steps to enable Kerberos authentication on your Autonomous Database instance.
• Disable Kerberos Authentication on Autonomous Database
  Shows the steps to disable Kerberos authentication for your Autonomous Database instance.
• Notes for Kerberos Authentication on Autonomous Database
  Provides notes on using Kerberos Authentication for Autonomous Database.

About Kerberos Authentication

You can configure Oracle Autonomous Database to use Kerberos network authentication protocol to authenticate database users. Kerberos is a strong network authentication protocol. It uses secret-key cryptography to enable strong authentication by providing user-to-server authentication.

• Oracle Autonomous Database support for Kerberos provides the benefits of single sign-on and centralized authentication of Oracle users. Kerberos is a trusted third-party authentication system that relies on shared secrets. It presumes that the third party is secure, and provides single sign-on capabilities, centralized password storage, database link authentication, and enhanced PC security. It does this through a Kerberos authentication server.

• The Kerberos system revolves around the concept of a ticket. A ticket is a set of electronic information that identifies a user or a service. A ticket identifies you and your network access privileges.

• In Kerberos-based authentication, you transparently send a request for a ticket to a Key Distribution Center (KDC). The Key Distribution Center authenticates you and grants you a ticket to access the database.

Components of the Kerberos Authentication System

Provides an overview of the Kerberos authentication system.

• A realm establishes an authentication administrative domain. Each realm has its own Kerberos database which contains the users and services for that particular administrative domain.

• Tickets are issued by the Key Distribution Center (KDC). Clients present tickets to the Database Server to demonstrate the authenticity of their identity. Each ticket has expiration and a renewal time.

• Keytabs stores long-term keys for one or more principals. A keytab file is generated by invoking the tool kadmin.local (for MIT Key Distribution Center) or ktpass (for Active Directory Key Distribution Center).

• Principals are the entries in the Key Distribution Center database. Each user, host or service is given a principal. A principal is a unique identity to which the Key Distribution Center can assign tickets.

• Kerberos support in Autonomous Database uses these values for various components that make up a service principal's name:

Component of Service Principal	Value in Autonomous Database
kinstance	You can obtain this value 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 query to obtain the kinstance: SELECT json_value(cloud_identity, '$.PUBLIC_DOMAIN_NAME') "KINSTANCE" FROM v$pdbs;
kservice	On Autonomous Database you have two options for the kservice value: Use the database GUID: If you do not provide a Kerberos service name with DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION, the default service name used is the GUID of the Autonomous Database instance. In this case, when you create the keytab file, use the GUID as the value for the service name. Because in the default case the Keytab file uses a service name that is a GUID, which is instance specific, when you use the default service name you must generate different Keytab files for each Autonomous Database instance. Use the following command to obtain the GUID (case is significant): SELECT GUID FROM v$pdbs; Use a custom name: Set the service name when you want to use the same Keytab files on multiple Autonomous Database instances. When you use a custom name you do not need to create and upload different Keytab files for each Autonomous Database instance. When you use a custom name you must specify the params kerberos_service_name parameter with DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION. Specifying this parameter is not required when you use the GUID for the service name. After Kerberos is enabled on your Autonomous Database instance, use the following query to view the Kerberos service name: SELECT SYS_CONTEXT('USERENV', 'KERBEROS_SERVICE_NAME') FROM DUAL;
REALM	Any realm supported by your KDC. REALM must always be in uppercase.

To enable Kerberos authentication for your Autonomous Database, you must keep your Kerberos configuration files (krb.conf) and service key table file (v5srvtab) ready. For more information on these files and steps to obtain them, please see Configuring Kerberos Authentication.

Enable Kerberos Authentication on Autonomous Database

Shows the steps to enable Kerberos authentication on your Autonomous Database instance.

To run DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION you must be logged in as ADMIN user or have the EXECUTE privilege on DBMS_CLOUD_ADMIN.

To use DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION to enable Kerberos authentication:

To enable Kerberos authentication for your Autonomous Database, you must obtain the Kerberos configuration files: krb.conf and the service key table file v5srvtab. For more information on these files and steps required to obtain them, see Configuring Kerberos Authentication .

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

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

2. 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 krb.conf and v5srvtab in the Object Storage location specified in the location_uri parameter.

   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.

   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 then supplying a credential_name is not required.

   This creates a directory object named KERBEROS_DIR in your database and uses the credential to download the Kerberos configuration files from the Object Store location to the directory object.

   You can specify the params kerberos_service_name parameter to specify a Kerberos service name. 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'
                  'kerberos_service_name' value 'oracle' ));
   END;
   /

3. After you enable Kerberos authentication, remove the configuration krb.conf and v5srvtab 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 Navigate to Oracle Cloud Infrastructure Object Storage and Create Bucket for more information on Object Storage.

See ENABLE_EXTERNAL_AUTHENTICATION Procedure for more information.

Disable Kerberos Authentication on Autonomous Database

Shows the steps to disable Kerberos authentication for your Autonomous Database instance.

1. Run DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATION procedure to disable Kerberos authentication. To run the procedure, you must be logged in as ADMIN user or have the EXECUTE privilege on DBMS_CLOUD_ADMIN.

   BEGIN   
      DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATION;
   END;
   /

   This disables the Kerberos authentication (or any external authentication scheme specified) for Oracle Autonomous Database.

   See DISABLE_EXTERNAL_AUTHENTICATION Procedure for more information.

Notes for Kerberos Authentication on Autonomous Database

Provides notes on using Kerberos Authentication for Autonomous Database.

• If you enable Kerberos authentication for your Autonomous Database, you can still use password-based database authentication for your database.

• Kerberos authentication is not supported for these tools:

  • Oracle Database API for MongoDB

  • Oracle REST Data Services

  • Oracle Machine Learning

  • APEX

  • Oracle Graph Studio

  • Oracle Database Actions

• You can enable Kerberos authentication to authenticate the ADMIN user. You can use the Reset Password functionality on the Oracle Cloud Infrastructure Console to reset the ADMIN user's password and regain access if a corrupted keytab file causes ADMIN user's authentication to fail.

• The default value for the maximum clock skew in Autonomous Database is 300 seconds (5 minutes). You cannot change the default clock skew value.