On Sun, 2010-07-11 at 14:16 -0700, Howard Chu wrote:
Andrew Bartlett wrote:
I'm back on my occasional task of trying to get the OpenLDAP backend to Samba4 going again, and was hoping to simply test out the fine work done on the vernum module. (which I should have tested at the time it was developed).
Anyway, Samba has moved on, and things have broken. Part of the changes relate to these additional DN types (found in AD), of:
#define DSDB_SYNTAX_BINARY_DN "1.2.840.113556.1.4.903" http://msdn.microsoft.com/en-us/library/ms684429%28VS.85%29.aspx
#define DSDB_SYNTAX_STRING_DN "1.2.840.113556.1.4.904" http://msdn.microsoft.com/en-us/library/ms684430%28VS.85%29.aspx
#define DSDB_SYNTAX_OR_NAME "1.2.840.113556.1.4.1221" http://archives.free.net.ph/message/20091211.162430.74b43d9e.en.html
These are quite odd in their behaivour, but in short they are both a string or binary blob and a DN, all in one. Only the DN portion is relevant for attribute matching rules.
Currently, I map these to strings, but they are not strings - and need proper DN match rules, as I need to be able to use the 'deref' module on them (and to correctly handle the case sensitive/insensitive nature of DNs).
What is the best way to get OpenLDAP to understand it needs to match on and follow references to the DN part of these values?
Good question. So far the only way to get DN semantics is by using distinguishedName syntax. In a few places we've also special-cased recognition of NameAndOptionalUID syntax, but that's not universal. I suppose, if you can shoehorn your extra blobs into the UID portion, you can use that syntax and we can figure out where else it needs to be accepted.
Looking over the definition of NameAndOptionalUID, shoehorn would certainly be the correct expression... But yes, it looks to me like I just need to convert every binary or string element into a bitstring of it's bits.
Andrew Bartlett