Murder / LDAP / SASL Problem... END

Jared Watkins jwatkins at snowcrash.homeip.net
Tue Nov 5 14:44:08 EST 2002


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




More information about the Info-cyrus mailing list