Mostly dis-jointed notes on the Microsoft Active Directory and the wldap32.dll
Only supports Domain Naming constructs in LDAP Tree layout, not the X.500 of ou=,o=.
Reading the Schema#From the JNDI tutorial - Windows Active Directory: Only authenticated users may read the Active Directory schema. See the Security Lesson (in the Tips for LDAP Users trail) on information on how to perform authentication. The Microsoft Active Directory schema is updated through an internal schema tree. The examples in this lesson that perform updates to the schema will not work against Microsoft Active Directory.
Replication#On the surface, partitioning the whole domain replication employed in Active Directory is a lot easier to understand and manage than with Compared to NDS eDirectory. But as soon as you start to build large networks Active Directory starts to get an awful lot more complicated than eDirectory.
CommonName CN#On the ldap-nis mailing list (discussing PADL Software's software projects) it has come to light that naming attributes (particularly "cn" - "commonName", also "CN" in NDS) in AD are always single-valued; the current definition of the attribute in AD is:
Note the Attribute-ID (OID), "18.104.22.168". The page also indicates that the information is subject to change (let's hope it does so).
Various members of the list (and off-list) have checked the standards and reported that the following all define the attribute (same OID) to be multi-valued (not single-valued):
- IETF RFC 2256
- DMTF DEN (most interesting because Microsoft was one of the founders of the DEN effort...)
- ITU-T X.520(93)
Testing against some existing LDAPv3 servers (namely, Netscape Directory 4.0 and Novell NetWare 5's LDAPv3 front-end to NDS 8) shows that they accept "cn" as multi-valued.
The discussion was in relation to RFC 2307 (and whether or not Microsoft Active Directory could really be compliant with the existing schema given this - and other - limitations and namespace clashes).