sqlnet.ora NTS and ODBC

I'm trying to connect to oracle databases (V11.1 and V11.2 which are running on windows servers) from Windows clients using oracle instant client V11.1
It appears that I need to eliminate NTS from the sqlnet.authentication_services=
line in sqlnet.ora for ODBC connections to work.

Is this usual, and why is this?
The problem is that I want to also run odbc connections out from the servers themselves.  (for testing purposes)
If I eliminate NTS from the authentication services, then I can't run sqlplus using "/ as sysdba" locally.

Why would NTS need to be eliminated for ODBC connections to work.

Who is Participating?
dakota5Author Commented:
Thanks for the link to the Hall article.  Some of the behavior is curious.  Upon further testing (V11.2) I've found that

1.  Windows OS authentication is problematic going across domains that are not trusted.  Within the same domain, OS authentication works out of the box (default config for windows has NTS turned on-- NTS is present in the sqlnet.ora file).  Client in domain A can connect to oracle server in domain A- no problem
For some reason, if there is a one-way trust relation between domains A and B, with domain A trusting domain B,
clients in Domain A can connect to Oracle servers in domain B using OS authentication, but clients in domain B (the more restricted domain) can't connect to Oracle servers on Domain A.

2.  There is no way to have NTS turned off for the client on an Oracle server box but turned on for the main database on the same box.

3.  Having multiple clients on an oracle server, with multiple sqlnet.ora files (like a client installation in addition to the client in the database home) can make the OS authentiation process non-functional.  Generally a bad idea.
This is an interesting question.  I primarily administer Oracle on Solaris and generally avoid Winduhs like the plague, but when it comes to security authentication_services=NTS comes with blessings and curses.

The potential scenario is that you have a database, and you just want users that have already authenticated themselves by logging on to the network to have access to your database without having to supply an additional password, or in particular have to remember and maintain a different password.

An old school approach with many caveats is to enable init.ora parm REMOTE_OS_AUTHENT=TRUE, and this truly permits users to connect with no password if you can trust you can identify who they are by the username alone, but allows anyone with root on a Linux box allowed on your network to spoof anyone easily.  So this tends not to be very popular where security is of any importance.

If you have specified REMOTE_OS_AUTHENT=TRUE then it is incompatible with SQLNET AUTHENTICATION_SERVICES=(NTS); you would need to have (NONE) as the remote os authent requires that the remote system authentication be trusted without any confirmation.

This appears all to be designed to help sell you Oracle Advanced Security.

But anyway, the question I find myself asking is, assuming...
== init.ora parms ===
== sqlnet.ora parms ===

and that if you create user identified externally, then you can set up a user where the Oracle DBA doesn't need to maintain the password, but it isn't like leaving the barn door open, the user will be required to enter their proper WIndows domain password, and be confirmed to be authenticated via appropriate Winduhs Wintel Active Directory protocols.  

Thanks to Tim Hall for more detailed explanation on this...

Thx for charitable thoughts dakota5, but building on your input I can offer a more specific solution.

Yes it can be annoying having a "multi-home client", and generally you want to set up the environment in a manner that is satisfactory for most of the users most of the time.  Presuming that in your case, if you can't identify a way around it with further investigation, your main ${ORACLE_HOME}/network/admin should have NTS turned off to satisfy your ODBC.  Perhaps you are using Heterogenous Connectivity for DB-Links over ODBC to other databases(?)

And then for the specific circumstances where you have startup/shutdown/maintenance scripts that need to connect as SYSDBA, just add a "set TNS_ADMIN=" that points to a directory that contains the version of SQLNET.ORA that has the NTS turned on, so this script works as intended, and can be scripted and automated as at-job if you need to automate cold backups on weekends or some such thing.


Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.