Migrating mailbox data from Cyrus to MicroSoft Office 365 using their import tool.

[Dan White]

On 06/23/16 16:49 +0200, Eric Luyten via Info-cyrus wrote:
>On Wed, June 22, 2016 6:02 pm, Dan White wrote:
>> To enable SASL LOGIN support, add 'LOGIN' to your sasl_mech_list. Don't
>> confuse login with pre-sasl user/pass authentication.
>>
>> If Office 365 isn't performing TLS, you'll need to configure
>> sasl_minimum_layer and allowplaintext appropriately.
>
>By restricting the sasl_mech_list in imapd.conf I can make our server
>announce only AUTH=PLAIN in its capabilities string but the client
>insists on (and succeeds in) authenticating using AUTH=LOGIN, thus
>rendering proxying impossible.

You're right. I missed that part before. LOGIN doesn't allow the passing of
authz credentials, which is necessary for proxy authentication.

>There is a mech_list setting in saslauthd.conf which currently reads
>'mech_list: login plain ldap' but this applies server wide and so
>I am a bit reluctant playing with it.

saslauthd.conf does not support a mech_list option (you're looking for
sasl_mech_list in /etc/imapd.conf). If you're using the ldap backend,
reference 'saslauthd/LDAP_SASLAUTHD' in the cyrus sasl source for
documentation.

DIGEST-MD5 is a better approach here, except that you're using saslauthd,
which cannot support it.

If you have access to customer credentials, which I assume you do, then you
could finagle a solution by creating a /etc/sasldb2 database (with
saslpasswd2), and then exposing the DIGEST-MD5 mechanism via mech_list.

>The Office365 IMAP import client uses TLS, I have requested to deselect
>that option to see whether it then switches to using the stronger mech
>AUTH=PLAIN

PLAIN isn't any stronger than LOGIN. Both are considered unsecure without
TLS.

-- 
Dan White