LDAP Entries and Attributes

What Are LDAP Entries and Attributes?

In LDAP (Lightweight Directory Access Protocol), the structure and management of directory data hinge on the precise definitions of entries and attributes. For developers integrating identity, authentication, or directory-backed applications, understanding these concepts is essential for creating, querying, and troubleshooting directory structures. At its core, an LDAP directory models data as a tree of entries, each uniquely identified and described through a set of typed attributes—all governed by a schema that defines and enforces integrity and meaning.

Consider the following LDIF example, which highlights the distinction:

dn: uid=jsmith,ou=users,dc=example,dc=com
objectClass: inetOrgPerson
cn: John Smith
sn: Smith
mail: jsmith@example.com

Here, the entry represents a directory object (a user), while 'cn', 'sn', and 'mail' are its attributes—properties defined by the directory schema.

LDAP Entry Structure: DN, RDN, ObjectClass, and Attributes

An LDAP entry is a concrete representation of a real-world object—like a user, a group, or a device—in the directory tree. This directory information tree (DIT) acts much like a filesystem hierarchy, where each entry is a node or leaf.

Distinguished Name (DN) and Relative Distinguished Name (RDN)

• Distinguished Name (DN): The DN uniquely identifies an entry in the entire directory. It is a string made up of a comma-separated list of attribute-value pairs, which trace the entry’s path in the directory hierarchy. In the example above, uid=jsmith,ou=users,dc=example,dc=com is the DN.
• Relative Distinguished Name (RDN): The RDN is the leftmost attribute-value pair in the DN. It uniquely identifies the entry relative to its immediate parent. In our example, uid=jsmith is the RDN.

ObjectClass: Blueprint for Structure

Each entry must have at least one objectClass attribute. Object classes define which attributes an entry can or must have, effectively enforcing the entry's structure and semantics. Object classes can inherit from others, leading to cumulative attribute sets. For instance, inetOrgPerson inherits from organizationalPerson and person.

Attributes

Attributes are sets of typed key-value pairs associated with an entry, such as cn (common name), sn (surname), or mail. Every entry has at least the objectClass attribute, plus all required attributes mandated by its object classes.

The directory hierarchy is then visualized as nodes (entries), each bearing a set of attributes, with the DN specifying their location.

Understanding LDAP Attributes: Types, Syntax, and Values

Attributes describe properties of an entry. Their types and values are governed by the directory's schema.

Attribute Types and Identification

Each attribute type is defined by:

• A unique Object Identifier (OID): Ensures global uniqueness, not just by name.
• One or more names: A human-readable identifier, potentially with aliases.
• Syntax: Specifies the permitted value format (e.g., Directory String, IA5 String, Integer).

For example, the cn (common name) attribute's definition includes its OID, syntax (Directory String), and potential matching rules.

Single-Valued vs Multi-Valued Attributes

Attribute types may be defined as single-valued (only one value permitted) or multi-valued (multiple values permitted). Many common attributes, like mail, allow multiple values to account for aliases.

Attribute Options and Language Tags

Attributes can include options, such as language tags. For instance, cn;lang-en and cn;lang-fr can store English and French names, respectively.

Common LDAP Attributes

(These and others are defined in RFC 4519.)

Operational vs User Attributes

Not all attributes serve the same functional role in an LDAP directory.

• User attributes: Primary information about the entry, usually editable by users or administrators (e.g., cn, mail, uid).
• Operational attributes: Maintained by the LDAP server for internal management and often read-only. These include metadata like creatorsName (who created the entry), createTimestamp, modifyTimestamp, and access control directives.

For integration and troubleshooting, it’s crucial to recognize that operational attributes generally cannot be modified by external users and may not be returned by default in queries unless specifically requested.

Mandatory and Optional Attributes: Enforced by Object Classes

Object classes not only group attributes—they also impose schema constraints:

• Mandatory (MUST) attributes: Required for any entry using the object class. The entry cannot be created or updated without providing a value for these attributes.
• Optional (MAY) attributes: Supported by the object class but not required.

For example, the inetOrgPerson object class defines:

This means a new inetOrgPerson entry must include at least cn and sn, while mail and telephoneNumber are optional.

Mandatory and optional distinctions are enforced by the directory server when entries are created or modified, ensuring data consistency for applications and integrations.

Custom LDAP Attributes and Schema Extension (Overview)

Standard schemas may not always satisfy bespoke integration needs. Directories can be extended with custom attribute types and object classes to support new application requirements.

Custom attribute essentials:

• Each new attribute requires a globally unique OID, a name, defined syntax, and constraints.
• Custom object classes are typically defined to collect one or more related custom attributes for use by entries.
• Modifications to the directory schema must comply with standard format and enforce global uniqueness, especially for OIDs.

For example, an organization may define an attribute for a proprietary employee identifier, allocating it an unused OID, specifying allowed syntax (e.g., Integer), and introducing an object class to enable its use on person entries.

Schema extension requires caution: modifying existing schemas or mismanaging OIDs can break interoperability or server function.

Practical Tips and Common Misconceptions

LDAP’s flexibility and complexity generate pitfalls for newcomers and even experienced integrators. Key clarifications:

• Entry ≠ Attribute: An entry is a unique, addressable node in the directory. Attributes are data about that entry. Confusing the two leads to schema violations and buggy integrations.
• Not all attributes are user-editable: Operational attributes (e.g., createTimestamp, creatorsName) are read-only and managed by the LDAP server.
• Attribute uniqueness: The attribute’s OID—not its name—guarantees uniqueness. Several names (aliases) may map to the same OID. Relying only on string names in code can cause mapping errors.
• Schema enforcement: You cannot add just any attribute to any entry; the entry’s object classes strictly control which attributes are permitted. Attempts to add unlisted attributes result in schema errors.
• Multi-valued handling: Some attributes (like mail) can have multiple values—this must be accommodated in both schema and client code.
• Language and options: Attributes may be tagged for language or other options; ensure your integration correctly interprets or emits these variants.

Key Takeaways and Next Steps

LDAP entries are the structure—concrete nodes in a directory tree—each uniquely identified by a DN. Attributes are typed key-value pairs constituting the data about an entry, strictly governed by object classes defined in the directory’s schema.

• Object classes specify which attributes entries must and may have, maintaining structural integrity.
• Attributes come in user and operational forms; only user attributes are typically modifiable by clients.
• Mandatory vs. optional attribute distinction is enforced for data consistency.
• Custom attributes and object classes require careful schema extension, with unique OIDs and appropriate syntax.

A clear grasp of these building blocks is essential for any developer or identity engineer building, integrating, or troubleshooting directory-based solutions. For more detail, consult the referenced standards for LDAP schema, directory information models, and attribute definitions.

Sources

• www.rfc-editor.org — rfc4512
• www.rfc-editor.org — rfc4519
• www.openldap.org — guide.html