Storing Vendor Information in the LDAP root DSE
How LDAP servers advertise their vendor and version
Meredith, M., "Storing Vendor Information in the LDAP root DSE", RFC 3045, DOI 10.17487/RFC3045, January 2001, <https://www.rfc-editor.org/info/rfc3045>.
@misc{rfc3045,
series = {Request for Comments},
number = 3045,
howpublished = {RFC 3045},
publisher = {RFC Editor},
doi = {10.17487/RFC3045},
url = {https://www.rfc-editor.org/info/rfc3045},
author = {M. Meredith},
title = {{Storing Vendor Information in the LDAP root DSE}},
pagetotal = 6,
year = 2001,
month = jan,
} RFC text
Contents
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.
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.
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.
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.
9. Author's Address
Mark Meredith
Novell Inc.
1800 S. Novell Place
Provo, UT 84606
Phone: 801-861-2645
EMail: mark_meredith@novell.com
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.
AI ELI5
On this page
§1Introduction
LDAP (Lightweight Directory Access Protocol) is a system for accessing directory information, like a phone book for the internet. When an LDAP client connects to a server, it can query the root DSE (Directory Server Entry) to discover information about that server, such as what controls and extensions it supports.
This RFC adds two new attributes that servers can place in the root DSE: vendorName (the name of the company that wrote the server) and vendorVersion (the release version number of that software).
When you connect to an LDAP server, it is like knocking on a door. The server can tell you who runs the building and what version of the locks they have installed.
§2The Two Attributes
vendorName is a single text field containing the name of the LDAP server implementer, such as 'Novell, Inc.' or another vendor. It is optional and read-only, meaning clients cannot modify it. All LDAP server implementations SHOULD maintain this attribute.
vendorVersion contains a string representing the version of the LDAP server software, such as 'LDAPv3 8.0' or similar version numbers used by the software developer. Like vendorName, it is single-valued, read-only, and optional. The version string MUST be unique between different versions, but vendors can format it however they choose.
vendorName is like the company logo on the front door. vendorVersion is the version number, like '3.0' or '2.1'.
§3Using Vendor Information
Software often has bugs or incomplete features. It is impossible to catalog every known issue in the standard LDAP attributes. When clients discover a known issue with a particular version of a server, they can use vendorName and vendorVersion to identify that exact version and apply a workaround.
However, these attributes MUST NOT be used to discover or advertise features. Feature discovery should use proper LDAP mechanisms, preferably ones defined alongside those features. Many server implementations support multiple platforms and configurations, so bugs may only affect certain setups. Clients SHOULD accept any value in these attributes and MUST assume a server is correct if they do not recognize the vendor or version.
If a programmer finds a quirk in version 3.5 of a directory server, they can tell their software, 'When you see this vendor and version, do this workaround.'
§4Security Considerations
These attributes are provided only for display, information, and anomaly identification. The mere presence of vendor and version information does not guarantee that the server was actually built by that vendor or that the version is authentic. A misconfigured or compromised server could report false information.
Server implementers should be aware that this information could be misused to target security exploits. An attacker who learns that a server is running a specific version with a known vulnerability can attempt to exploit it. However, the RFC itself does not introduce new security issues beyond those already present in LDAP.
A server could lie about who made it or what version it is. Bad people might use this information to find servers with known problems and attack them.
§5Notes for Implementers
Server implementers SHOULD maintain accurate vendorName and vendorVersion attributes. Developers may consider tying the vendorVersion to the build mechanism so it is automatically updated when the version number changes.
Client developers must remember that vendorName and vendorVersion are NOT mechanisms for feature discovery. Clients written to accept any value in these attributes, and to assume a server is complete and correct if they do not recognize it, will be more robust and compatible with diverse LDAP implementations. Clients MUST work with servers that do not publish these attributes at all.
Server makers should keep this information up to date. Client makers should not rely on it to figure out what the server can do—they should ask the server directly about its features.