Problem using saslauthd against ldap server ...

Robert Werner rwerner2 at ucmerced.edu
Mon Jun 18 15:57:30 EDT 2018


I've done more testing but I'm still stuck.  Anyone have any suggestion as to how I can debug the ldap/saslauthd interaction more?




--

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: Cyrus-sasl <cyrus-sasl-bounces+rwerner2=ucmerced.edu at lists.andrew.cmu.edu> on behalf of Robert Werner <rwerner2 at ucmerced.edu>
Sent: Tuesday, June 5, 2018 3:45 PM
To: Dan White
Cc: cyrus-sasl at lists.andrew.cmu.edu
Subject: Re: Problem using saslauthd against ldap server ...


I've attached the debug output from sasl using the new "ldap_debug: -7" attribute.


using the "%u" attribute makes no difference.


What I'm seeing in the tcpdump output is that the uid is being sent in full.  In fact,  the ldap search is finding the "dn" correctly.


We are using the "userPassword" attribute,  and the password is encrypted.  I"m not sure what the algo is.  But the the thing is that with Auth Plain and Auth Login the password is being send in clear.


I don't see anything in the debug output that helps me know why this is happening.


I'm a bit reluctant to post the tcpdump because that has a lot more info than I'm really prepared to share in public.


Anything else I can share?



--

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 2:23 PM
To: Robert Werner
Cc: cyrus-sasl at lists.andrew.cmu.edu
Subject: Re: Problem using saslauthd against ldap server ...

On 06/05/18 20:19 +0000, Robert Werner wrote:
>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 .

I gave you the wrong option. It's 'ldap_debug: -1'.

>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" .

Does using 'ldap_filter: uid=%u' make any difference?

To clarify, it is the user supplied password that is getting cut short, and
not the ldap_bind_pw password?

Are you using a password-hash/olcPasswordHash on the server side, e.g.
{CRYPT}?

>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).
>
>________________________________
>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:
>>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.
>>
>>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/20180618/7d117047/attachment.html>


More information about the Cyrus-sasl mailing list