Extending LDB for Extended DNs

[Andrew Bartlett]

On Mon, 2008-11-10 at 09:06 +0100, Stefan (metze) Metzmacher wrote:
> Stefan (metze) Metzmacher schrieb:
> > Andrew Bartlett schrieb:
> >> 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?
> > 
> > With libcli (smbclient) you can still pass invalid filenames
> > and don't validate them on the client.
> > 
> > An invalid dn still produces a valid LDAP request.
> > I think the samba dsdb dn handlers should make sure the dn is valid,
> > the raw ldb code should just handle invalid dns as special, but not
> > invalid. And the ildap and ldap backends should just pass along what the
> > caller gives. It would really a pain if we couldn't just use ldbsearch
> > to test invalid parameters as we can with smbclient.
> 
> BTW: also an ldbsearch from the standalone ldb build should be able to
> ask for an extended dn against an LDAP server. Without having the
> samba specific dn handlers to parse it.

While I understand what you are getting at, I don't see this as the role
of the abstract 'struct ldb_dn' and handlers.

When I get this all in, perhaps we can look at adding a way to 'use this
particular string, no matter what' function (which would not actually do
any validation before being emitted to LDAP).

In the meantime, I never imagined DN behaviour could be so complex!

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/20081114/8a12cd9a/attachment.bin