Extending LDB for Extended DNs

[Andrew Bartlett]

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;

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.

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. 

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. 

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com

-------------- 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/20081028/59a0ade2/attachment.bin