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.
- 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 18.104.22.168.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 22.214.171.124.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 126.96.36.199.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;
- 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:
3) Verify that /etc/krb5.conf (/etc/krb5/krb5.conf on Solaris) has the following encryption parameters:
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/<hostname_fqdn>@<DOMAIN_NAME> -c "<Service Account_OU>" \ -K $ORACLE_HOME/ORACLE.keytab -V -d <domain_name> -u <priv_AD_user> \
-P ORACLE/<hostname> -P ORACLE/<hostname_fqdn>@<DOMAIN_NAME> <service_account>
-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 <priv_user> 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 188.8.131.52.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 184.108.40.206.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 220.127.116.11.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 18.104.22.168.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 /]$
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.
- 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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.