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 at abc.com, OBJECTCLASS=rtperson
|
instead of the proper formating, which is:
CN=xxx at 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 at abc.com, O=Microsoft, C=US
|
this DN must already exist:
as must this one:
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.
| |
| |
Free eBook: 
