Murder / LDAP / SASL Problem...
Rob Siemborski
rjs3 at andrew.cmu.edu
Thu Oct 31 12:22:24 EST 2002
On Thu, 31 Oct 2002, Jared Watkins wrote:
> >Do you have a copy of the entire log I could look at (since you've
> >already sent the passwords to a public list, I'm guessing you don't
> >really care about them any more)?
> >
> The only log entry I get on the backend.. even with CYRUS_VERBOSE turned
> up... is this:
>
> Oct 31 11:30:53 is8000new imapd[19749] badlogin: [10.10.100.42] PLAIN
> [SASL (-4): no mechanism available: security flags do not match required]
>
> The tcpdump log for this action follows... ignore the differences in
> time stamps.. This is all I've been able to go by for logs... if there
> is some way of getting more detailed logs from cyrus.. let me know and
> I'll try that. Oh and no I'm not concerned with passwords.. these are
> all test systems on a private network.
Is imtest selecting PLAIN as its mechanism?
I have a feeling you're getting screwed because in general you can't use
PLAIN without an external security layer (e.g. TLS) present.
One thing you can try is removing the backend1_mechs line from your
frontend's imapd.conf, and see if that makes it do the same thing that
imtest is doing.
I'm not sure what the correct approach is in your situation with
currently-written code, since you really want to be using DIGEST-MD5 or
another challenge-response mechanism that supports proxying to
authenticate to the backends, but you need to keep the full user database
in LDAP (and the full user list needs to be able to authenticate to the
backends, as referrals are always a possibility).
It may be worthwhile to look into the LDAP auxprop patch to make this
possible (or you can try having a sasldb2 with just the frontend's id's in
it, and fall back to PLAIN for the rest, but this requires clients to not
get upset when authenticating via DIGEST-MD5 fails).
The "bad" way to fix this is to change this line in imapd.c:
secprops = mysasl_secprops(SASL_SEC_NOPLAINTEXT);
to:
secprops = mysasl_secprops(0);
(it occurs twice)
-Rob
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper
More information about the Info-cyrus
mailing list