FYI here's how we did it in XAD, page 19ff.
http://www.openldap.org/conf/odd-wien-2003/luke.pdf
Implemented in OpenLDAP completely at the SLAPI layer. Without help
from the underlying DB, though, it wasn't transaction safe; so the
approach of storing "member" and computing "memberOf" is probably
better.
-- Luke
On 23/03/2008, at 2:25 AM, Luke Howard wrote:
On 22/03/2008, at 10:17 AM, Andrew Morgan wrote:
> On Sat, 22 Mar 2008, Luke Howard wrote:
>
>>>> To me, this says that the directory does an internal group
>>>> search to
>>>> generate the isMemberOf attribute on the fly. I believe this is
>>>> the way
>>>> Active Directory handles the memberOf attribute as well.
>>> IIRC in AD memberOf is a linked attribute, stored permanently.
>>
>>
>> From memory, AD stores the entry IDs of the link tuples in a
>> separate table, so both "member" and "memberOf" are
ostensibly
>> generated on the fly. But this is really an implementation
>> decision (although things do start to get interesting when dealing
>> with references across partition boundaries).
>
> I noticed that the memberOf tab in AD Users and Computers does not
> show group membership for groups that are not in the same domain as
> the user. Access controls were still correctly applied though, so
> those interfaces must be enumerating group membership some other way.
Right, this is because it's expensive (I think they'll show such
memberships if you query through the GC port [3268] but that
requires you talk to a GC).
When a non-GC KDC builds a PAC, it will contact a GC over RPC to
complete the user's token (cf. IDL_DRSGetMemberships).
-- Luke
--
Fedora-directory-devel mailing list
Fedora-directory-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-devel
--
www.padl.com |
www.fghr.net