Overview#
An entry is the structure that holds data in a DIT and may be referred to as a node.LDAP Entry consists of the following components:
- A DN that is a Unique Identifier for the LDAP Entry among all other entries in the DIT.
- A collection of ObjectClass values that are used to govern the contents of the LDAP Entry.
- A collection of Attribute Values that contain the actual data for the LDAP Entry.
Every LDAP Entry is characterized by precisely one Structural ObjectClass superclass chain which has a single structural object class as the most subordinate ObjectClass.
The Collection of object classes determines the available Attributes for the entry. The Collection of ObjectClass define a set of required attributes, which MUST be present in the LDAP Entry, and possibly OPTIONAL attributeTypes, which may be included in the entry but are not required.
Within the DIT the LDAP Entry may be a Leaf Entry or a Non-leaf entry
Structure of an LDAP Entry (RFC 4512)#
An LDAP Entry consists of a set of AttributeTypes that hold data about the object that the LDAP Entry represents. Some attributeType represent user information and are called user attributes. Other attributes represent OperationalAttributes and/or administrative information and are called operational attributes.An attributeType is an attribute description with 0 or more Attribute Options with one or more associated values. An attributeType is often referred to by its attribute description. For example, the 'givenName' attributeType is the attribute that consists of the attribute description 'givenName' (the 'givenName' attribute type RFC 4519 and zero Attribute Options) and one or more associated values.
The attributeType governs whether the attribute can have multiple values, the LDAPSyntaxes and matching Rules used to construct and compare values of that attribute, and other functions. Attribute Options indicate subtypes and other functions.
Attribute values conform to the defined LDAPSyntaxes of the attribute type.
No two values of an attributeType may be equivalent. Two values are considered equivalent if and only if they would match according to the EQUALITY matching Rule of the attributeType. Or, if the attributeType is defined with no EQUALITY matching Rule, two values are equivalent if and only if they are identical. (See RFC 4512 2.5.1 for other restrictions.)
For example, a 'givenName' attributeType can have more than one value, they must be Directory Strings, and they are case-insensitive. A 'givenName' attributeType cannot hold both "John" and "JOHN", as these are equivalent values per the equality matching rule of the attribute type.
Additionally, no attribute is to have a value that is not equivalent to itself. For example, the 'givenName' attribute cannot have as a value a directory string that includes the REPLACEMENT CHARACTER (U+FFFD) code point, as matching involving that directory string is Undefined per this attribute's equality matching rule.
When an attributeType is used for naming of the entry, one and only one value of the attribute is used in forming the Relative Distinguished Name. This value is known as a Distinguished Value.
More Information#
There might be more information for this subject on one of the following:- ACCOUNTDISABLE
- ACCOUNT_UNLOCK
- ACL (eDirectory Attribute)
- AD DOMAIN
- AUXILIARY
- Access Control
- Account
- Add Request
- Alias
- Ambiguous Name Resolution
- AssociatedInternetGateway
- Attribute
- Authentication ID
- AuthorizationID
- BaseObject
- Best Practices For LDAP Naming Attributes
- Best Practices For Unique Identifiers
- ChangeNumber
- Cn
- Collective Attribute
- CollectiveAttributeSubentry
- Compare Request
- Container
- DACL_SECURITY_INFORMATION
- DN Syntax
- DSA-Specific Entry
- DSE_ADD_VALUE
- DSE_DELETE_VALUE
- Delete Request
- Delete Response
- Determine LDAP Server Vendor
- DirectReports
- Directory Information Base
- Directory Information Tree
- Distinguished Names
- Draft-behera-ldap-password-policy
- DynamicGroup
- EDirectory Monitor Entry
- EDirectory Password Expiration
- ERROR_ACCOUNT_LOCKED_OUT
- ExtensibleObject
- Glossary Of LDAP And Directory Terminology
- Groups Are Bad
- I-number
- IDM Tricks
- Introduction To LDAP
- IsDeleted
- Join Request and Result Controls
- LDAP Data Interchange Format
- LDAP Entry Collection
- LDAP Model of User Information
- LDAP Query Basic Examples
- LDAP Result Codes
- LDAP Schema
- LDAP Schema Element Type
- LDAP Subentry
- LDAP_ADMINLIMIT_EXCEEDED
- LDAP_MATCHING_RULE_IN_CHAIN
- Leaf Entry
- Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute
- LocalEntryID
- MAD Determine the Classes Associated With an Entry
- MatchingRule
- Maximum Database Record Size
- Member
- MemberOf
- ModifiersName
- Modify Request
- ModifyDNRequest
- Modrdn
- NDS Master Replica
- NDS Sparse Read Replica
- Ndstrace Log Searches
- NewSuperior
- Non-leaf
- Not Synchronized
- NspmConfigurationOptions
- NspmPasswordPolicyDN
- OWNER_SECURITY_INFORMATION
- Object
- Object ACL
- ObjectClass Types
- ObjectClass=unknown
- Password MUST Change
- Permissions to read Universal Password
- Persistent Search Control
- RBAC vs ABAC
- Revision
- SACL_SECURITY_INFORMATION
- SCIM Resource
- STRUCTURAL
- Schema Checking
- SearchRequest
- SearchResultEntry
- Security Identifier
- SingleLevel
- Smart referrals
- Static groups
- Structural ObjectClass
- Subentries
- TargetDN
- Thinking of LDAP
- Time Restrictions
- Trusted Domain Object
- UidObject
- Understanding Name Forms
- Virtual Attribute
- Which Jane Doe