INTERNET-DRAFT Michael P. Armijo
-<draft-ietf-ldapext-locate-02.txt> Levon Esibov
-April, 2000 Paul Leach
-Expires: October, 2000 Microsoft Corporation
+<draft-ietf-ldapext-locate-04.txt> Levon Esibov
+August, 2000 Paul Leach
+Expires: February, 2001 Microsoft Corporation
R.L. Morgan
University of Washington
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited. It is filed as <draft-
- ietf-ldapext-locate-02.txt>, and expires on October 15, 2000.
+ ietf-ldapext-locate-04.txt>, and expires on February 25, 2001.
Please send comments to the authors.
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.
+ DNs cannot be converted into a domain name. Converted DNs result
+ in a fully qualified domain name.
- The output domain name is initially empty. For each RDN component
- of the DN, beginning with the first, if the attribute type is "DC",
- then the attribute value is used as a domain name component (label).
- The first such value becomes the most significant (i.e., rightmost)
- domain name component, and successive values occupy less significant
- positions (i.e., extending leftward), in order. If the attribute
- type is not "DC", then processing stops. If the first RDN component
- of the DN is not of type "DC" then the DN cannot be converted to a
- domain name.
+ 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)
+ consists of a single AttributeTypeAndValue; (2) the attribute type
+ is "DC"; and (3) the attribute value is non-null. If it can be
+ converted, the attribute value is used as a domain name component
+ (label). The first such value becomes the rightmost (i.e., most
+ significant) domain name component, and successive converted RDN
+ values extend to the left. If an RDN cannot be converted,
+ processing stops. If the output domain name is empty when
+ processing stops, the DN cannot be converted into a domain name.
+
+ For DN:
+
+ cn=John Doe,ou=accounting,dc=example,dc=net
+
+ The client would convert the DC components as defined above into
+ DNS name:
+
+ example.net.
+
+ The determined DNS name will be submitted as a DNS query using the
+ algorithm defined in section 4.
4. Locating LDAP servers through DNS
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 2. Note that
+ 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].
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 2, does a SRV record query using the DNS
+ the algorithm of Section 3, 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
_ldap._tcp.example.net. IN SRV 0 0 389 phoenix.example.net.
The set of returned records may contain multiple records in the case
- where multiple LDAP servers serve the same domain.
-
+ where multiple LDAP servers serve the same domain. If there are no
+ matching SRV records available for the converted DN the client SHOULD
+ NOT attempt to 'walk the tree' by removing the least significant
+ portion of the constructed fully qualified domain name.
5. Security Considerations
+ DNS responses can typically be easily spoofed. Clients using this
+ location method SHOULD ensure, via use of strong security
+ mechanisms, that the LDAP server they contact is the one they
+ intended to contact. See [7] for more information on security
+ threats and security mechanisms.
+
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 [6] for more details.
+ considerations section in [5] for more details.
6. References
[6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
+ [7] Wahl, M., Alvestrand, H., Hodges, J. and Morgan, R.,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
-6. Authors' Addresses
+7. Authors' Addresses
Michael P. Armijo
One Microsoft Way
EMail: rlmorgan@washington.edu
URI: http://staff.washington.edu/rlmorgan/
- Expires October, 2000
+ Expires February 25, 2001
+
+
projects / openldap / blobdiff