[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Connecting to imap on a Microsoft Exchange server with gsasl
From: |
Simon Josefsson |
Subject: |
Re: Connecting to imap on a Microsoft Exchange server with gsasl |
Date: |
Wed, 12 Sep 2012 14:08:49 +0200 |
User-agent: |
Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) |
address@hidden (Adam Sjøgren) writes:
> On Mon, 10 Sep 2012 09:47:07 +0200, Simon wrote:
>
>> Interesting, I hadn't seen that before. Could you try modifying
>> src/imap.c:imap_step_recv a bit?
>
> I tried the minimal change I could come up with (my C is quite rusty):
>
> --- src/imap.c 2012-09-12 13:47:16.643822739 +0200
> +++ src/imap.c.asjo 2012-09-12 13:47:25.963197465 +0200
> @@ -147,7 +147,7 @@
>
> if (!args_info.server_flag)
> {
> - if (p[0] != '+' || p[1] != ' ')
> + if (p[0] != '+')
> {
> fprintf (stderr, _("error: Server did not return expected SASL
> "
> "data (it must begin with '+ '):\n%s\n"),
> p);
Yes that should work (although the code has changed since the version
you use).
> And with that I get:
>
> * CAPABILITY IMAP4 IMAP4rev1 AUTH=NTLM AUTH=GSSAPI AUTH=PLAIN IDLE
> NAMESPACE LITERAL+
> . OK CAPABILITY completed.
> . AUTHENTICATE GSSAPI
> +
> gsasl: mechanism error: GSSAPI error in client while negotiating
> security context in gss_init_sec_context() in SASL library. This is
> most likely due insufficient credentials or malicious interactions.
> $
>
> which is probably in line with your prediction:
>
>> This could be a bit disappointing, since it might suggest there are
>> actually Kerberos/GSSAPI issues as well.
>
> (Or maybe my patch is to stupid? My initial thought was to just add the
> space myself if it was missing, but then I remembered stuff about
> handling memory allocations and chickened out.)
>
> We have battled a bit with Kerberos getting our webservers to use it
> etc, so I won't give up totally at this point, but my limited experience
> is that error messages from Kerberos are hard to parse for me.
>
> I have both Firefox and Chromium working against Kerberos enabled
> (internal) websites.
>
> Chromium needed --auth-server-whitelist and
> --auth-negotiate-delegate-whitelist to be set to match our intranet
> domain and also --disable-auth-negotiate-cname-lookup, while in Firefox
> I had to configure network.negotiate-auth.delegation-uris and
> network.negotiate-auth.trusted.uris to match our intranet domain.
>
> Maybe I need something akin to that for gsasl?
gsasl is just a thin layer to the GSS-API library you are using, so all
these kind of configurations would go to the GSS-API library. Alas, the
GSS-API interface provides little tuning, so this is typically done
through configuration files or out of band. I think you need to check
with the community for the GSS-API library you use.
/Simon