member/memberOf and samldb.c
lukeh at padl.com
Mon Aug 29 00:46:55 GMT 2005
>> So I've been thinking about how we should handle this type of detail
>> in our ldb code. I can see two workable approaches:
>> 1) we could not store the memberOf fields in the user record in ldb
>> at all, and instead generate them on the fly in the samldb.c ldb
>> module. This could be made efficient using an indexing trick (more
>> on that below).
>I strongly favor the dynamic approach, until we show that it cannot be
>sustained. This is particularly because will allow it to work
>transparently and atomically with an arbitrary ldap or tdb backend,
>without the need for transactions.
The dynamic approach also avoids the integrity issues that arise when
you refer to entries only by distinguished name. Don't forget that,
as far as Active Directory is concerned, an object that is recreated
with the same name as a deleted object is NOT the same object. This
has security implications, too, because they will have different SIDs
and potentially completely different token memberships.
Objects should be linked using a persistent identifier such as GUID
to avoid these referential integrity issues -- some of them are very
tricky to do after the fact.
More information about the samba-technical