i thought this too. I think this: access_provider = ldap ldap_access_filter = memberOf=host=does-not-exist-host ldap_access_order = filter ldap_user_authorized_host = host must confuse sssd so much that it denies login. But the user without host attribute can still login. With kind regards, ulrich On 05/12/2015 09:23 PM, m.roth@xxxxxxxxx wrote: > Ulrich Hiller wrote: >> that's intersting. "performing access check" is really missing. >> >> also the "sdap_access" lines are not there. Therefore i do have: >> >> (Tue May 12 13:16:20 2015) [sssd[be[default]]] [dp_get_options] >> (0x0400): Option ldap_access_filter has no value >> (Tue May 12 13:16:20 2015) [sssd[be[default]]] [dp_get_options] >> (0x0400): Option ldap_access_order has value host >> (Tue May 12 13:16:20 2015) [sssd[be[default]]] [be_process_init] >> (0x2000): ACCESS backend target successfully loaded from provider [ldap]. > <snip> > I really don't know this level, but from the above, my first reaction is > to see if there has to be an ldab_access_filter that then leads to the > ldap_access_order in the chain. > > mark > > _______________________________________________ > CentOS mailing list > CentOS@xxxxxxxxxx > http://lists.centos.org/mailman/listinfo/centos > > _______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos