mail this page
products | company | support | training | contact us
The glossary gives a quick definition or a term and may contain a link to further information either on this site or off-site.
A session is described as anonymous if neither a DN nor a password (credentials) is supplied when initiating the session (sending the bind). LDAP defines a state called unauthorized in which a DN is supplied with the bind but no password. The net effect of such a bind in OpenLDAP is to create an anonymous session.
The ITU-T's Abstract Syntax Notation One (X.208/X.680 series). A language for describing and encoding rules for data representation. ASN.1 is used to encode protocol data units (PDUs a.k.a messages, blocks or frames) using a variety of encoding systems including BER (Basic Encoding Rules X.690), CER (Canonical Encoding Rules), DER (Distinguished Encoding Rules), XER (XML Encoding Rules) and PER (Packed Encoding Rules X.691). In the case of LDAP only the simpler BER is used rather than the stupifyingly complicated PER. ASN.1 OIDs described. ASN.1 SYNTAX overview.
The data in an entry is contained in attribute-value pairs. Each attribute has a name (and sometimes a short form of the name) and belongs to (in contained in) one or more objectClass(es). The attributes characteristics are fully described by an ASN.1 definition. One or more objectClasses may be included in a Schema. Depending on the ASN.1 definition of the attribute there can be one (SINGLE-VALUE) or more that one (default) attribute-value pair of the same named attribute in an entry. One (or more) attribute(s), the naming attribute or RDN, will always uniquely identify an entry. Attributes may be categorised as either user (userApplication) or operational (dSAOperation).
Any number of AUXILIARY objectClasses can be present in (or added to) a DIT entry. An AUXILIARY objectClass cannot create an entry, instead, one (and only one) STRUCTURAL objectClass must be used to create the entry. An AUXILIARY objectClass will contain one or more attributes.
|AVA||Attribute Value Assertion.|
|Base||The base entry (a.k.a root and suffix) is one of many terms commonly used to describe the topmost entry in a DIT or naming-context. The term base seems to be used because the search scope base in a LDAP URL or other search typically uses this value. The Root DSE is the highest level in an LDAP enabled directory. Base Naming.|
|BER||Basic Encoding Rules an ITU-T binary format (defined in X.690) for formating ASN.1 fields for transmission within a protocol. In a number of cases, notably search filters, LDAP uses strings rather than binary (BER) encodings.|
When connection is made to an LDAP server the first operation of the sequence is called a bind. The bind operation sends the dn of the entry that will be used for authentication and the password (usually contained in the userPassword attribute) to be used. In the case of an anonymous bind both values will be NULL. A Bind operation does not allow searching and therefore the DN used for authentication must be the same as the DN which initially created the entry. More information on this topic.
|Chaining||When a Referral ObjectClass is encountered by an LDAP server during a search operation it may be returned as a Referral to the requesting client or the Server may be configured to follow the referral using a process known as chaining through use of the overlay chain directive. By default OpenLDAP returns referrals but may be configured to implement chaining with consequent performance overheads. For more information.|
|Client||Client a.k.a LDAP Client describes software that provides access to an LDAP sever. Most standard web browsers (MSIE and Gecko) provide limited LDAP client capabilities using LDAP URLs. LDAP browsers and web interfaces are both very common examples of LDAP clients. List of Open Source LDAP Clients. In some cases, such as during mutual authentication, an LDAP server will act temporarily as an LDAP client.|
|cn (commonName)||cn (alias commonName) is one of the most commonly used attributes. Its ASN.1 definition contains no helpful hints as to usage so it is widely used as the attribute to name some "thing" or real-world entity (most of the other name attributes reflect DAP/LDAP's original personal directory objective, for example, sn(surname) or gn (givenName)). cn is one of a handful of attributes that are part of a hierarchy, in this case the SUP attribute is name.|
|Component Matching||Component Matching (RFC 3687) provides both an alternative (but longer) search filter syntax for simple attributes and a method by which components (parts or instances) of compound attributes may be extracted and searched. More Information.|
|contextCSN||The Change Sequence Number (CSN) of the context (the highest entryCSN used in the context or synchronization search scope). CSNs (both entryCSN and contextCSN) are extensively used in OpenLDAP syncrepl style replication operations. The contextCSN is included in the SyncCookie. CSNs appear to be only defined in an expired RFC draft draft-chu-ldap-csn-xx.txt and for version 2.4 in this FAQ to consist of a timestamp - including microseconds, an operation-within-second counter (6 octets), a 3 octet replica id (as defined by ServerID) and a 6 octet counte-within-modify operation.|
|consumer||Describes a server which uses (consumes) a service which is supplied by a provider server. An example of a consumer is an RFC 4533 Sync Client used in replication.|
|CSN||The Change Sequence Number (CSN) used OpenLDAP to identify changes in a replicated configuration. CSNs appear to be only defined in an expired RFC draft draft-chu-ldap-csn-xx.txt and for version 2.4 in this FAQ to consist of a timestamp - including microseconds, an operation-within-second counter (6 octets), a 3 octet replica id (as defined by ServerID) and a 6 octet counte-within-modify operation.|
|DAP||Directory Access Protocol. X.500 term for an OSI based network protocol that enables access to a DSA and which implies the directory data model.|
|DIT||The Directory Information Tree (a.k.a the naming-context. The DIT is the hierarchy of objects that make up the local directory structure. More than one DIT may be supported by an LDAP server. The Root DSE will provide this information. Further Information|
|DN||The Distinguished Name. A DN is comprised of a series of RDNs that uniquely describe the naming attributes on the path UP the DIT from the required entry to the directory root. A DN is written LEFT to RIGHT and looks something like this:
DN: uid=bill,ou=people,dc=smokeyjoe,dc=comMore info.
|DSA||Directory System Agent. X.500 term for any DAP or LDAP enabled directory service e.g. an LDAP server.|
|DSE||DSA Specific Entry (DSE). A control entry in a local directory server.|
|entry||The name given to a stored object in a LDAP enabled directory. Each entry has one parent entry (except for the DIT root, suffix or base)) and zero or more child entries (objects). An entry must comprise one (and only one) STRUCTURAL objectClass but may contain any number of AUXILIARY objectclasses. The data content of an entry consist of one or more attributes one (or more) of which is (are) used as the naming attribute (more correctly the RDN) to uniquely identify this object in the DIT.|
|entryCSN||The Change Sequence Number (CSN) of the entry. CSNs (both entryCSN and contextCSN) are extensively used in OpenLDAP syncrepl style replication operations. CSNs appear to be only defined in an expired RFC draft draft-chu-ldap-csn-xx.txt and for version 2.4 in this FAQ to consist of a timestamp - including microseconds, an operation-within-second counter (6 octets), a 3 octet replica id (as defined by ServerID) and a 6 octet counte-within-modify operation.|
|entryUUID||An attribute containing the Universally Unique ID (UUID) of a DIT entry. Servers are now mandated to create an entryUUID attribute when adding new entries to any DIT. The UUID is defined in RFC 4122 and the LDAP implementation and syntax of entryUUID in RFC 4530. The RFC defines both the entryUUID syntax together with uuidMatch and uuidOrderingMatch matching rules.|
|EQUALITY||EQUALITY defines the comparison rule of an attribute when used in a search filter which contains NO wildcards both contents and length must be exactly the same. When wildcards are used this is called a substring and the SUBSTR rule is used. Attribute definition.|
|filter||An LDAP search is carried out by defining a base DN, a scope and a search filter.|
|LDAP||Lightweight Directory Access Protocol. IETF term for an TCP/IP based network protocol that enables access to a DSA. Some reduced functionality from X.500 DAP specification.|
|LDIF||LDAP Data Interchange Format. IETF term for a textual format for loading (importing) and saving (exporting) entries into a LDAP enables directory. LDIF is defined by RFC 2849.|
|matchingRule||The method by which an attribute is compared in a search operation. A matchingRule is an ASN.1 definition which contains an OID (usually) a name e.g. caseIgnoreMatch (OID = 184.108.40.206) and the data type it operates on e.g. DirectoryString. More Information.|
|name space||Term used to describe all DNs that lie in (or are contained within or bounded by) a given DIT, that is, if the DIT root is dc=example,dc=com then cn=people,dc=example,dc=com is said to lie in the name space but ou=people,dc=example,dc=net does not - it lies in the dc=example,dc=net name space.|
One attribute, the naming attribute (a.k.a RDN) is used to uniquely identify each entry in the DIT. The sum of all naming attributes (a.k.a RDN) that define the path to an entry within a DIT is called the DN.
|naming context||a.k.a namingContexts or DIT defines a unique name space starting from (and including) the root/suffix DN. The naming contexts supported by an LDAP server are defined in the operational attribute namingContexts of the rootDSE.|
|objectClass||Object Classes are collections of attributes. They define:
|OID||An Object IDentifier (OID) is a dot-separated valued e.g. 220.127.116.11 (OID of country objectclass) that uniquely defines an object and who is responsible for its definition. OIDs used in LDAP.|
|Operational||Operational Objects are used by the LDAP server to provide informational about the server or to control how the server behaves. They live under the Root DSE) and can be interrogated to yield the secrets of the known universe. Operational attributes, such as entryCSN are used by the LDAP server to control processing. They cannot be created or modified by the end user. Operational attributes may read by using the value + in the required attribute section of a search expression.|
|ORDERING||ORDERING defines the comparison rule of an attribute when used in a search filter which contains >= or <= operators. Attribute definition.|
|Organizational Unit||organizationalUnit (ou) defines an arbitrary organisational unit and can be used at multiple levels in the hierarchy. Its value will typically be relevant in the context in which it is used. Thus, in the context of defining an ITU format root name (ou,c format) it will likely be the name of the company or organisation (or even organization), in the context of a lower level in the hierarchy it may be 'people' or or 'manufacturing' or 'usa' or 'usa-manufacturing' or anything else that makes sense and requires the attributes defined by the object.|
|Ports||LDAP uses the TCP/IP protcol and connects to port 389 (ldap) for non-ssl access and 636 when using SSL (ldaps).|
|primary||The primary name is the first name that appears in an attributetype definition. The primary name MUST be used when indexing an attribute using the olcIndex/index attribute/directive in cn=config/slapd.conf. Example:
attributetype ( 18.104.22.168 NAME ( 'cn' 'commonName' ) SUP name )In the above example cn is the primary name of this attribute.
When an entry is created (added) to a DIT it is assigned an initial DN using the LDIF (or LDAP client). This 'creation' DN has no special terminolgy assigned by the standards. If the entry will be used for authentication then the creation DN must be the same as that used in the Bind DN. When used in this manner the creation DN is sometimes called the Principal DN especially in the context of Microsoft's AD. Further info on this topic.
|provider||Describes a server which provides a service which is consumed (or used) by one or more other server or clients. An example of a provider is an RFC 4533 Sync Server used in replication. The more cynical would suggest that provider = master, consumer = slave, the more nuanced will spend hours describing the difference.|
|RDN||The Relative Distinguished Name (frequently but incorrectly written as Relatively Distinguished Name). The name given to an attribute(s) that is unique at its level in the hierarchy. RDNs may be single valued or multi-valued in which case two or more attributes are combined using '+' (plus) to create the RDN e.g. cn+uid. The term RDN is only meaningful when used as part of a DN to uniquely describe the attributes on the path UP the DIT from a selected entry (or search start location) to the directory root (or more correctly the Root DSE). More info.|
|referral||A referral is where the LDAP server returns to an LDAP Client the name of (typically a LDAP URL) another LDAP server which may, or does, contain the requested information. Configuring Referrals. LDAP Servers may be configured to automatically follow referrals using a process known as chaining.|
|root||The root entry (a.k.a base, suffix) is one of many terms used to describe the topmost entry in a DIT. The Root DSE is a kinda super root. Root Naming.|
|olcRootDn/rootdn||olcRootDn/rootdn is a confusingly named attribute/directive which defines the DN of the superuser for each DIT which can bypass normal directory access rules (ACLs). The olcRootDn/rootdn does not need to appear in the directory, or even be related, in any way, to the DIT structure (the exception to this rule is for the OLC (cn=config) DIT where the olcRootDn must lie under cn=config, for example, cn=admin, cn=config).|
|Root DSE||Conceptually the topmost entry in a LDAP hierarchy - think of it as a super root and normally invisible i.e. not accessed in normal operations. Sometimes confused with root or base or suffix. DSE stands for DSA Specific Entry and DSA in turn stands for Directory System Agent (any directory enabled service providing DAP or LDAP access). Information about the rootDSE may be obtained in OpenLDAP by querying the OpenLDAProotDSE classobject or to any LDAP server (including OpenLDAP) by issuing an anonynmous bind with an empty base DN ("") and will provide information about protocol versions supported, services supported and the naming-context(s) ( or DIT(s)) supported.|
|scope||Used in two senses:
|Schema||A package of attributes and objectclasses definitions, written in ASN.1, that are sometimes (nominally) related. The schema(s), in which the object classes and attributes that the LDAP application (DIT(s)) will use ( or reference), are identified to the LDAP server so that it can read and parse all that wonderful ASN.1 stuff. In OpenLDAP schemas are defined under cn=config, cn=schema (for OLC) or using the include directive in the slapd.conf file.|
|search||An LDAP search is carried out by defining a base DN, a scope and a search filter.|
|slapd||slapd is the name of the daemon (task) that runs the OpenLDAP service. slapd provides the local LDAP service and is configured either using OLC (cn=config) or the slapd.conf file.|
|slapd.conf||slapd.conf is a static configuration file used by slapd and, where configured, slurpd. OpenLDAP version 2.3+ introduced an alternative, run-time configuration capability (slapd.d (cn=config) or OLC.|
|slurpd||slurpd was (prior to OpenLDAP 2.4) a daemon that provided the LDAP replication service and was configured using the slapd.conf and ldap.conf files. More information on Replication. slurpd style replication was obsoleted in OpenLDAP version 2.4+ and replaced with syncreply style replication.|
|subordinate||OpenLDAP documentation uses the term subordinate database (DIT) to define a DIT which is referenced in a referral object. Since referral objects delegate the search for the remaining part of the DN to the referred DIT they may be viewed as a hierarchy and the referred DIT as subordinate in that hierarchy. Unfortunately OpenLDAP also uses the term superior whose definition is much more dubious. Configuration and use of Referrals.|
|SUBSTR||SUBSTR defines the comparison rule of an attribute when used in a search filter which contains one or more wildcards. When there are no wildcards in the search expression (filter) the EQUALITY rule is used. Attribute definition.|
|substring||substring refers to any string values used in a search filter which contains wildcards. The form of the comparison, for instance, case sensitive or case insensitive is defined by the SUBSTR rule in the attribute definition.|
LDAPv3 defines a number of subtypes. At this time two have been defined binary (in RFC 2251) and lang (in RFC 2596). subtypes may be used when referencing an attribute and qualify the search, for example, cn;lang-en-us=smith would perform a search using US english. The subtype does not affect the encoding since UTF-8 (used for cn) allows for all language types. lang subtypes are case insensitive.
|suffix||suffix (a.k.a root, base) is one of many terms used to describe the topmost entry in a DIT. The term is typically used because this entry is usually defined by the olcSuffix/suffix attribute/directive. The Root DSE is a kinda super suffix. Suffix Naming.|
|superior||OpenLDAP documentation uses the term superior database (DIT) to define a DIT from which another DIT is referenced in a referral object. Since referral objects delegate the search for the remaining part of the DN to the referred DIT they may be viewed as a hierarchy and the DIT which contains the referral is superior to the referred DIT. A DIT which is the destination of a referral is known as subordinate. Configuration and use of Referrals. SUPerior is also used in the context of attribute and objectclass hierarchies.|
|supportedExtension||The LDAP specifications (RFCs) allow for optional capabilities and extensions. If an LDAP server supports a particular extension its OID will be published in the rootDSE. RFC3674 defines the attribute supportedFeatures in the rootDSE which will yield a list of supported features and extensions.|
|SyncCookie||A cookie sent by a provider to a consumer during sysncrepl style replication. Detail and configuration of Replication.|
|syncrepl||A method of Replication based on the LDAP Content Synchronization protocol (RFC 4533) and released in OpenLDAP version 2.2. From OpenLDAP version 2.4 all other replication methods are obsoleted. Named from the olcSyncrepl/syncrepl configuration attribute/directive. More information about Replication.|
|types||types (a.k.a. data types) is commonly used to refer to the ASN.1 SYNTAX of an attribute. LDAP Data types.|
|unauthorized||A session is described as unauthorized if a DN is supplied without a password (credentials) when initiating the session (sending a bind). The net effect of such a bind in OpenLDAP (it must be explicity permitted with a olcAllow/allow bind_anon_dn) is to create an anonymous session.|
Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.
3 ldap objects
4 install ldap
7 replica & refer
10 ldap api
14 ldap tools
notes & info
rfc's & x.500
This work is licensed under a Creative Commons License.
If you are happy it's OK - but your browser is giving a less than optimal experience on our site. You could, at no charge, upgrade to a W3C STANDARDS COMPLIANT browser such as Firefox