On 19/08/13 22:14, Viktor Dukhovni wrote:
On Mon, Aug 19, 2013 at 10:08:18PM +0100, Rowland Penny wrote:

There is no such thing as "the relevant email addresses", all
addresses selected by the filter and result attributes are equally
relevant.
When I said "the relevant email addresses", I meant, get from the
group members the contents of the 'otherMailbox' attributes where
said contents end with the email domain from the mailgroups mail
attribute.
This ad-hoc interpretation of "relevance" is not described in any
LDAP standards documents.  There is no reason to expect that the
member addresses of a group are restricted to the same domain as
the group.

As in when searching for mailgr...@example.com, the result should be
just f...@example.com and should not also bring f...@otherdomain.com
That's what you might want in this case, but there is no reason to
expect groups to work this way.

D) Return only mail addresses that end in the mailgroups domain.
Sorry, LDAP does not work that way.  Your LDAP groups must expand
to the correct list of member addresses (primary addresses of group
members).
So, from what you are saying, if you have multiple attributes with
the same name under a users DN then you can only select all of them
and not just the one you require if you search the group.
You have a single attribute with multiple values, not multiple
attributes with the same name.  Result attributes in matching LDAP
entries are returned in full.

I know that Openldap works differently from windows AD, but AD is
what I am trying to work with.
This has nothing to do with AD vs. OpenLDAP.  If you want to return
a particular single address for each user, you need to select a
result attribute that contains *only* that address.

That is what I was trying to do, do a search of a group, get its members and return the 'otherMailbox' from the group members that contain the members CN@%d.

But from what you are saying, this is not possible and whilst I can search via the group, I will get every 'otherMailbox' attribute under every member of the mailgroup and there is no way to fix this.

I will have to rethink this, there must be another way of getting what I want, this is after all unix ;-)


AD allows you to extend the schema.  If nothing suitable is available,
you can populate a custom attribute.

The problem with AD is that whilst it a version of LDAP, it is a very bastardized version, moulded by MS to do what they wanted to do, you cannot do with Ad what you can do very easily with LDAP.

Rowland

Reply via email to