documentAuthor: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
documentLocation: http://www.rfc-editor.org/rfc/rfc4524.txt
documentPublisher: Internet Engineering Task Force
description: A collection of schema elements for use in LDAP
description: Obsoletes RFC 1274
seeAlso: documentIdentifier=RFC 4510,cn=RFC,dc=Example,dc=COM
seeAlso: documentIdentifier=RFC 1274,cn=RFC,dc=Example,dc=COM
3.3. documentSeries
The ’documentSeries’ object class is used to define an entry that
represents a series of documents (e.g., The Request For Comments
memos).
( 0.9.2342.19200300.100.4.9 NAME ’documentSeries’
SUP top STRUCTURAL
MUST cn
MAY ( description $ l $ o $ ou $ seeAlso $
telephonenumber ) )
The ’top’ object class is described in [RFC4512]. The ’description’,
’l’, ’o’, ’ou’, ’seeAlso’, and ’telephoneNumber’ attribute types are
described in [RFC4519].
Example:
dn: cn=RFC,dc=Example,dc=COM
objectClass: documentSeries
cn: Request for Comments
cn: RFC
description: a series of memos about the Internet
3.4. domain
The ’domain’ object class is used to define entries that represent
DNS domains for objects that are not organizations, organizational
units, or other kinds of objects more appropriately defined using an
object class specific to the kind of object being defined (e.g.,
’organization’, ’organizationUnit’).
The ’dc’ attribute should be used for naming entries of the ’domain’
object class.
( 0.9.2342.19200300.100.4.13 NAME ’domain’
SUP top STRUCTURAL
MUST dc
MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $
teletexTerminalIdentifier $ telephoneNumber $
internationaliSDNNumber $ facsimileTelephoneNumber $ street $
postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ st $ l $ description $ o $
associatedName ) )
The ’top’ object class and the ’dc’, ’userPassword’, ’searchGuide’,
’seeAlso’, ’businessCategory’, ’x121Address’, ’registeredAddress’,
’destinationIndicator’, ’preferredDeliveryMethod’, ’telexNumber’,
’teletexTerminalIdentifier’, ’telephoneNumber’,
’internationaliSDNNumber’, ’facsimileTelephoneNumber’, ’street’,
’postOfficeBox’, ’postalCode’, ’postalAddress’,
’physicalDeliveryOfficeName’, ’st’, ’l’, ’description’, and ’o’ types
are described in [RFC4519]. The ’associatedName’ attribute type is
described in Section 2 of this document.
Example:
dn: dc=com
objectClass: domain
dc: com
description: the .COM TLD
3.5. domainRelatedObject
The ’domainRelatedObject’ object class is used to define entries that
represent DNS domains that are "equivalent" to an X.500 domain, e.g.,
an organization or organizational unit.
( 0.9.2342.19200300.100.4.17 NAME ’domainRelatedObject’
SUP top AUXILIARY
MUST associatedDomain )
The ’top’ object class is described in [RFC4512]. The
’associatedDomain’ attribute type is described in Section 2 of this
document.
Example:
dn: dc=example,dc=com
objectClass: organization
objectClass: dcObject
objectClass: domainRelatedObject
dc: example
associatedDomain: example.com
o: Example Organization
The ’organization’ and ’dcObject’ object classes and the ’dc’ and ’o’
attribute types are described in [RFC4519].
3.6. friendlyCountry
The ’friendlyCountry’ object class is used to define entries
representing countries in the DIT. The object class is used to allow
friendlier naming of countries than that allowed by the object class
’country’ [RFC4519].
( 0.9.2342.19200300.100.4.18 NAME ’friendlyCountry’
SUP country STRUCTURAL
MUST co )
The ’country’ object class is described in [RFC4519]. The ’co’
attribute type is described in Section 2 of this document.
Example:
dn: c=DE
objectClass: country
objectClass: friendlyCountry
c: DE
co: Deutschland
co: Germany
co: Federal Republic of Germany
co: FRG
The ’c’ attribute type is described in [RFC4519].
3.7. rFC822LocalPart
The ’rFC822LocalPart’ object class is used to define entries that
represent the local part of Internet mail addresses [RFC2822]. This
treats the local part of the address as a ’domain’ object.
( 0.9.2342.19200300.100.4.14 NAME ’rFC822localPart’
SUP domain STRUCTURAL
MAY ( cn $ description $ destinationIndicator $
facsimileTelephoneNumber $ internationaliSDNNumber $
physicalDeliveryOfficeName $ postalAddress $ postalCode $
postOfficeBox $ preferredDeliveryMethod $ registeredAddress $
seeAlso $ sn $ street $ telephoneNumber $
teletexTerminalIdentifier $ telexNumber $ x121Address ) )
The ’domain’ object class is described in Section 3.4 of this
document. The ’cn’, ’description’, ’destinationIndicator’,
’facsimileTelephoneNumber’, ’internationaliSDNNumber,
’physicalDeliveryOfficeName’, ’postalAddress’, ’postalCode’,
’postOfficeBox’, ’preferredDeliveryMethod’, ’registeredAddress’,
’seeAlso’, ’sn, ’street’, ’telephoneNumber’,
’teletexTerminalIdentifier’, ’telexNumber’, and ’x121Address’
attribute types are described in [RFC4519].
Example:
dn: dc=kdz,dc=example,dc=com
objectClass: domain
objectClass: rFC822LocalPart
dc: kdz
associatedName: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
The ’dc’ attribute type is described in [RFC4519].
3.8. room
The ’room’ object class is used to define entries representing rooms.
The ’cn’ (commonName) attribute SHOULD be used for naming entries of
this object class.
( 0.9.2342.19200300.100.4.7 NAME ’room’
SUP top STRUCTURAL
MUST cn
MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) )
The ’top’ object class is described in [RFC4512]. The ’cn’,
’description’, ’seeAlso’, and ’telephoneNumber’ attribute types are
described in [RFC4519]. The ’roomNumber’ attribute type is described
in Section 2 of this document.
dn: cn=conference room,dc=example,dc=com
objectClass: room
cn: conference room
telephoneNumber: +1 755 555 1111
3.9. simpleSecurityObject
The ’simpleSecurityObject’ object class is used to require an entry
to have a ’userPassword’ attribute when the entry’s structural object
class does not require (or allow) the ’userPassword attribute’.
( 0.9.2342.19200300.100.4.19 NAME ’simpleSecurityObject’
SUP top AUXILIARY
MUST userPassword )
The ’top’ object class is described in [RFC4512]. The ’userPassword’
attribute type is described in [RFC4519].
dn: dc=kdz,dc=Example,dc=COM
objectClass: account
objectClass: simpleSecurityObject
uid: kdz
userPassword: My Password
seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
4. Security Considerations
General LDAP security considerations [RFC4510] are applicable to the
use of this schema. Additional considerations are noted above where
appropriate.
Directories administrators should ensure that access to sensitive
information be restricted to authorized entities and that appropriate
data security services, including data integrity and data
confidentiality, are used to protect against eavesdropping.
Simple authentication (e.g., plain text passwords) mechanisms should
only be used when adequate data security services are in place. LDAP
offers reasonably strong authentication and data security services
[RFC4513].
5. IANA Considerations
The Internet Assigned Numbers Authority (IANA) has updated the LDAP
descriptors registry [RFC4520] as indicated in the following
template:
Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comment
Object Identifier: see comments
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: see comments
Specification: RFC 4524
Author/Change Controller: IESG
Comments:
The following descriptors have been updated to refer to RFC 4524.
NAME Type OID
------------------------ ---- --------------------------
account O 0.9.2342.19200300.100.4.5
associatedDomain A 0.9.2342.19200300.100.1.37
associatedName A 0.9.2342.19200300.100.1.38
buildingName A 0.9.2342.19200300.100.1.48
co A 0.9.2342.19200300.100.1.43
document O 0.9.2342.19200300.100.4.6
documentAuthor A 0.9.2342.19200300.100.1.14
documentIdentifier A 0.9.2342.19200300.100.1.11
documentLocation A 0.9.2342.19200300.100.1.15
documentPublisher A 0.9.2342.19200300.100.1.56
documentSeries O 0.9.2342.19200300.100.4.8
documentTitle A 0.9.2342.19200300.100.1.12
documentVersion A 0.9.2342.19200300.100.1.13
domain O 0.9.2342.19200300.100.4.13
domainRelatedObject O 0.9.2342.19200300.100.4.17
drink A 0.9.2342.19200300.100.1.5
favouriteDrink A* 0.9.2342.19200300.100.1.5
friendlyCountry O 0.9.2342.19200300.100.4.18
friendlyCountryName A* 0.9.2342.19200300.100.1.43
homePhone A 0.9.2342.19200300.100.1.20
homePostalAddress A 0.9.2342.19200300.100.1.39
homeTelephone A* 0.9.2342.19200300.100.1.20
host A 0.9.2342.19200300.100.1.9
info A 0.9.2342.19200300.100.1.4
mail A 0.9.2342.19200300.100.1.3
manager A 0.9.2342.19200300.100.1.10
mobile A 0.9.2342.19200300.100.1.41
mobileTelephoneNumber A* 0.9.2342.19200300.100.1.41
organizationalStatus A 0.9.2342.19200300.100.1.45
pager A 0.9.2342.19200300.100.1.42
pagerTelephoneNumber A* 0.9.2342.19200300.100.1.42
personalTitle A 0.9.2342.19200300.100.1.40
rFC822LocalPart O 0.9.2342.19200300.100.4.14
rfc822Mailbox A* 0.9.2342.19200300.100.1.3
room O 0.9.2342.19200300.100.4.7
roomNumber A 0.9.2342.19200300.100.1.6
secretary A 0.9.2342.19200300.100.1.21
simpleSecurityObject O 0.9.2342.19200300.100.4.19
singleLevelQuality A 0.9.2342.19200300.100.1.50
uniqueIdentifier A 0.9.2342.19200300.100.1.44
userClass A 0.9.2342.19200300.100.1.8
where Type A is Attribute, Type O is ObjectClass, and *
indicates that the registration is historic in nature.
6. Acknowledgements
This document is based on RFC 1274, by Paul Barker and Steve Kille,
as well as on RFC 2247, by Steve Kill, Mark Wahl, Al Grimstad, Rick
Huber, and Sri Satulari.
7. References
7.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, October
1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.
Sataluri, "Using Domains in LDAP/X.500 Distinguished
Names", RFC 2247, January 1998.
[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
2821, April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003.
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
Protocol (LDAP): Technical Specification Road Map", RFC
4510, June 2006.
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, June
2006.
[RFC4513] Harrison, R., "Lightweight Directory Access Protocol
(LDAP): Authentication Methods and Security
Mechanisms", RFC 4513, June 2006.
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
(LDAP): Syntaxes and Matching Rules", RC 4517, June
2006.
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
Protocol (LDAP): Schema for User Applications", RFC
4519, June 2006.
[X.501] International Telecommunication Union -
Telecommunication Standardization Sector, "The
Directory -- Models," X.501(1993) (also ISO/IEC 9594-
2:1994).
7.2. Informative References
[COSINEpilot] Goodman, D., "PARADISE" section of the March 1991
INTERNET MONTHLY REPORTS (p. 28-29),
http://www.iana.org/periodic-reports/imr-mar91.txt
[ISO3166] International Organization for Standardization, "Codes
for the representation of names of countries", ISO
3166.
[RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500
Schema", RFC 1274, November 1991.
[RFC1279] Hardcastle-Kille, S., "X.500 and Domains", RFC 1279,
November 1991.
[RFC1487] Yeong, W., Howes, T., and S. Kille, "X.500 Lightweight
Directory Access Protocol", RFC 1487, July 1993.
[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight
Directory Access Protocol (v3)", RFC 2251, December
1997.
[RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object
Class", RFC 2798, April 2000.
[RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
version 2 (LDAPv2) to Historic Status", RFC 3494, March
2003.
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
(IANA) Considerations for the Lightweight Directory
Access Protocol (LDAP)", BCP 64, RFC 4520.
Appendix A. Changes since RFC 1274
This document represents a substantial rewrite of RFC 1274. The
following sections summarize the substantive changes.
A.1. LDAP Short Names
A number of COSINE attribute types have short names in LDAP.
X.500 Name LDAP Short Name
------------- ---------------
domainComponent dc
favoriteDrink drink
friendCountryName co
homeTelephoneNumber homePhone
mobileTelephoneNumber mobile
pagerTelephoneNumber pager
rfc822Mailbox mail
userid uid
While the LDAP short names are generally used in LDAP, some
implementations may (for legacy reasons [RFC3494]) recognize the
attribute type by its X.500 name. Hence, the X.500 names have been
reserved solely for this purpose.
Note: ’uid’ and ’dc’ are described in [RFC4519].
A.2. pilotObject
The ’pilotObject’ object class was not brought forward as its
function is largely replaced by operational attributes introduced in
X.500(93) [X.501] and version 3 of LDAP [RFC4512]. For instance, the
function of the ’lastModifiedBy’ and ’lastModifiedTime’ attribute
types is now served by the ’creatorsName’, ’createTimestamp’,
’modifiersName’, and ’modifyTimestamp’ operational attributes
[RFC4512].
A.3. pilotPerson
The ’pilotPerson’ object class was not brought forward as its
function is largely replaced by the ’organizationalPerson’ [RFC4512]
object class and its subclasses, such as ’inetOrgPerson’ [RFC2798].
Most of the related attribute types (e.g., ’mail’, ’manager’) were
brought forward as they are used in other object classes.
A.4. dNSDomain
The ’dNSDomain’ object class and related attribute types were not
brought forward as its use is primarily experimental [RFC1279].
A.5. pilotDSA and qualityLabelledData
The ’pilotDSA’ and ’qualityLabelledData’ object classes, as well as
related attribute types, were not brought forward as its use is
primarily experimental [QoS].
A.6. Attribute Syntaxes
RFC 1274 defined and used caseIgnoreIA5StringSyntax attribute syntax.
This has been replaced with the IA5String syntax and appropriate
matching rules in ’mail’ and ’associatedDomain’.
RFC 1274 restricted ’mail’ to have non-zero length values. This
restriction is not reflected in the IA5String syntax used in the
definitions provided in this specification. However, as values are
to conform to the <Mailbox> production, the ’mail’ should not contain
zero-length values. Unfortunately, the directory service will not
enforce this restriction.
Appendix B. Changes since RFC 2247
The ’domainNameForm’ name form was not brought forward as
specification of name forms used in LDAP is left to a future
specification.
Editor’s Address
Kurt D. Zeilenga
OpenLDAP Foundation
EMail: Kurt@OpenLDAP.org
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).