Dynamic Group problems

[Jonah Neugass]

Hello all, I am having a problem getting dynamic groups to work using
DS4.0 and Enterprise 3.6.

I have constructed a group called CIDDS CM with the following URL as a
dynamic group entry:

ldap:///o=motorola.com??sub(&(objectclass=person)(uid=*jgn*))

I am currently only searching for users with my initials. Now, when I
use the console to test the URL, it returns my user entry, however, when
I try to access a page that has an acl restriction that allows only
users from the CIDDS CM group, I get a "Not Found" error.

Here is what shows up in the access log:

[21/Jun/1999:11:00:00 -0700] conn=30 op=21 SRCH base="o=motorola.com"
scope=2 filter="(uid=jgn)"
[21/Jun/1999:11:00:00 -0700] conn=30 op=21 RESULT err=0 tag=101
nentries=1 etime=0
[21/Jun/1999:11:00:00 -0700] conn=30 op=22 BIND
dn="uid=jgn,ou=People,o=motorola.com" method=128 version=2
[21/Jun/1999:11:00:00 -0700] conn=30 op=22 RESULT err=0 tag=97
nentries=0 etime=0
[21/Jun/1999:11:00:00 -0700] conn=30 op=23 BIND dn="" method=128
version=2
[21/Jun/1999:11:00:00 -0700] conn=30 op=23 RESULT err=0 tag=97
nentries=0 etime=0
[21/Jun/1999:11:00:00 -0700] conn=30 op=24 SRCH base="o=motorola.com"
scope=2
filter="(|(&(objectclass=groupofuniquenames)(|(uniquemember=uid=jgn,ou=People,
o=motorola.com)))(&(objectclass=groupofnames)(|(member=uid=jgn,ou=People,
o=motorola.com))))"
[21/Jun/1999:11:00:00 -0700] conn=30 op=24 RESULT err=0 tag=101
nentries=0 etime=0
[21/Jun/1999:11:00:00 -0700] conn=30 op=25 SRCH base="o=motorola.com"
scope=2
filter="(|(&(objectclass=groupofuniquenames)(|(uniquemember=uid=jgn,ou=People,
o=motorola.com)))(&(objectclass=groupofnames)(|(member=uid=jgn,ou=People,
o=motorola.com))))"
[21/Jun/1999:11:00:00 -0700] conn=30 op=25 RESULT err=0 tag=101
nentries=0 etime=0

Any help would be greatly appreciated. Thanks!

[Mark Wilcox]

as far as I know dynamic groups are not supported in E 3.6, you have to wait until E 4.0.

Mark

[Chad Fowler]

Is Dynamic groups something an LDAP *client* will need to be aware of or should it be handled on the server side?  I.E., if I were to write a program that tried to bind as a member of a dynamic group and access a resource restricted to that group, would I need to do something special or just authenticate and try to retrieve the resource?  I would think the answer would be the latter.

Chad Fowler

[Mark Wilcox]

Because dynamic groups are called via a LDAP URL, the client will need to know how to access them.

Other than that I think everything should work as expected.

mark

[Jason Brvenik]

authentication based on a dynamic group is extremely inefficient. I
would think that for each auth attempt the group would have to be
rebuilt. How would multiple requests be handled without causing a DOS
real quick?....

Thoughts please
Jason

Chad Fowler wrote:

--
===========================================================

CONFIDENTIALITY NOTICE: E-mail may contain confidential information
that is legally privileged.

This e-mail transmission, and any documents, files or previous e-mail
messages attached to it may contain confidential information that is
legally privileged. If you are not the intended recipient, or a person
responsible for delivering it to the intended recipient, you are hereby
notified that any disclosure, copying, distribution or use of any of the
information contained in or attached to this transmission is STRICTLY
PROHIBITED. If you have received this transmission in error, please
immediately notify me by reply e-mail, or by telephone at (410) 579-4037
and destroy the original transmission and its attachments without
reading or saving in any manner. Thank you.
===========================================================

[Leif Hedstrom]

Jason Brvenik wrote:

> authentication based on a dynamic group is extremely inefficient. I
> would think that for each auth attempt the group would have to be
> rebuilt. How would multiple requests be handled without causing a DOS
> real quick?....

I assume you mean for credentials and authorization? And yes, it can be very
expensive, and it's up to the LDAP client to make a good implementation. For
instance, the group evaluation in Netscape DS-4.0 ACLs (which supports dynamic
groups) has been signficantly improved compared to previous servers.

Note that in order to find out if a particular user is a member of a dynamic
group you do not have to retrieve and search the entire group. For instance, one
simple implementation could be something like:

1. Get the DN of the person who's credentials and access permissions you need
to verify (e.g. search for "uid=leif", and get the DN attribute only).
2. Get the dynamic search filter(s) (LDAP URLs) from the group you want to
check against.
3. Get the filter component, e.g. (departmentnumber=1234) out of the URL (use
ldap_url_parse() for instance).
4. Do an LDAP search, with the user-DN (from #1) as the search base, scope of
BASE, and the filter component from above. Only request the DN attribute for
best performance.

If the LDAP search in #4 (or LDAP searches, looping through all groups) returns
exactly one entry (no more, no less!), you know that the user with the DN above
is a member of that dynamic group. This is much more efficient than trying to
evaluate the entire dynamic group, which can be arbitrarily large (thousands or
millions of members).

If you have a persistent LDAP client, like a daemon of some sort, doing local
caching of group evaluation is a good thing. This is not an option in CGIs for
instance, unless you use some persistant CGI scheme (FastCGI maybe?).

Ciao,

-- Leif