Background

Oracle has supported authenticating internal users against Active Directory for several years now, but it does require a fundamental comprehension of Kerberos in order to configure it properly. Of course, this is much easier to accomplish on Windows than Unix and Linux, but luckily, we have the Centrify DirectControl agent to extend the Kerberos environment and help us achieve secure, Active Directory-based authentication without remembering passwords.

Requirements

• Oracle 11g Database software installed and functioning properly on a Centrify-supported Linux server
• The Oracle 11g Database must support Kerberos authentication. In order to obtain support for Kerberos with your Oracle 11g DB software, you will need to deploy the Enterprise Edition (EE). With Oracle 12c, Kerberos is supported out of the box with Standard Edition 1 (SE1).
• Centrify-supported Linux server with the DirectControl agent installed and joined to an Active Directory domain
• Valid Zone user that can authenticate to the Linux server with Active Directory credentials
• Root & oracle account access to the Linux DB server and domain admin privileges to the Active Directory domain
• Oracle 11g client software installed on a separate Linux server for remote client sqlplus connections (optional); if using a remote Linux client server, make sure it is also joined to the AD domain, via the DirectControl agent
• Oracle 11g client software installed on a separate Windows server for remote client sqlplus connections (optional)

Step 1 - Verify Environment Readiness

• Execute 'adinfo' to verify that the server is connected to your AD domain:

[dwirth@newcentos /]$ adinfo
Local host name:   newcentos
Joined to domain:  centrify.vms
Joined as:         newcentos.centrify.vms
Pre-win2K name:    newcentos
Current DC:        dc.centrify.vms
Preferred site:    Demo-Network
Zone:              centrify.vms/centrifyse/Zones/Global
Last password set: 2016-11-26 15:33:21 CST
CentrifyDC mode:   connected
Licensed Features: Enabled

• As the oracle user account, execute 'tnsping' to verify that clients can connect to the Oracle instance, and then verify that standard username/password authentication works for an internal user, via sqlplus connection:

[oracle@newcentos ~]$ tnsping dev

TNS Ping Utility for Linux: Version 11.2.0.1.0 - Production on 26-NOV-2016 15:55:49
Copyright (c) 1997, 2009, Oracle.  All rights reserved.
Used parameter files:
/u01/app/oracle/product/11.2.0/dbhome_1/network/admin/sqlnet.ora

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = newcentos.centrify.vms)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = DEV.CENTRIFY.VMS)))
OK (10 msec)
[oracle@newcentos ~]$ sqlplus "sys as sysdba"

SQL*Plus: Release 11.2.0.1.0 Production on Sat Nov 26 15:56:01 2016
Copyright (c) 1982, 2009, Oracle.  All rights reserved.
Enter password: 

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options
SQL> exit

• As the oracle user account, execute ‘adapters’ to verify that Kerberos is a supported authentication mechanism:

NOTE - A good initial Kerberos test is to have a user attempt an SSH connection from a Windows domain computer to the Linux DB server; if possible, use the Centrify kerberized PuTTY client as it already has Kerberos support compiled.

Step 2 - Configure the Environment Variables & Authentication Type

NOTE - The environment variables marked in RED are specific for this article, so update them according to your own environment.

• As the root user account, append the following Oracle environment variables to /etc/profile:

[root@newcentos ~]# tail -6 /etc/profile
# These are global Oracle environment variables
ORACLE_OWNER=oracle
ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1
ORACLE_SID=dev
PATH=$PATH:$ORACLE_HOME/bin
export ORACLE_OWNER ORACLE_HOME ORACLE_SID PATH

• Configure the Oracle initialization parameter; this overrides the default 30-character limit for Kerberos user names:

$ su - oracle
Password: 
[oracle@newcentos ~]$ sqlplus "sys as sysdba"
Enter password: 
Connected to:
SQL> show parameter os_authent_prefix;
NAME     TYPE VALUE
------------------------------------ ----------- ------------------------------
os_authent_prefix     string
NOTE - The VALUE column should be a null string; if it’s not, proceed below.

SQL> alter system set os_authent_prefix = '' scope=spfile;
System altered.
NOTE - There are two single-quote marks after the "=" sign above.
SQL> shutdown immediate;
SQL> startup;
SQL> exit

• As the root user account, perform the following Kerberos-related updates:

        1) Stop the DirectControl agent:

             # adclient -x

        2) Update the following policy in /etc/centrifydc/centrifydc.conf:

             adclient.krb5.keytab.entries: 1

        3) Verify that /etc/krb5.conf (/etc/krb5/krb5.conf on Solaris) has the following encryption parameters:

             [libdefaults]
             default_tgs_enctypes = aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
             default_tkt_enctypes = aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
             permitted_enctypes = aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
             dns_lookup_realm = true
             dns_lookup_kdc = true
             passwd_check_s_address = false
             ccache_type = 3

        4) Restart the DirectControl agent:

             # adclient -F

• Update $ORACLE_HOME/network/admin/sqlnet.ora with the following parameters:

SQLNET.KERBEROS5_KEYTAB = /u01/app/oracle/product/11.2.0/dbhome_1/ORACLE.keytab
SQLNET.AUTHENTICATION_SERVICES= (BEQ, KERBEROS5, ALL)
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT, LDAP)
SQLNET.KERBEROS5_CONF = /etc/krb5.conf
SQLNET.KERBEROS5_CONF_MIT = TRUE
NAMES.DEFAULT_DOMAIN = CENTRIFY.VMS   # The name of your domain, in CAPS
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE = ORACLE   # The Oracle SPN from the keytab command in the next section
ADR_BASE = /u01/app/oracle

NOTE - For Oracle 12c instances, the SQLNET.AUTHENTICATION_SERVICES entry should be set to (BEQ, KERBEROS5PRE, KERBEROS5, ALL).

Step 3 - Create the Service Account, Keytab, and Associated Service Principals

• Execute the following command as the root user account:

# adkeytab -n -U ORACLE/@ -c "" \
  -K $ORACLE_HOME/ORACLE.keytab -V -d  -u  \
  -P ORACLE/{hostname} -P ORACLE/@ 

      OPTIONS:

      -n --new                         create a new service account in AD

      -U --upn                         sets the UPN for the service account in AD

      -c --container              container definition for the service account (DN format)

      -K --keytab                   location and name of the keytab file

      -V --verbose                 displays detailed information

      -d --domain name     specifies the domain where the service principal is to be added

      -P --principal                specifies additional service principals

      -u              specifies the privileged account to perform the AD operation

NOTE - Make sure that DOMAIN_NAME is capitalized like the example above shows. This is actually the Kerberos Realm name and is almost always capitalized in the principal string.

NOTE - Make changes to the command options based on your local environment. Once you have generated the keytab file, it must not be moved; otherwise the DirectControl agent won’t be able to renew the keytab.

• Use the following syntax as an example:

# adkeytab -n -U ORACLE/newcentos.centrify.vms@CENTRIFY.VMS \
  -c "OU=ServiceAccounts,OU=centrifyse,DC=centrify,DC=vms" \
  -K $ORACLE_HOME/ORACLE.keytab -V -d centrify.vms -u dwirth -P ORACLE/newcentos \
  -P ORACLE/newcentos.centrify.vms@CENTRIFY.VMS ORACLE-newcentos

• Update the ownership of the keytab to oracle:oinstall (use the primary group of the oracle account, if different from oinstall).
• Update the permissions of the new keytab to 400.
• If you make a mistake and need to start over, execute the following command (as root) to remove everything:
  # adkeytab -D -K ./ORACLE.keytab -u priv_AD_user> service_account>

Step 4 - Create Internal Database Account(s)

• User accounts must also be defined in the local Oracle Database for Kerberos SSO to work.
• Login as the oracle user, connect to Oracle Database as sysdba, and create an AD user with the appropriate rights:

[dwirth@newcentos /]$ su - oracle
Password: 
[oracle@newcentos ~]$ sqlplus "sys as sysdba"

SQL*Plus: Release 11.2.0.1.0 Production on Sat Nov 26 18:45:53 2016
Copyright (c) 1982, 2009, Oracle.  All rights reserved.
Enter password: 
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options

SQL> create user "TESTUSER@CENTRIFY.VMS" identified externally;
User created.

SQL> grant connect, resource to "TESTUSER@CENTRIFY.VMS";
Grant succeeded.

SQL> select username from dba_users where username like 'TESTUSER%';
USERNAME
------------------------------
TESTUSER@CENTRIFY.VMS

SQL> exit

NOTE - There are several ways to create users in the Oracle Database, and the format used will determine if the USER is capitalized in the syntax; with the format of the above example, ensure that the USER@DOMAIN is capitalized.

NOTE - If the user already has a non-Kerberos-enabled account in the Database, then a new account will need to be created (in UPPER-CASE) for the AD user.

Step 5 - Test the Kerberos Authentication

• Once authenticated to the Linux computer as a non-privileged user, verify the Kerberos TGT:

[dwirth@newcentos /]$ /usr/share/centrifydc/kerberos/bin/klist
Ticket cache: FILE:/tmp/krb5cc_1040188499
Default principal: dwirth@CENTRIFY.VMS

Valid starting     Expires            Service principal
11/26/16 18:24:06  11/27/16 04:24:08  krbtgt/CENTRIFY.VMS@CENTRIFY.VMS
renew until 11/27/16 18:24:06
[dwirth@newcentos /]$ 

• If the user account doesn’t have a Kerberos TGT, or it has expired, generate a new one:

[dwirth@newcentos /]$ /usr/share/centrifydc/kerberos/bin/klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1040188499)

[dwirth@newcentos /]$ /usr/share/centrifydc/kerberos/bin/kinit
Password for dwirth@CENTRIFY.VMS: 

[dwirth@newcentos /]$ /usr/share/centrifydc/kerberos/bin/klist
Ticket cache: FILE:/tmp/krb5cc_1040188499
Default principal: dwirth@CENTRIFY.VMS

Valid starting     Expires            Service principal
11/26/16 18:26:29  11/27/16 04:26:31  krbtgt/CENTRIFY.VMS@CENTRIFY.VMS
renew until 11/27/16 18:26:29
[dwirth@newcentos /]$ 

NOTE - If kinit fails, try specifying the user account name (in upper-case) with the kinit command.

• Now, you can test the Kerberos service ticket retrieval:

[dwirth@newcentos /]$ sqlplus /@dev

SQL*Plus: Release 11.2.0.1.0 Production on Sat Nov 26 18:29:21 2016
Copyright (c) 1982, 2009, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options

SQL> 

NOTE - If the connection is successful, you will access the SQL prompt without entering a password.

NOTE - Due to the Authentication sequence that you specified in sqlnet.ora, any accounts (e.g. oracle) that don't exist in AD will continue to authenticate with username/password.

• To confirm the service ticket, re-enter “klist”, and you should now see the ORACLE service ticket:

[dwirth@newcentos /]$ /usr/share/centrifydc/kerberos/bin/klist
Ticket cache: FILE:/tmp/krb5cc_1040188499
Default principal: dwirth@CENTRIFY.VMS

Valid starting     Expires            Service principal
11/26/16 18:26:29  11/27/16 04:26:31  krbtgt/CENTRIFY.VMS@CENTRIFY.VMS
renew until 11/27/16 18:26:29
11/26/16 18:29:21  11/27/16 04:26:31  ORACLE/newcentos@CENTRIFY.VMS
renew until 11/27/16 18:26:29
[dwirth@newcentos /]$ 

Summary

Note that this article provides a simple example for authenticating AD users to Oracle, via Kerberos, in a single Forest/Domain (with 1 KDC). Centrify DirectControl also works seemlessly in more complex Kerberos environments; therefore, the same example in this article should apply.

Verify:

• That the Oracle Database supports Kerberos authentication
• That the Linux DB Server (and any remote clients) are connected to your AD domain, via Centrify DirectControl
• That Kerberos service tickets are being issued for other principals (HOST)
• That you have the proper entries in /etc/krb5.conf and $ORACLE_HOME/network/admin/sqlnet.ora
• That your adkeytab syntax is correct and the resultant keytab file has the proper ownership and permissions
• That your AD users have been added internally to the Oracle DB with the appropriate rights