AWS Database Blog

Enable Kerberos authentication with Amazon RDS Custom for Oracle – Part 1

Amazon Relational Database Service (Amazon RDS) Custom for Oracle allows you the flexibility to configure the database authentication method that can help you meet your security needs.

A common and traditional method is to use database authentication via user names and passwords, but this method requires more effort from both administrators and users to manage, with the added overhead for security officers to audit and govern.

In this post, we show you how to enable Kerberos authentication with RDS Custom for Oracle, and in future posts we will walk through other authentication methods.

Kerberos is a network authentication protocol that allows resources to verify the identity of one another over an untrusted network. Kerberos provides the option for Oracle databases to integrate with a central authentication service such as Microsoft Active Directory (AD), which has Kerberos built in. Oracle databases work with MIT Kerberos (Kerberos V5), and work with compatible Kerberos 5 key distribution center (KDC) servers.

Similar to the rest of the Amazon Relational Database Service (Amazon RDS) family, like Amazon RDS for PostgreSQL, Amazon RDS for Oracle, Amazon RDS for SQL Server, and Amazon Aurora PostgreSQL-Compatible Edition, you can enable external authentication using Kerberos on RDS Custom for Oracle.

Solution overview

With RDS Custom for Oracle, when users authenticate to the Oracle instance, the authentication request could be forwarded to an AWS Managed Microsoft AD directory or a customer-managed Microsoft AD. Centralizing the storage and management credentials of multiple databases can save time and effort and improve your organization’s overall security profile.

The Kerberos authentication workflow is illustrated by the following steps and diagram:

  1. The user initiates the authentication process by sending an authentication ticket to the Microsoft AD key distribution center (KDC) via an OS logon process (if Linux/Windows client is joined to domain) or through the okinit command.
  2. Microsoft AD responds via a Ticket-Granting Ticket (TGT) to the user after a successful authentication.
  3. The user sends the request to Microsoft AD to request access to the Oracle database service running on Amazon RDS Custom for Oracle instance.
  4. The Microsoft AD KDC responds with a service ticket for the Oracle database service.
  5. The user sends the service ticket to Oracle database service for authentication.
  6. The Oracle database service verifies the service ticket with the KDC.
  7. The Oracle database service grants the user access through an Oracle client.

Kerberos authentication workflow

In this post, we demonstrate how to enable Kerberos to externally authenticate your users via a Linux and Windows client, through AWS Managed Microsoft AD. This includes the following high-level steps:

  1. Configure AWS Managed Microsoft AD as a KDC.
  2. Configure Kerberos on the RDS Custom for Oracle database server.
  3. Configure the Oracle client on Linux OS.
  4. Configure the Oracle client on a Windows 2019 server.

Prerequisites

Before starting, it’s assumed that you have deployed an RDS Custom for Oracle 19c database instance and you have access to the Linux OS through SSH or AWS System Manager. For instructions, refer to Creating and connecting to a DB instance for Amazon RDS Custom for Oracle.

Note down the following information from your RDS Custom for Oracle instance to use in subsequent sections:

  • DB identifier – orcl
  • Endpoint – orcl.abcdefghijk.ap-southeast-1.rds.amazonaws.com
  • Port – 1521
  • Hostname – ip-10-1-4-113 (output of command hostname)
  • Domain – '' (output of command domainname)
  • Fully Qualified Domain Name (FQDN) – ip-10-1-4-113 (concatenation based on previous hostname and domain values)

Configure AWS Managed Microsoft AD as a KDC

In this post, we use the AWS Directory Service for Microsoft Active Directory as the Kerberos KDC. AWS Managed Microsoft AD enables your directory-aware workloads and AWS resources to use managed Active Directory (AD) in AWS. When you create an AWS Managed Microsoft AD directory, AWS Directory Service creates two domain controllers in different subnets within a VPC. This redundancy increases fault tolerance to your directory services in the event of failures.

You could use similar steps to integrate a self-managed AD with RDS Custom for Oracle, with the onus on the user to verify that the AD stack is configured to meet their businesses availability needs.

Create an AWS Managed Microsoft AD directory

To create your AWS Managed Microsoft AD directory, complete the following steps:

  1. On the AWS Directory Service console, in the navigation pane, choose Directories.
  2. Choose Set up Directory.
  3. Choose AWS Managed Microsoft AD, then choose Next.
  4. Choose either Standard Edition or Enterprise Edition, based on your business requirements.
  5. For Directory DNS name, enter the fully-qualified name for the directory, such as corp.example.com.
  6. For Directory NetBIOS name, enter the short name for the directory, such as CORP.
  7. For Directory description, enter an optional description for the directory.
  8. For Admin password, enter the password for the default administrative user named Admin.
  9. Choose Next.
  10. For VPC, choose the VPC that contains your RDS Custom for Oracle instances.
  11. For Subnets, choose two subnets for your directory servers (they must be in different Availability Zones).
  12. Choose Next.
  13. Review the directory information and make any necessary changes, then choose Create directory.

It may take several minutes for the directory to be created. When it has been successfully created, the Status value changes to Active.

  1. Note down the DNS address for the newly created AWS Managed Microsoft AD.
    Networking details in AWS Managed Microsoft AD
  2. Configure the security group inbound rules to allow the Oracle database server and clients to communicate with AWS Managed Microsoft AD.

Create a database service account and keytab file

The database service account is a regular Active Directory user account, which is used by the Oracle database to communicate with the KDC during Kerberos authentication. Because it’s only used by the Oracle database service, typically it’s configured with the account option Password never expires, although it’s not a requirement for Kerberos authentication.

When creating a user in AWS Managed Microsoft AD, we recommend following the naming convention db+<hostname> as the service account name, so that each service account maps to one RDS Custom for Oracle instance. See the following steps:

  1. Create a user in corp.example.com/CORP/Users.
  2. For Full name, enter db-ip-10-1-4-1113.
  3. For User logon name, enter db-ip-10-1-4-113@corp.example.com.
  4. For User logon name (pre-Windows 2000), enter CORP\db-ip-10-1-4-113.
  5. Choose Next.
  6. For Password, enter a complex password meeting your password policy.
  7. For Account options, select Password never expires.
  8. Choose Next.

Specify user details to create user in AWS Managed Microsoft AD Specify user password to create user in AWS Managed Microsoft AD

  1. Generate the keytab file for the service account.

You can use the ktpass command to configure the service principal name for the RDS Custom for Oracle instance in AD, and generate a keytab file that contains the shared secret key of the service. See the following code:

C:\Users\admin\Downloads>ktpass.exe -princ oracle/ip-10-1-4-113@CORP.EXAMPLE.COM -mapuser db-ip-10-1-4-113@CORP.EXAMPLE.COM  -crypto all -pass * -ptype KRB5_NT_PRINCIPAL -out ip-10-1-4-113.keytab
Targeting domain controller: WIN-3HFREJQV929.corp.example.com
Using legacy password setting method
Successfully mapped oracle/ip-10-1-4-113 to db-ip-10-1-4-113.
Type the password for oracle/ip-10-1-4-113:
Type the password again to confirm:
Key created.
Key created.
Key created.
Key created.
Key created.
Output keytab to ip-10-1-4-113.keytab:
Keytab version: 0x502
keysize 64 oracle/ip-10-1-4-113@CORP.EXAMPLE.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x1 (DES-CBC-CRC) keylength 8 (0x863b513745752aad)
keysize 64 oracle/ip-10-1-4-113@CORP.EXAMPLE.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x3 (DES-CBC-MD5) keylength 8 (0x863b513745752aad)
keysize 72 oracle/ip-10-1-4-113@CORP.EXAMPLE.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x17 (RC4-HMAC) keylength 16 (0xe4a22d8e7bbec871b341c88c2e94cba2)
keysize 88 oracle/ip-10-1-4-113@CORP.EXAMPLE.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x12 (AES256-SHA1) keylength 32 (0x272c53b381a9e872cce0d72b7286cd68545ee3e638d07b23b47eebc6e71bebb1)
keysize 72 oracle/ip-10-1-4-113@CORP.EXAMPLE.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x11 (AES128-SHA1) keylength 16 (0xc2e63904cc8fbc9b7b83a96b668b382b)

The code uses the following parameters:

  • -princ – The principal name is the format of "oracle/" + "<FQDN>" + "@CORP.EXAMPLE.COM". It’s case-sensitive.
  • -mapuser – The service account created in previous section.
  • -pass * – Promotes for the service account password.
  • -out – Specifies the name of the Kerberos version 5 keytab file to generate.

The ktpass command generates a keytab file with the name of your host suffixed with the extension keytab (for example, ip-10-1-4-113.keytab) in the current directory. You can upload this file to the RDS Custom for Oracle database server in subsequent steps.

Create a demo user for Kerberos authentication

Next, you will create a demo user in AWS Managed Microsoft AD, which we use to log in to the database through Kerberos authentication.

  1. Create a user in corp.example.com/CORP/Users.
  2. For Full name, enter krbuser.
  3. For User logon name, enter krbuser@corp.example.com.
  4. For User logon name (pre-Windows 2000), enter CORP\krbuser.
  5. For Password, enter a complex password meeting your password policy.

Configure an RDS Custom for Oracle database server

To enable Kerberos authentication, you will first need to configure the database server to resolve the DNS lookup requests with the DNS servers, followed by installing the Kerberos client, and lastly configuring the database, as documented in the following steps.

Configure default DNS servers

By default, RDS Custom for Oracle uses the default DNS server in the VPC. To allow DNS lookup to obtain the realm for the KDC and map realms to KDC hosts, you can change the default DNS servers with the following steps. If your Linux host running RDS Custom for Oracle has already joined the domain corp.example.com, you can skip these steps.

  1. Edit the file /etc/resolv.conf by replacing entries search and nameserver with DNS records obtained from the previous step: 
    search ap-southeast-1.compute.internal corp.example.com
nameserver 10.1.4.88
nameserver 10.1.5.76
  2. Edit the file /etc/dhcp/dhclient.conf to ensure DNS changes are persisted after reboot: 
    timeout 300;
supersede domain-search "ap-southeast-1.compute.internal", "corp.example.com";
supersede domain-name-servers 10.1.4.88,10.1.5.76;
  3. Verify connectivity. If your DNS servers are configured correctly, the ping command resolves the hostname to an IP address and runs successfully. 
    [ec2-user@ip-10-1-4-113 ~]$ ping corp.example.com
PING corp.example.com (10.1.4.88) 56(84) bytes of data.
64 bytes from corp.example.com (10.1.4.88): icmp_seq=1 ttl=128 time=0.243 ms
64 bytes from corp.example.com (10.1.4.88): icmp_seq=2 ttl=128 time=0.291 ms
64 bytes from corp.example.com (10.1.4.88): icmp_seq=3 ttl=128 time=0.290 ms

Install Kerberos client packages

Install the packages with the following code:

sudo yum install -y krb5-workstation krb5-libs

Configure Kerberos for the Oracle database server

To configure Kerberos, complete the following steps:

  1. Switch to the OS user (rdsdb) running the Oracle database instance: 
    [ec2-user@ip-10-1-4-113 ~]$ sudo su - rdsdb 

-bash-4.2$ id -a rdsdb 
uid=61001(rdsdb) gid=1000(rdsdb) groups=1000(rdsdb),61001(database)
  2. Create directories for Kerberos configuration and log files on the mount point /rdsdbdata: 
    -bash-4.2$ mkdir /rdsdbdata/config/security/
-bash-4.2$ mkdir /rdsdbdata/log/security/

    Files in these directories are persisted and not impacted by RDS Custom for Oracle database version upgrades.

  3. Copy the keytab file generated from the previous steps into the database server and store it as /rdsdbdata/config/security/db-ip-10-1-4-113.keytab.
  4. Verify that the keytab file contains valid service principals using the oklist command: 
    -bash-4.2$ oklist -k -t  /rdsdbdata/config/security/ip-10-1-4-113.keytab -old

Kerberos Utilities for Linux: Version 19.0.0.0.0 - Production on 24-JUN-2022 09:06:30

Copyright (c) 1996, 2019 Oracle.  All rights reserved.

Service Key Table: /rdsdbdata/config/security/ip-10-1-4-113.keytab

Ver      Timestamp                    Principal
3  01-Jan-1970 00:00:00  oracle/ip-10-1-4-113@CORP.EXAMPLE.COM
3  01-Jan-1970 00:00:00  oracle/ip-10-1-4-113@CORP.EXAMPLE.COM
3  01-Jan-1970 00:00:00  oracle/ip-10-1-4-113@CORP.EXAMPLE.COM
3  01-Jan-1970 00:00:00  oracle/ip-10-1-4-113@CORP.EXAMPLE.COM
3  01-Jan-1970 00:00:00  oracle/ip-10-1-4-113@CORP.EXAMPLE.COM
  5. Create the Kerberos configuration file (/rdsdbdata/config/security/krb5.conf) containing the Kerberos realms and domains for your user and service accounts. Refer to Kerberos documentation krb5.conf for a detailed explanation. 
    [logging]
default = FILE:/rdsdbdata/log/security/krb5libs.log

[libdefaults]
default_realm = CORP.EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
allow_weak_crypto = true
default_ccache_name = /tmp/krb5cc_%{uid}

[realms]
CORP.EXAMPLE.COM = {
kdc = corp.example.com
admin_server = corp.example.com
}

[domain_realm]
.corp.example.com = CORP.EXAMPLE.COM
corp.example.com = CORP.EXAMPLE.COM
.CORP.EXAMPLE.COM = CORP.EXAMPLE.COM
CORP.EXAMPLE.COM = CORP.EXAMPLE.COM
  6. Add the following parameters to sqlnet.ora (/rdsdbbin/oracle/network/admin/sqlnet.ora): 
    SQLNET.KERBEROS5_CONF=/rdsdbdata/config/security/krb5.conf
SQLNET.KERBEROS5_KEYTAB=/rdsdbdata/config/security/ip-10-1-4-113.keytab
SQLNET.KERBEROS5_CONF_MIT=TRUE
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=oracle
SQLNET.AUTHENTICATION_SERVICES=(BEQ,KERBEROS5)
SQLNET.FALLBACK_AUTHENTICATION=TRUE

Configure Oracle initialization parameters

Changing the parameter os_authent_prefix requires restarting the database to take effect. Follow the steps in Pausing and resuming RDS Custom automation to pause the automation before database shutdown in step 3, and resume the automation once database startup.

  1. Log in to the database as SYSDBA or another privileged user with the required permissions: 
    -bash-4.2$ sqlplus / as sysdba
  2. Change parameter os_authent_prefix: 
    SQL> alter system set os_authent_prefix='' scope=spfile;
  3. Restart the database to take effect: 
    SQL> shutdown immediate
SQL> startup

Create an external authenticated Oracle user

Create a database user that maps to your demo user previously created in Active Directory:

SQL> CREATE USER krbuser IDENTIFIED EXTERNALLY AS 'krbuser@CORP.EXAMPLE.COM';
SQL> GRANT CREATE SESSION TO krbuser;

Configure the Oracle client on Linux OS

In this section, we assume you have an Oracle 19c client installed on a Linux OS host that’s ready for Kerberos integration. Refer to Database Client Installation Guide for Linux for detailed installation steps.

The Oracle client has the following configuration:

  • Linux OS – Amazon Linux 2
  • Hostname – ip-10-1-4-29.ap-southeast-1.compute.internal
  • Oracle Base – /u01/app/oracle
  • Oracle Home – /u01/client
  • Oracle Version – 19.13

Although this post is based on Amazon Linux 2, the same steps apply for RHEL7 clients as well.

Configure default DNS servers

By default, an Amazon Elastic Compute Cloud (Amazon EC2) instance running your Oracle Client uses the default DNS server in the VPC. To allow DNS lookups to obtain the realm for the KDC to map realms to the KDC hosts, you can change the default DNS servers with the following steps. If your Linux host running the Oracle client has already joined the domain corp.example.com, you can skip these steps.

  1. Edit the file /etc/resolv.conf, and replace the entries for search and nameserver with the DNS records obtained from the previous step: 
    search ap-southeast-1.compute.internal corp.example.com
nameserver 10.1.4.88
nameserver 10.1.5.76
  2. Edit the file /etc/dhcp/dhclient.conf to verify that the DNS change remains after reboot. 
    supersede domain-search "ap-southeast-1.compute.internal", "corp.example.com";
supersede domain-name-servers 10.1.4.88,10.1.5.76;
timeout 300;
  3. Verify connectivity. If your DNS server is configured properly, the ping command resolves the hostname to an IP address and runs successfully: 
    [ec2-user@ip-10-1-4-29 ~]$ ping corp.example.com
PING corp.example.com (10.1.4.88) 56(84) bytes of data.
64 bytes from corp.example.com (10.1.4.88): icmp_seq=1 ttl=128 time=0.403 ms
64 bytes from corp.example.com (10.1.4.88): icmp_seq=2 ttl=128 time=0.501 ms
64 bytes from corp.example.com (10.1.4.88): icmp_seq=3 ttl=128 time=0.513 ms

Install Kerberos client packages

Install the packages with the following code:

sudo yum install -y krb5-workstation krb5-libs

Configure Kerberos for the Linux Oracle database client

To configure Kerberos, complete the following steps:

  1. Connect to the Linux client using the Oracle client software owner (oracle). You can verify your Oracle client software owner using the ls command: 
    [oracle@ip-10-1-4-29 ~]$ ls -ld $ORACLE_HOME
drwxr-xr-x 59 oracle oinstall 4096 Jun 24 11:53 /u01/client
  2. Modify the Kerberos configuration file (/etc/krb5.conf) containing Kerberos realms and domains for your user and service accounts. Refer to Kerberos documentation krb5.conf for a detailed explanation. 
    # Configuration snippets may be placed in this directory as well
includedir /etc/krb5.conf.d/

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
dns_lookup_realm = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
pkinit_anchors = /etc/pki/tls/certs/ca-bundle.crt
default_realm = CORP.EXAMPLE.COM
default_ccache_name = /tmp/krb5cc_%{uid}

[realms]
CORP.EXAMPLE.COM = {
kdc = corp.example.com
admin_server = corp.example.com
}

[domain_realm]
.corp.example.com = CORP.EXAMPLE.COM
corp.example.com = CORP.EXAMPLE.COM
.CORP.EXAMPLE.COM = CORP.EXAMPLE.COM
CORP.EXAMPLE.COM = CORP.EXAMPLE.COM
  3. Add the following parameters to the sqlnet.ora file (/u01/client/network/admin/sqlnet.ora): 
    SQLNET.KERBEROS5_CONF=/etc/krb5.conf
SQLNET.KERBEROS5_CONF_MIT=TRUE
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=oracle
SQLNET.AUTHENTICATION_SERVICES=(BEQ,KERBEROS5)
  4. Change the permission on the Oracle database Net Services configuration files to allow read access to other users: 
    [oracle@ip-10-1-4-29 ~]$ chmod o+r /u01/client/network/admin/sqlnet.ora
[oracle@ip-10-1-4-29 ~]$ chmod o+r /u01/client/network/admin/tnsnames.ora

Obtain an initial Kerberos ticket

To connect to the database using Kerberos authentication, you will need to request a Kerberos ticket from the KDC. If your Linux client has already joined the domain and you have logged in to the Linux client using Kerberos authentication, you can ignore these steps.

  1. Log in to the Linux client with user krbuser. Although it’s not mandatory to have the same OS and AD username, having such conventions provides better consistency and avoids confusion. 
    [krbuser@ip-10-1-4-29 ~]$ id
uid=54322(krbuser) gid=54331(krbuser) groups=54331(krbuser)
  2. Set environment variables for Oracle: 
    [krbuser@ip-10-1-4-29 ~]$ export ORACLE_BASE=/u01/app/oracle
[krbuser@ip-10-1-4-29 ~]$ export ORACLE_HOME=/u01/client
[krbuser@ip-10-1-4-29 ~]$ export PATH=$ORACLE_HOME/bin:$PATH
[krbuser@ip-10-1-4-29 ~]$ export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
  3. Obtain a Kerberos ticket using okinit: 
    [krbuser@ip-10-1-4-29 ~]$ okinit krbuser

Kerberos Utilities for Linux: Version 19.0.0.0.0 - Production on 24-JUN-2022 23:19:25

Copyright (c) 1996, 2019 Oracle.  All rights reserved.

Configuration file : /etc/krb5.conf.
Password for krbuser@CORP.EXAMPLE.COM:

List the Kerberos ticket

List the Kerberos ticket from the Kerberos ticket cache using the command oklist:

[krbuser@ip-10-1-4-29 ~]$ oklist

Kerberos Utilities for Linux: Version 19.0.0.0.0 - Production on 24-JUN-2022 23:31:06

Copyright (c) 1996, 2019 Oracle.  All rights reserved.

Configuration file : /etc/krb5.conf.
Ticket cache: FILE:/tmp/krb5cc_54322
Default principal: krbuser@CORP.EXAMPLE.COM

Valid starting     Expires            Service principal
06/24/22 23:19:29  06/25/22 09:19:29  krbtgt/CORP.EXAMPLE.COM@CORP.EXAMPLE.COM
renew until 07/01/22 23:19:25

Connect to the database

Use the following code to connect to the database:

[krbuser@ip-10-1-4-29 ~]$ sqlplus /@orcl.abcdefghijk.ap-southeast-1.rds.amazonaws.com/ORCL

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Jun 24 23:47:27 2022
Version 19.13.0.0.0

Copyright (c) 1982, 2021, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.13.0.0.0

SQL> show user;
USER is "KRBUSER"
SQL> 
SQL> select network_service_banner from v$session_connect_info       
  2  where sid=sys_context('USERENV','SID');

NETWORK_SERVICE_BANNER
--------------------------------------------------------------------------------
TCP/IP NT Protocol Adapter for Linux: Version 19.0.0.0.0 - Production
Authentication service for Linux: Version 19.0.1.0.0 - Production
KERBEROS5 Authentication service adapter for Linux: Version 19.0.0.0.0 - Production

Encryption service for Linux: Version 19.0.1.0.0 - Production
Crypto-checksumming service for Linux: Version 19.0.1.0.0 – Production

Configure an Oracle client on a Windows 2019 server

In this section, you need a pre-installation of an Oracle 19c client on a Windows 2019 server that’s ready to integrate with Kerberos. Refer to Database Client Installation Guide for Microsoft Windows for detailed installation steps.

You must have administrator rights on the Windows server running the Oracle client to perform the following steps. One option to do this is by adding the account krbuser@corp.example.com to the Administrators group.

The following is an example of the Oracle client install configurations:

  • Windows OS – Windows Server Datacenter
  • Hostname – EC2AMAZ-7RRI139
  • Domain – corp.example.com
  • Oracle Base – C:\Oracle\Base
  • Oracle Home – C:\Oracle\Client
  • Oracle Version – 19.15

Special settings on the service account in AD

To avoid error ORA-12638: Credential retrieval failed while authenticating with Kerberos using the Oracle client on Windows, change the account setting for the service account with the option Account is sensitive and cannot be delegated.
Change the account setting for the service account

Configure Kerberos for the Windows Oracle database client

Create the Kerberos configuration file (C:\Oracle\Client\network\admin\krb5.conf) containing the Kerberos realms and domains for your user and service accounts. Refer to Kerberos documentation krb5.conf for a detailed explanation.

[libdefaults]
dns_lookup_realm = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
default_realm = CORP.EXAMPLE.COM

[realms]
CORP.EXAMPLE.COM = {
kdc = corp.example.com
admin_server = corp.example.com
}

[domain_realm]
.corp.example.com = CORP.EXAMPLE.COM
corp.example.com = CORP.EXAMPLE.COM

Add the following parameters to the sqlnet.ora file (C:\Oracle\Client\network\admin\sqlnet.ora):

#Kerberos Parameters
SQLNET.AUTHENTICATION_SERVICES=(kerberos5)
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=oracle
SQLNET.KERBEROS5_CONF=C:\Oracle\Client\network\admin\krb5.conf
SQLNET.KERBEROS5_CLOCKSKEW=6000
SQLNET.KERBEROS5_CONF_MIT=TRUE
SQLNET.KERBEROS5_CC_NAME=MSLSA:

List the Kerberos ticket

Log in to the Windows server with user krbuser@corp.example.com, start a command prompt with Run as Administrator, and list the Kerberos ticket from the Kerberos ticket cache using the command oklist:

C:\Windows\system32>oklist

Kerberos Utilities for 64-bit Windows: Version 19.0.0.0.0 - Production on 25-JUN-2022 05:46:05

Copyright (c) 1996, 2021 Oracle.  All rights reserved.

Configuration file : C:\Oracle\Client\network\admin\krb5.conf.
Ticket cache: MSLSA:
Default principal: krbuser@CORP.EXAMPLE.COM

Valid starting     Expires            Service principal
06/25/22 05:38:43  06/25/22 15:38:43  LDAP/WIN-NF6IONHTVGD.corp.example.com/corp.example.com@CORP.EXAMPLE.COM
renew until 07/02/22 05:38:43

Connect to the database

Use the following code to connect to the database:

C:\Windows\system32>sqlplus /@orcl.abcdefghijk.ap-southeast-1.rds.amazonaws.com/ORCL

SQL*Plus: Release 19.0.0.0.0 - Production on Sat Jun 25 05:47:43 2022
Version 19.15.0.0.0

Copyright (c) 1982, 2021, Oracle.  All rights reserved.

Last Successful login time: Fri Jun 24 2022 23:47:26 +00:00

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.13.0.0.0

SQL> show user;
USER is "KRBUSER"
SQL>
SQL> select network_service_banner from v$session_connect_info
2  where sid=sys_context('USERENV','SID');

NETWORK_SERVICE_BANNER
--------------------------------------------------------------------------------
TCP/IP NT Protocol Adapter for Linux: Version 19.0.0.0.0 - Production
Authentication service for Linux: Version 19.0.1.0.0 - Production
KERBEROS5 Authentication service adapter for Linux: Version 19.0.0.0.0 - Product
ion

Encryption service for Linux: Version 19.0.1.0.0 - Production
Crypto-checksumming service for Linux: Version 19.0.1.0.0 – Production

Additional considerations

In this section, we discuss other considerations when implementing this solution.

Restore RDS Custom or create a new read replica

When you restore RDS Custom for Oracle, it restores into a new RDS Custom instance (host) with a different hostname. Similarly, when you create a read replica, RDS Custom for Oracle restores it from a snapshot, using a different host and a new hostname. In these scenarios, perform the following additional steps if Kerberos authentication is required for the restored databases:

  1. Create a service account for the new host.
  2. Generate a keytab file and copy it to the new host.
  3. Update the sqlnet.ora file on the new host to point to the new keytab file.
  4. Delete the old keytab file on the new host.

If Kerberos authentication is no longer required in the restored environment, update the Oracle database sqlnet.ora file by removing the settings related to the Kerberos configurations and delete the keytab file.

Automation based on RDS DB instance events

Amazon RDS events are created automatically during RDS Custom instance creation and deletion. Together with Amazon EventBridge and AWS System Manager, you can automate steps such as service account creation, keytab creation, and RDS Custom for Oracle database server configuration using an automation runbook. With automation, you can minimize the manual effort required for configuring Kerberos authentication, as well as verifying that obsolete service accounts are removed from your managed AD after the deletion of the RDS Custom for Oracle instance.

Troubleshooting

If you encounter the error ORA-12638: Credential retrieval failed on your Windows platform running your Oracle client, check the flag for the service account in the Kerberos cache and verify that there is no F (forwardable) in it.

In the following working example, the Flags for oracle/ip-10-1-4-113@CORP.EXAMPLE.COM is RA (renewable and pre-authenticated), without F (forwardable). If there is an F flag, refer to the earlier steps to configure an Oracle client on a Windows 2019 server to fix it.

C:\Windows\system32>oklist -f

Kerberos Utilities for 64-bit Windows: Version 19.0.0.0.0 - Production on 25-JUN-2022 06:33:36

Copyright (c) 1996, 2021 Oracle.  All rights reserved.

Configuration file : C:\Oracle\Client\network\admin\krb5.conf.
Ticket cache: MSLSA:
Default principal: krbuser@CORP.EXAMPLE.COM

Valid starting     Expires            Service principal
06/25/22 05:47:44  06/25/22 15:38:43  oracle/ip-10-1-4-113@CORP.EXAMPLE.COM
renew until 07/02/22 05:38:43, Flags: RA
06/25/22 05:38:43  06/25/22 15:38:43  LDAP/WIN-NF6IONHTVGD.corp.example.com/corp.example.com@CORP.EXAMPLE.COM
renew until 07/02/22 05:38:43, Flags: FRAO

If the error message isn’t clear enough to identify the possible root cause, you can enable Oracle SQL*Net trace to examine the connection details for diagnostic purposes. Beware of performance overheads and the extra storage space consumed by these trace files.

The following is a sample sqlnet.ora file for an Oracle database server:

DIAG_ADR_ENABLED=off
TRACE_LEVEL_SERVER=support
TRACE_DIRECTORY_SERVER=/rdsdbdata/log/security
TRACE_FILE_SERVER=serversqlnet.trc

The following is a sample sqlnet.ora file for an Oracle database client on Linux:

DIAG_ADR_ENABLED=off
TRACE_LEVEL_CLIENT=support
TRACE_FILE_CLIENT=/tmp/clientsqlnet.trc

The following is a sample sqlnet.ora file for an Oracle database client on a Windows 2019 server:

DIAG_ADR_ENABLED=off
TRACE_LEVEL_CLIENT=support
TRACE_FILE_CLIENT=C:\Oracle\Client\network\log\clientsqlnet.trc

Conclusion

In this post, we showed you how to use AWS Managed Microsoft AD and Kerberos to centralize the storage and management credentials of your RDS Custom for Oracle users, improve your organization’s overall security profile, and reduce time and effort operationally. For organizations with self-managed Active Directory either in AWS or on-premises, you can adopt a similar pattern with minimal alterations.

In Part 2 of this series, we look into how we can take advantage of a new feature named Oracle Centrally Managed User (CMU) to authenticate and authorize Microsoft AD users with the database directly.

If you have any comments or questions, leave them in the comments section.

About the Authors

Donghua LuoDonghua Luo is a Senior RDS Specialist Solutions Architect. He works with AWS customers to migrate and achieve higher flexibility, scale, and resiliency with database services in AWS cloud.

William Wong is a Principal Database Specialist Solutions Architect with Amazon Web Services based out of Australia. He is passionate around all things data and works closely with customers to help improve and modernize their database workloads on AWS. William brings 20+ years of experience in the field, from migrating legacy applications, to modernising with open source engines, or innovating with purpose built databases.