11

Partly as a result of having problems with conflicting versions or bitness with the full installation of Oracle client, my development team (of which I'm a member) has been moving towards using Oracle Instant Client and avoiding the installation on our development machines for most new projects. This has worked out pretty well, even to the point that we deploy to production with this setup. Since we're mostly a .NET shop, we're using the native client (with .NET wrappers), rather than the Java one.

Now a client is requiring that we register the database service with an LDAP server and use the LDAP server for name look up. They have provided sqlnet.ora and ldap.ora files (and an accompanying encryption config file) that appear to be correct. In particular, the sqlnet.ora file does specify LDAP as a possible source for looking up net service names:

names.directory_path=(tnsnames,ldap)

I am confident that the machine I'm working with can use LDAP to access the service since I was able to do so using SQL Developer (which allowed me to input the LDAP information directly). Assuming they are correct, how can I get Instant Client to recognize this configuration and use LDAP for the name look up?

What I've tried so far

I have tried setting the TNS_ADMIN environment variable to the directory that contains the provided files, and while this works fine for making Instant Client recognize a tnsnames.ora file, it doesn't seem to be enough to get it to start looking at LDAP. Here are the results (with paths, usernames, and passwords changed):

(The following commands happen to be Windows Command Prompt, but I imagine something similar is doable on Linux. The sqlplus seen here is the Instant version as well, with accompanying Instant Client binaries in the same directory.)

C:\TEMP>SET TNS_ADMIN=C:\path\to\sqlnet\ldap\and\tnsnames\ora\files

C:\TEMP>echo %TNS_ADMIN%
C:\path\to\sqlnet\ldap\and\tnsnames\ora\files

C:\TEMP>sqlplus.exe USERNAME/PASSWORD@LOCALTNSNAME

SQL*Plus: Release 11.2.0.2.0 Production on Mon Jul 7 10:22:25 2014

Copyright (c) 1982, 2010, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options

SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Produ
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options

C:\TEMP>sqlplus.exe USERNAME/PASSWORD@LDAPTNSNAME

SQL*Plus: Release 11.2.0.2.0 Production on Mon Jul 7 10:24:21 2014

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

ERROR:
ORA-12154: TNS:could not resolve the connect identifier specified

Side note

Are there tags for TNS, LDAP, or Instant Client (or even just normal Oracle Client) that could be added to this question? I couldn't locate any.

  • Is it the correct executable? "where sqlplus" – Bjarte Brandt Jul 7 '14 at 19:25
  • @BjarteBrandt Yes, it is the one I expect it to be when I run where (C:\TEMP\sqlplus.exe). To be more specific, sqlplus is not "installed" on the machine. It's just sitting in the current directory, with the client binaries beside it. It's definitely picking up on the tnsnames.ora file using the TNS_ADMIN environment variable, since that is off in a completely different directory. – jpmc26 Jul 7 '14 at 19:26
  • @BjarteBrandt To confirm it's using the right client binaries, I went ahead and ran where oci.dll, too. It also gives the expected result: C:\TEMP\oci.dll. – jpmc26 Jul 7 '14 at 19:30
  • could be a domain issue. Did you also try with FQ name? (dbname_or_whatever.domainname) – ik_zelf Jul 7 '14 at 20:41
  • 2
    @ora-600 Sorry, I forgot about this question. It turned out to be problems with the config files themselves, which were provided to us by our client. (Possibly the Kerberos config file; I can't recall off-hand.) What's funny is that I was working in a dev environment trying to do this, it was equally problematic to get it working in staging, and it still isn't working in prod as far as I know. (We ended up using a local TNS name to get the app working.) Definitely wasted money for the project; even if/when it works in prod, the return on investment would be miniscule compared to the cost. – jpmc26 Dec 22 '14 at 16:55
0

Place the sqlnet.ora and ldap.ora files in your $ORACLE_ADMIN directory and make sure to set the environment variables. I made mine the TNS_ADMIN directory

(Linux) my .bashrc

export TNS_ADMIN=/opt/oracle/instantclient_12_1/network/admin
export ORACLE_ADMIN=${TNS_ADMIN}

[ku14lts:/opt/oracle/instantclient_12_1/network/admin]
$ ls
ldap.ora  sqlnet.ora  tnsnames.ora

And I was able to connect to a DB not in my tnsnames.ora

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.