Introduction
In 9iR1 (9.0.1) Oracle released the first version of DBMS_LDAP. Between then and 18c the package has received a few enhancements including support for BLOBs, Basic Encoding Rules (BER,) and NLS character set conversions.
The documentation for the package has alwasy been somewhat terse, especially if you’re unfamiliar with LDAP structures and usage.
I’ve had the need to muddle through a few times over the years, accumulating a hodgepodge of notes and code snippets to act as mnemonics. Herein and in following posts I will attempt to organize and expand on these notes to, hopefully, aid myself as well as others.
- Introduction (this page)
- Establishing a Connection
- Searching Hierarchical Data
- Browsing Attributes
- Timeouts
- Modifying Data
LDAP itself is merely the means of communicating with a directory server; however the structure of the communication is designed to reflect directory structure of the data storage (even if the server doesn’t actually use such a mechanism.)
That is, when reading or writing data you will need to observe the hierarchical structure of the directory. For example, from the LDAP RFC 4511:
A directory entry might be found at: “OU=People,DC=Example,DC=NET”
Similar to a network address, the path can be read backwards from least to most specific.
DC=NET (Domain Component = NET)
DC=Example (Domain Component = Example)
OU=People (Organizational Unit = People)
Thus, People are a group within the Example domain, which is itself a sub-domain within the NET domain.
The RFC doesn’t provide examples of specific people under this tree but does show an additional layer of organization under People with Organizational Units for Managers and Consultants. Adding a few people of our own, we might end up with a staffing directory structure that looks something like this where each person is assigned a unique user id (uid.)
DC=NET
DC=Example
OU=People
OU=Managers
uid=1234
uid=3456
OU=Consultants
uid=1987
uid=6543
Digging a little deeper individual people will likely have attributes. Thus fleshing out the directory tree to something like this:
DC=NET
DC=Example
OU=People
OU=Managers
uid=1234
CN=Jane Doe
hiredate=2005-04-03
email=jane.doe@example.net
department=Acquisitions
objectClass=person
uid=3456
CN=John Doe
hiredate=2006-05-04
email=john.doe@example.net
department=Sales
objectClass=person
OU=Consultants
uid=1987
CN=Mickey Mouse
hiredate=2005-12-11
email=mickey.mouse@example.net
department=Acquisitions
objectClass=person
uid=6543
CN=Donald Duck
hiredate=2008-07-06
email=donald.duck@example.net
department=Sales
objectClass=person
To find a particular user you would specify the full path to that user which is called a “distinguished name” or “dn”. In relational database land, we might refer to the distinguished name as the “primary key.”
So, Mickey Mouse would be identified in this hierarchy as:
uid=1987,ou=consultants,ou=people,dc=example,dc=net
Note, capitalization is not important within the hierarchy, so searches and dn references are case-insensitive.
Much like learning a new database schema, you might not know all of the tables and relationships right away. So, it may be necessary to talk to your LDAP server admin about the structure and hierarchy of elements you will need. You may also want to use a browsing tool. There are free and/or open source tools such as JXplorer, LDAP Admin, or Apache Directory Studio. If I used LDAP more extensively or had to administer a production system I might use other tools; but for my limited use JXplorer has been adequate. I like that I was able to use the same tool in Windows and Linux.
Hopefully this brief introduction helps explain how data within an LDAP tree is organized and how references to it can be made. In my next post I’ll show how connections are made anonymously, with authentication, and through SSL.