Update 08-JUN-2018
This bug has been fixed with the Oracle 19.3 client release for Windows. Below workaround should not be necessary anymore.
One cool feature of using Kerberos authentication is that when you have a TGT (Ticket Granting Ticket) in the ticket cache the Oracle client software can use that to get a service ticket and log you into the database without further asking for any credentials (single sing-on).
Here’s what it looks like with a Kerberos authenticated SSH session on Linux:
As you can see from the screenshot the “orasrv” service ticket is flagged “forwardable” and the database login is successful (“-f” tells “oklist” to show the ticket flags).
On Windows on the other hand the same fails with “ORA-12638: Credential retrieval failed”:
If we change to “non-forwardable” service tickets it works on both, Linux and Windows:
How do you change to “non-forwardable” service tickets?
1) Use “okinit” to manually re-initialize your ticket cache. By default it will get “non-forwardable” tickets (or use “-F” to be explicit).
2) You can configure the service principal in Active Directory so only “non-forwadable” tickets will be issued (even when you use “okinit -f” to explicitly ask for “forwardable” tickets)
Both workarounds do the trick but I don’t like neither of them for their obvious drawbacks. After a few weeks trying to convince the Oracle Support Engineer of the issue bug 28734494 has been filed on Oct 8, 2018 with no notable progress to date 🙁
Despite what the bug description says the issue is not MSLSA vs file ticket cache, it is the ticket flags that make or break.
Btw. I’ve tested client versions 12.2.0.1, 18.3, 18.5 and they all exhibit the same behaviour.
Hello and thank you for this very useful blog.
I have tried to make the described workaround for Oracle client 12.2 with okinit but could not make it work . The ticket is not forwardable but Kerberos authentication fails.
Can you share the configuration of you sqlnet.ora and the kerb5.conf
Oracle 19.3 works fine without any workarounds , just wanted 12.2 to work also
Hi, thanks for the feedback!
Here’s the client sqlnet.ora:
ADR_BASE = C:\app\oracle
NAMES.DIRECTORY_PATH = (TNSNAMES,EZCONNECT)
SQLNET.AUTHENTICATION_SERVICES = (KERBEROS5)
SQLNET.KERBEROS5_CC_NAME = MSLSA:
SQLNET.KERBEROS5_CONF = C:\app\oracle\etc\krb5.conf
SQLNET.KERBEROS5_CONF_MIT = TRUE
And client-side krb5.conf:
[libdefaults]
default_realm = SPOTONORACLE.COM
[realms]
SPOTONORACLE.COM = {
kdc = win2016dc1.spotonoracle.com:88
}
[domain_realm]
.spotonoracle.com = SPOTONORACLE.COM
spotonoracle.com = SPOTONORACLE.COM
Hope that helps.
Great blog post. If only I had seen it a few weeks ago.
I have the same bug on Oracle 19.3. It took me days to figure out that the forwardable flag caused the problems. Authentication on Windows with forwardable Tickets is still broken here with Oracle 19.3.
Hi Mike,
Thanks for the comment. In my 19.3 environment (client and server) it works as expected. I’m curious where the configurations differ.
Best regards,
Beat
My Client configuration is very similar to your krb5.conf file, of course with our domain instead of yours.
My Oracle 19.3 test database is running on Windows 10 Version 1903.
My Oracle 19.3 test client is running on another machine with Windows 10 Version 1903.
I didn’t install any Oracle Updates on the test database or the test client.
Our Active Directory Server is running on Windows Server 2016.
I just tried it again to confirm the problem. Kerberos login is working if I disable account delegation for the service user. If I enable delegation I get a forwardable ticket for the service user on my client system whenever I try to login with sqlplus. The following error is then logged in the kerberos trace file on the client and the login fails:
[12060] 1568887844.487007: Retrieving myuser@MYDOMAIN.NET -> krbtgt/MYDOMAIN.NET@MYDOMAIN.NET from MSLSA: with result: -1765328243/Matching credential not found
The sqlnet client trace file has the following lines for the error:
…
(3928) [000001 19-SEP-2019 12:10:44:559] nauztk5aauthent: Error building credentials request “9”.
(3928) [000001 19-SEP-2019 12:10:44:559] nauztk5aauthent: failed
(3928) [000001 19-SEP-2019 12:10:44:559] nauztk5aauthent: exit
(3928) [000001 19-SEP-2019 12:10:44:559] nau_ccn: get credentials function failed
(3928) [000001 19-SEP-2019 12:10:44:559] nau_ccn: failed with error 12638
…
Is your database running on Linux?
Hi Mike,
Thanks for sharing.
The only difference in my setup is that the database is running on Oracle Linux 7.6.
Hi son,
thank you for the information.
I will test it on a linux setup soon.
We also have this issue with 19.3 when attempting Kerberos authentication from Windows (works from Linux clients). By default we get forwardable tickets and connection attempts error with the error “ORA-12638: Credential retrieval failed”.
If we then run “okdstry” and “okinit -F” (capital F) then we are able to connect with the non-fowardable ticket.
Mike – Were you able to resolve your ORA-12638 issue for forwardable tickets?
Thanks much!
Chuck
Is there a patch to resolve the issue with Oracle 19.3 client on Windows? I am running with the same credential retrieval issue and it works only with non-forwardable tickets (okinit -F). I am running my database on OEL 7.x
Any other configuration changes required in krb5.conf file other than these?
[libdefaults]
default_realm = SPOTONORACLE.COM
[realms]
SPOTONORACLE.COM = {
kdc = win2016dc1.spotonoracle.com:88
}
[domain_realm]
.spotonoracle.com = SPOTONORACLE.COM
spotonoracle.com = SPOTONORACLE.COM
and sqlnet.ora:
SQLNET.AUTHENTICATION_SERVICES = (KERBEROS5)
SQLNET.KERBEROS5_CC_NAME = MSLSA:
SQLNET.KERBEROS5_CONF = C:\app\oracle\etc\krb5.conf
SQLNET.KERBEROS5_CONF_MIT = TRUE
Hi Nara
In my lab environment it worked with 19.3 using the exact same configuration. Have you tried with latest RU 19.12?
Otherwise I would suggest you open a SR.
Best regards,
Beat
Try to install the MIT Kerberos client on the client pc (https://web.mit.edu/kerberos/dist/kfw/4.1/kfw-4.1-amd64.msi).
I got the ‘nauztk5aauthent: Error building credentials request “9”.’ as well unless I explicitely do a okinit -F
With the MIT Kerberos client installed it works without having to do an explicit okinit.
I got the reference to this from an Oracle Support case, I think it is mentioned in some Oracle Documentation, but can’t recall at the moment..
Exactly what this achieve is unclear to me.
I am using a 19 (.3?) Oracle client.
This worked like a charm for me as well, thanks for the suggestion! The strange thing is that I didn’t even need to start the MIT client. It works even without an initial okinit after that (as it should have done from the start!).