如前所述，NetMeeting 在多个方面违反了 LDAP 协议。 记录如下，NetMeeting
没有正确地构建专有名称 (DN)
NetMeeting 将最重要的元素放在 DN 的开头，而不是结尾，使用
C=US, O=Microsoft, CN=xxx@abc.com, OBJECTCLASS=rtperson
而不是正确的格式，应该是
CN=xxx@abc.com, O=Microsoft, C=US
不包含必需的 “objectclass” 属性
相反，它将 “OBJECTCLASS” 元素附加到 DN 的末尾，如上所示。
不将父级插入到 LDAP 服务器中
这明显违反了 LDAP 标准，该标准要求在创建子级之前父级必须存在。 例如，要插入此 DN
CN=xxx@abc.com, O=Microsoft, C=US
此 DN 必须已存在
O=Microsoft, C=US
这个也必须存在
C=US
不理解属性别名，因此无法识别 “sn” 和 “surname” 指的是同一个属性。
要求搜索请求中的属性必须按照请求的顺序完全返回，而 OpenLDAP 服务器不保证此要求。
在搜索请求中指定 “base” 范围，但实际上应该使用 “sub”，因为它想要一个条目列表，而不仅仅是一个条目
在搜索请求中使用 “%” 字符作为通配符，而不是标准指定的 “*” 字符。
在名称属性（“surname”、“givenname”）中，将带重音的欧洲字符编码为 8 位 ISO 8859-1，而不是 LDAP（RFC 2252 和 2256）要求的多字符 UTF-8 序列。
使用非标准方式刷新动态条目。
Microsoft 服务器维护一个 “sttl” 属性，它是条目的生存时间（以分钟为单位）。 对属性 “sttl” 的搜索请求会重置计时器。 如果计时器归零，则该条目应该从数据库中消失。 NetMeeting 2 提供了一个 “sttl” 属性，但 NetMeeting 3 实际上根本不创建 “sttl” 属性。 此外，客户端不费心告诉我们它想要更新的完整 DN，只提供 “cn” 组件。
Windows 2000 实现了修改后的 DNS SRV (RFC 2782)，这是一种增强的网络服务器定位方式，包括 LDAP。 基本上，如果您的 NetMeeting 服务器名称是 “ils.freesoft.org”，Microsoft Active Directory 将期望使用一个名为 “_msdcs.ils.freesoft.org” 的子域。 在此子域中，域控制器将被称为 “dc._msdcs.ils.freesoft.org”，其 LDAP SRV 记录将被称为 “_ldap._tcp.dc._msdcs.ils.freesoft.org”，如 Microsoft 所述。 明白了吗？ 要在同一主机上指定默认端口号 (389)，您的 DNS SRV 条目应如下所示
$ORIGIN ils.freesoft.org.
_ldap._tcp.dc._msdcs IN SRV 1 1 389 ils.freesoft.org.
|
我最近（2001 年 3 月）亲自测试了这一点，发现它实际上并没有做太多事情。 端口号似乎被完全忽略了。 UDP 数据包被发送到列出主机上的端口 389，但标准没有指定 LDAP over UDP，并且 OpenLDAP 不支持它。