On Mon, Aug 29, 2016 at 03:51:29PM +0200, Jakub Hrozek wrote:
On Fri, Aug 26, 2016 at 05:06:08PM +0200, Lukas Slebodnik wrote:
> On (26/08/16 14:39), rpoyner(a)wisc.edu wrote:
> >ldapsearch with myuser as the binddn and the correct password works.
> >
> >
> >ldapsearch -H
ldaps://unixauth2.cae.wisc.edu -b uid=myuser,ou=People,o=ENGR -s
base -D uid=myuser,ou=People,o=ENGR -W
Can you try with
ldapsearch -ZZ -H
ldap://unixauth2.cae.wisc.edu -b uid=myuser,ou=People,o=ENGR -s base -D
uid=myuser,ou=People,o=ENGR -W
i.e. use StartTLS on port 389 to create the TLS tunnel instead of using
the ldaps port 636. Maybe the server is configured to reject
authentication on port 389?
bye,
Sumit
> > >
> > >If I give the correct password for myuser the search works. If I hit enter
at the password prompt it fails. So it would appear that ldap searches work as expected.
> >
> > IIUC, it works with -w 'your_secret_password'
> > But It does not work with interactive prompting e.g. -W
> >
> > That sounds weird and sounds like a bug in libldap
> > which is used by sssd.
>
> I'm not sure, I would have guessed someone would have found a bug like
> this a long time ago..
>
> I'm not really sure how to debug this further, we test this case all the
> time and I've never seen any case where password-based authentication
> via LDAP doesn't work for anyone.
>
> I wonder if the PAM configuration could be sending a wrong password down
> the stack?
>
> Maybe the server logs would reveal something or maybe you can dissect
> the traffic with wireshark to see if the password is the one you'd
> expect or you can gdb sssd_be and peek at the authtok value..
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org