Problem using saslauthd against ldap server ...

[Robert Werner]

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

rwerner2 at ucmerced.edu<mailto:rwerner2 at ucmerced.edu> | it.ucmerced.edu<https://it.ucmerced.edu/> | 209.201.4368



________________________________
From: Dan White <dwhite at olp.net>
Sent: Tuesday, June 5, 2018 8:42 AM
To: Robert Werner
Cc: cyrus-sasl at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/attachments/20180605/d3a59238/attachment.html>