B. NetMeeting LDAP protocol violations

As mentioned, NetMeeting violates the LDAP protocol in several ways. For the record, NetMeeting:

• Doesn't structure Distinguished Names (DNs) properly

  NetMeeting puts the most significant elements in the DN first, instead of last, using:

  C=US, O=Microsoft, CN=xxx@abc.com, OBJECTCLASS=rtperson

  instead of the proper formating, which is:

  CN=xxx@abc.com, O=Microsoft, C=US

• Doesn't include the required "objectclass" attribute

  Instead, it tacks an "OBJECTCLASS" element to the end of the DN, as shown above.

• Doesn't insert parents into the LDAP server

  This is a clear violation of the LDAP standard, which requires parents to exist before children can be created. I.e, to insert this DN:

  CN=xxx@abc.com, O=Microsoft, C=US

  this DN must already exist:

  O=Microsoft, C=US

  as must this one:

  C=US

• Doesn't understand attribute aliases, and is therefore unable to recognize that "sn" and "surname" refer to the same attribute.

• Requires that attributes in a search request be returned in exactly the same order they were requested, a requirement not guaranteed by the OpenLDAP server.

• Specifies "base" scope in search requests, when it really should use "sub", since it wants a list of entries, not just one

• Uses the "%" character as wildcard in search requests, instead of the "*" character specified by the standard.

• In name attributes ("surname", "givenname"), encodes accented European characters as 8-bit ISO 8859-1, instead of multi character UTF-8 sequences as required by LDAP (RFCs 2252 and 2256).

• Uses a non-standard means of refreshing dynamic entries.

  The Microsoft server maintains an "sttl" attribute, which is a time to live for the entry in minutes. A search request for attribute "sttl" resets the timer. If the timer goes to zero, the entry is supposed to disappear from the database. NetMeeting 2 supplies an "sttl" attribute, but NetMeeting 3 doesn't actually create the "sttl" attribute at all. Also, the client doesn't bother to give us the whole DN it wants updated, only supplying the "cn" component.

Windows 2000 implements a modified DNS SRV (RFC 2782), an enhanced means of locating network servers, including LDAP. Basically, if your NetMeeting server name is "ils.freesoft.org", Microsoft Active Directory will expect to use a subzone called "_msdcs.ils.freesoft.org". Within this subzone, the domain controller will be called "dc._msdcs.ils.freesoft.org" and its LDAP SRV record will be called "_ldap._tcp.dc._msdcs.ils.freesoft.org", as described by Microsoft. Got it? To specify the default port number (389) on the same host, your DNS SRV entry would look something like this:

$ORIGIN ils.freesoft.org.

_ldap._tcp.dc._msdcs     IN     SRV     1 1 389 ils.freesoft.org.
      

I've recently (March 2001) tested this myself, and found that it doesn't really do much of anything. The port number appears to be completely ignored. UDP packets are sent to port 389 on the listed host, but the standards don't specify LDAP over UDP and OpenLDAP doesn't support it.