directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre Smits <>
Subject Re: [Studio] Dealing with various LDAP servers...
Date Wed, 17 Jun 2015 14:31:11 GMT
I support the idea of listing the servers our Studio product works with. It
help clarify the message to our (potential) adopters. It also helps
building the community.

But what numbers (regarding servers - supported vs unsupported) are we
talking about? Maybe we should talk with the product owners/community
representatives to work more with us...

Best regards,

Pierre Smits

Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade

On Wed, Jun 17, 2015 at 4:21 PM, Emmanuel L├ęcharny <>

> Hi guys,
> we have a serious problem with the way we deal with the various LDAP
> server we want to support. Well, I would say we try to avoid knowing
> which server we are talking to, expecting all the servers to provide
> pure and compatible LDAP information.
> Sadly, this is not a perfect world, and there are *many* differences
> between the various LDAP server out there. Here is a use case where it's
> critical to know beforehand what is the server we are daling with :
> - I'm trying to create an OpenLDAP schema project, loading the schema
> from an OpenLDAP server. It should be easy, but at some point, I get
> some error, because some AttributeType uses some MatchingRules that are
> not visible in the cn=subschema. As a matter of fact, we try to
> workaround the problem by *creating* fake MR, that has no OID, but a
> name instead. This work up to the point you want to actually write the
> schema on disk, because the OID is not numeric.
> We do have some method used to try to discover the type of LDAP Server
> we are working with, based on the VendorName attribute (rfc3045), but
> OpenLDAP, for instance, does not expose this Attribute. But even if we
> had this information, that would not be enough : we also need to know
> whcih version of the LDAP server we are dealing with, as their schema
> may evolve in the time.
> So at the end of the day, it works most of the time, but when it
> doesn't, there is no simple way to workaround the problem.
> I'd like to suggest we add some information in the Connection to help
> Studio with those aspects. Typically, it would be quiet useful to
> propose a list of Server we know we support, and their versions. If one
> decide to use OpenDLAP 2.4.31, for instance, then we could add some
> specific classes to suport what is specific for this server.
> I know that it would add a lot of specific classes, each one of them
> being dedicated to a range of versions of a specific LDAP server, but I
> don't really see what we could do other than that to fix this situation.
> And btw, we already have such dedicated classes :
> ApacheDsSchemaConnector and GenericSchemaConnector.
> Note that it's not going to be easy, and it might impact Studio in many
> aspects, so I'm not suggesting to do it right away, I just like to have
> your opinion about those problems.
> Thanks !

View raw message