Extending LDB for Extended DNs

[Stefan (metze) Metzmacher]

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). 
> 
> Finally, as the replicated DN (over DRSUAPI) is of this form:
> 
> 	/* DN String values */
> 	typedef [public,gensize] struct {
> 		[value(ndr_size_drsuapi_DsReplicaObjectIdentifier3(r, ndr->flags))]
> uint32 __ndr_size;
> 		[value(ndr_size_dom_sid28(&sid,ndr->flags))]  uint32 __ndr_size_sid;
> 		GUID guid;
> 		dom_sid28 sid;
> 		[value(strlen_m(dn))] uint32 __ndr_size_dn;
> 		[charset(UTF16)] uint16 dn[__ndr_size_dn+1];
> 	} drsuapi_DsReplicaObjectIdentifier3;

we also need
        typedef [public,gensize] struct {

[value(ndr_size_drsuapi_DsReplicaObjectIdentifier3Binary(r,
ndr->flags))] uint32 __ndr_size;
                [value(ndr_size_dom_sid28(&sid,ndr->flags))]  uint32
__ndr_size_sid;
                GUID guid;
                dom_sid28 sid;
                [value(strlen_m(dn))] uint32 __ndr_size_dn;
                [charset(UTF16)] uint16 dn[__ndr_size_dn+1];
                [value(binary.length + 4)] uint32 __ndr_size_binary;
                [flag(NDR_REMAINING)] DATA_BLOB binary;
        } drsuapi_DsReplicaObjectIdentifier3Binary;

note the additional DATA_BLOB binary, that's the syntax used for the
wellkownObjects attribute, where the standard non extended form looks like

B:32:22b70c67d56e4efb91e9300fca3dc1aa:CN=ForeignSecurityPrincipals,${DOMAINDN}

There's also syntax with an additional string instead of a blob,
but that's not used in the w2k3 standard schema and I haven't tried
to create my own attribute with this syntax yet.

> I would like to store the DN, and the associated SID and GUID in the
> database 'intact'.  This will avoid data loss on inbound replication,
> and make outbound replication much simpler.

yes, a lot simpler

> 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...

> Dispite my jokes last night on IRC, I don't actually intend to pollute
> ldb with #ifdef SAMBA4...
> 
> In terms of LDB level comparisons and indexing, my plan is that the
> canonical form of the DN will not include the GUID or SID, so matching
> on the DN will be unaffected.  The stored format will however change for
> new entries and new databases in Samba4 ONLY (becuase without a GUID or
> SID specified, the behaviour will not change). 
> 
> I hope to come up with a patch to describe what I'm after soon, but I
> wanted to put this out for comment in the meantime. 

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:-)

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/20081028/8b0ab4f3/signature.bin