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"...
Active Directory (AD) is Microsoft's LDAP-compliant directory service, and is an integral part of the Windows Server architecture. Active Directory is a hierarchical framework of resources (such as printers), services (such as email), and users (user accounts and groups).
AD FS supports any LDAP v3-compliant directory.
AD is a directory service for Microsoft that makes important information about individuals available on a limited basis within a certain entity. Meanwhile, LDAP is a protocol not exclusive to Microsoft that allows users to query an AD and authenticate access to it.
LDAP is Still Very Much Alive Although LDAP may not to be quite as popular as it once was, it is still a mainstay. LDAP is still often the protocol of choice for many open source technical solutions—think Docker, Kubernetes, Jenkins, and thousands of others.
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.
Unfortunatly, Active Directory breaks many LDAP things, and 'singlevalueness' is only one of them.
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"...
Absolutely.
does anyone have a definitive list of differences between connecting to and querying Active Directory vs. other directory servers (OpenLDAP, eDirectory, etc.)?
I haven't seen one. But, Active Directory schema is well documented at MSDN so you can always check the difference.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With