Extending LDB for Extended DNs

[Andrew Bartlett]

On Fri, 2008-11-07 at 09:57 +0100, Stefan (metze) Metzmacher wrote:
> Andrew Bartlett schrieb:
> > On Thu, 2008-11-06 at 13:14 +0100, Stefan (metze) Metzmacher wrote:
> >> Andrew Bartlett schrieb:
> >>> On Tue, 2008-10-28 at 08:13 +0100, Stefan (metze) Metzmacher wrote:
> >>>> Andrew Bartlett schrieb:
> >>>>> Simo,
> >>>>>
> >>>>> Per our discussion on IRC last night, I wanted to clarify with you want
> >>>>> I would like to do to DN support in Samba4, and how I would like to
> >>>>> extend LDB to help with this.
> >>>>>
> >>>>> The problem of extended DNs is partially indicated by:
> >>>>>
> >>>>> http://msdn.microsoft.com/en-us/library/cc200561.aspx
> >>>>>
> >>>>> Firstly, I would like to try and support sending 'extended dns' to
> >>>>> clients, as required by the extended DN control.  
> >>>>>
> >>>>> To do this properly, we need to do better than extended_dn.c does at the
> >>>>> moment - it relies on the fact that if you stuff something into
> >>>>> ldb_dn_new(), then it will appear in the DN - the DN structure does not
> >>>>> contain the parsed DN.
> >>>>>
> >>>>> Secondly, I would like to accept the alternate DN forms 
> >>>>>
> >>>>> http://msdn.microsoft.com/en-us/library/cc200459.aspx
> >>>>>
> >>>>> My hope is that these should be parsed as 'normal' DNs as much as
> >>>>> possible - then canonicalised into a form we can actually look up (or
> >>>>> used directly if possible). 
> >>>>> My plan is to extend the ldb DN parser's existing 'TODO' handling of
> >>>>> <SID= and <GUID= to be a general set of key-value pairs, much like the
> >>>>> DN components are.  Samba4 can then register a custom handler to parse
> >>>>> and print these attributes (with 'string as is' being the default).
> >>>>> This will be much like we handle all other 'samba special' types in
> >>>>> LDB. 
> >>>> I think that's the correct way of doing it...
> >>>> I thing that will be a big step forward (but please remember that next
> >>>> thing is the handling of per attribute replication meta data for linked
> >>>> attributes:-)
> >>> Great.  I've been working on this hard for the past week or so.  See
> >>> http://gitweb.samba.org/?p=abartlet/samba.git/.git;a=shortlog for the
> >>> current work in progress.
> >>>
> >>> I'm currently working on the comprehensive testsuite for DN behaviours,
> >>> particularly with the extended DNs.
> >>>
> >>> I would appreciate any comments or feedback,
> >> I think
> >> in ldb_ildap() we should use extended type 0, as w2k doesn't support type 1.
> >>
> >> ldb_dn_extended_linearized(msg, req->op.search.base, 1)
> > 
> > Yeah, good point (it's a pity, as type 1 is so much easier to use :-)
> 
> It would be nice if ildap would use what the ldb caller used,
> otherwise ldbseach and friends against a windows server can't test all
> combinations. Maybe it'd useful to use the exact form the caller used,
> maybe allowing invalid dn's, so that we can test them against a remote
> server.
> 
> Maybe the ldb_dn_extended_linearized() should just return the callers
> string, when no dsdb ldb modules are loaded and ldb_dn_new() should
> also accept each dn, in that case.

I don't really like that as a solution.  Instead, we could create a new
control, attached to the search/modify/etc operation, that is not
emitted onto the wire, which indicates the type of extended DN to send
(default 0).

For invalid stuff, I think we should just use the raw (painful) LDAP
layer, just as we don't try to construct invalid packets with the full
libcli for SMB. 

What do you think?

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20081110/3543a4f2/attachment.bin