I was trying to roll out RMAN backups in an environment with three Windows domains: dev, pre-prod and production. The RMAN repository database needs to be in the production domain and yet be accessible from each domain, (eg to allow development databases to be refreshed from production). There was no trust relationship between client domain and DB domain.
When I tried to connect to the RMAN catalogue from another domain, using a username and password, it failed and the repository database’s alert log records:
TNS-12638: Credential retrieval failed
OS authentication was being used within the production domain, (eg for monitoring), so we required:
Setting AUTHENTICATION_SERVICES to NONE allowed the connections to succeed, but it would mean we’d have to stop using OS authentication.
TNS-12638: Credential retrieval failed
Using SQL*Plus to connect to a database running on Windows in a different domain with “SQLNET.AUTHENTICATION_SERVICES = (NTS)” in sqlnet.ora
No trust relationship between client domain and DB domain, so the database can’t check if OS user is in the DBA group, or use OS authentication, etc, even if the correct user and password are provided.
ORA-12638 // *Cause: The authentication service failed to retrieve the credentials of a // user. // *Action: Enable tracing to determine the exact error.
The trace file contained:
2016-06-30 11:22:48.333047 : naun5authent:Authentication type is 0 2016-06-30 11:22:48.333058 : naun5authent:SPP is KERBEROS 2016-06-30 11:22:48.337280 : naun5authent:SSPI: 0x80090303 error in InitializeSecurityContext 2016-06-30 11:22:48.337301 : naun5authent:exit 2016-06-30 11:22:48.337316 : naunauthent:exit 2016-06-30 11:22:48.337331 : nau_ccn:get credentials function failed 2016-06-30 11:22:48.337344 : nau_ccn:failed with error 12638 2016-06-30 11:22:48.337357 : nacomsd:entry 2016-06-30 11:22:48.337367 : nacomfsd:entry 2016-06-30 11:22:48.337377 : nacomfsd:exit 2016-06-30 11:22:48.337387 : nacomsd:exit 2016-06-30 11:22:48.337397 : nau_ccn:exit 2016-06-30 11:22:48.337408 : na_csrd:failed with error 12638 2016-06-30 11:22:48.337418 : na_csrd:exit 2016-06-30 11:22:48.337430 : nacomer:error 12638 received from Authentication service 2016-06-30 11:22:48.337441 : nacomer:failed with error 12638 2016-06-30 11:22:48.337451 : nacomsn:entry 2016-06-30 11:22:48.337461 : nacomap:entry 2016-06-30 11:22:48.337472 : nacomap:Packet length 21 # of services 1 Error sent? TRUE 2016-06-30 11:22:48.337485 : nacomap:Version transmitted: Oracle Advanced Security for 64-bit Windows: Version 0.0.0.0.0 - Production 2016-06-30 11:22:48.337496 : nacomps:entry 2016-06-30 11:22:48.337508 : nacomps:service Authentication # of fields 0 ORACLE error 12638
The Windows error indicated an infrastructure issue:
Hex : 0x80090303 Decimal : -2146893053 (2148074243) Define(s) : [winerror.h ] SEC_E_TARGET_UNKNOWN Message : The specified target is unknown or unreachable
It doesn’t make sense that Oracle refuses access with TNS-12638 when a valid database account and password is provided, so I logged a ticket with Oracle Support asking how we could keep OS authentication enabled while allowing authentication by password from a domain without a trust relationship, (thereby allowing a pre-production database to connect to the RMAN repository in the production domain).
Oracle Support said:
NTS is Windows Native authentication, where user is authenticated based on the OS credentials to login to the database. NTS code checks group membership, For example if OS user is a member of ORA_DBA group then that user can login as sqlplus / as sysdba using NTS authentication.
So when you specify sqlnet.authentication_services=(NTS), It is expected that client should be authenticated and login to database using OS credentials via Windows Native Authentication and no external password is needed.
If you are have specified sqlnet.authentication_services=(NTS) in sqlnet.ora, then client should pick NTS adapter to authenticate using WIndows OS credentials and login to database.
If you are specifying client to be authenticates using NTS and providing external username/password based authentication, <<< it should throw an error. >>>
It has been clearly mentioned in Oracle docs to set sqlnet.authentication_services=(NONE) for trying external username/password based authentication.
Yes, setting SQLNET.AUTHENTICATION_SERVICES to NONE allows logging in with a password from a different domain, but it breaks using OS authentication from the same domain.
Setting it to NTS doesn’t prevent logging in with a username and password from within the same domain or with trusts between the domains (when no OP$ account exists and the user isn’t in ORA_DBA), so I disagree that it “should throw an error”. I’m sure most Oracle on Windows customers have their system configured this way. The difference at this site is that we have separated the domains. I can’t see any need for the behaviour to be different when using multiple domains. If Oracle/windows can’t confirm OS authentication, why not fall back to using the supplied user and password? Or even just use that first and fall back to trying OS authentication.
Oracle on Linux and UNIX can use both OS authentication and password authentication at the same time, so it doesn’t make sense that Oracle on Windows doesn’t.
I raised an enhancement request to resolve this issue:
Bug 25087191 : NTS ADAPTER SHOULD ALLOW PASSWORD AUTHENTICATION ACROSS DOMAINS
Useful Work Around
I found an acceptable work around – wrapping RMAN scripts with a command that hides the client’s domain name from Oracle.