I'm working on a plug-in to one of our products (an RMS) that will allow customers to import employee information stored in their LDAP directory into a corresponding Person record in our application.
Our RMS allows Person records to have multiple names and addresses (it's a public safety system: this feature is for supporting persons with AKA's and multiple known addresses). Because of the nature of the software, we think it would very useful to pull multiple names and addresses from LDAP if the LDAP server supports it.
I was under the impression Active Directory would support this, but it doesn't appear to at all. Looking at RFC 2256, Sections 5.41 and 5.42, for example, it seems obvious that
givenName is intended to be a multi-value field (i.e. the syntax doesn't specify
SINGLE-VALUE, and RFC 2252 states that "multi-value" is the default). The same goes for
streetAddress, and most any other "standard" attribute I bother to look up.
Microsoft's own documentation seems to suggest that they are in compliance with RFC 2256:
Currently, Windows 2000 Active
Directory reaches LDAP compliance
through support of the following RFCs.
[RFC 2256 is then listed among the various "supported" RFCs, under the heading "Core LDAP Requirements – RFC 3377"]
RFC 3377 states that RFC 2256 is indeed part of a collection of 8 RFC's that together comprise the complete technical specification for LDAPv3.
I'm confused: wouldn't not following the actual proposed syntax for standard attributes such as
givenName et al. constitute "non-compliance"?
Also, does anyone have a definitive list of differences between connecting to and querying Active Directory vs. other directory servers (OpenLDAP, eDirectory, etc.)? This is a VB6 application, so I've been using the
ADSDSOObject ADODB provider. Initially I thought I could just write the same code for any directory server and have it work as long as I was using standard attributes, but obviously if the same attribute is defined as single-value in some implementations and multi-value in others, I'm going to have to write code to deal with that scenario.
I'm beginning to wonder if this is one reason why so many applications that have "LDAP integration" of some sort typically have a completely separate settings page for "Active Directory", and then the settings for "every other LDAP server that isn't Active Directory"…
The problem with "compliance" to standards is that it's rare that an entity or piece of software is truly 100% compliant in all possible respects. Instead, in the absence of some guidelines or rules, using the phrase "compliant" generally means that the implementing entity thinks that the software satisfies the meat of the specification.
For example, take CSS Level 2. Most modern browsers today would claim to be "CSS 2 compliant", but it's not the case that every such browser implements 100% of the specification. Nevertheless, users will likely find the rendering experience to be approximately equal for a significant fraction of cases. Thus, compliance tends to be indicated by a combination of:
It's much the same way here with AD and LDAP "compliance". The document you linked alludes to the absence of any compliance or conformance directives, and so Microsoft here has taken a (reasonable, IMO) position that "vendor declarations combined with third-party testing suites are the most suitable alternatives". Essentially, this means that if Exchange and other entities claiming LDAP compliance pass tests which measure compliance with the standard, then effectively they are compliant.