In LDAP, what exactly IS a bind DN?
I've written various pieces of code that connect to LDAP servers and run queries, but it's always been voodoo to me. One thing I don't really understand is the concept of a bind DN. Here's an example using the ldapsearch command-line tool available from openldap. (Ignore the lack of authentication.)
ldapsearch -h 1.2.3.4 -D dc=example,dc=com [query]
What is the purpose and function of the -D dc=example,dc=com part of this? Why do we need to bind to a particular location in the directory hierarchy? Is it to establish which part of the directory my queries should apply to? E.g. if the root node of the directory is dc=com, and it has two children (dc=foo and dc=bar), maybe I want my queries to be against the dc=foo,dc=com subtree and not the dc=bar,dc=com subtree?
A bind DN is an object that you bind to inside LDAP to give you permissions to do whatever you're trying to do. Some (many?) LDAP instances don't allow anonymous binds, or don't allow certain operations to be conducted with anonymous binds, so you must specify a bindDN to obtain an identity to perform that operation.
In a similar non-technical way - and yes this is a stretch - a bank will allow you to walk in and look at their interest rates without giving them any sort of ID, but in order to open an account or withdraw money, you have to have an identity they know about - that identity is the bindDN.
Do not get confused between the baseDN and the bindDN.
-
The baseDN of a search is the starting point. Where it will start searching. Pretty self-explanatory.
-
The bindDN DN is basically the credential you are using to authenticate against an LDAP.
When using a bindDN it usually comes with a password associated with it.
In other words when you specify a bindDN you are using that object security access to go through the LDAP tree.
Now, the string dc=example,dc=com is not the best example for a bindDN as it is a "domain" for an LDAP tree. dc stands for domain component and every LDAP tree defines its root with a string in the form of dc=string,dc=string,... But these strings are NOT a "path" like the rest of the tree.
Valid examples are:
dc=example,dc=comdc=mydomaindc=avery,dc=long,dc=list,dc=of,dc=domains
But, these root elements are indivisible. Although they look like they might be several elements representing a path like the rest of the tree, but they are not. (So for these elements the comma "," is NOT an element separator.)
So for the dc=avery,dc=long,dc=list,dc=of,dc=domains example this means that this is the entire element name. It it is NOT a path of elements. It can NOT be broken down into sub elements: There IS NO object dc=of,dc=domains.
To make an analogy to file system paths:
Imagine naming your C: drive like D:\my\folder\. Every path in there will look something like D:\my\folder\my\real\path which would be confusing as the real file path would be \my\real\path right? Well, that is the way the base (root) of an LDAP looks like, with a set of dc= elements.
Relevant link: Oracle documentation: "The ldapsearch Tool" http://docs.oracle.com/cd/E19199-01/816-6400-10/lsearch.html
Further Reading
- LDAP.com has a nice article: "DIT and the LDAP Root DSE" https://ldap.com/dit-and-the-ldap-root-dse/ (Archived here.) Quote: (emphasis added)
There is no standard that mandates any particular structure for LDAP DITs, so directory servers may hold entries in any kind of hierarchical arrangement. However, there are some common conventions. [...]
For example, if the organization has a domain of example.com, then the naming context would probably be something like dc=example,dc=com. It is perfectly legal for a naming context to have multiple components, so just because the server has an entry with a DN of dc=example,dc=com there does not necessarily have to be an entry with a DN of dc=com.