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 cn
, sn
, 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"...