Dan, thank you so much for your suggestions:
I tried running the saslauthd with the flags you suggested and got the following output: lpmail01 01:09 PM ~ root (1031) : /usr/sbin/saslauthd -d -n 1 -m /run/saslauthd -a ldap -O /etc/saslauthd.conf saslauthd[4718] :main : num_procs : 1 saslauthd[4718] :main : mech_option: /etc/saslauthd.conf saslauthd[4718] :main : run_path : /run/saslauthd saslauthd[4718] :main : auth_mech : ldap saslauthd[4718] :ipc_init : using accept lock file: /run/saslauthd/mux.accept saslauthd[4718] :detach_tty : master pid is: 0 saslauthd[4718] :ipc_init : listening on socket: /run/saslauthd/mux saslauthd[4718] :main : using process model saslauthd[4718] :get_accept_lock : acquired accept lock saslauthd[4718] :rel_accept_lock : released accept lock saslauthd[4718] :do_auth : auth failure: [user=rwerner2] [service=smtp] [realm=] [mech=ldap] [reason=Unknown] saslauthd[4718] :do_request : response: NO saslauthd[4718] :get_accept_lock : acquired accept lock The "debug: -1" flag didn't seem to affect the output . The problem doesn't seem to be username dependent. I've used several different ones. I'm mostly testing with my own which is "rwerner2" but I've also tested with "ucmit-mcp" . I'm seeing the same output from saslauthd in /var/log/secure after directing the auth.debug facility there (in rsyslog). The only way I could tell that the saslauthd was sending out only 7 chars of the password was by looking at the tcpdump of the conversation with the ldap server. (as an FYI for anyone else messing with this on RHEL, I had to disable selinux because the restrictions wouldn't let postfix talk to a saslauthd launched from the command line as root; once this is resolved I'll re-enable selinux). -- Robert G. Werner Systems Administrator University of California Merced, Office of Information Technology rwern...@ucmerced.edu<mailto:rwern...@ucmerced.edu> | it.ucmerced.edu<https://it.ucmerced.edu/> | 209.201.4368 ________________________________ From: Dan White <dwh...@olp.net> Sent: Tuesday, June 5, 2018 8:42 AM To: Robert Werner Cc: cyrus-sasl@lists.andrew.cmu.edu Subject: Re: Problem using saslauthd against ldap server ... On 06/04/18 22:42 +0000, Robert Werner wrote: >I'm trying to use saslauthd to test "auth plain" and "auth login" >authentication against our LDAP data store using the "MECH=ldap" >configuration. > >When saslauthd tries to bind with the credentials, it is only sending 7 >characters of the password. I've validated this by using Wireshark to >examine the sasl communications. The ldap search for the user is >successful and saslauthd is finding the correct user and binding as >desired. But the auth fails, obviously, because the only 7 characters of >the actual (9 character) password is sent. > >If I use the "MECH=pam" and authenticate against a valid user (also with a >password that is 9 charcaters) on the local server, the authentication is >successful. > >I'm running this on RHEL 7.5 with cyrus-sasl* packages that are version >"2.1.26-23.el7.x86_64", ie: > >cyrus-sasl-plain-2.1.26-23.el7.x86_64 >cyrus-sasl-2.1.26-23.el7.x86_64 >cyrus-sasl-gssapi-2.1.26-23.el7.x86_64 >cyrus-sasl-lib-2.1.26-23.el7.x86_64 > >I've attached my smtp.conf, saslauthd and saslauthd.conf files (with >passwords redacted). > >Is there a configuration I'm missing or have I found a bug? Any >suggestions as to how to get around this problem? >ldap_bind_dn: <user> >ldap_bind_pw: <password> >ldap_servers: ldap://lplds.ucmerced.edu >ldap_search_base: dc=ucmerced,dc=edu >ldap_filter: uid=%U >ldap_version: 3 >log_level: 7 >log_level: 7 >pwcheck_method: saslauthd >mech_list: plain login Is this problem reproducable with testsaslauthd and smtptest? Disable saslauthd caching (without -c) and run in debug (-d) mode for additional output. Set 'debug: -1' (man 3 ldap_set_option), in saslauthd.conf to increase libldap's output. Is this problem specific to a particular user name? If so, would you mind sharing what that username is? -- Dan White