From: Kurt Zeilenga Date: Wed, 5 Dec 2001 23:16:35 +0000 (+0000) Subject: Misc I-D updates X-Git-Tag: LDBM_PRE_GIANT_RWLOCK~759 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=8362bc91f5b761b922837fcbc8131c9956668523;p=openldap Misc I-D updates Misc schema updates --- diff --git a/doc/drafts/draft-ietf-ldapext-locate-xx.txt b/doc/drafts/draft-ietf-ldapext-locate-xx.txt index 88d6cd2b01..5df1a32760 100644 --- a/doc/drafts/draft-ietf-ldapext-locate-xx.txt +++ b/doc/drafts/draft-ietf-ldapext-locate-xx.txt @@ -1,7 +1,9 @@ + + INTERNET-DRAFT Michael P. Armijo - Levon Esibov -August, 2000 Paul Leach -Expires: February, 2001 Microsoft Corporation + Levon Esibov +November 13, 2001 Paul Leach +Expires: May 13, 2002 Microsoft Corporation R.L. Morgan University of Washington @@ -32,8 +34,12 @@ Status of this Memo 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 @@ -41,7 +47,20 @@ Status of this Memo 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 @@ -85,13 +104,20 @@ Status of this Memo 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) @@ -114,12 +140,13 @@ Status of this Memo 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 @@ -128,17 +155,31 @@ Status of this Memo _._. - where is always "ldap", and is a protocol that can - be either "udp" or "tcp". 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 is "ldap", and is "tcp". 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 @@ -160,6 +201,12 @@ Status of this Memo 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 @@ -168,12 +215,24 @@ Status of this Memo 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 @@ -196,9 +255,17 @@ Status of this Memo [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 @@ -217,6 +284,12 @@ Status of this Memo 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 @@ -227,7 +300,63 @@ Status of this Memo 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 , and + expires May 13, 2002. +Armijo, Esibov, Leach and Morgan [Page 7] \ No newline at end of file diff --git a/servers/slapd/schema/core.schema b/servers/slapd/schema/core.schema index c93fb23dbb..f09804d60f 100644 --- a/servers/slapd/schema/core.schema +++ b/servers/slapd/schema/core.schema @@ -137,13 +137,13 @@ attributetype ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes' # 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 ) @@ -152,7 +152,7 @@ attributetype ( 2.5.4.49 NAME 'distinguishedName' # 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 ) @@ -162,7 +162,7 @@ attributetype ( 2.5.4.1 NAME ( 'aliasedObjectName' 'aliasedEntryName' ) 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} ) @@ -368,7 +368,7 @@ attributetype ( 2.5.4.43 NAME 'initials' 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 ) @@ -567,7 +567,8 @@ objectclass ( 2.5.6.19 NAME 'cRLDistributionPoint' 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 $ @@ -584,8 +585,9 @@ objectclass ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' 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 ) ) @@ -599,13 +601,15 @@ objectclass ( 2.5.6.21 NAME 'pkiUser' 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 ) @@ -699,7 +703,8 @@ objectclass ( 2.16.840.1.113730.3.2.6 NAME 'referral' # # 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 ) @@ -797,6 +802,8 @@ attributetype ( 1.3.6.1.4.1.4203.1.3.2 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)' @@ -804,19 +811,10 @@ attributetype ( 1.3.6.1.4.1.4203.666.1.5 SYNTAX 1.3.6.1.4.1.4203.666.2.1 USAGE directoryOperation ) -# -# Author: Ando -# 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' diff --git a/servers/slapd/schema/cosine.schema b/servers/slapd/schema/cosine.schema index 69283fd997..6ae5c593ae 100644 --- a/servers/slapd/schema/cosine.schema +++ b/servers/slapd/schema/cosine.schema @@ -10,7 +10,7 @@ # # Note: It seems that the pilot schema evolved beyond what was # described in RFC1274. However, this document attempts to describes -# RFC1274 as published. +# RFC1274 as published. # # Depends on core.schema @@ -1258,7 +1258,7 @@ objectclass ( 0.9.2342.19200300.100.4.14 NAME 'RFC822localPart' # objectclass ( 0.9.2342.19200300.100.4.15 NAME 'dNSDomain' SUP 'domain' STRUCTURAL - MAY ( ARecord $ MDRecord $ MXRecord $ NSRecord $ + MAY ( ARecord $ MDRecord $ MXRecord $ NSRecord $ SOARecord $ CNAMERecord ) ) @@ -1276,6 +1276,7 @@ objectclass ( 0.9.2342.19200300.100.4.15 NAME 'dNSDomain' # ::= {pilotObjectClass 17} # objectclass ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject' + DESC 'RFC1274: an object related to an domain' SUP top AUXILIARY MUST associatedDomain ) diff --git a/servers/slapd/schema/inetorgperson.schema b/servers/slapd/schema/inetorgperson.schema index 3112dd265c..525a70714d 100644 --- a/servers/slapd/schema/inetorgperson.schema +++ b/servers/slapd/schema/inetorgperson.schema @@ -6,12 +6,12 @@ # Definition of an X.500 Attribute Type and an Object Class to Hold # Uniform Resource Identifiers (URIs) [RFC2079] # (core.schema) -# +# # A Summary of the X.500(96) User Schema for use with LDAPv3 [RFC2256] # (core.schema) # # The COSINE and Internet X.500 Schema [RFC1274] (cosine.schema) - + # carLicense # This multivalued field is used to record the values of the license or # registration plate associated with an individual. @@ -72,7 +72,7 @@ attributetype ( 2.16.840.1.113730.3.1.4 # Interchange Format [JFIF]. # Note that the jpegPhoto attribute type was defined for use in the # Internet X.500 pilots but no referencable definition for it could be -# located. +# located. attributetype ( 0.9.2342.19200300.100.1.60 NAME 'jpegPhoto' DESC 'RFC2798: a JPEG image' @@ -139,4 +139,4 @@ objectclass ( 2.16.840.1.113730.3.2.2 photo $ roomNumber $ secretary $ uid $ userCertificate $ x500uniqueIdentifier $ preferredLanguage $ userSMIMECertificate $ userPKCS12 ) - ) + )