Authenticate Autonomous AI Database Users with Kerberos

You can configure Autonomous AI Database on Dedicated Exadata Infrastructure 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.

Autonomous AI Database on Dedicated Exadata Infrastructure 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 AI Database uses these values for various components that make up a service principal's name:

Component of Service Principal Value in Autonomous AI Database

Component of Service Principal	Value in Autonomous AI 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`: `sql SELECT json_value(cloud_identity, '$.PUBLIC_DOMAIN_NAME') "KINSTANCE" FROM v$pdbs;` Note: This will be the value of the `host` parameter found in the TNS connect string.
`kservice`	On Autonomous AI 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 AI 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 AI Database instance. Use the following command to obtain the `GUID` (case is significant): `sql 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 AI Database instances. When you use a custom name you do not need to create and upload different Keytab files for each Autonomous AI 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 AI Database instance, use the following query to view the Kerberos service name: `sql SELECT SYS_CONTEXT('USERENV', 'KERBEROS_SERVICE_NAME') FROM DUAL;`
`REALM`	Any realm supported by your KDC. `REALM` must always be in uppercase.

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:

sql SELECT json_value(cloud_identity, '$.PUBLIC_DOMAIN_NAME') "KINSTANCE" FROM v$pdbs;

Note: This will be the value of the host parameter found in the TNS connect string.

kservice

On Autonomous AI 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 AI 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 AI Database instance.
Use the following command to obtain the GUID (case is significant):
```
sql 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 AI Database instances. When you use a custom name you do not need to create and upload different Keytab files for each Autonomous AI 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 AI Database instance, use the following query to view the Kerberos service name:

sql 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 AI 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.

Notes About Kerberos Authentication on Autonomous AI Database

Before proceeding with Kerberos authentication on Autonomous AI Database on Dedicated Exadata Infrastructure, review the following notes:

If you enable Kerberos authentication for your Autonomous AI Database, you can still use password-based database authentication for your database.
Only one external authentication method can be used for your Autonomous AI Database at any time. That is, you can only have Oracle Cloud Infrastructure (IAM), Centrally Managed User with Active Directory (CMU-AD), Azure AD, or Kerberos authentication schemes enabled at any time.

Note: The only exception is that Kerberos authentication can be configured on top of CMU-AD to provide CMU-AD Kerberos authentication for Microsoft Active Directory users.

Kerberos authentication is not supported for the following 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 (OCI) Console to reset the ADMIN user's password and regain access if a corrupted keytab file causes ADMIN user's authentication to fail.
Kerberos authentication is supported with TCP protocol for Autonomous AI Database versions 19.27 or later.
Kerberos authentication is not supported with DB_LINKs and databases with Autonomous Data Guard.

Enable Kerberos Authentication on Autonomous AI Database

Follow the below-listed steps to enable Kerberos authentication for Autonomous AI Database on Dedicated Exadata Infrastructure:

As there can only be one external authentication scheme enabled for an Autonomous AI Database at any given time, run the DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATION procedure to disable any external authentication scheme that is already enabled for your database.

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;
/
```
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 in Oracle Database 19c Security Guide or Oracle Database 26ai Security Guide.
Copy the Kerberos configuration files krb.conf and v5srvtab to a bucket in your Object Store.

Note: Oracle recommends that you store the Kerberos configuration files in a private 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.
To enable Kerberos as the external authentication for your Autonomous AI Database, 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 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: To provide CMU-AD Kerberos authentication for Microsoft Active Directory users, you can enable Kerberos authentication on top of CMU-AD by setting type to CMU in the above example.

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.

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 use the kerberos_service_name parameter to specify the 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;
/
```
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 AI Database

Before enabling any other external authentication scheme on your database, you must disable the Kerberos authentication running the DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATION procedure.

To run this 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;
/

See DISABLE_EXTERNAL_AUTHENTICATION Procedure for more information.

Note: To provide CMU-AD Kerberos authentication for the Microsoft Active Directory users, you must continue to configure CMU-AD authentication without disabling Kerberos authentication.