Oracle Kerberos Authentication — Part 2: RAC Integration

 

Introduction

In Part 1, we covered the fundamentals of Kerberos authentication with a single Oracle instance. But in real-world enterprise deployments, most mission-critical databases run on Oracle RAC (Real Application Clusters). RAC introduces complexity: multiple nodes, shared services, SCAN listeners, and failover scenarios. Kerberos must be configured consistently across all nodes to ensure seamless authentication.

This guide walks through the step-by-step RAC integration process, enriched with lessons learned from production environments.

Step 1: Synchronize Kerberos Configuration Across Nodes

Every RAC node must have identical Kerberos configuration files.

1. Distribute krb5.conf

   scp /etc/krb5.conf racnode2:/etc/krb5.conf scp /etc/krb5.conf racnode3:/etc/krb5.conf

2. Distribute Keytab

   scp /etc/krb5.keytab racnode2:/etc/krb5.keytab scp /etc/krb5.keytab racnode3:/etc/krb5.keytab chmod 600 /etc/krb5.keytab

3. Verify Consistency

   md5sum /etc/krb5.conf /etc/krb5.keytab

Step 2: Configure sqlnet.ora on Each Node

Each RAC node’s $ORACLE_HOME/network/admin/sqlnet.ora must include Kerberos settings:

SQLNET.AUTHENTICATION_SERVICES = (KERBEROS5) SQLNET.KERBEROS5_CONF = /etc/krb5.conf

SQLNET.KERBEROS5_KEYTAB = /etc/krb5.keytab

Step 3: SCAN Listener Integration

RAC environments use SCAN listeners for client connections. These must be Kerberos-aware.

1. Create Service Principal for SCAN On AD/KDC:

   ktpass -princ oracle/rac-scan.example.com@EXAMPLE.COM -mapuser oracleuser \ -pass <StrongPassword> \ -ptype KRB5_NT_PRINCIPAL \ -out racscan.keytab

2. Deploy Keytab to All Nodes

   scp racscan.keytab racnode1:/etc/krb5.keytab scp racscan.keytab racnode2:/etc/krb5.keytab scp racscan.keytab racnode3:/etc/krb5.keytab

Step 4: srvctl Configuration

Update RAC services to use Kerberos authentication.

1. Register Service

   srvctl add service -d ORCL -s HR_SERVICE -r racnode1,racnode2

2. Enable Kerberos Modify listener.ora to reference Kerberos keytab. Example:

   ENCRYPTION_SERVICES = (KERBEROS5)

Step 5: Testing RAC Kerberos Authentication

1. Obtain Ticket

   kinit hr@EXAMPLE.COM klist

2. Connect via SCAN

   sqlplus /@HR_SERVICE

3. Failover Test Shut down one node:

   srvctl stop instance -d ORCL -i racnode1 Reconnect — Kerberos authentication should succeed via another node.

Step 6: Common Pitfalls in RAC + Kerberos

• Keytab Drift: If one node has an outdated keytab, authentication fails.

• SCAN Principal Misconfiguration: Ensure SCAN FQDN matches Kerberos principal.

• Ticket Expiration During Failover: Automate ticket renewal for long-running sessions.

• Firewall Rules: All nodes must reach KDC on port 88.

Step 7: Best Practices

• Automate Distribution: Use Ansible or Puppet to push Kerberos configs to all nodes.

• Centralize Documentation: Maintain a single source of truth for principals and keytabs.

• Monitor Tickets: Implement scripts to check ticket validity across nodes.

• Audit Regularly: Ensure compliance with enterprise security policies.

Real-World DBA Insights

• In one deployment, failover consistently failed because the SCAN principal was registered with a short hostname instead of FQDN. Always use fully qualified domain names.

• Another case involved mismatched keytabs across nodes after a patch cycle. Automating distribution solved this permanently.

• RAC environments amplify Kerberos issues — what works on one node must work identically everywhere.

Conclusion

Kerberos authentication in RAC environments requires discipline and consistency. By synchronizing configs, properly registering SCAN principals, and automating distribution, you can achieve seamless passwordless authentication across clustered databases.

This not only strengthens security but also ensures high availability without compromising compliance.