Knowledge Base : Oracle Database 12c Kerberos Configuration

381 Juni 16, 2022

How to configure an Oracle Database 12.1 for Kerberos authentication

When configuring Kerberos in an 12c Oracle Database, there are several new aspects to consider. Oracle has completely rewritten the Kerberos stack in 12c, and there are some open bugs with this.

The following example walks to the steps necessary to access the database from Windows and Linux workstations with authentication via a Microsoft 2012 Server as an Active Directory (AD) backend.In this walkthrough, the domain name used is „tested.lcl“, and the Kerberos realm used is „TESTED.LCL“.

Active Directory Configuration

We have to create an SPN entry in Active Directory to reference the Oracle Database. This is created by adding a user in AD. The username is the database server.


Create a Service Key Table as Keytab-File and transfer the key tab file to the database server:

PS C:UsersAdministrator> ktpass.exe -princ oracle/[email protected] -mapuser ioaotow01 -crypto RC4-HMAC-NT -pass XXX -out c:ioaotow-hmac2.keytab -ptype KRB5_NT_PRINCIPAL
Targeting domain controller: test-dchh01.tested.lcl
Successfully mapped oracle/ioaotow01.tested.lcl to ioaotow01.
Password successfully set!
Key created.
Output keytab to c:ioaotow-hmac2.keytab:
Keytab version: 0x502 keysize 73 oracle/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 13 etype 0x17 (RC4-HMAC) keylength 16 (0xbd54ec4ab1feb299c0969b67f1d9deb8)

You cannot use -crypto=all in some cases. We needed to use RC4-HMAC. When debugging an „okinit: KDC has no support for encryption type“ error while trying to obtain a valid kerberos ticket for the database, Oracle Support suggested using RC4-HMAC.

The nature of the incompatibility between keytabs generated with „-crypto=all“ and AES-encrypted tickets and the database 12.1 is unclear at the moment. In this setup, a Windows PC connected to the AD domain controller uses Kerberos tickets with AES-256-CTS-HMAC-SHA1-96 crypto. RC4-HMAC-NT is deprecated for Windows Server 2012. We have also seen cases in which -crypto all succeeded. Maybe it happens when the AD falls back to DES instead of AES.

Check the SPN on the AD server:

C:Program FilesSupport Tools> setspn -L ioaotow01

To check and test the key tab file on the database server:

[oracle@ioaotow01 TESTDB-KERB5]$ oklist -k ioaotow01.keytab
Kerberos Utilities for Linux: Version 12.1.0.2.0 - Production on 13-JAN-2016 15:11:59
Copyright (c) 1996, 2014 Oracle.  All rights reserved.
Service Key Table: ioaotow01.keytab
Ver      Timestamp                    Principal
 4  01-Jan-1970 01:00:00  oracle/[email protected]

If the AD server is used as an DNS nameserver, we have to create a DNS entry for the database server.

You cannot use the database name as SPN. You have to use the database server name.

Database Configuration

The Kerberos topic has been moved inside Oracle documentation. While it was located in the Advanced Security Guide, it is now located in Database Security Guide.

In the first step, we have to check the Linux Kerberos configuration. If there is none, we need to provide a Kerberos configuration file for the Oracle database to use.

krc5.conf

dns_lookup_realm = false
[domain_realm]
.tested.lcl = TESTED.LCL
tested.lcl = TESTED.LCL

Next, we have to configure the SQL Net settings.

sqlnet.ora

  1. General Settings
    NAMES.DIRECTORY_PATH=(TNSNAMES, HOSTNAME)
    SQLNET.AUTHENTICATION_SERVICES= (BEQ,TCPS,KERBEROS5PRE,KERBEROS5)
  2. Kerberos Settings
    SQLNET.KERBEROS5_CONF=/etc/krb5.conf
    SQLNET.KERBEROS5_CONF_MIT=true
    SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=oracle
    SQLNET.KERBEROS5_KEYTAB=/oracle/product/12.1.0/dbhome_1/network/admin/ioaotow01.keytab
    SQLNET.KERBEROS5_CC_NAME=/oracle/diag/krb/cc/krb5cc_99

It is important to include Kerberos Pre-Authentication (KERBEROS5PRE) in the configuration for 12c.

Now we re-start the listener:

[oracle@ioaotow01 ~]$ lsnrctl start
LSNRCTL for Linux: Version 12.1.0.2.0 - Production on 13-JAN-2016 15:47:10
Copyright (c) 1991, 2014, Oracle.  All rights reserved.
Starting /oracle/product/12.1.0/dbhome_1/bin/tnslsnr: please wait...
TNSLSNR for Linux: Version 12.1.0.2.0 - Production
System parameter file is /oracle/product/12.1.0/dbhome_1/network/admin/listener.ora
Log messages written to /oracle/diag/tnslsnr/ioaotow01/listener/alert/log.xml
Trace information written to /oracle/diag/tnslsnr/ioaotow01/listener/trace/ora_65404_140061787710912.trc
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=ioaotow01)(PORT=1521)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=ioaotow01)(PORT=2484)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ioaotow01)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 12.1.0.2.0 - Production
Start Date                13-JAN-2016 15:47:10
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               support
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /oracle/product/12.1.0/dbhome_1/network/admin/listener.ora
Listener Log File         /oracle/diag/tnslsnr/ioaotow01/listener/alert/log.xml
Listener Trace File       /oracle/diag/tnslsnr/ioaotow01/listener/trace/ora_65404_140061787710912.trc
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=ioaotow01)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=ioaotow01)(PORT=2484)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
Services Summary...
Service "testdb.tested.lcl" has 1 instance(s).
  Instance "TESTDB", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully

Test of the Kerberos Login on DB server

Create a database user for testing

[oracle@ioaotow01 ~]$ sqlplus "/ AS SYSDBA"
SQL*Plus: Release 12.1.0.2.0 Production on Tue Jan 12 13:33:36 2016
Copyright (c) 1982, 2014, Oracle.  All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
SQL> create user "[email protected]" identified externally as '[email protected]';
SQL> grant connect,resource to "[email protected]";

Test the key tab file on DB server

[oracle@ioaotow01 admin]$ oklist -k ioaotow01.keytab
Kerberos Utilities for Linux: Version 12.1.0.2.0 - Production on 08-FEB-2016 16:23:32
Copyright (c) 1996, 2014 Oracle.  All rights reserved.
Service Key Table: ioaotow01.keytab
Ver      Timestamp                    Principal
13  01-Jan-1970 01:00:00  oracle/[email protected]

Test Kerberos login on DB server

[oracle@ioaotow01 ~]$ okinit user01
Kerberos Utilities for Linux: Version 12.1.0.2.0 - Production
Copyright (c) 1996, 2014 Oracle.  All rights reserved.
Password for [email protected]:


[oracle@ioaotow01 ~]$ oklist
Kerberos Utilities for Linux: Version 12.1.0.2.0 - Production on 08-FEB-2016 16:24:43
Copyright (c) 1996, 2014 Oracle.  All rights reserved.
Ticket cache: /oracle/diag/krb/cc/krb5cc_99
Default principal: [email protected]
Valid Starting           Expires            Principal
08-Feb-2016 14:11:20  08-Feb-2016 22:11:11  krbtgt/[email protected]
08-Feb-2016 14:11:33  08-Feb-2016 22:11:11  oracle/[email protected]
08-Feb-2016 14:16:40  08-Feb-2016 22:11:11  oracle/[email protected]
[oracle@ioaotow01 ~]$ sqlplus /@TESTDB
SQL*Plus: Release 12.1.0.2.0 Production on Mon Feb 8 16:24:51 2016
Copyright (c) 1982, 2014, Oracle.  All rights reserved.
Last Successful login time: Mon Feb 08 2016 14:17:35 +01:00
Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
SQL> show user; USER is "[email protected]

Client Configuration

The client is a Windows PC (Windows 7, SP1, 64bit, Oracle 12.1.0.2 Client) connected to the Active Directory domain.

Oracle Client configuration

sqlnet.ora

SQLNET.AUTHENTICATION_SERVICES= (BEQ,TCPS,KERBEROS5PRE,KERBEROS5)
SQLNET.KERBEROS5_CONF = C:Usersuser01Oraclekrb5.conf
SQLNET.KERBEROS5_CONF_MIT=TRUE
SQLNET.KERBEROS5_CC_NAME=OSMSFT://

Like with the database configuration, it is important to configure KERBEROS5PRE.

krb5.conf

[realms]
TESTED.LCL = {
 kdc = test-dchh01.tested.lcl
 kdc = test-dchh02.tested.lcl
 admin_server = test-dchh01.tested.lcl
 admin_server = test-dchh02.tested.lcl
}
[domain_realm]
.tested.lcl = TESTED.LCL
tested.lcl = TESTED.LCL

On a Windows workstation, it is not necessary to obtain a Kerberos ticket with „(o)kinit“, since we are in the AD servers domain and every Windows user automatically gets a Kerberos ticket from the AD server.

C:Usersuser01>klist
Aktuelle Anmelde-ID ist 0:0x28dc15
Zwischengespeicherte Tickets: (12)
#0>     Client: user01 @ TESTED.LCL
        Server: krbtgt/TESTED.LCL @ TESTED.LCL
        KerbTicket (Verschlüsselungstyp): AES-256-CTS-HMAC-SHA1-96
        Ticketkennzeichen 0x60810000 -> forwardable forwarded renewable name_canonicalize
        Startzeit: 2/9/2016 9:51:20 (lokal)
        Endzeit:   2/9/2016 19:28:51 (lokal)
        Erneuerungszeit: 2/12/2016 8:22:06 (lokal)
        Sitzungsschlüsseltyp: AES-256-CTS-HMAC-SHA1-96
#1>     Client: user01 @ TESTED.LCL
        Server: krbtgt/TESTED.LCL @ TESTED.LCL
        KerbTicket (Verschlüsselungstyp): AES-256-CTS-HMAC-SHA1-96
        Ticketkennzeichen 0x40c10000 -> forwardable renewable initial name_canonicalize
        Startzeit: 2/9/2016 9:28:51 (lokal)
        Endzeit:   2/9/2016 19:28:51 (lokal)
        Erneuerungszeit: 2/12/2016 8:22:06 (lokal)
        Sitzungsschlüsseltyp: AES-256-CTS-HMAC-SHA1-96
...

Test of login in SQLPlus

Caveats

We experienced difficulties when setting up the configuration initially.

ORA-12638 during database login

[oracle@ioaotow01 admin]$ sqlplus /@TESTDB
SQL*Plus: Release 12.1.0.2.0 Production on Wed Jan 13 15:56:45 2016
Copyright (c) 1982, 2014, Oracle.  All rights reserved.
ERROR:
ORA-12638: Credential retrieval failed

Debugging the ORA-12638 error

This means we did not get a valid Kerberos ticket from the AD server.

In the Active Directory server log file, it says:

A Kerberos authentication ticket (TGT) was requested. Account Information: Account Name: user01 Supplied Realm Name: TESTED.LCL User ID: TESTEDuser01 Service Information: Service Name: krbtgt Service ID: TESTEDkrbtgt Network Information: Client Address: ::ffff:10.115.150.11 Client Port: 42230 Additional Information: Ticket Options: 0x0 Result Code: 0x0 Ticket Encryption Type: 0x12 Pre-Authentication Type: 2 Certificate Information: Certificate Issuer Name: Certificate Serial Number: Certificate Thumbprint: Certificate information is only provided if a certificate was used for pre-authentication. Pre-authentication types, ticket options, encryption types and result codes are defined in RFC 4120.
Reading List:
  • Doc ID 1958479.1: „Bug 19931730, The keytab has/uses arcfour-hmac encryption which currently has an open 12c bug:19636771. The workaround for this is to use AES encryption in the keytab“
  • Doc ID 1611643.1: Bug 17497520 : KERBEROS CONNECTIONS USING A 12C CLIENT AND THE OKINIT REQUESTED TGT ARE FAILING
  • Doc ID 182979.1: Oracle is not able to parse the krb5.conf file due to the tabs between the assignment operator in the domain to realm mapping section.
  • Doc ID 185897.1: Kerberos Troubleshooting Guide
  • Master Note For Kerberos Authentication (Doc ID 1375853.1)
  • WNA- Kinit Fails with Exception: krb_error 6 Client Not Found in Kerberos Database (Doc ID 294890.1): „While creating the keytab file, SSO hostname value was given without specifying fully qualified domain“
  • How To Configure EUS Kerberos Authentication For Database Administrative Users (SYSDBA and SYSOPER) (Doc ID 2081984.1): „On a 12c database  sqlplus connection fails with ORA-1017 and this is caused by Bug 19307420 : KERBEROS AUTHENTICATED EUS USER FAILS WITH ORA-01017 FOR ADMINISTRATIVE LOGIN.“
  • Configuring ASO Kerberos Authentication with a Microsoft Windows 2008 R2 Active Directory KDC (Doc ID 1304004.1)
  • Microsoft Technet: Service Logons Fail Due to Incorrectly Set SPNs
  • Laurent Schneider: The long long route to Kerberos
  • Microsoft Technet: FIX: User accounts that use DES encryption for Kerberos authentication types cannot be authenticated in a Windows Server 2003 domain after a Windows Server 2008 R2 domain controller joins the domain
  • WNA- Kinit Fails with Exception: krb_error 6 Client Not Found in Kerberos Database (Doc ID 294890.1)
  • Case Study: Configuring the Kerberos Adapter in a Windows Environment (Kevin Reardon, Consulting Technical Advisor)
Setup debugging (sqlnet.ora):
trace_level_server = 32
trace_file_server = svr_trc
trace_directory_client = $ORACLE_HOME/network/trace
TRACE_LEVEL_CLIENT=SUPPORT
TRACE_FILENO_CLIENT=6
TRACE_FILELEN_CLIENT=51200
TRACE_UNIQUE_CLIENT=ON
TRACE_TIMESTAMP_CLIENT=ON
TRACE_DIRECTORY_CLIENT=/home/oracle/client_trace
LOG_DIRECTORY_CLIENT=/home/oracle/client_trace
DIAG_ADR_ENABLED=OFF
TRACE_DIRECTORY_OKINIT = /oracle/diag/krb/cc
TRACE_FILE_OKINIT = okinit
TRACE_LEVEL_OKINIT = SUPPORT

At this point, we set up a network trace of the traffic between the database server and the AD server. It showed some interesting packets:

ErrorCode: KDC_ERR_S_PRINCIPAL_UNKNOWN (7) KerberosV5    KerberosV5:TGS Request Realm: TESTED.LCL Sname: oracle/ioaotow01     {UDP:59, IPv4:20}

SetSPN Output on keyfile creation was:

C:UsersAdministratorDocuments>setspn -L ioaotow01 Registered ServicePrincipalNames for CN=ioaotow01,OU=AO,OU=IT-Department,DC=tested,DC=lcl: oracle/ioaotow01.tested.lcl

Countermeasures

  • Switch off Kerberos Pre Authentication
  • Generate new keyfile with crypto AES-Only
  • Use fully qualified domain names (FQDN) as host names.

Error „KDC has no support for encryption type“ during okinit

[oracle@ioaotow01 ~]$ okinit -k -t /tmp/ioaotow01-np-all.2..keytab oracle/[email protected]
Kerberos Utilities for Linux: Version 12.1.0.2.0 - Production on 29-JAN-2016 09:00:12
Copyright (c) 1996, 2014 Oracle.  All rights reserved.
okinit: KDC has no support for encryption type

Debugging „KDC has no support for encryption type“

Test with new key tab from previous step:

[oracle@ioaotow01 ~]$ oklist -k /tmp/ioaotow01-np-all.2..keytab
Kerberos Utilities for Linux: Version 12.1.0.2.0 - Production on 29-JAN-2016 08:59:54
Copyright (c) 1996, 2014 Oracle.  All rights reserved.
Service Key Table: /tmp/ioaotow01-np-all.2..keytab
Ver      Timestamp                    Principal
10  01-Jan-1970 01:00:00  oracle/[email protected]
10  01-Jan-1970 01:00:00  oracle/[email protected]
10  01-Jan-1970 01:00:00  oracle/[email protected]
10  01-Jan-1970 01:00:00  oracle/[email protected]
10  01-Jan-1970 01:00:00  oracle/[email protected]

…same result.

Contacting Oracle support led to some clarification:

  • There are several open bugs with 12c and Kerberos
  • With some AD configurations, it is necessary to use RC4-HMAC as Kerberos crypto setting. With others, crypto-all works.
  • Only the keytab which was created last works. After creating a new keytab on AD server, all old versions of key tab files for this user SPN become invalid. So you cannot test with several versions of keytab files.

We added the kerberos5pre adapter in sqlnet.oraas the workaround for bug 19636771.

Thereafter, sqlplus connections failed with ORA-12631 and in the tracefile we could see there is mismatch between kvno of the keytab on AD and on the database server:

[08-FEB-2016 09:24:44:943] nauk5y2_kt_get_entry: Searching for keytype=23 ,kvno=10;Current keytype=1,kvno=9
[08-FEB-2016 09:24:44:943] nauk5fq_free_principal: entry
[08-FEB-2016 09:24:44:943] nauk5fq_free_principal: exit
[08-FEB-2016 09:24:44:943] nauk5y2_kt_get_entry: Searching for keytype=23 ,kvno=10;Current keytype=3,kvno=9
[08-FEB-2016 09:24:44:943] nauk5fq_free_principal: entry [08-FEB-2016 09:24:44:943] nauk5fq_free_principal: exit
[08-FEB-2016 09:24:44:943] nauk5y2_kt_get_entry: Searching for keytype=23 ,kvno=10;Current keytype=23,kvno=9
[08-FEB-2016 09:24:44:944] nauk5fq_free_principal: entry [08-FEB-2016 09:24:44:944] nauk5fq_free_principal: exit
[08-FEB-2016 09:24:44:944] nauk5y2_kt_get_entry: Searching for keytype=23 ,kvno=10;Current keytype=18,kvno=9
[08-FEB-2016 09:24:44:944] nauk5fq_free_principal: entry [08-FEB-2016 09:24:44:944] nauk5fq_free_principal: exit
[08-FEB-2016 09:24:44:944] nauk5y2_kt_get_entry: Searching for keytype=23 ,kvno=10;Current keytype=17,

KVO means key version number, everytime the keytab is generated or the password of database principal account is changed in AD kvno is incremented.
Currently on AD this kvno is 10 but the keytab on db has the kvno 9 which means the keytab has been regenerated and not copied on the db or the password has been changed.

Countermeasures

  • Create new Keytab with -crypto RC4-HMAC-NT, using FQDN database server hostname
  • Enable Kerberos Preauthentication: SQLNET.AUTHENTICATION_SERVICES= (BEQ,TCPS,KERBEROS5PRE,KERBEROS5)

Error „WARNING: pType and account type do not match. This might cause problems“ when creating key tab

This occurs if „-ptype KRB5_NT_PRINCIPAL“ is missing in the ktpass-command issued for keytab creation.