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), [email protected] 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 > [email protected] > https://lists.fedorahosted.org/admin/lists/[email protected] _______________________________________________ sssd-users mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected]
