Table of Contents
How to Resolve ORA-12638 and ORA-12641 Errors in Oracle Database with Kerberos Authentication
When integrating Oracle Database with Kerberos authentication, you might encounter errors such as ORA-12638: Credential retrieval failed or ORA-12641: Authentication service failed to initialize. These errors often occur when attempting to authenticate without running your application or tools (like SQL*Plus or PowerShell) with administrator privileges.
In this blog, we’ll discuss a secure solution to resolve these errors without disabling important security policies on your Windows system. We’ll also contrast this with a less secure workaround, explaining why the primary solution is recommended.
Problem Overview
ORA-12638: Credential retrieval failed
This error typically occurs when SQL*Plus or other Oracle tools fail to retrieve the Kerberos credentials needed for authentication. The failure is often due to insufficient permissions or configuration issues in Windows when using a dynamic Kerberos ticket cache (MSLSA).
ORA-12641: Authentication service failed to initialize
This error is related to the inability of Oracle’s authentication service to initialize properly, which is often tied to misconfigurations in the sqlnet.ora file or Kerberos ticket settings.
Both errors commonly surface in environments where:
- The application or script is not run with administrator privileges.
- There is an issue with Kerberos ticket caching, especially when using the Windows-based Kerberos ticket system (MSLSA).
Step-by-Step Solution
Primary Solution: Secure Kerberos Configuration Without Disabling Security Policies
The key to resolving these errors securely lies in properly configuring your Kerberos and Oracle network files, ensuring strong encryption, and avoiding the need to run applications with elevated privileges.
Kerberos Configuration (krb5.conf)
Below is a recommended configuration for the krb5.conf file on both the server and the client:
[libdefaults]
default_realm = DOMAIN.LOCAL
# Use only strong encryption types supported by your domain
default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
# Do not allow weak cryptography
allow_weak_crypto = false
# Enable DNS lookup for KDC and realm
dns_lookup_kdc = true
dns_lookup_realm = true
# Disable reverse DNS
rdns = false
# Maximum number of retries for KDC requests
max_retries = 1
# Do not allow forwardable tickets
forwardable = false
# Reduce allowed clock skew (e.g., to 6000 seconds)
clockskew = 6000
# Enable KDC time synchronization
kdc_timesync = 1
# Cache type (default is 4)
ccache_type = 4
[realms]
DOMAIN.LOCAL = {
kdc = domaincontroller01.domain.local # Your AD Domain Controller
kdc = domaincontroller02.domain.local
master_kdc = domaincontroller01.domain.local
default_domain = domain.local
admin_server = domaincontroller01.domain.local # Your AD Domain Controller
admin_server = domaincontroller02.domain.local
}
[domain_realm]
.DOMAIN.LOCAL = DOMAIN.LOCAL
DOMAIN.LOCAL = DOMAIN.LOCAL
.domain.local = DOMAIN.LOCAL
domain.local = DOMAIN.LOCAL
Explanation of Key Settings:
- Strong Encryption Only: By specifying default_tkt_enctypes, default_tgs_enctypes, and permitted_enctypes, we enforce the use of strong encryption algorithms (AES 128 and 256-bit).
- Disallow Weak Cryptography: Setting allow_weak_crypto = false ensures that weak encryption methods are not permitted.
- DNS and KDC Settings: Enabling dns_lookup_kdc and dns_lookup_realm allows Kerberos to locate the Key Distribution Center (KDC) via DNS. Disabling rdns prevents reverse DNS lookups, which can cause delays or failures.
- Time Synchronization: Proper time sync is crucial for Kerberos. clockskew defines the acceptable time difference between client and server.
Oracle Network Configuration (sqlnet.ora)
On the Server:
# sqlnet.ora Network Configuration File on the Server
SQLNET.AUTHENTICATION_SERVICES = (NTS, KERBEROS5, KERBEROS5PRE)
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE = oracle
SQLNET.KERBEROS5_CONF = D:\Kerberos\krb5.conf
SQLNET.KERBEROS5_CC_NAME = MSLSA:
SQLNET.KERBEROS5_KEYTAB = D:\Kerberos\oracle.keytab
SQLNET.KERBEROS5_CONF_MIT = TRUE
On the Client:
# sqlnet.ora Network Configuration File on the Client
SQLNET.AUTHENTICATION_SERVICES = (KERBEROS5)
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE = oracle
SQLNET.KERBEROS5_CC_NAME = D:\Kerberos\ticket_cache
SQLNET.KERBEROS5_CONF = D:\Kerberos\krb5.conf
SQLNET.KERBEROS5_CONF_MIT = TRUE
Explanation of Key Settings:
- Authentication Services: On the server, we include NTS (Windows Native Authentication) and Kerberos services. On the client, we specify KERBEROS5 to use Kerberos authentication.
- Kerberos Service Name: SQLNET.AUTHENTICATION_KERBEROS5_SERVICE should match the Service Principal Name (SPN) used in your Kerberos setup.
- Kerberos Configuration Path: SQLNET.KERBEROS5_CONF points to the location of your krb5.conf file.
- Kerberos Ticket Cache:
- On the server, SQLNET.KERBEROS5_CC_NAME = MSLSA: instructs Oracle to use the Windows Kerberos ticket cache.
- On the client, we use a static ticket cache file (D:\Kerberos\ticket_cache).
- Keytab File (Server Only): SQLNET.KERBEROS5_KEYTAB points to the keytab file containing the server’s secret key for Kerberos authentication.
- MIT Kerberos Configuration: SQLNET.KERBEROS5_CONF_MIT = TRUE ensures Oracle uses the standard MIT Kerberos configuration format.
Benefits of This Configuration:
Security: By enforcing strong encryption and not allowing weak cryptography, you maintain a high security standard.
No Need to Disable Security Policies: This solution avoids altering Windows Local Security Policies, preserving system integrity and compliance.
No Administrator Privileges Required: Applications and tools can authenticate via Kerberos without needing to be run as an administrator.
Secondary Solution: Disabling Security Policies (Not Recommended)
An alternative approach involves modifying Windows Local Security Policies to allow applications to access the Windows Kerberos ticket cache (MSLSA:) without administrator privileges. However, this method reduces the security of your system and is not recommended.
1. Configure Kerberos with allow_weak_crypto in your Configuration File
One potential issue is related to the encryption method used by Kerberos. You can enable the use of weaker encryption algorithms by modifying the Kerberos configuration (krb5.conf) or directly in the sqlnet.ora file used by Oracle.
To do this, add the following line to your configuration:
allow_weak_crypto = true
This setting allows Oracle to support weaker cryptographic algorithms that may be necessary to establish a successful Kerberos authentication connection, especially in legacy environments.
2. Using a Static Kerberos Ticket Cache
To avoid problems with dynamically retrieving Kerberos tickets from Windows, you can use a static ticket cache. This ensures that the Kerberos tickets are retrieved from a file location, not directly from the Windows Local Security Authority (LSA).
Modify your sqlnet.ora file to include the following:
SQLNET.KERBEROS5_CC_NAME = “d:\Kerberos\ticket_cache”
In this example, the Kerberos ticket is stored in a file (ticket_cache), and Oracle will use this file for authentication.
You can generate and refresh the Kerberos ticket using the command:
okinit
This command will prompt you for credentials and store the ticket in the specified cache file.
3. Using the Dynamic Ticket Cache (MSLSA)
If you want to use the default Windows Kerberos ticket cache (known as MSLSA), you can set this in your sqlnet.ora file:
SQLNET.KERBEROS5_CC_NAME = MSLSA:
This instructs Oracle to retrieve Kerberos tickets directly from the Windows ticket cache.
However, using the MSLSA dynamic ticket cache often requires administrator privileges due to how Windows manages access to security credentials. If you don’t want to run SQL*Plus or PowerShell as an administrator, you will need to adjust your Windows security settings.
4. Adjust Windows Security Settings (Local Security Policies)
To enable Kerberos ticket retrieval from MSLSA without administrator privileges, you need to modify the local security policies on your Windows machine:
Open the Local Security Policy editor by typing secpol.msc in the Run dialog (Win + R).
Navigate to Local Policies > Security Options.
Locate and disable the following two settings:
- User Account Control: Run all administrators in Admin Approval Mode
- User Account Control: Admin Approval Mode for the Built-in Administrator account
By disabling these settings, you allow Oracle to access the Windows Kerberos cache (MSLSA) without requiring elevated permissions.
Restart your machine for the changes to take effect.
5. Test the Connection
Once you have made these changes, test your Kerberos authentication by running SQL*Plus or PowerShell without administrator privileges:
sqlplus /@DBNAME
If everything is configured correctly, you should be able to authenticate without encountering the ORA-12638 or ORA-12641 errors.
Summary
To resolve ORA-12638 and ORA-12641 errors when using Kerberos authentication in Oracle, especially when you don’t want to run your tools with elevated privileges, follow these steps:
Enable weak cryptography in the Kerberos or Oracle configuration.
Use a static Kerberos ticket cache if you want to avoid using MSLSA.
If using MSLSA, adjust your local security policies to allow non-administrative access to the Kerberos ticket cache.
After implementing these configurations, you should be able to authenticate via Kerberos successfully without requiring administrator permissions for every session.
By following these steps, you ensure smoother integration between Oracle and Kerberos, allowing more flexibility in how you manage database connections in secured environments.