Hi,

On Tue, Dec 18, 2012 at 3:05 PM, Jakub Hrozek <jhrozek@redhat.com> wrote:
On Tue, Dec 18, 2012 at 02:43:08PM +0100, François Dagorn wrote:
> Hello all,
>
> according to my ldap base administrator I'm sending border line ldap
> requests. Of course I'm using SSSD configured as follows :
>
> [domain/default]
> auth_provider = ldap
> ldap_id_use_start_tls = False
> chpass_provider = ldap
> cache_credentials = False
> ldap_search_base = ou=people,dc=univ-xxxx,dc=fr
> id_provider = ldap
> ldap_uri = ldaps://yyyy.univ-xxxx.fr/
> ldap_tls_cacertdir = /etc/sssd/cacerts
>

The configuration looks correct to me.

> What happens : the ldap error_log says the following,
>
> search is not indexed base='ou=people,dc=univ-xxxx,
> dc=fr' filter='(&(objectClass=posixAccount)(uid=*)(uidNumber=*)
> (gidNumber=*))'scope='sub'
>
> I do not know why there are these counfounded objectClass, uid=*, ...

I'm not entirely sure I understood your problem, but it seems the LDAP
server admin is complaining that the SSSD is putting high load on the
server, right?

The above search requires the uid, uidNumber and gidNumber attributes to
be indexed in order to be efficient. I think they usually are in most
server deployments..
 
They need to have a "presence" index to leverage indexing with that query.
(attribute=*) simply means check that the attribute exists.
I suspect your admin has indexed those attirbutes only for "eq".
 
HTH
Marco
 
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel