[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:
>     . OK CAPABILITY completed.
>     +
>     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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]