Lightweight Directory Access Protocol (LDAP): Schema for User Applications
Extracted elements (30)
PKI-related schema elements (certificate attributes and object classes) were removed from this document and placed in RFC 4523 to separate general-purpose user schema from specialized PKI schema.
The 'dcObject' and 'uidObject' object classes are defined as AUXILIARY rather than STRUCTURAL because they add supplemental identity information to entries already typed by an existing structural class, avoiding requiring a separate entry hierarchy.
The 'distinguishedName' and 'name' attribute types are defined as supertypes that are unlikely to appear directly in entries; they exist so that user attribute types with DN or name syntax can inherit matching rules via attribute subtyping.
The directory service will not enforce that 'dc' values conform to host label restrictions (RFC 1123) or that 'destinationIndicator' values conform to CCITT F.1/F.31; enforcement is the client application's responsibility.
The 'searchGuide' attribute is superseded by 'enhancedSearchGuide'; both 'searchGuide' and 'teletexTerminalIdentifier' are greatly discouraged and servers need not implement them.
The 'x500UniqueIdentifier' attribute (OID 2.5.4.45) is distinct from both the 'uid' attribute and the 'uniqueIdentifier' attribute defined in RFC 4524, despite sharing the name 'uniqueIdentifier' in X.520.
An LDAP server implementation SHOULD recognize the attribute types described in Section 2, with the exception of 'searchGuide' and 'teletexTerminalIdentifier' whose use is greatly discouraged.
Applications SHOULD prepare textual strings used as passwords by transcoding to Unicode, applying SASLprep (RFC 4013), and encoding as UTF-8 before storing in 'userPassword'.
Client implementations MUST NOT assume that LDAP servers are capable of performing attribute subtyping, as noted for both 'distinguishedName' and 'name' supertypes.
Directory applications supporting International Domain Names SHALL use the ToASCII method (RFC 3490) to produce the domain component label for the 'dc' attribute.
LDAP servers SHOULD recognize all the Object Classes listed in Section 3 as values of the 'objectClass' attribute.
Directory entry attributes represent real-world information about people, organizations, or devices; most countries have privacy laws regarding the publication of such information, which implementers must consider.
The 'c' (countryName) attribute type (OID 2.5.4.6) is SINGLE-VALUE, uses Country String syntax, and contains a two-letter ISO 3166 country code.
The 'cn' (commonName) attribute type (OID 2.5.4.3) is a multi-valued attribute containing names of an object, inheriting from the 'name' supertype; for persons it is typically the full name.
The 'dc' (domainComponent) attribute type (OID 0.9.2342.19200300.100.1.25) holds a single DNS domain label encoded as IA5String with case-insensitive equality matching; it is SINGLE-VALUE.
The 'dcObject' object class (OID 1.3.6.1.4.1.1466.344) is AUXILIARY, requiring 'dc', and is used in conjunction with an existing structural object class to add domain component information.
The 'distinguishedName' attribute type (OID 2.5.4.49) is a base supertype for user attribute types with DN syntax; it uses distinguishedNameMatch equality and DN syntax.
The 'groupOfNames' object class (OID 2.5.6.9) is STRUCTURAL, requires 'member' and 'cn', and represents a set of named objects including group maintenance information.
The 'groupOfUniqueNames' object class (OID 2.5.6.17) is STRUCTURAL, requires 'uniqueMember' and 'cn', and ensures object names are not repeated or reassigned within a set scope.
The 'organization' object class (OID 2.5.6.4) is STRUCTURAL, requires 'o', and permits a broad set of optional contact and address attributes including 'userPassword' and telecom numbers.
The 'person' object class (OID 2.5.6.6) is a STRUCTURAL class requiring 'sn' and 'cn', with optional 'userPassword', 'telephoneNumber', 'seeAlso', and 'description'.
The 'uid' (userid) attribute type (OID 0.9.2342.19200300.100.1.1) contains computer system login names, uses caseIgnoreMatch equality and Directory String syntax.
The 'uidObject' object class (OID 1.3.6.1.1.3.1) is AUXILIARY, requiring 'uid', and is used in conjunction with an existing structural object class to add user identification.
The 'uniqueMember' attribute type (OID 2.5.4.50) uses Name and Optional UID syntax (1.3.6.1.4.1.1466.115.121.1.34) with uniqueMemberMatch equality to handle reused distinguished names.
The 'userPassword' attribute (OID 2.5.4.35) stores octet strings using Octet String syntax with octetStringMatch equality; passwords are not encrypted at rest.
IANA updated the LDAP descriptors registry to map all attribute type and object class short names defined in RFC 4519 (e.g., 'cn', 'dc', 'uid', 'person', 'organization') to their OIDs under RFC 4519.
Multiple values for 'userPassword' must be used with care; administrator password reset becomes tricky or impossible if multiple application-specific values are present, and servers are encouraged to provide controls restricting 'userPassword' to one value.
Transfer of cleartext passwords via 'userPassword' is strongly discouraged where the underlying transport cannot guarantee confidentiality and integrity, as this may disclose passwords to unauthorized parties.
The 'dc' attribute value is an ASCII label conforming to the ABNF: label = (ALPHA / DIGIT) [*61(ALPHA / DIGIT / HYPHEN) (ALPHA / DIGIT)], encoded as IA5String.
The 'postalAddress' attribute uses Postal Address syntax (OID 1.3.6.1.4.1.1466.115.121.1.41) with caseIgnoreListMatch equality and caseIgnoreListSubstringsMatch substring matching.