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 -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.

  • Does the bindDN always correspond to a node in the directory? Or can it be an arbitrary string? – dirtside Jul 30 '14 at 18:51
  • Yes. It must correspond to a node that has the capability of carrying a password attribute or otherwise being authenticated against. – John Jul 31 '14 at 11:04
  • Tomayto, tomahto. 🍅 Username, bind DN. 🤷🏻‍♂️ – emallove Feb 13 at 18:00

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=com
  • dc=mydomain
  • dc=avery,dc=long,dc=list,dc=of,dc=domains

But, these root elements are indivisible. They look like they are several elements representing a path like the rest of the tree, but they are not. For instance, in the last example an object dc=of,dc=domains does not exist.

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: http://docs.oracle.com/cd/E19199-01/816-6400-10/lsearch.html

  • 7
    That seems like an unnecessarily confusing design, but your explanation does make sense. – dirtside Jul 30 '14 at 20:53
  • 1
    Yeah, I agree. Naming your root too look like a path is not the best choice but I guess it must have its reasons. Now you know why all the DNs end with a series of dc= components. =) – Marcelo Jul 30 '14 at 20:56

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.