Request for Comments: 4519 eB2Bcom
Obsoletes: 2256 June 2006
Updates: 2247, 2798, 2377
Category: Standards Track
Lightweight Directory Access Protocol (LDAP):
Schema for User Applications
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document is an integral part of the Lightweight Directory Access
Protocol (LDAP) technical specification. It provides a technical
specification of attribute types and object classes intended for use
by LDAP directory clients for many directory services, such as White
Pages. These objects are widely used as a basis for the schema in
many LDAP directories. This document does not cover attributes used
for the administration of directory servers, nor does it include
directory objects defined for specific uses in other documents.
Table of Contents
1. Introduction ....................................................3
1.1. Relationship with Other Specifications .....................3
1.2. Conventions ................................................4
1.3. General Issues .............................................4
2. Attribute Types .................................................4
2.1. ’businessCategory’ .........................................5
2.2. ’c’ ........................................................5
2.3. ’cn’ .......................................................5
2.4. ’dc’ .......................................................6
2.5. ’description’ ..............................................6
2.6. ’destinationIndicator’ .....................................7
2.7. ’distinguishedName’ ........................................7
2.8. ’dnQualifier’ ..............................................8
2.9. ’enhancedSearchGuide’ ......................................8
2.10. ’facsimileTelephoneNumber’ ................................9
2.11. ’generationQualifier’ .....................................9
2.12. ’givenName’ ...............................................9
2.13. ’houseIdentifier’ .........................................9
2.14. ’initials’ ...............................................10
2.15. ’internationalISDNNumber’ ................................10
2.16. ’l’ ......................................................10
2.17. ’member’ .................................................11
2.18. ’name’ ...................................................11
2.19. ’o’ ......................................................11
2.20. ’ou’ .....................................................12
2.21. ’owner’ ..................................................12
2.22. ’physicalDeliveryOfficeName’ .............................12
2.23. ’postalAddress’ ..........................................13
2.24. ’postalCode’ .............................................13
2.25. ’postOfficeBox’ ..........................................14
2.26. ’preferredDeliveryMethod’ ................................14
2.27. ’registeredAddress’ ......................................14
2.28. ’roleOccupant’ ...........................................15
2.29. ’searchGuide’ ............................................15
2.30. ’seeAlso’ ................................................15
2.31. ’serialNumber’ ...........................................16
2.32. ’sn’ .....................................................16
2.33. ’st’ .....................................................16
2.34. ’street’ .................................................17
2.35. ’telephoneNumber’ ........................................17
2.36. ’teletexTerminalIdentifier’ ..............................17
2.37. ’telexNumber’ ............................................18
2.38. ’title’ ..................................................18
2.39. ’uid’ ....................................................18
2.40. ’uniqueMember’ ...........................................19
2.41. ’userPassword’ ...........................................19
2.42. ’x121Address’ ............................................20
2.43. ’x500UniqueIdentifier’ ...................................20
3. Object Classes .................................................20
3.1. ’applicationProcess’ ......................................21
3.2. ’country’ .................................................21
3.3. ’dcObject’ ................................................21
3.4. ’device’ ..................................................21
3.5. ’groupOfNames’ ............................................22
3.6. ’groupOfUniqueNames’ ......................................22
3.7. ’locality’ ................................................23
3.8. ’organization’ ............................................23
3.9. ’organizationalPerson’ ....................................24
3.10. ’organizationalRole’ .....................................24
3.11. ’organizationalUnit’ .....................................24
3.12. ’person’ .................................................25
3.13. ’residentialPerson’ ......................................25
3.14. ’uidObject’ ..............................................26
4. IANA Considerations ............................................26
5. Security Considerations ........................................28
6. Acknowledgements ...............................................28
7. References .....................................................29
7.1. Normative References ......................................29
7.2. Informative References ....................................30
Appendix A Changes Made Since RFC 2256 ...........................32
1. Introduction
This document provides an overview of attribute types and object
classes intended for use by Lightweight Directory Access Protocol
(LDAP) directory clients for many directory services, such as White
Pages. Originally specified in the X.500 [X.500] documents, these
objects are widely used as a basis for the schema in many LDAP
directories. This document does not cover attributes used for the
administration of directory servers, nor does it include directory
objects defined for specific uses in other documents.
1.1. Relationship with Other Specifications
This document is an integral part of the LDAP technical specification
[RFC4510], which obsoletes the previously defined LDAP technical
specification, RFC 3377, in its entirety. In terms of RFC 2256,
Sections 6 and 8 of RFC 2256 are obsoleted by [RFC4517]. Sections
5.1, 5.2, 7.1, and 7.2 of RFC 2256 are obsoleted by [RFC4512]. The
remainder of RFC 2256 is obsoleted by this document. The technical
specification for the ’dc’ attribute type and ’dcObject’ object class
found in RFC 2247 are superseded by sections 2.4 and 3.3 of this
document. The remainder of RFC 2247 remains in force.
This document updates RFC 2798 by replacing the informative
description of the ’uid’ attribute type with the definitive
description provided in Section 2.39 of this document.
This document updates RFC 2377 by replacing the informative
description of the ’uidObject’ object class with the definitive
description provided in Section 3.14 of this document.
A number of schema elements that were included in the previous
revision of the LDAP Technical Specification are not included in this
revision of LDAP. PKI-related schema elements are now specified in
[RFC4523]. Unless reintroduced in future technical specifications,
the remainder are to be considered Historic.
The descriptions in this document SHALL be considered definitive for
use in LDAP.
1.2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.3. General Issues
This document references Syntaxes defined in Section 3 of [RFC4517]
and Matching Rules defined in Section 4 of [RFC4517].
The definitions of Attribute Types and Object Classes are written
using the Augmented Backus-Naur Form (ABNF) [RFC4234] of
AttributeTypeDescription and ObjectClassDescription given in
[RFC4512]. Lines have been folded for readability. When such values
are transferred as attribute values in the LDAP Protocol, the values
will not contain line breaks.
2. Attribute Types
The attribute types contained in this section hold user information.
There is no requirement that servers implement the ’searchGuide’ and
’teletexTerminalIdentifier’ attribute types. In fact, their use is
greatly discouraged.
An LDAP server implementation SHOULD recognize the rest of the
attribute types described in this section.
2.1. ’businessCategory’
The ’businessCategory’ attribute type describes the kinds of business
performed by an organization. Each kind is one value of this
multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.15 NAME ’businessCategory’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[RFC4517].
Examples: "banking", "transportation", and "real estate".
2.2. ’c’
The ’c’ (’countryName’ in X.500) attribute type contains a two-letter
ISO 3166 [ISO3166] country code.
(Source: X.520 [X.520])
( 2.5.4.6 NAME ’c’
SUP name
SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
SINGLE-VALUE )
1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax
[RFC4517].
Examples: "DE", "AU" and "FR".
2.3. ’cn’
The ’cn’ (’commonName’ in X.500) attribute type contains names of an
object. Each name is one value of this multi-valued attribute. If
the object corresponds to a person, it is typically the person’s full
name.
(Source: X.520 [X.520])
( 2.5.4.3 NAME ’cn’
SUP name )
Examples: "Martin K Smith", "Marty Smith" and "printer12".
2.4. ’dc’
The ’dc’ (’domainComponent’ in RFC 1274) attribute type is a string
holding one component, a label, of a DNS domain name
[RFC1034][RFC2181] naming a host [RFC1123]. That is, a value of this
attribute is a string of ASCII characters adhering to the following
ABNF [RFC4234]:
label = (ALPHA / DIGIT) [*61(ALPHA / DIGIT / HYPHEN) (ALPHA / DIGIT)]
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
DIGIT = %x30-39 ; "0"-"9"
HYPHEN = %x2D ; hyphen ("-")
The encoding of IA5String for use in LDAP is simply the characters of
the ASCII label. The equality matching rule is case insensitive, as
is today’s DNS. (Source: RFC 2247 [RFC2247] and RFC 1274 [RFC 1274])
( 0.9.2342.19200300.100.1.25 NAME ’dc’
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )
1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax
[RFC4517].
Examples: Valid values include "example" and "com" but not
"example.com". The latter is invalid as it contains multiple domain
components.
It is noted that the directory service will not ensure that values of
this attribute conform to the host label restrictions [RFC1123]
illustrated by the <label> production provided above. It is the
directory client’s responsibility to ensure that the labels it stores
in this attribute are appropriately restricted.
Directory applications supporting International Domain Names SHALL
use the ToASCII method [RFC3490] to produce the domain component
label. The special considerations discussed in Section 4 of RFC 3490
[RFC3490] should be taken, depending on whether the domain component
is used for "stored" or "query" purposes.
2.5. ’description’
The ’description’ attribute type contains human-readable descriptive
phrases about the object. Each description is one value of this
multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.13 NAME ’description’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[RFC4517].
Examples: "a color printer", "Maintenance is done every Monday, at
1pm.", and "distribution list for all technical staff".
2.6. ’destinationIndicator’
The ’destinationIndicator’ attribute type contains country and city
strings associated with the object (the addressee) needed to provide
the Public Telegram Service. The strings are composed in accordance
with CCITT Recommendations F.1 [F.1] and F.31 [F.31]. Each string is
one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.27 NAME ’destinationIndicator’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
[RFC4517].
Examples: "AASD" as a destination indicator for Sydney, Australia.
"GBLD" as a destination indicator for London, United
Kingdom.
It is noted that the directory will not ensure that values of this
attribute conform to the F.1 and F.31 CCITT Recommendations. It is
the application’s responsibility to ensure destination indicators
that it stores in this attribute are appropriately constructed.
2.7. ’distinguishedName’
The ’distinguishedName’ attribute type is not used as the name of the
object itself, but it is instead a base type from which some user
attribute types with a DN syntax can inherit.
It is unlikely that values of this type itself will occur in an
entry. LDAP server implementations that do not support attribute
subtyping need not recognize this attribute in requests. Client
implementations MUST NOT assume that LDAP servers are capable of
performing attribute subtyping.
(Source: X.520 [X.520])
( 2.5.4.49 NAME ’distinguishedName’
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
1.3.6.1.4.1.1466.115.121.1.12 refers to the DN syntax [RFC4517].
2.8. ’dnQualifier’
The ’dnQualifier’ attribute type contains disambiguating information
strings to add to the relative distinguished name of an entry. The
information is intended for use when merging data from multiple
sources in order to prevent conflicts between entries that would
otherwise have the same name. Each string is one value of this
multi-valued attribute. It is recommended that a value of the
’dnQualifier’ attribute be the same for all entries from a particular
source.
(Source: X.520 [X.520])
( 2.5.4.46 NAME ’dnQualifier’
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
[RFC4517].
Examples: "20050322123345Z" - timestamps can be used to disambiguate
information.
"123456A" - serial numbers can be used to disambiguate
information.
2.9. ’enhancedSearchGuide’
The ’enhancedSearchGuide’ attribute type contains sets of information
for use by directory clients in constructing search filters. Each
set is one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.47 NAME ’enhancedSearchGuide’
SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax
[RFC4517].
Examples: "person#(sn$APPROX)#wholeSubtree" and
"organizationalUnit#(ou$SUBSTR)#oneLevel".
2.10. ’facsimileTelephoneNumber’
The ’facsimileTelephoneNumber’ attribute type contains telephone
numbers (and, optionally, the parameters) for facsimile terminals.
Each telephone number is one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.23 NAME ’facsimileTelephoneNumber’
SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone
Number syntax [RFC4517].
Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution".
2.11. ’generationQualifier’
The ’generationQualifier’ attribute type contains name strings that
are typically the suffix part of a person’s name. Each string is one
value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.44 NAME ’generationQualifier’
SUP name )
Examples: "III", "3rd", and "Jr.".
2.12. ’givenName’
The ’givenName’ attribute type contains name strings that are the
part of a person’s name that is not their surname. Each string is
one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.42 NAME ’givenName’
SUP name )
Examples: "Andrew", "Charles", and "Joanne".
2.13. ’houseIdentifier’
The ’houseIdentifier’ attribute type contains identifiers for a
building within a location. Each identifier is one value of this
multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.51 NAME ’houseIdentifier’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[RFC4517].
Example: "20" to represent the house number 20.
2.14. ’initials’
The ’initials’ attribute type contains strings of initials of some or
all of an individual’s names, except the surname(s). Each string is
one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.43 NAME ’initials’
SUP name )
Examples: "K. A." and "K".
2.15. ’internationalISDNNumber’
The ’internationalISDNNumber’ attribute type contains Integrated
Services Digital Network (ISDN) addresses, as defined in the
International Telecommunication Union (ITU) Recommendation E.164
[E.164]. Each address is one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.25 NAME ’internationalISDNNumber’
EQUALITY numericStringMatch
SUBSTR numericStringSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
[RFC4517].
Example: "0198 333 333".
2.16. ’l’
The ’l’ (’localityName’ in X.500) attribute type contains names of a
locality or place, such as a city, county, or other geographic
region. Each name is one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.7 NAME ’l’
SUP name )
Examples: "Geneva", "Paris", and "Edinburgh".
2.17. ’member’
The ’member’ attribute type contains the distinguished names of
objects that are on a list or in a group. Each name is one value of
this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.31 NAME ’member’
SUP distinguishedName )
Examples: "cn=James Clarke,ou=Finance,o=Widget\, Inc." and
"cn=John Xerri,ou=Finance,o=Widget\, Inc." may
be two members of the financial team (group) at Widget,
Inc., in which case, both of these distinguished names
would be present as individual values of the member
attribute.
2.18. ’name’
The ’name’ attribute type is the attribute supertype from which user
attribute types with the name syntax inherit. Such attribute types
are typically used for naming. The attribute type is multi-valued.
It is unlikely that values of this type itself will occur in an
entry. LDAP server implementations that do not support attribute
subtyping need not recognize this attribute in requests. Client
implementations MUST NOT assume that LDAP servers are capable of
performing attribute subtyping.
(Source: X.520 [X.520])
( 2.5.4.41 NAME ’name’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[RFC4517].
2.19. ’o’
The ’o’ (’organizationName’ in X.500) attribute type contains the
names of an organization. Each name is one value of this
multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.10 NAME ’o’
SUP name )
Examples: "Widget", "Widget, Inc.", and "Widget, Incorporated.".
2.20. ’ou’
The ’ou’ (’organizationalUnitName’ in X.500) attribute type contains
the names of an organizational unit. Each name is one value of this
multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.11 NAME ’ou’
SUP name )
Examples: "Finance", "Human Resources", and "Research and
Development".
2.21. ’owner’
The ’owner’ attribute type contains the distinguished names of
objects that have an ownership responsibility for the object that is
owned. Each owner’s name is one value of this multi-valued
attribute.
(Source: X.520 [X.520])
( 2.5.4.32 NAME ’owner’
SUP distinguishedName )
Example: The mailing list object, whose DN is "cn=All Employees,
ou=Mailing List,o=Widget\, Inc.", is owned by the Human
Resources Director.
Therefore, the value of the ’owner’ attribute within the
mailing list object, would be the DN of the director (role):
"cn=Human Resources Director,ou=employee,o=Widget\, Inc.".
2.22. ’physicalDeliveryOfficeName’
The ’physicalDeliveryOfficeName’ attribute type contains names that a
Postal Service uses to identify a post office.
(Source: X.520 [X.520])
( 2.5.4.19 NAME ’physicalDeliveryOfficeName’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[RFC4517].
Examples: "Bremerhaven, Main" and "Bremerhaven, Bonnstrasse".
2.23. ’postalAddress’
The ’postalAddress’ attribute type contains addresses used by a
Postal Service to perform services for the object. Each address is
one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.16 NAME ’postalAddress’
EQUALITY caseIgnoreListMatch
SUBSTR caseIgnoreListSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
[RFC4517].
Example: "15 Main St.$Ottawa$Canada".
2.24. ’postalCode’
The ’postalCode’ attribute type contains codes used by a Postal
Service to identify postal service zones. Each code is one value of
this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.17 NAME ’postalCode’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[RFC4517].
Example: "22180", to identify Vienna, VA, in the USA.
2.25. ’postOfficeBox’
The ’postOfficeBox’ attribute type contains postal box identifiers
that a Postal Service uses when a customer arranges to receive mail
at a box on the premises of the Postal Service. Each postal box
identifier is a single value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.18 NAME ’postOfficeBox’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[RFC4517].
Example: "Box 45".
2.26. ’preferredDeliveryMethod’
The ’preferredDeliveryMethod’ attribute type contains an indication
of the preferred method of getting a message to the object.
(Source: X.520 [X.520])
( 2.5.4.28 NAME ’preferredDeliveryMethod’
SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
SINGLE-VALUE )
1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method syntax
[RFC4517].
Example: If the mhs-delivery Delivery Method is preferred over
telephone-delivery, which is preferred over all other
methods, the value would be: "mhs $ telephone".
2.27. ’registeredAddress’
The ’registeredAddress’ attribute type contains postal addresses