摘要

  • RFC 3045 在 LDAP 服务器的 root DSE 中定义了可选的 vendorName 和 vendorVersion 属性，用于展示实现厂商，或帮助识别某类软件异常。
  • RFC 明确禁止把这些字符串用于发现功能。服务器自报的厂商和版本既不是软件来源的认证，也不能证明某项能力在当前服务器或会话中可用。

LDAP 客户端原本就可以读取 root DSA-specific Entry，也就是 root DSE，了解当前连接到的那台服务器。RFC 3045 在这个响应中增加了两个可选线索：vendorName 和 vendorVersion。这份 2001 年 1 月发布的信息类 RFC 允许服务器报告软件实现者和产品版本字符串。这两个属性是单值的操作属性，不是目录用户可以随意改写的普通字段。

这项提议刻意保持狭窄。客户端可以把厂商和版本显示给运维人员，也可以识别某个已知异常关联的版本，再考虑采用专门的规避办法。但 RFC 3045 禁止用这两个值推断服务器支持哪些功能。厂商名称说明不了某个具体实例接受哪些控制、扩展或机制；版本字符串也不能说明功能是否在当前配置中启用、是否对当前认证会话开放，或是否正常工作。能力应由针对相应功能设计的机制来声明。

这条边界阻止了一个看似省事、实则脆弱的捷径。如果客户端把“厂商 X、版本 Y”当成能力协商，就可能绕开真正为该功能设计的协议证据。结果可能是调用服务器不支持的操作，也可能是放弃其实可用的功能。RFC 3045 允许产品身份为故障观察提供背景，却不允许它取代观察本身。

版本字符串的匹配规则同样是在反对虚假的精确性。RFC 要求不同版本的 vendorVersion 值彼此唯一，却没有规定语法或大小顺序。它采用相等匹配，而不是“小于”或“大于”。客户端若要针对异常选择规避操作，应精确匹配已知字符串，而不是擅自认定 8.01 比 8.5 新或旧。版本标签首先是名字，不一定是可比较的数轴。

即使字符串完全相同，也不能完整描述一套实现。RFC 3045 指出，同一版本号下的异常可能只影响部分实例：运行平台、配置选项和插件都可能不同。它还提醒读者，服务器返回某个厂商或版本，并不能保证软件真由该厂商构建，也不能保证当前运行的就是该版本。标签证明的只是服务器报告了什么，不是二进制的真实性，更不是所有行为。

这两个属性也不是必填项。服务器可以限制访问，客户端不得依赖它们一定存在。看不到厂商版本，不代表服务器损坏，更不是停止互操作的理由。对排障有用的信息，也可能把软件细节暴露给攻击者；RFC 3045 特别指出，这类信息可能帮助定位服务器弱点。

后来的 LDAP 架构继续区分身份和能力。RFC 4512 将 root DSE 描述为每台服务器各自的操作条目，并列出 supportedControl、supportedExtension 和 supportedFeatures 等独立属性；这些值还可能随会话条件变化。IANA 的 LDAP 参数登记表仍列有 vendorName 与 vendorVersion 的 OID，但登记只确认编号，不证明任何服务器说法或能力。RFC 3045 的经验是分工：标签帮助识别背景，具体功能的证据才回答当前连接实际能用什么。

来源