+
+
INTERNET-DRAFT Michael P. Armijo
-<draft-ietf-ldapext-locate-04.txt> Levon Esibov
-August, 2000 Paul Leach
-Expires: February, 2001 Microsoft Corporation
+<draft-ietf-ldapext-locate-06.txt> Levon Esibov
+November 13, 2001 Paul Leach
+Expires: May 13, 2002 Microsoft Corporation
R.L. Morgan
University of Washington
ietf-ldapext-locate-04.txt>, and expires on February 25, 2001.
Please send comments to the authors.
+ Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
-1. Abstract
+Abstract
A Lightweight Directory Access Protocol (LDAP) request must be
directed to an appropriate server for processing. This document
the Domain Name System.
-2. Introduction
+
+
+
+
+
+
+
+Armijo, Esibov, Leach and Morgan [Page 1]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS Novemeber 13, 2001
+
+
+
+1. Introduction
The LDAPv3 protocol [1] is designed to be a lightweight access
protocol for directory services supporting X.500 models. As a
names, and use of domain-name-based DNs is becoming common.
-3. Mapping Distinguished Names into Domain Names
+
+2. Mapping Distinguished Names into Domain Names
This section defines a method of converting a DN into a DNS domain
name for use in the server location method described below. Some
DNs cannot be converted into a domain name. Converted DNs result
in a fully qualified domain name.
+Armijo, Esibov, Leach and Morgan [Page 2]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS Novemeber 13, 2001
+
+
+
The output domain name is initially empty. The DN is processed in
right-to-left order (i.e., beginning with the first RDN in the
sequence of RDNs). An RDN is able to be converted if it (1)
example.net.
The determined DNS name will be submitted as a DNS query using the
- algorithm defined in section 4.
+ algorithm defined in section 3.
-4. Locating LDAP servers through DNS
- LDAP server location information is to be stored using DNS Service
+3. Locating LDAPv3 servers through DNS
+
+ LDAPv3 server location information is to be stored using DNS Service
Location Record (SRV)[5]. The data in a SRV record contains the DNS
name of the server that provides the LDAP service, corresponding
Port number, and parameters that enable the client to choose an
_<Service>._<Proto>.<Domain>
- where <Service> is always "ldap", and <Proto> is a protocol that can
- be either "udp" or "tcp". <Domain> is the domain name formed by
- converting the DN of a naming context mastered by the LDAP Server
- into a domain name using the algorithm in Section 3. Note that
- "ldap" is the symbolic name for the LDAP service in Assigned
- Numbers[6], as required by [5].
+ where <Service> is "ldap", and <Proto> is "tcp". <Domain> is the
+ domain name formed by converting the DN of a naming context mastered
+ by the LDAP Server into a domain name using the algorithm in
+ Section 2. Note that "ldap" is the symbolic name for the LDAP
+ service in Assigned Numbers[6], as required by [5].
+
+
+
+
+
+
+
+
+
+
+Armijo, Esibov, Leach and Morgan [Page 3]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS Novemeber 13, 2001
+
+
Presence of such records enables clients to find the LDAP servers
using standard DNS query [4]. A client (or server) seeking an LDAP
server for a particular DN converts that DN to a domain name using
- the algorithm of Section 3, does a SRV record query using the DNS
+ the algorithm of Section 2, does a SRV record query using the DNS
name formed as described in the preceding paragraph, and interprets
the response as described in [5] to determine a host (or hosts) to
contact. As an example, a client that searches for an LDAP server
portion of the constructed fully qualified domain name.
+
+4. IANA Considerations
+
+ This document does not require any IANA actions.
+
+
5. Security Considerations
DNS responses can typically be easily spoofed. Clients using this
intended to contact. See [7] for more information on security
threats and security mechanisms.
+ The client MUST use the server hostname it used to open the LDAP
+ connection as the value to compare against the server name as
+ expressed in the server's certificate. The client MUST NOT use the
+ server's canonical DNS name or any other derived form of name.
+
This document describes a method that uses DNS SRV records to
discover LDAP servers. All security considerations related to DNS
SRV records are inherited by this document. See the security
considerations section in [5] for more details.
+
+
+Armijo, Esibov, Leach and Morgan [Page 4]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS Novemeber 13, 2001
+
+
6. References
[1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
[6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
- [7] Wahl, M., Alvestrand, H., Hodges, J. and Morgan, R.,
+ [7] Wahl, M., Alvestrand, H., Hodges, J. and Morgan, R.,
"Authentication Methods for LDAP", RFC 2829, May 2000.
+ [8] Hodges, J., Morgan, R., Wahl, M., "Lightweight Directory Access
+ Protocol (v3): Extension for Transport Layer Security", RFC 2830,
+ May 2000.
+
+
+
+
+
7. Authors' Addresses
Redmond, WA 98052
levone@microsoft.com
+
+
+Armijo, Esibov, Leach and Morgan [Page 5]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS Novemeber 13, 2001
+
RL "Bob" Morgan
University of Washington
4545 15th Ave NE
EMail: rlmorgan@washington.edu
URI: http://staff.washington.edu/rlmorgan/
- Expires February 25, 2001
+8. Intellectual Property Statement
+
+The IETF takes no position regarding the validity or scope of any
+intellectual property 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; neither does it represent that it has made any
+effort to identify any such rights. Information on the IETF's
+procedures with respect to rights in standards-track and standards-
+related documentation can be found in BCP-11. Copies of claims of
+rights made available for publication 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
+implementors or users of this specification can be obtained from the
+IETF Secretariat.
+
+The IETF invites any interested party to bring to its attention any
+copyrights, patents or patent applications, or other proprietary rights
+which may cover technology that may be required to practice this
+standard. Please address the information to the IETF Executive
+Director.
+
+
+9. Full Copyright Statement
+
+Copyright (C) The Internet Society (2001). All Rights Reserved.
+This document and translations of it may be copied and furnished to
+others, and derivative works that comment on or otherwise explain it or
+assist in its implementation may be prepared, copied, published and
+distributed, in whole or in part, without restriction of any kind,
+provided that the above copyright notice and this paragraph are included
+on all such copies and derivative works. However, this document itself
+may not be modified in any way, such as by removing the copyright notice
+or references to the Internet Society or other Internet organizations,
+except as needed for the purpose of developing Internet standards in
+which case the procedures for copyrights defined in the Internet
+Standards process must be followed, or as required to translate it into
+languages other than English. The limited permissions granted above are
+perpetual and will not be revoked by the Internet Society or its
+successors or assigns. This document and the information contained
+herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
+
+
+Armijo, Esibov, Leach and Morgan [Page 6]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS Novemeber 13, 2001
+
+INTERNET ENGINEERING TASK FORCE DISCLAIMS 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."
+
+
+10. Expiration Date
+ This documentis filed as <draft-ietf-ldapext-locate-06.txt>, and
+ expires May 13, 2002.
+Armijo, Esibov, Leach and Morgan [Page 7]
\ No newline at end of file
#
attributetype ( 2.5.4.41 NAME 'name'
- DESC 'RFC2256: common supertype of name attributes'
+ DESC 'RFC2256: common supertype of name attributes'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
attributetype ( 2.5.4.49 NAME 'distinguishedName'
- DESC 'RFC2256: common supertype of distingushed name attributes'
+ DESC 'RFC2256: common supertype of distingushed name attributes'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
#
attributetype ( 2.5.4.0 NAME 'objectClass'
- DESC 'RFC2256: object classes of the entity'
+ DESC 'RFC2256: object classes of the entity'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
attributetype ( 2.5.4.2 NAME 'knowledgeInformation'
- DESC 'RFC2256: knowledge information'
+ DESC 'RFC2256: knowledge information'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
DESC 'RFC2256: initials of some or all of names, but not the surname(s).'
SUP name )
-attributetype ( 2.5.4.44 NAME 'generationQualifier'
+attributetype ( 2.5.4.44 NAME 'generationQualifier'
DESC 'RFC2256: name qualifier indicating a generation'
SUP name )
MAY ( certificateRevocationList $ authorityRevocationList $
deltaRevocationList ) )
-objectclass ( 2.5.6.20 NAME 'dmd' SUP top STRUCTURAL
+objectclass ( 2.5.6.20 NAME 'dmd'
+ SUP top STRUCTURAL
MUST ( dmdName )
MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
x121Address $ registeredAddress $ destinationIndicator $
DESC 'RFC2252: extensible object'
SUP top AUXILIARY )
-objectclass ( 2.5.20.1 NAME 'subschema' AUXILIARY
- DESC 'RFC2252: controlling subschema (subentry)'
+objectclass ( 2.5.20.1 NAME 'subschema'
+ DESC 'RFC2252: controlling subschema (subentry)'
+ AUXILIARY
MAY ( dITStructureRules $ nameForms $ ditContentRules $
objectClasses $ attributeTypes $ matchingRules $
matchingRuleUse ) )
SUP top AUXILIARY
MUST userCertificate )
-objectclass ( 2.5.6.22 NAME 'pkiCA' SUP top AUXILIARY
+objectclass ( 2.5.6.22 NAME 'pkiCA'
DESC 'RFC2587: PKI certificate authority'
+ SUP top AUXILIARY
MAY ( authorityRevocationList $ certificateRevocationList $
cACertificate $ crossCertificatePair ) )
-objectclass ( 2.5.6.23 NAME 'deltaCRL' SUP top AUXILIARY
+objectclass ( 2.5.6.23 NAME 'deltaCRL'
DESC 'RFC2587: PKI user'
+ SUP top AUXILIARY
MAY deltaRevocationList )
#
# LDAPsubEntry
# likely to change!
-objectclass ( 2.16.840.1.113719.2.142.6.1.1 NAME 'LDAPsubEntry'
+objectclass ( 2.16.840.1.113719.2.142.6.1.1
+ NAME 'LDAPsubEntry'
DESC 'LDAP Subentry'
SUP top STRUCTURAL MAY cn )
SYNTAX 1.3.6.1.4.1.4203.1.1.1
SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
+# OpenLDAP Access Control Information
+# Experimental
attributetype ( 1.3.6.1.4.1.4203.666.1.5
NAME 'OpenLDAPaci'
DESC 'OpenLDAP access control information (experimental)'
SYNTAX 1.3.6.1.4.1.4203.666.2.1
USAGE directoryOperation )
-#
-# Author: Ando <ando@OpenLDAP.org>
-# Subject: Monitor schema items
-# Date: 2001/07/09
-# Status: Work in Progress
-#
-
-#
# monitorSubEntry
-#
-# Notes: in 'cn' (inherited from 'LDAPsubEntry') it holds the name
-# of the subsystem it is monitoring
-#
+# Notes: in 'cn' (inherited from 'LDAPsubEntry') it holds the name
+# of the subsystem it is monitoring
+# Experimental!
#objectclass ( 1.3.6.1.4.1.4203.666.X.Y.Z
# NAME 'monitorSubEntry'
# DESC 'OpenLDAP ancestor class for system monitoring'
projects / openldap / commitdiff