Re: Murder / LDAP / SASL Problem... END

[Jared Watkins]

Just to give this thread some closure... I've abandoned the effort to get this to work for now... Since I can always add it on later... I'll just wait a bit until these issues are shaken out a little more...

I would think that in a large environment where a murder might be used... it will be common to use an LDAP backend... so I'll be lurking.. seeing what others come up with. In the mean time... I'll be putting in a virtualized san.. with the ability to do local mirrors and long distance replication... making the boot disk and data 'portable' and that should be enough to cover for single machine hardware failures.. and there is always per user transport ldap lookups in postfix for multiple cyrus stores... that should cover my bases for the next year or two.

Thanks for the input...
jared


Rob Siemborski wrote:

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