Using OpenLDAP for Net Service Name Resolution

OID is Oracle’s official solution

Several years ago, I was struggling with a solution to managing hundreds of net service names across several dozen database servers and many hundreds of Oracle client machines.  At the time, Oracle had just discontinued ONAMES (which I never had an opportunity to use), and the “official” Oracle solution was the OIM/OID software suite.  Well, after weeks of struggling with OID, I decided it was an unwieldy beast, and was just plain painful to set up.  (I don’t think I ever did get it completely working.)  Just as things were looking down, I spotted a bit of sunlight, through the fog.


After much thrashing about with Oracle’s OID, I discovered a very cool little program, called tnsManager.  tnsManager is a scaled-down, highly specialized LDAP server, whose sole purpose in life is to serve up net service names.  tnsManager, written by Andrew Barry of, was an absolute godsend.  It was lightweight, extremely simple to set up, and supported replication.  It offered (almost) everything I wanted in terms of a solution for net service name resolution.  On the downside, to my knowledge, Mr. Barry only ever released tnsManager as a binary, available on Windows, Linux, and Solaris.  As it turns out, the Linux version, which I was interested in, was extremely stable and reliable.  I have been running tnsManager, in production, on a tnsnames.ora file that has around 250 entries, since around 2008.  It has never failed, and never given me any problems whatsoever.  So, why mess with it?  Well, I wouldn’t have, except that Mr. Barry seems to have fallen off the face of the earth.  Emails to his last known email address don’t bounce, but have not been returned.  Also, his website, is still online, but all content has been wiped.  So, on one hand, I have a program that has proven itself a winner, with over 5 years of continuous service.  On the other hand, my entire enterprise is reliant on a piece of software, for which I have no source code, and which the author seems to have abandoned.  So, I decided a pragmatic approach was appropriate here.  I’m continuing to run the very reliable tnsManager in production.  However, at the same time, I’ve started down the path of finding a replacement.  This quickly lead me to OpenLDAP, as a free, open source solution, which others have proven works well with Oracle.

Implementing OpenLDAP

With just a bit of searching with my favorite search engine, I discovered an excellent blog post by Howard Rogers.  Howard did an excellent job demonstrating a very quick and easy setup to get OpenLDAP up and running for net service name resolution.  By following the steps in Howard’s blog post, I had OpenLDAP installed, configured, and running in less than an hour.  I have to give kudos to Howard, for documenting a simple, straightforward procedure.  However, there are a couple of features that are not implemented or configured in Howard’s basic setup.  Specifically, aliases and replication are not touched upon.  Both of these features were supported in tnsManager, so, I’m quite interested in getting them working with OpenLDAP.


Net service names aliases are quite straightforward, in that they simply allow for multiple aliases for the same net service name.  An example of a tnsnames.ora entry that demonstrates a net service name would be:

mydb,myalias,myalias2 = (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=myhost)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=myservice)))

In the above tnsnames.ora entry, the net service name is ‘mydb’, and ‘myalias’ and ‘myalias2’ are both aliases.  All three strings will resolve to the same connect string.  After a bit more searching, I ran across Ronny Egner’s blog, which showed how to implement aliases in OpenLDAP.  More on this just a bit later.


The other thing that my initial OpenLDAP configuration didn’t support was replication.  This is a feature that is used in my current setup with tnsManager, so, if I was planning to replace tnsManager, getting replication up and running was important to me.  After doing a bit of reading, I learned that OpenLDAP supports different types of replication, including multi-master and master/slave.  With a bit of research and experimentation, I was able to configure simple master/slave replication, using the OpenLDAP documentation.

DNS Autodiscovery

Finally, it would be desirable to be able to use DNS autodiscovery.  If you’re not familiar with DNS autodiscovery, it’s a method by which one does not provide an ldap.ora file, and instead, the Oracle Client code can discover the location of the LDAP server.  Very briefly, the way it works is, the DNS administrator creates a service record (type SRV) in DNS, which points to the LDAP server.  Then, the client will query the rootOracleContext for the defaultSubscriber, which it will use to set the DEFAULT_SEARCH_DOMAIN since there is no ldap.ora file.  For a detailed explanation, see MOS Doc ID 1363773.1.

Next Steps – Installation and Configuration

In my next post, I’ll get into the specifics of installing and configuring OpenLDAP for Net Service Name resolution.  Stay tuned for part 2, OpenLDAP Installation and Configuration.

13 comments on “Using OpenLDAP for Net Service Name Resolution

  1. […] If you missed it, there were two previous parts to this series of blog posts.  You can start reading part 1 here. […]

  2. […] This is part 2 of a multi-part blog post on using OpenLDAP for Net Service Name Resolution.  Part 1 can be found here. […]

  3. […] This is part 4 of a multi-part blog post on using OpenLDAP for Net Service Name Resolution.  Part 1 can be found here. […]

  4. […] This is part 5 of a multi-part blog post on using OpenLDAP for Net Service Name Resolution.  Part 1 can be found here. […]

  5. […] This is the final part of a multi-part blog post on using OpenLDAP for Net Service Name Resolution.  Part 1 can be found here. […]

  6. […] now that I have OpenLDAP working for Oracle Net Service Name resolution, my next little adventure will be exploring the possibilities of zero downtime upgrades for Oracle […]

  7. Fd Habash says:

    Hi Mark, I asked you yesterday about using LDAP with JDBC thin client & it looks like there is a way to make it work. Please check out this reference

    Here’s an excerpt ….
    LDAP Syntax
    An example of database specifier using the Lightweight Directory Access Protocol (LDAP) syntax is as follows:
    When using SSL, change this to:
    The JDBC Thin driver can use LDAP over SSL to communicate with Oracle Internet Directory if you substitute ldaps: for ldap: in the database specifier. The LDAP server must be configured to use SSL. If it is not, then the connection attempt will hang.

  8. mbobak says:

    That’s brilliant! And Awesome! I had no idea this was possible! Way cool! Thanks so much for that tip!

  9. Fd Habash says:

    My pleasure.
    This why we like we we do, the ‘constant state of wanting to know’.

  10. Hi, Mark.
    You can reach an actual or retired version of using local hosts file.
    Here is the history of the ip addresses of the domain. The oldest one is
    So using local hosts file with a record
    you can take a look on old site.

  11. Two of the documents linked to in this very useful post have moved.

    “With just a bit of searching with my favorite search engine, I discovered an excellent blog post by Howard Rogers.”

    The document linked to by “excellent blog post” has moved to (with a short version at

    The document linked to by “Howard Rogers” has moved to “”.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s