From 19cf82a74650056e316464eaa45655709779b762 Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Sat, 21 Apr 2001 00:50:06 +0000 Subject: [PATCH] Updates from devel including anonymous modify deny and moddn newsuperior check. --- CHANGES | 1 + doc/rfc/INDEX | 3 + doc/rfc/rfc3045.txt | 339 +++++++++++++++++ doc/rfc/rfc3088.txt | 619 +++++++++++++++++++++++++++++++ servers/slapd/back-ldbm/modrdn.c | 4 +- servers/slapd/backend.c | 5 + servers/slapd/slap.h | 2 +- 7 files changed, 971 insertions(+), 2 deletions(-) create mode 100644 doc/rfc/rfc3045.txt create mode 100644 doc/rfc/rfc3088.txt diff --git a/CHANGES b/CHANGES index 4221f1be5b..e2fb2f4ddf 100644 --- a/CHANGES +++ b/CHANGES @@ -13,6 +13,7 @@ OpenLDAP 2.0.8 Release Engineering Fixed back-ldbm modify password DN bug (ITS#1060) Fixed libldap SASL GSSAPI interop bug (ITS#884) Fixed libldap TLS/SASL crash bugs (ITS#889) + Updated slapd anonymous write default to deny Updated libldap TLS seeding (ITS#948) Updated libldap TLS certificate handling Updated libldap referral/reference handling (ITS#905,1047) diff --git a/doc/rfc/INDEX b/doc/rfc/INDEX index f475a3743e..a4652af33a 100644 --- a/doc/rfc/INDEX +++ b/doc/rfc/INDEX @@ -33,6 +33,9 @@ rfc2830.txt LDAPv3: StartTLS (PS) rfc2831.txt SASL/DIGEST-MD5 (PS) rfc2849.txt LDIFv1 (PS) rfc2891.txt LDAPv3: Server Side Sorting of Search Results (PS) +rfc3045.txt Storing Vendor Information in the LDAP root DSE (I) +rfc3062.txt LDAP Password Modify Extended Operation (PS) +rfc3088.txt OpenLDAP Root Service (E) Legend: STD Standard diff --git a/doc/rfc/rfc3045.txt b/doc/rfc/rfc3045.txt new file mode 100644 index 0000000000..e7abc25c9a --- /dev/null +++ b/doc/rfc/rfc3045.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group M. Meredith +Request for Comments: 3045 Novell Inc. +Category: Informational January 2001 + + + Storing Vendor Information in the LDAP root DSE + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + This document specifies two Lightweight Directory Access Protocol + (LDAP) attributes, vendorName and vendorVersion that MAY be included + in the root DSA-specific Entry (DSE) to advertise vendor-specific + information. These two attributes supplement the attributes defined + in section 3.4 of RFC 2251. + + The information held in these attributes MAY be used for display and + informational purposes and MUST NOT be used for feature advertisement + or discovery. + +Conventions used in this document + + 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 [RFC2219] + +1. Overview + + LDAP clients discover server-specific data--such as available + controls, extensions, etc.--by reading the root DSE. See section 3.4 + of [RFC2251] for details. + + For display, information, and limited function discovery, it is + desirable to be able to query an LDAP server to determine the vendor + name of that server and also to see what version of that vendor's + code is currently installed. + + + + + + +Meredith Informational [Page 1] + +RFC 3045 LDAP Root DSE to Display Vendor Information January 2001 + + +1.1 Function discovery + + There are many ways in which a particular version of a vendor's LDAP + server implementation may be functionally incomplete, or may contain + software anomalies. It is impossible to identify every known + shortcoming of an LDAP server with the given set of server data + advertisement attributes. Furthermore, often times, the anomalies of + an implementation are not found until after the implementation has + been distributed, deployed, and is in use. + + The attributes defined in this document MAY be used by client + implementations in order to identify a particular server + implementation so that it can 'work around' such anomalies. + + The attributes defined in this document MUST NOT be used to gather + information related to supported features of an LDAP implementation. + All LDAP features, mechanisms, and capabilities--if advertised--MUST + be advertised through other mechanisms, preferably advertisement + mechanisms defined in concert with said features, mechanisms, and + capabilities. + +2. Attribute Types + + These attributes are an addition to the Server-specific Data + Requirements defined in section 3.4 of [RFC2251]. The associated + syntaxes are defined in section 4 of [RFC2252]. + + Servers MAY restrict access to vendorName or vendorVersion and + clients MUST NOT expect these attributes to be available. + +2.1 vendorName + + This attribute contains a single string, which represents the name of + the LDAP server implementer. + + All LDAP server implementations SHOULD maintain a vendorName, which + is generally the name of the company that wrote the LDAP Server code + like "Novell, Inc." + + ( 1.3.6.1.1.4 NAME 'vendorName' EQUALITY + 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) + +2.2 vendorVersion + + This attribute contains a string which represents the version of the + LDAP server implementation. + + + + +Meredith Informational [Page 2] + +RFC 3045 LDAP Root DSE to Display Vendor Information January 2001 + + + All LDAP server implementations SHOULD maintain a vendorVersion. + Note that this value is typically a release value--comprised of a + string and/or a string of numbers--used by the developer of the LDAP + server product (as opposed to the supportedLDAPVersion, which + specifies the version of the LDAP protocol supported by this server). + This is single-valued so that it will only have one version value. + This string MUST be unique between two versions, but there are no + other syntactic restrictions on the value or the way it is formatted. + + ( 1.3.6.1.1.5 NAME 'vendorVersion' EQUALITY + 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) + + The intent behind the equality match on vendorVersion is to not allow + a less than or greater than type of query. Say release "LDAPv3 8.0" + has a problem that is fixed in the next release "LDAPv3 8.5", but in + the mean time there is also an update release say version "LDAPv3 + 8.01" that fixes the problem. This will hopefully stop the client + from saying it will not work with a version less than "LDAPv3 8.5" + when it would also work with "LDAPv3 8.01". With the equality match + the client would have to exactly match what it is looking for. + +3. Notes to Server Implementers + + Server implementers may consider tying the vendorVersion attribute + value to the build mechanism so that it is automatically updated when + the version value changes. + +4. Notes to Client Developers + + As mentioned in section 2.1, the use of vendorName and vendorVersion + MUST NOT be used to discover features. + + It should be noted that an anomalies often on affect subset of + implementations reporting the same version information. Most + implementations support multiple platforms, have numerous + configuration options, and often support plug-ins. + + Client implementations SHOULD be written in such a way as to accept + any value in the vendorName and vendorVersion attributes. If a + client implementation does not recognize the specific vendorName or + vendorVersion as one it recognizes, then for the purposes of 'working + around' anomalies, the client MUST assume that the server is complete + and correct. The client MUST work with implementations that do not + publish these attributes. + + + + + + +Meredith Informational [Page 3] + +RFC 3045 LDAP Root DSE to Display Vendor Information January 2001 + + +5. Security Considerations + + The vendorName and vendorVersion attributes are provided only as + display or informational mechanisms, or as anomaly identifying + mechanisms. Client and application implementers must consider that + the existence of a given value in the vendorName or vendorVersion + attribute is no guarantee that the server was actually built by the + asserted vendor or that its version is the asserted version and + should act accordingly. + + Server implementers should be aware that this information could be + used to exploit a security hole a server provides either by feature + or flaw. + +6. IANA Considerations + + This document seeks to create two attributes, vendorName and + vendorVersion, which the IANA will primarily be responsible. This is + a one time effort; there is no need for any recurring assignment + after this stage. + +7. References + + [RFC2219] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, + "Lightweight Directory Access Protocol (v3): Attribute + Syntax Definitions", RFC 2252, December 1997. + +8. Acknowledgments + + The author would like to thank the generous input and review by + individuals at Novell including but not limited to Jim Sermersheim, + Mark Hinckley, Renea Campbell, and Roger Harrison. Also IETF + contributors Kurt Zeilenga, Mark Smith, Mark Wahl, Peter Strong, + Thomas Salter, Gordon Good, Paul Leach, Helmut Volpers. + + + + + + + + +Meredith Informational [Page 4] + +RFC 3045 LDAP Root DSE to Display Vendor Information January 2001 + + +9. Author's Address + + Mark Meredith + Novell Inc. + 1800 S. Novell Place + Provo, UT 84606 + + Phone: 801-861-2645 + EMail: mark_meredith@novell.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Meredith Informational [Page 5] + +RFC 3045 LDAP Root DSE to Display Vendor Information January 2001 + + +10. 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 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Meredith Informational [Page 6] + diff --git a/doc/rfc/rfc3088.txt b/doc/rfc/rfc3088.txt new file mode 100644 index 0000000000..430fbafe12 --- /dev/null +++ b/doc/rfc/rfc3088.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 3088 OpenLDAP Foundation +Category: Experimental April 2001 + + + OpenLDAP Root Service + An experimental LDAP referral service + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + The OpenLDAP Project is operating an experimental LDAP (Lightweight + Directory Access Protocol) referral service known as the "OpenLDAP + Root Service". The automated system generates referrals based upon + service location information published in DNS SRV RRs (Domain Name + System location of services resource records). This document + describes this service. + +1. Background + + LDAP [RFC2251] directories use a hierarchical naming scheme inherited + from X.500 [X500]. Traditionally, X.500 deployments have used a + geo-political naming scheme (e.g., CN=Jane + Doe,OU=Engineering,O=Example,ST=CA,C=US). However, registration + infrastructure and location services in many portions of the naming + hierarchical are inadequate or nonexistent. + + The construction of a global directory requires a robust registration + infrastructure and location service. Use of Internet domain-based + naming [RFC2247] (e.g., UID=jdoe,DC=eng,DC=example,DC=net) allows + LDAP directory services to leverage the existing DNS [RFC1034] + registration infrastructure and DNS SRV [RFC2782] resource records + can be used to locate services [LOCATE]. + + + + + + + + +Zeilenga Experimental [Page 1] + +RFC 3088 OpenLDAP Root Service April 2001 + + +1.1. The Glue + + Most existing LDAP implementations do not support location of + directory services using DNS SRV resource records. However, most + servers support generation of referrals to "superior" server(s). + This service provides a "root" LDAP service which servers may use as + their superior referral service. + + Client may also use the service directly to locate services + associated with an arbitrary Distinguished Name [RFC2253] within the + domain based hierarchy. + + Notice: + The mechanisms used by service are experimental. The descriptions + provided by this document are not definitive. Definitive + mechanisms shall be published in a Standard Track document(s). + +2. Generating Referrals based upon DNS SRV RRs + + This service returns referrals generated from DNS SRV resource + records [RFC2782]. + +2.1. DN to Domain Name Mapping + + The service maps a DN [RFC2253] to a fully qualified domain name + using the following algorithm: + + domain = null; + foreach RDN left-to-right // [1] + + { + if not multi-valued RDN and + RDN.type == domainComponent + { + if ( domain == null || domain == "." ) + { // start + domain = ""; + } + else + { // append separator + domain .= "."; + } + + if ( RDN.value == "." ) + { // root + domain = "."; + } + else + + + +Zeilenga Experimental [Page 2] + +RFC 3088 OpenLDAP Root Service April 2001 + + + { // append domainComponent + domain .= RDN.value; + } + continue; + } + domain = null; + } + + Examples: + + Distinguished Name Domain + ----------------------------- ------------ + DC=example,DC=net example.net + UID=jdoe,DC=example,DC=net example.net + DC=. . [2] + DC=example,DC=net,DC=. . [3] + DC=example,DC=.,DC=net net [4] + DC=example.net example.net [5] + CN=Jane Doe,O=example,C=US null + UID=jdoe,DC=example,C=US null + DC=example,O=example,DC=net net + DC=example+O=example,DC=net net + DC=example,C=US+DC=net null + + Notes: + + 0) A later incarnation will use a Standard Track mechanism. + + 1) A later incarnation of this service may use a right-to-left + algorithm. + + 2) RFC 2247 does not state how one can map the domain representing + the root of the domain tree to a DN. We suggest the root of the + domain tree be mapped to "DC=." and that this be reversable. + + 3) RFC 2247 states that domain "example.net" should be mapped to the + DN "DC=example,DC=net", not to "DC=example,DC=net,DC=.". As it is + not our intent to introduce or support an alternative domain to DN + mapping, the algorithm ignores domainComponents to the left of + "DC=.". + + 4) RFC 2247 states that domain "example.net" should be mapped to the + DN "DC=example,DC=net", not to "DC=example,DC=.,DC=net". As it is + not our intent to introduce or support an alternative domain to DN + mapping, the algorithm ignores domainComponents to the left of + "DC=." and "DC=." itself if further domainComponents are found to + the right. + + + + +Zeilenga Experimental [Page 3] + +RFC 3088 OpenLDAP Root Service April 2001 + + + 5) RFC 2247 states that value of an DC attribute type is a domain + component. It should not contain multiple domain components. A + later incarnation of this service may map this domain to null or + be coded to return invalid DN error. + + If the domain is null or ".", the service aborts further processing + and returns noSuchObject. Later incarnation of this service may + abort processing if the resulting domain is a top-level domain. + +2.2. Locating LDAP services + + The root service locates services associated with a given fully + qualified domain name by querying the Domain Name System for LDAP SRV + resource records. For the domain example.net, the service would do a + issue a SRV query for the domain "_ldap._tcp.example.net". A + successful query will return one or more resource records of the + form: + + _ldap._tcp.example.net. IN SRV 0 0 389 ldap.example.net. + + If no LDAP SRV resource records are returned or any DNS error occurs, + the service aborts further processing and returns noSuchObject. + Later incarnations of this service will better handle transient + errors. + +2.3. Constructing an LDAP Referrals + + For each DNS SRV resource record returned for the domain, a LDAP URL + [RFC2255] is constructed. For the above resource record, the URL + would be: + + ldap://ldap.example.net:389/ + + These URLs are then returned in the referral. The URLs are currently + returned in resolver order. That is, the server itself does not make + use of priority or weight information in the SRV resource records. A + later incarnation of this service may. + +3. Protocol Operations + + This section describes how the service performs basic LDAP + operations. The service supports operations extended through certain + controls as described in a later section. + + + + + + + + +Zeilenga Experimental [Page 4] + +RFC 3088 OpenLDAP Root Service April 2001 + + +3.1. Basic Operations + + Basic (add, compare, delete, modify, rename, search) operations + return a referral result if the target (or base) DN can be mapped to + a set of LDAP URLs as described above. Otherwise a noSuchObject + response or other appropriate response is returned. + +3.2. Bind Operation + + The service accepts "anonymous" bind specifying version 2 or version + 3 of the protocol. All other bind requests will return a non- + successful resultCode. In particular, clients which submit clear + text credentials will be sent an unwillingToPerform resultCode with a + cautionary text regarding providing passwords to strangers. + + As this service is read-only, LDAPv3 authentication [RFC2829] is not + supported. + +3.3. Unbind Operations + + Upon receipt of an unbind request, the server abandons all + outstanding requests made by client and disconnects. + +3.4. Extended Operations + + The service currently does recognize any extended operation. Later + incarnations of the service may support Start TLS [RFC2830] and other + operations. + +3.5. Update Operations + + A later incarnation of this service may return unwillingToPerform for + all update operations as this is an unauthenticated service. + +4. Controls + + The service supports the ManageDSAit control. Unsupported controls + are serviced per RFC 2251. + +4.1. ManageDSAit Control + + The server recognizes and honors the ManageDSAit control [NAMEDREF] + provided with operations. + + If DNS location information is available for the base DN itself, the + service will return unwillingToPerform for non-search operations. + For search operations, an entry will be returned if within scope and + matches the provided filter. For example: + + + +Zeilenga Experimental [Page 5] + +RFC 3088 OpenLDAP Root Service April 2001 + + + c: searchRequest { + base="DC=example,DC=net" + scope=base + filter=(objectClass=*) + ManageDSAit + } + + s: searchEntry { + dn: DC=example,DC=net + objectClass: referral + objectClass: extensibleObject + dc: example + ref: ldap://ldap.example.net:389/ + associatedDomain: example.net + } + s: searchResult { + success + } + + If DNS location information is available for the DC portion of a + subordinate entry, the service will return noSuchObject with the + matchedDN set to the DC portion of the base for search and update + operations. + + c: searchRequest { + base="CN=subordinate,DC=example,DC=net" + scope=base + filter=(objectClass=*) + ManageDSAit + } + + s: searchResult { + noSuchObject + matchedDN="DC=example,DC=net" + } + +5. Using the Service + + Servers may be configured to refer superior requests to + . + + Though clients may use the service directly, this is not encouraged. + Clients should use a local service and only use this service when + referred to it. + + The service supports LDAPv3 and LDAPv2+ [LDAPv2+] clients over + TCP/IPv4. Future incarnations of this service may support TCP/IPv6 + or other transport/internet protocols. + + + +Zeilenga Experimental [Page 6] + +RFC 3088 OpenLDAP Root Service April 2001 + + +6. Lessons Learned + +6.1. Scaling / Reliability + + This service currently runs on a single host. This host and + associated network resources are not yet exhausted. If they do + become exhausted, we believe we can easily scale to meet the demand + through common distributed load balancing technics. The service can + also easily be duplicated locally. + +6.2. Protocol interoperability + + This service has able avoided known interoperability issues in + supporting variants of LDAP. + +6.2.1. LDAPv3 + + The server implements all features of LDAPv3 [RFC2251] necessary to + provide the service. + +6.2.2. LDAPv2 + + LDAPv2 [RFC1777] does not support the return of referrals and hence + may not be referred to this service. Though a LDAPv2 client could + connect and issue requests to this service, the client would treat + any referral returned to it as an unknown error. + +6.2.3. LDAPv2+ + + LDAPv2+ [LDAPv2+] provides a number of extensions to LDAPv2, + including referrals. LDAPv2+, like LDAPv3, does not require a bind + operation before issuing of other operations. As the referral + representation differ between LDAPv2+ and LDAPv3, the service returns + LDAPv3 referrals in this case. However, as commonly deployed LDAPv2+ + clients issue bind requests (for compatibility with LDAPv2 servers), + this has not generated any interoperability issues (yet). + + A future incarnation of this service may drop support for LDAPv2+ + (and LDAPv2). + +6.2.4. CLDAP + + CLDAP [RFC1798] does not support the return of referrals and hence is + not supported. + + + + + + + +Zeilenga Experimental [Page 7] + +RFC 3088 OpenLDAP Root Service April 2001 + + +7. Security Considerations + + This service provides information to "anonymous" clients. This + information is derived from the public directories, namely the Domain + Name System. + + The use of authentication would require clients to disclose + information to the service. This would be an unnecessary invasion of + privacy. + + The lack of encryption allows eavesdropping upon client requests and + responses. A later incarnation of this service may support + encryption (such as via Start TLS [RFC2830]). + + Information integrity protection is not provided by the service. The + service is subject to varies forms of DNS spoofing and attacks. LDAP + session or operation integrity would provide false sense of security + concerning the integrity of DNS information. A later incarnation of + this service may support DNSSEC and provide integrity protection (via + SASL, TLS, or IPSEC). + + The service is subject to a variety of denial of service attacks. + The service is capable of blocking access by a number of factors. + This capability have yet to be used and likely would be ineffective + in preventing sophisticated attacks. Later incarnations of this + service will likely need better protection from such attacks. + +8. Conclusions + + DNS is good glue. By leveraging of the Domain Name System, global + LDAP directories may be built without requiring a protocol specific + registration infrastructures. + + In addition, use of DNS service location allows global directories to + be built "ad hoc". That is, anyone with a domain name can + participate. There is no requirement that the superior domain + participate. + +9. Additional Information + + Additional information about the OpenLDAP Project and the OpenLDAP + Root Service can be found at . + + + + + + + + + +Zeilenga Experimental [Page 8] + +RFC 3088 OpenLDAP Root Service April 2001 + + +10. Author's Address + + Kurt Zeilenga + OpenLDAP Foundation + + EMail: kurt@openldap.org + +11. Acknowledgments + + Internet hosting for this experiment is provided by the Internet + Software Consortium . Computing resources were + provided by Net Boolean Incorporated . This + experiment would not have been possible without the contributions of + numerous volunteers of the open source community. Mechanisms + described in this document are based upon those introduced in + [RFC2247] and [LOCATE]. + +References + + [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, November 1987. + + [RFC1777] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory + Access Protocol", RFC 1777, March 1995. + + [RFC1798] Young, A., "Connection-less Lightweight Directory Access + Protocol", RFC 1798, June 1995. + + [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 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. + + [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [RFC2253] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory + Access Protocol (v3): UTF-8 String Representation of + Distinguished Names", RFC 2253, December 1997. + + [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, + December 1997. + + [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + + +Zeilenga Experimental [Page 9] + +RFC 3088 OpenLDAP Root Service April 2001 + + + [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, + "Authentication Methods for LDAP", RFC 2829, May 2000. + + [RFC2830] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory + Access Protocol (v3): Extension for Transport Layer + Security", RFC 2830, May 2000. + + [LOCATE] IETF LDAPext WG, "Discovering LDAP Services with DNS", + Work in Progress. + + [LDAPv2+] University of Michigan LDAP Team, "Referrals within the + LDAPv2 Protocol", August 1996. + + [NAMEDREF] Zeilenga, K. (editor), "Named Subordinate References in + LDAP Directories", Work in Progress. + + [X500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, + Models and Service", 1993. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Experimental [Page 10] + +RFC 3088 OpenLDAP Root Service April 2001 + + +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 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Zeilenga Experimental [Page 11] + diff --git a/servers/slapd/back-ldbm/modrdn.c b/servers/slapd/back-ldbm/modrdn.c index 38572293a9..78f8383572 100644 --- a/servers/slapd/back-ldbm/modrdn.c +++ b/servers/slapd/back-ldbm/modrdn.c @@ -332,7 +332,9 @@ ldbm_back_modrdn( goto return_results; } - if ( strcasecmp( old_rdn_type, new_rdn_type ) != 0 ) { + if ( newSuperior == NULL + && strcasecmp( old_rdn_type, new_rdn_type ) != 0 ) + { /* Not a big deal but we may say something */ Debug( LDAP_DEBUG_TRACE, "ldbm_back_modrdn: old_rdn_type=%s, new_rdn_type=%s!\n", diff --git a/servers/slapd/backend.c b/servers/slapd/backend.c index 467d0adfe3..74fd594fab 100644 --- a/servers/slapd/backend.c +++ b/servers/slapd/backend.c @@ -761,6 +761,11 @@ backend_check_restrictions( *text = "update confidentiality required"; return LDAP_CONFIDENTIALITY_REQUIRED; } + + if( op->o_ndn == NULL ) { + *text = "modifications require authentication"; + return LDAP_OPERATIONS_ERROR; + } } } diff --git a/servers/slapd/slap.h b/servers/slapd/slap.h index ee4d4d34f4..bed78c771e 100644 --- a/servers/slapd/slap.h +++ b/servers/slapd/slap.h @@ -37,7 +37,7 @@ LDAP_BEGIN_DECL #define SERVICE_NAME OPENLDAP_PACKAGE "-slapd" -#define SLAPD_ANONYMOUS "" +#define SLAPD_ANONYMOUS "cn=anonymous" #ifdef f_next #undef f_next /* name conflict between sys/file.h on SCO and struct filter */ -- 2.39.2