Oracle and Kerberos

Overview

This page describes how to set up an Oracle database instance for Kerberized connections. The following steps are described:

Creating a service principal and adding it to the database system
Configuring the database to use Kerberos authentication
Creating database users identified via Kerberos
Troubleshooting tips

Prerequisites

This page assumes you already have a Kerberized network environment with an MIT Kerberos KDC. These procedures have been tested successfully with Oracle database versions 11.2.0.2, 11.2.0.4, and 12.2.1. Oracle database version 12.1.0.1 did not pass testing.

The following is needed from your Kerberos environment:

The krb5.conf file
A user principal and associated password or key tab to be used for logging into the Oracle database
The ability to create a service principal for the Oracle database and retrieve the associated key tab

In addition, these example values are used:

Oracle database host – ora-db.bar.com
Oracle service name – oracle

Creating the Oracle service principal

A service principal is a unique identity for a service on a network, used primarily for Kerberos authentication. The format for naming the Oracle service principal combines the service name and the host, followed by the domain.

Given the example values provided where the service name is oracle and the host is ora-db.bar.com, the domain being bar.com, the service principal would aptly be named oracle/ora-db.bar.com@bar.com.

The hostname is whatever the database thinks its hostname is, so the output of uname -n on the database system rather than the actual DNS name. Typically, these values would be the same, but this is not always the case.

On the KDC, run the following:

CODE

# kadmin.local
kadmin.local: addprinc -randkey oracle/ora-db@bar.com
kadmin.local: ktadd -norandkey -k /var/tmp/ora-db.keytab oracle/ora-db@bar.com

Copy the resulting key tab file (/var/tmp/ora-db.keytab) to the Oracle database at this location: /etc/v5srvtab.
As a root user on the Oracle database, ensure the key tab has the correct permissions:

CODE

# chown root:oinstall /etc/v5srvtab
# chmod 440 /etc/v5srvtab

Finally, copy /etc/krb5.conf from the KDC to /etc/krb5.conf on the Oracle database. This file should be readable by all users.

Configuring the Oracle database for Kerberos

Log into the Oracle database system as the appropriate user for the database in question.

CODE

$ cd $ORACLE_HOME
$ vi network/admin/sqlnet.ora

For Oracle 11, add the following:

CODE

SQLNET.KERBEROS5_CONF=/etc/krb5.conf SQLNET.AUTHENTICATION_SERVICES=(BEQ,KERBEROS5) SQLNET.KERBEROS5_CONF_MIT=true SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=oracle

For Oracle 12, add the following:

CODE

NAMES.DIRECTORY_PATH=(TNSNAMES, EZCONNECT, HOSTNAME) SQLNET.KERBEROS5_CONF=/etc/krb5.conf SQLNET.AUTHENTICATION_SERVICES=(BEQ,KERBEROS5PRE,KERBEROS5) SQLNET.KERBEROS5_CONF_MIT=true SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=oracle

For Oracle 11 databases (not needed on Oracle 12), use the $ vi dbs/init.ora command to open the init.ora file using vi.

Add this line at the end – OS_AUTHENT_PREFIX=""

OS_AUTHENT_PREFIX is an Oracle initialization parameter that affects operating system authentication. Setting this parameter to an empty string ("") means that no prefix is required for Oracle to recognize operating system user names.

Creating a database User Identified via Kerberos

Log into the Oracle database system as the appropriate database user and open a database session as the DBA:

CODE

$ sqlplus / as sysdba

On Oracle 12, to alter your session to create the user in one of the PDBs:

CODE

SQL> alter session set container=MYPDB;

Create the user that will connect to the database using Kerberos:

CODE

SQL> create user krbdbuser identified externally as 'krbuser@BAR.COM';

Grant the user privileges necessary for masking.

The following example grants all privileges:

Oracle 11

CODE

SQL> grant all privilege to krbdbuser;

Oracle 12 (Customize permissions as necessary for your environment)

CODE

SQL> grant connect,resource to krbdbuser;
SQL> grant create tablespace, drop tablespace to krbdbuser;
SQL> grant create table to krbdbuser;
SQL> grant create sequence to krbdbuser;
SQL> grant select_catalog_role to krbdbuser;
SQL> grant unlimited tablespace to krbdbuser;
SQL> grant select_catalog_role to krbdbuser;
SQL> grant alter system to krbdbuser;
SQL> grant sysoper to krbdbuser;
SQL> grant dba to krbdbuser;

Troubleshooting

Connecting via JDBC with Kerberos authentication from Continuous Compliance requires a Kerberos login, followed by JDBC connect. A failure stack with an error in the login function indicates a misconfiguration on either the engine or KDC – the engine has not attempted to communicate with the database at that point. Failure stacks are saved in the debugging log for masking.
Login exceptions that mention a checksum error mean either the password or key tab supplied does not match the expected password/key on the KDC for the principal you are trying to use. Server Setup verifies that your key tab works at configuration time, but it could stop working if the key for your principal is updated on the KDC.
Prior to Oracle 12, Oracle databases instances assume they can create/write a particular temporary file to store Kerberos credentials for the database. This means if you attempt to run multiple Kerberized instances of Oracle 11 on the same system or VM, and the databases run as different system users, the first Oracle instance that performs Kerberos authentication will create and own this file. Kerberos authentication will fail to function on all other instances.