Entries and attributes

Every node in the directory tree — every DN — points to an entry: a set of named attributes describing that person, group, or resource.

Directory tools and export files typically represent an entry in LDIF (LDAP Data Interchange Format), a simple text format:

dn: CN=Jane Doe,OU=Engineering,OU=Users,DC=example,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Jane Doe
sn: Doe
givenName: Jane
mail: jane.doe@example.com
memberOf: CN=Engineering,OU=Groups,DC=example,DC=com

A few things to notice:

• The first line is always the entry's DN.
• Every other line is attributeName: value.
• An attribute can repeat — objectClass appears four times here, and memberOf would repeat once per group the user belongs to.

objectClass is the attribute that tells the directory (and anyone reading the entry) what kind of thing this is, and which attributes it's allowed — or required — to have. Object classes typically inherit from each other: user in Active Directory builds on organizationalPerson, which builds on person, which builds on top.

This matters practically: if you try to write an attribute that isn't permitted by the entry's object classes, the directory server will reject the change.

Most attributes can hold more than one value. mail might have a primary and an alias address; memberOf typically lists many groups. A handful of attributes — like cn used as part of the RDN — are effectively single-valued in practice. When you read an entry with ldapjs, always assume an attribute could come back as an array.

Each attribute type has a defined syntax — a directory string, an integer, binary data, a timestamp, and so on. This is enforced by the server's schema, not something client code needs to implement, but it explains some things you'll see in the wild:

• Active Directory timestamps like pwdLastSet are large integers (100-nanosecond intervals since 1601), not ISO dates.
• Binary attributes, like objectGUID or a certificate, are returned as raw bytes and need explicit decoding.

Now that you know what's inside an entry, the next pages cover how to prove who you are (Bind and authentication) and how to find entries in the first place (Searching).