On Fri, 21 Mar 2008, simo wrote:
On Fri, 2008-03-21 at 05:40 -0700, Howard Chu wrote:
simo wrote:
On Wed, 2008-03-19 at 17:33 -0700, Howard Chu wrote:
Searching on memberOf doesn't make a lot of sense to me, when you could simply
read the group object directly. When is this actually a useful thing to do? An
alternative would be to make the memberOf overlay intercept these filters and
rewrite them in terms of member.
Premise: here I am thinking beyond what AD is doing as I use the
memberOf concept in another project.
From my usage memberOf makes it very simple to find all the groups a
member is part of even if that membership derives from nested grouping.
Ah, an interesting point, but probably a separate discussion. Note that the
OpenLDAP memberOf overlay doesn't handle nested groups.
Interesting.
To be honest, if memberOf does not solve the nesting group problem, I
find it rather useless, and that may explain your comments below.
It's very clear that most of the time you have an identity and you want
to know what this Identity is part of, not the other way.
No, not clear at all. A very common application of "groups" is for things like
email lists. In that case, an MTA knows a specific group (the name of the
email list), and needs to know all of the members.
My bad, I should have specified that this is the case I meet/care in my
work. It is not, in general, the most common case, I agree.
Other times (e.g. access control) you know an identity (current user) and want
to know if the identity belongs to a particular group (for an authorization
check). In that case, it is an equal amount of work to look in the user's
entry for a memberOf value as to look in the group entry for the particular
member value. In practice, because groups may be referenced frequently for
multiple users, the group entries will be hot in the server cache and so the
member lookup is actually cheaper.
This is true only if you do member checking by looking at groups. But if
you don't they won't, so I am not sure this really is a reason unless
there is another reason groups are frequently checked. But given the
fact that groups may have huge memberships, actually wasting a lot of
cache memory to keep around the members could also be a reason not to do
it that way. Of course this is just cheap talk of me, without numbers
related to a particular use case (and the use case here is more identity
management, not much MTAs or such, even if, in the end, the same
Directory can be used for many applications, so groups can actually be
really in cache already).
We run a medium sized directory here at Oregon State University which
contains user objects for all students, staff, and faculty (approximately
35,000 entries). It also contains a few static groups (not nested) for
categorizing users. We are using Sun Directory Server 5.2.
The documentation for Sun Directory Server 6.2 says:
The isMemberOf attribute is calculated and added to the user entry at
the start of the search. It is then removed again after the search has
finished. This functionality provides easy management of groups, and
fast read access.
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.
Most directory servers suggest tuning the caches so that the entire
directory fits in RAM, which isn't too hard these days with the price of
RAM. Directory entries are typically only a few kilobytes each.
From a performance standpoint, it may not matter which method of group
enumeration you use. Directory servers are optimized for reads, and a
simple LDAP query like:
(&(objectclass=groupofuniquenames)(uniquemember=uid=doej))
can be just as fast as:
(&(objectclass=posixaccount)(uid=doej))
I'm not familiar with the background of this whole discussion. It sounds
like the memberOf/isMemberOf implementations are relatively new. Unless
you want Samba to require the latest and greatest versions of these
directory servers, you may need to avoid memberOf/isMemberOf and use the
standard methods of querying group membership.
Andy
--
Fedora-directory-devel mailing list
Fedora-directory-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-devel
