Extending LDB for Extended DNs
Stefan (metze) Metzmacher
metze at samba.org
Tue Oct 28 07:13:17 GMT 2008
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
More information about the samba-technical
mailing list