directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject [Studio] Dealing with various LDAP servers...
Date Wed, 17 Jun 2015 14:21:24 GMT
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