This is a discussion on Re: LDAP queries for nested mailing lists - VMS ; > On Fri, 13 May 2005 09:58:29, email@example.com wrote: > ... > >> Let's say now I want to get the email addresses of the uniquemembers of my > >> groups, say the I-Tech group: > > > >> $ ...
> On Fri, 13 May 2005 09:58:29, firstname.lastname@example.org wrote:
> >> Let's say now I want to get the email addresses of the uniquemembers of my
> >> groups, say the I-Tech group:
> >> $ pmdf test/url "ldap:///ou=Groups,dc=acme,dc=edu?mail?sub?(cn=i-tech)"
> >> cannot open URL
> >> %PMDF-E-NO, Basic NO
> >> OK, that error message isn't much help here. What am I doing wrong?
> >Hard to say. I tried a similar URL here, only changing the base DN and the cn
> >so they would match some real entries, and it worked fine.
> >You can try adding a /debug qualifier and see if that produces more
> >information. I'll warn you, however, that all too often all you get is an error
> >from the underlying LDAP client library. Knowing that you have a "protocol
> >error" isn't very helpful, but it is all the library provides.
> Yes, /debug gives me some useful hints -- even if it suggests I've
> been barking up the wrong tree for several months ;-P
> >> Is it because there is no mail attribute in that cn item?
> >That's the error you'll get if the search doesn't match anything. And
> >this is one case where /DEBUG will tell you exactly what's going on.
> >> I want the
> >> mail attribute from each of the uniquemembers in cn=itech, but I dont'
> >> know how to request that I guess...
> >If I read this right, what you want is to look in the group entry for each
> >uniquemember attribute, and take each of those attributes and find the
> >corrsponding mail address in the entry they point to.
> Not only that, but if a given group is subordinate to another,
> I either need the subordinate group name along with the uniquemembers
> for the SUPERordinate group in the response, or I need the LDAP query
> to walk the entire subordinate list and give me EVERY uniquemember
> all the way thru. Wildcarding is NOT usable, since for example, we
> could easily have groups which are NOT subordinate to each other
> matching the same wildcard.
Not necessarily. There are two levels of expansion involved here: Alias
and LDAP. If one of your uniquemembers points to another mail group
and that group is well defined and has a mail address, alias expansion
will come back around and expand it for you.
For thie reason I view implementing pure LDAP nested group support as
part of uniquemember handling as superfluous.
> >If so, there's no way to do that in a single LDAP URL. We support this sort of
> >list in iMS, and it requires two lookups. I don't know if the LDAP support in
> >PMDF handles this or not - the iMS support was written some time after the
> >PMDF-iMS split.
> Well, the LDAP server we're using is Solaris Directory Services 5.2,
> which is based on the Netscape Suite in a previous incarnation, which
> I thought had its origins in iMS.
Which has nothing whatsoever to do with the code in PMDF or iMS that handles
groups. This has nothing to do with the LDAP server and everything to do with
what calls are made to that server.
LDAP servers are constrained in what they do by the LDAP protocol itself, which
is a simple "here's the answer to your query, next operation please" sort of
deal. There's no facility in LDAP that says "query this, take the result and
use it top perform a bunch of other queries, returning those queries as the
final result". If you want to do this sort of thing there has to be
code on the client to do it.
> Probably where that support there
> came from. You'd think that one could imbed multiple queries by using
> a query instead of the attribute to nest them.
Sorry, that's just not how LDAP works.
> Our LDAP structure is NOT cast in stone, and this kind of functionality
> is crucial. Any suggestions on building our LDAP schema to achieve
> this within PMDF's apparent limitations in this area?
I've never much cared for groups defined with uniquemember. My preference
has always been to use dynamic groups instead. That is, rather than
have a list of all the DNs of the group members in the group itself, put
an attribute on each of the user entries saying what groups they belong
to. Assumimg that attribute is called "groups", you then perform a query
along the lines of:
where GROUPNAME is the name of the group you're expanding.
Again, I don't know what PMDF's LDAP facilities are capable of these days so I
don't know if this is supported. At least it only requires one lookup.