ORA-12638: Status 82 "Not a bug"

One thing that completely spoils the previous entry on Kerberos authentication in the database, is the state of denial Oracle is in. It seems impossible to admit there's a bug in SQL*Net in the sense there's no fallback for username/password authentication when Kerberos fails.

ORA-12638 [Credential retrieval failed]

What's the case? Well, after you have set up Kerberos authentication, your database links seize working with ORA-12638: Credential retrieval failed, as soon as both databases are Kerberos aware.

Now, of course this is a situation you do not want. You want administrators and users to log in using their working environment credentials, but you rely on named accounts, and passwords, for database links.
Alas. Here comes Bug 6341668: CLIENT CAN NOT CONNECT TO DATABASE BY PASSWORD IF ANY KERBEROS PROBLEM OCCURS. Current status: 82 "Closed, not a bug". Al least someone else tried Kerberos authentication...
This is in contradiction with another Kerberos-related bug, # 2647883: Kerberos current user database links do not work (See Doc ID 2647883.8), where the actual workaround is ... use fixed user database links (!).
Catch-22, eh?

I hate it when I get confronted with this rubbish on Friday afternoons. It ruins my weekend!
Oh - might anyone wonder: this is cross platform, 10.2.0.4.

One other reference on Oracle Support: TNS-12638 when database authentication tried on Kerberos setup (Doc ID 972896.1)

Updates

ASO is standard

There's a note stating the Advanced Security Option is now standard with the Enterprise Database Install. Makes you wonder: is it included in the standard license fee, then?

Patch 10.2.0.5

Took the time to update the 10.2.0.4 environment I tested the scenario in to 10.2.0.5, which does have some Kerberos related bugs resolved. The result of all this is not only a ruined Sunday, it's also not resolving anything.

C:\>sqlplus /@db10
SQL*Plus: Release 10.2.0.5.0 - Production on Sun Sep 26 18:32:25 2010
Copyright (c) 1982, 2010, Oracle. All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production
With the Partitioning, Data Mining and Real Application Testing options

SQL> select sysdate from dual@fvb;
select sysdate from dual@fvb
*
ERROR at line 1:
ORA-12638: Credential retrieval failed

Only after removing the services from sqlnet.ora on the server side, it works:

[ora10@db1 admin]$ cat sqlnet.ora
names.default_domain=home.local
# sqlnet.authentication_services=(beq, kerberos5)
sqlnet.kerberos5_conf=/oracle/db10/admin/krb5.conf
sqlnet.kerberos5_keytab=/oracle/db10/admin/db1.keytab
sqlnet.authentication_kerberos5_service=orcl
sqlnet.kerberos5_conf_mit=true

Which makes the same query on the client work... instantaneous!

SQL> select sysdate from dual@fvb;

SYSDATE
---------
26-SEP-10

It's getting weirder

I stumbled upon this, trying to find a workable solution on maintainting two TNS_ADMIN locations on the server. A similar problem has been logged as Bug 5054469: "DATABASE AUTHENTICATED USERS REQUIRE KERBEROS CREDENTIAL CACHE TO CONNECT", which has been closed as duplicate of (internal) bug 9056628.
Explain: how can a bug# 5 million-and-something be closed as a duplicate of bug# almost-twice-as-high? Makes me wonder.
And the best is this: Doc ID 972896.1 (TNS-12638 when database authentication tried on Kerberos setup) states "This has been an issue in the past that the authentication services are not skipped to next when first fails".
Yeah right: has been... in the past...