Extending LDB for Extended DNs

[Stefan (metze) Metzmacher]

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.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.samba.org/archive/samba-technical/attachments/20081110/785ea4c6/signature.bin