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.
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 paramskerberos_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 .
Copy the Kerberos configuration files krb.conf and
v5srvtab to a bucket in your Object Store.
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.
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 paramskerberos_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;
/
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.
Disable Kerberos Authentication on Autonomous Database 🔗
Shows the steps to disable Kerberos authentication for your Autonomous Database instance.
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.
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.