Introduction
The Lightweight Directory Access Protocol (LDAP) is, essentially, a database (it used to be the protocol needed to talk to a database, but it’s long-since become the name of the database itself). You can store all sorts of data in it -personnel details, perhaps, including usernames and passwords; records of each PC or server you own, complete with its hostname, IP address, and so on; or (here’s the point of this particular article!) details about what Oracle databases run on which servers.
The particular implementation of LDAP I’m going to concern myself with here is OpenLDAP. It’s open source, supplied with virtually every Linux distro in existence, and is completely and forever free of charge. It’s also quite lightweight in terms of server resources needed to run it: mine runs on a server with just 128MB RAM which is already running Apache, Bind and DHCP!
The generic name for what we’ll use this OpenLDAP server for is Oracle tnsnames resolution. You want to connect to a database called “sales”… what server is that on? What IP address? What port do we go via? The idea is that you get your Oracle client software to look those details up in an LDAP database and use the answers found to connect you automatically. Traditionally, we do tnsnames resolution using a text file stored on the client PC itself, called tnsnames.ora… but if you’ve got dozens of users connecting from different PCs, or a frequently-changing list of which databases to connect to, modifying each of those tnsnames.ora individually is a pain. Life becomes a lot easier if everyone consults a single store of tnsnames details. You make the changes to that one, central store… and all users automatically pick up on the changes.
There is an official Oracle product to do this, available for no additional licensing fees, called Oracle Internet Directory (or OID for short). OID is part of a much bigger and more complex “identity management” application, and if you use it for anything other than the simple lookup of what database runs on which server, it does cost a lot. It’s also not at present certified to run on Red Hat Enterprise Linux 6 (only RHEL 4.x and 5.x). That’s not to say there’s anything particularly wrong with OID …just that it’s a bit of sledgehammer to crack a tnsnames lookup nut.
This article will therefore explain how to configure OpenLDAP to act as a zero-cost, single, centralised source of tnsnames resolution in your Oracle database environment. It describes setting up OpenLDAP on Scientific Linux 5.7 and Centos 6.2. Of course, those are both clones of Red Hat Enterprise Linux (RHEL), so these instructions are generically true for any RHEL-ish 5.x and 6.x Linux distro.
You should know that OpenLDAP’s implementation changed dramatically between the 5.x and 6.x release of Red Hat and its clones -but for this article, I’ve simply made the earlier 5.x configuration work on the 6.x platform using backward compatibility features. I haven’t attempted, therefore, to use the ‘native’ way of doing things in RHEL 6.x. All commands work for both versions, unless specifically stated otherwise -at which point, version-specific options will be described.
What follows is done entirely as the root user, unless otherwise indicated. It assumes that you have built your LDAP server using the ‘installing Linux over the Network’ technique I have documented elsewhere -and, specifically, that you have used my rh5.cfg or rh6.cfg Kickstart configuration files during the installation.
The article will fall into three main parts:
- Installation and basic configuration of OpenLDAP
- Configuration of an Oracle Internet Directory capability for OpenLDAP
- Management of OpenLDAP via graphical tools
You can try Apache Directory Studio [1]. Probably overkill for what you’re doing, but very good nonetheless.
[1] http://directory.apache.org/studio/
Thanks for the suggestion Georger. (In case anyone else is wondering what he’s encouraging me to try, Apache Directory Studio is another GUI LDAP browser that integrates nicely into the Eclipse IDE). I did look at it before writing the article and if you were a full-on developer, it’s pretty obviously the way you’d choose to go. But if you just want to browse the LDAP hierarchy and add a new key here and there, I think Georger’s assessment is right: ADS is complete overkill. For basic browsing and the occasional ‘new’, a lot of these tools look and feel much the same, but Jxplorer had the advantages (for me) of being nicely cross-platform and just a 4MB download.
Always good that alternatives get a mention, though, that’s for sure. I’ll edit the article to make a mention of it directly, how’s that?
Hi,
That would be great. Anyone who’s using some LDAP other than Active Directory would benefit from knowing about Apache Directory Studio.
Hi,
After configuration, windows clients are able to connect. However Linux oracle clients do not resolve. This is probably due to OID specific LDAP components.
e.g. ldapsearch -h -x -b “dc=xxxx,dc=xxxx,dc=com”
returns error as the syntax is incorrect.
Following error in the trace file
nnflilc: Opening sync conn to serv1.xxxx.xxxx.com:389
nnflalc: entry
nnflalc: bind call returns 0
nnflalc: exit
nnflilc: exit
nnflrlc: exit
nnflobc: exit
nnflcgc: exit
nnflboot: exit
nnflrne: entry
nnflcgc: entry
nnflcgc: exit
nnfln2x: entry
nnflgcp: entry
nnflgcp: exit
nnfln2x: exit
nnflrne: Quering the directory for dn: cn=rpqr,cn=OracleContext
nnflqbf: entry
nnflqbf: Search: Base: cn=rpqr,cn=OracleContext, Scope: 0, filter: (objectclass=*)
nnflqbf: Search: Attrs[0]: objectclass
nnflqbf: exit
nnflrne: exit
The ldapsearch is from ORACLE_HOME/bin
Update – Oracle instant client on linux works. However connecting from a full database installation doe not work.
Diz,
trying to ldapadd the oidbase.ldf..it loads but don’t see an entry for the Oracle Internel (typo?) Directory. get successful add with the comment that OracleContext:
heregoes:
ldapadd -c -x -D “cn=Manager,dc=ipacc,dc=com” -W -f oidbase.ldif
adding new entry “dc=ipacc,dc=com”
ldap_add: Already exists (68) (like u said)
adding new entry “cn=OracleContext,dc=ipacc,dc=com”
Da seach:
ldapsearch -x -b “dc=ipacc,dc=com” ‘(objectclass=*)’
# LDAPv3
# base with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# ipacc.com
dn: dc=ipacc,dc=com
objectClass: dcObject
objectClass: organization
o: yumrepos LDAP Server
dc: ipacc
# Manager, ipacc.com
dn: cn=Manager,dc=ipacc,dc=com
objectClass: organizationalRole
cn: Manager
# OracleContext, ipacc.com
dn: cn=OracleContext,dc=ipacc,dc=com
objectClass: orclContext
cn: OracleContext
<< I would have expected to see the contents of the oidbase.ldif loaded.
Da ldif file:
dn: dc=ipacc,dc=com |
objectClass: top |
objectClass: dcObject | < what I would expect to see in the ldapsearch
objectClass: organization |
o: Oracle Internet Directory |
dc: ipacc |
dn: cn=OracleContext,dc=ipacc,dc=com
objectclass: orclContext
cn: OracleContext
slapd.conf has the includes so I know it sees 'em. Looks like a collision on the dn
to me…any ideas??
Hey Diz,
Really think it is the ldif for oidbase. I can get a ‘thin’ connection to the db using
ldap e.g. sqlplus blah/blah@”cn=d_db,cn=OracleContext,dc=ipacc,dc=com”
this connects but will not tnsping (b/t/w I am on OEL 6).
Thnks!