Ldap what is dn

Here's an example using the ldapsearch command-line tool available from openldap. Ignore the lack of authentication. 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?

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.

The baseDN of a search is the starting point. Where it will start searching. Pretty self-explanatory. When using a bindDN it usually comes with a password associated with it. But these strings are NOT a "path" like the rest of the tree.

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. It it is NOT a path of elements. 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.

Sign up to join this community. The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group. An LDAP entry is a collection of information about an entity. Each entry consists of three primary components: a distinguished name, a collection of attributes, and a collection of object classes. Each of these is described in more detail below. Each RDN is comprised of one or more usually just one attribute-value pairs.

Attributes hold the data for an entry. Each attribute has an attribute type, zero or more attribute options, and a set of values that comprise the actual data. Attribute types are schema elements that specify how attributes should be treated by LDAP clients and servers.

All attribute types must have an object identifier OID and zero or more names that can be used to reference attributes of that type. They must also have an attribute syntax, which specifies the type of data that can be stored in attributes of that type, and a set of matching rules, which indicate how comparisons should be performed against values of attributes of that type.

Attribute types may also indicate whether an attribute is allowed to have multiple values in the same entry, and whether the attribute is intended for holding user data a user attribute or is used for the operation of the server an operational attribute.

Attribute options are not used all that often, but may be used to provide some metadata about an attribute. For example, attribute options may be used to provide different versions of a value in different languages. See Understanding LDAP Schema for more information on attribute types, syntaxes, matching rules, and other types of schema elements.

Object classes are schema elements that specify collections of attribute types that may be related to a particular type of object, process, or other entity.

Every entry has a structural object class, which indicates what kind of object an entry represents e. Like attribute types, object classes must have an object identifier, but they may also have zero or more names. An object identifier OID is a string that is used to uniquely identify various elements in the LDAP protocol, as well as in other areas throughout computing. OIDs consist of a sequence of numbers separated by periods e.

In the case of schema elements, there may also be user-friendly names that can be used in place of OIDs. Search filters are used to define criteria for identifying entries that contain certain kinds of information. There are a number of different types of search filters:. The logic used to perform the matching is encapsulated in matching rules, which are specified in attribute type definitions.

Different matching rules may use different logic for making the determination. For example, the caseIgnoreMatch matching rule will ignore differences in capitalization when comparing two strings, while the caseExactMatch matching rule will not.

Many matching rules are specific to certain data types e. All search requests include a base DN element, which specifies the portion of the DIT in which to look for matching entries, and a scope, which specifies how much of that subtree should be considered. The defined search scopes include:. LDAP clients may use a modify request to make changes to the data stored in an entry. A modify request specifies the DN of the entry to update and a list of the modifications to apply to that entry.

Each modification has a modification type, an attribute name, and an optional set of attribute values. An LDAP URL encapsulates a number of pieces of information that may be used to reference a directory server, a specific entry in a directory server, or search criteria to identify matching entries within a directory server. Collectives on Stack Overflow. Learn more. Asked 8 years, 5 months ago.

Active 1 year, 7 months ago. Viewed k times. Hello I'm trying to use my ldap test server in order to authenticate users in openca. Improve this question. Add a comment. Active Oldest Votes. I don't know about openca, but I will try this answer since you got very little traffic so far.

The ldap server will hash the password and compare with the stored hash value. If it matches, you're in. Things you have to look out for in your configuraiton file are : The dn your application will use to bind to the ldap server. This happens at application startup, before any user comes to authenticate.

The authentication method. It is usually a "simple bind".