Am Dienstag, 11. Dezember 2012, 18:12:42 schrieb Guido Winkelmann:
> Am Dienstag, 11. Dezember 2012, 17:50:03 schrieb Tomasz Sterna:
> > Dnia 2012-12-11, wto o godzinie 17:11 +0100, Guido Winkelmann pisze:
> > > For the services I have running so far, I was able to implement this
> > > by creating a new LDAP group (with objectClass: groupOfNames) for each
> > > service and having every service check whether a freshly authenticated
> > > user is a member of the respective group for this service before
> > > granting access.
> >
> > Quoting
> > https://github.com/jabberd2/jabberd2/blob/master/etc/c2s.xml.dist.in#L634
> >
> > <!-- Alternatively to <uidattr/> and <append-realm/> you may
> >
> > specify full LDAP search <query/> that will be used to
> > get user objects from directory.
> >
> > The following replacements take place:
> > %u is replaced by user login name
> > %r is replaced by user login realm
> >
> > When <query/> is specified, <uidattr/> and <append-realm/>
> > are unused and take no effect. -->
> >
> > <!--
> > <query>(&(mail=%u@%r)(objectClass=inetOrgPerson))</query>
> > -->
> >
> > Isn't this wat you are looking for?
>
> Hm, yes, but this is in that ldap-module (as opposed to ldapfull), which has
> its own problem: It does not allow me to specify the URI of the LDAP server
> as free form, so I cannot use the ldapi protocol. (The ldap server is
> running locally, listening on a unix socket, and I do not want to configure
> it to listen on any IP sockets.)
Also, I think using filters to check whether a given user is part of a given
group only works with AD but not with OpenLDAP, because the latter puts group
members as attributes into the group object in the form of member attributes,
while the former puts group memberships into the user objects in the form of
memberOf attributes.
Guido
