On Mon, May 07, 2012 at 02:49:33PM +0200, Angel Bosch wrote:
----- Original Message -----
> De: "Jakub Hrozek" <jhrozek(a)redhat.com>
> A: sssd-devel(a)lists.fedorahosted.org
> Enviat: dilluns, 7 de maig de 2012 14:42:39
> Assumpte: Re: [SSSD] variable substitution in ldap_access_filter
> On Mon, May 07, 2012 at 02:12:23PM +0200, Angel Bosch wrote:
> > > No, there is no variable substitution possible at the moment.
> > >
> > so do you plan to implement it? should I file a bug?
> Feel free to file an RFE..although in the case you are trying to
> it wouldn't help you anyway and I'm not sure if it's useful in
> The ldap_access_filter is anded with a "base filter" inside the SSSD,
> which looks something like this, depending on your schema:
> Then the SSSD performs a search with the complete filter and allows
> access only if the search yields a single result.
> In your specific case, the complete filter would look something like
> Which wouldn't do what you seem to want, i.e. only allow members of
> sysadmins group.
> Unfortunately if you're using the RFC2307 schema, there is no simple
> to create a filter that would point to a specific group.
> > > Depending on what you are trying to achieve (sounds to me like you
> > > wanted
> > > to only allow members of the sysadmin group?), would the simple
> > > access
> > > provider be a better choice?
> > >
> > for some machines this would be enough. must i "stack" providers?
> > can you point me to an example using ldap and simple providers?
> Providers cannot be stacked, sorry, there can only be one provider in
> You can, however, define two domains that point to the same servers
> differ by the access provider value only.
sorry if this has been discused before, i just landed in sssd world.
why don't make simple_allow_users|groups an option of any provider?
i know some providers have their own filtering mechanism but it makes more sense to me
having a global allow|deny_users|groups option.
I may have confused you, sorry. What I meant to say was that there can
only be one provider type specified per provider. It's perfectly legal
to have, say, id_provider=ldap, auth_provider=krb5 and
It's not supported to configure SSSD so that acess_provider=ldap,simple