Appendix D - LDAP Glossary

Term Explanation

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

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

Attribute The data in an entry is contained in attribute-value pairs (a.k.a. AVA). Each attribute has a name (and sometimes a short form of the name) and belongs to (is contained in) one or more objectClass(es). The attributes characteristics are fully described by an ASN.1 definition. One or more Attributes may be included in a Schema. Depending on the attribute's ASN.1 definition there can be one (SINGLE-VALUE) or more than 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 are categorised as either user (userApplication) or operational (dSAOperation).

authenticated A session is described as authenticated if a user DN and secret is supplied when initiating the session (sending the bind primitive).

AUXILIARY Any number of AUXILIARY objectClasses can be present in (or subsequently 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. Attribute-name=attribute value, for example, cn=joe is an AVA.

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.

bind 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 by 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=com

More 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. Entries may be of three types; an object entry (the most common entry type) consisting of user data contained in attributes within objectClasses; an alias entry having the objectClass alias with the single attribute aliasedObjectName; a subentry which is used to store administrative or operational data related (in some way) to its parent entry. The data content of an entry consists of one or more attributes one (or more) of which is (are) used as the naming attribute (more correctly the RDN) to uniquely identify the entry 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 = 2.5.13.2) 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.

naming attribute

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:

1. For each attribute whether it is mandatory (MUST) or optional (MAY)
2. The hierarchy of object classes and hence its inheritance (using the SUP property
3. Whether is it is a STRUCTURAL (it can create an entry) or AUXILIARY (cannot create an entry).

Each objectclass is uniquely identified by an OID. (MORE info on objectClass.)

OID An Object IDentifier (OID) is a dot-separated valued e.g. 2.5.6.2 (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) by default though most LDAP servers offer configuration features to change these default port numbers.

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 ( 2.5.4.3 NAME ( 'cn' 'commonName' ) SUP name )

In the above example cn is the primary name of this attribute.

Principal DN

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 anonymous 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:

1. search scope: may be base in which case only the supplied DN is used, one in which case the search descends one level from the supplied DN or sub in which case descends the hierarchy from the DN to the lowest level in the tree (DIT).
2. name scope: occasionally used when mutiple DITs are present in a single server. The name scope in this context is given by the DIT root (a.k.a. base or suffix), for instance, a dn ending with dc=example, dc=net would be within one name scope whereas a dn ending with dc=example, dc=com would be within a different name scope.

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.

session A session occurs between a LDAP client and a server when the client sends a bind command. A session may be either anonymous or authenticated.

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.

STRUCTURAL

ObjectClasses may be STRUCTURAL or AUXILIARY. One (and only one) STRUCTURAL objectClass must be used to create an entry. A STRUCTURAL objectClass will contain one or more attributes.

subentry subEntries are used to provide administrative or operational information. They are defined in RFC 3672 (and referenced in RFC 4512 and RFC 4533). An example of a subentry is cn=subschema (which appears in the rootDSE in the attribute subSchemaSubentry) and contains the collections of attributes, matching rules, ojectClasses and LDAP syntaxes supported by the LDAP server. More information about subEntry.

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.

subSchema subSchema is a subentry of the rootDSE of LDAP version 3 compliant LDAP servers. It is defined using the base DN cn=subschema (typically though the actual subentry name may be discovered by interrogating the rootDSE attribute subschemaSubentry) and contains the collections of objectClasses, LDAP syntaxes, matching rules and attributes supported by the LDAP server.

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.

subtype

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.

Copyright © 1994 - 2025 ZyTrax, Inc.
All rights reserved. Legal and Privacy site by zytrax
hosted by javapipe.com
Page modified: January 20 2022.