Re: [exim] cyrus sasl authentication problems

Pàgina inicial
Delete this message
Reply to this message
Autor: Ross Boylan
Data:  
A: exim-users
CC: ross
Assumpte: Re: [exim] cyrus sasl authentication problems
On Thu, 2008-01-10 at 16:44 -0800, Phil Pennock wrote:
> On 2008-01-10 at 18:07 -0500, Ross Boylan wrote:
> > I have been trying to authenticate using the same account database as my
> > Cyrus imap server. I can't even seem to get very useful debugging
> > output. I would appreciate any help.
> >
> > Following suggestions earlier on this list, I run (as root)
> > exim -d -oX 198.144.201.14.27 -bd 2>&1
> > and ran swaks on the client.
>
> Try -d+auth to turn on more authentication debugging.
>
> Since you saw nothing thereafter, not even a connection from the client,
> are you sure that you told the client to connect to port 27 instead of
> the default port?

Argh. I dropped the port specification while I fiddled with the
firewall. I put it back in (also with -d+auth). Now I get more
information, the key part of which is
9673 Cyrus SASL permanent failure -20 (user not found)
9673 LOG: REJECT
9673 cram_md5_sasl_server authenticator (CRAM-MD5):
9673 Cyrus SASL permanent failure: user not found
9673 SMTP>> 535 Incorrect authentication data

The other thing that seems odd is that I see no exchange of the user
name (on either the client or server side). Are the password and
username all wrapped into one in the challenge-response? If not, then
that's the immediate cause of the problem. I do specify -au to swak.
>
> > -------------- exim config -------------------------
> >
> > cram_md5_sasl_server:
> > driver = cyrus_sasl
> > public_name = CRAM-MD5
> > server_realm = betterworld.us
> > server_set_id = $auth1
>
> Since you're setting server_realm, are you sure that the user
> identifiers in the DB are all realm-qualified?
>
> I can't directly help; I vaguely remember all sorts of "interesting"
> debugging issues using sasldb back when I did that; these days, I use
> cyrus_sasl for GSSAPI and use an Exim-specific password file for
> password-based mail-sending.
>
> As an side: at $previous_employer, I set the policy that as an exception
> to the normal rule, email-sending passwords could be written down
> because they were generated for the user as pure randomness to protect
> against spammers using dictionary attacks; compromise of this
> mail-sending-only password would not give the ability to read any email,
> "only" send new email as that user. Since people configured their
> password in, eg, whatever MTA they used at home, this password
> separation policy seemed to work well.
>
> > Cyrus SASL knows about: CRAM-MD5
> > Cyrus SASL driver cram_md5_sasl_server: CRAM-MD5 initialised
>
> That looks good.
>
> > 4186 local_interfaces overridden by -oX:
> > 4186 <: 198.144.201.14.27
> > 4186 listening on 198.144.201.14 port 27
> > 4186 changed uid/gid: running as a daemon
> > 4186 uid=103 gid=103 pid=4186
> > 4186 auxiliary group list: 45 103
> > 4186 LOG: MAIN
> > 4186 exim 4.68 daemon started: pid=4186, no queue runs, listening for
> > SMTP on [198.144.201.14]:27
> > 4186 set_process_info: 4186 daemon: no queue runs, listening for SMTP
> > on [198.144.201.14]:27
> > 4186 daemon running with uid=103 gid=103 euid=103 egid=103
> > 4186 Listening...
> > # everything above here preceded client connection
> > # and nothing more appears after that.
>
> There should be something showing when someone connects. Since it made
> it into other logs, I strongly suspect that the client software wasn't
> using port 27.
>
> To confirm this, it's useful to have the pid in the log lines; it's not
> by default, but you can turn that on with log_selector in the main
> config section:
> log_selector = +pid
>
> If you want to test manually, I'mm attaching a short program to let you
> cut&paste challenge responses. You could then telnet and run this in a
> separate window.
>
> -Phil