LDAP backend TODO: Determine the real behaviour of DN+String and DN+Binary

Andrew Bartlett abartlet at samba.org
Thu Oct 21 21:58:40 MDT 2010


Anatoliy,

The next big task, as I mentioned on mumble yesterday, for us to do on
the OpenLDAP backend is to correctly test and implement the DN+String
and DN+Binary matching rules.

Once we have positive tests for these rules, then we can ask the
OpenLDAP team to implement them, but we want to make sure we ask once,
for the right thing (I may have already muddied the waters here, so I
want to try again once, with the right info).

The things we need to find out are:

If I search on a DN+String attribute, does it match against the DN, or
the DN+String.   Likewise for the DN+Binary.

If I attempt to add a duplicate DN+String value to an attribute, does it
conflict (only unique values allowed in LDAP) based on the DN, or the DN
+String.  Likewise for DN+Binary.

Once we understand this (and have tests to prove it), we need to
implement proper matching rules based on these, upgrading our comparison
functions to proper comparisons (not just canonicalise and memcmp()).  

Finally, we need to write the results of that research into a mail to
Howard Chu and OpenLDAP tecnical, and see if they can help us by
implementing this in their server, or if we should somehow deal with
this client side.  A particular difficulty is that we must have these
values implement DN rules, such backlinks, changing on target rename and
deleting when the target deletes etc, and a functional dereference
control (or a replacement with extended DNs).  

There may be additional funny rules like the fact that you will see
duplicates in backlinks that have different source String parts of the
DN+String values, but for the same DN. 

I've CC'ed Howard, Pierangelo and openldap-technical to give them a
heads-up about the fact that we are hoping to pick the ball up on this
again, now some other matters have settled down. 

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20101022/204a1318/attachment.pgp>


More information about the samba-technical mailing list