[Fedora-directory-devel] handling forward-only links, DN+Binary and DN+String

[Andrew Bartlett]

Having thought I got to the bottom of extended DN behaviour, I've come
across more challenges, that I would like thoughts on.

Handling renames of one-way links:  OpenLDAP already does this, but
Samba needs some help here (as we try to infer the rename from the
presence of backlinks, but for one-way links, how should we know we are
being linked to?)

Handling of DN+Binary and DN+String one-way links.  For example,

wellKnownObjects:
B:32:22b70c67d56e4efb91e9300fca3dc1aa:CN=ForeignSecurityPrincipals,DC=samba,DC=org

This is a 'DN+Binary' syntax attribute (for resolving well known GUIDs
into a DN), and must therefore follow when the well known target
renames.  MS-ADTS 3.1.1.1.6 specifies the behaviour.

The challenge I see here is that I really do need an additional syntax
in OpenLDAP.  If I map this to just a binary string (as I do now), then
the rename will not follow though.  If I map it to a DN (as I had tried
in the past), then the syntax is invalid.  Is it entirely unreasonable
to add an additional syntax?

This is a bit of a 'hit and run' question, as I won't be able to carry
on the discussion during Christmas/New Year, but any thoughts would be
most welcome.

Thanks,

Andrew Bartlett

[Luke Howard]

> The challenge I see here is that I really do need an additional syntax
> in OpenLDAP.  If I map this to just a binary string (as I do now),  
> then
> the rename will not follow though.  If I map it to a DN (as I had  
> tried
> in the past), then the syntax is invalid.  Is it entirely unreasonable
> to add an additional syntax?

Well, they are really new syntaxes, so you should add a new syntax.

Or at least a syntax that looks like { type, blob, DN } upon which you  
can implement the AD syntaxes (that's kind of what I did for  
eDirectory).

-- Luke