This gets even more fun when I torture it by giving the ntlm_auth helper a *wrong* password. In that situation, libsoup *does* emit the 'authenticate' signal to ask us for a better password. We ask the user again... and then don't actually bother to feed the resulting password back to libsoup to try with it.

I don't really know how the authentication flow is *supposed* to work here, so it's hard for me to propose a fix.

I wonder if it's right that libsoup invokes our 'authenticate' callback with 'retrying=1' when in fact it's only the SSO authentication attempt which failed. That makes us think that our own password was the one which didn't work, and forget it immediately.

So we never actually *do* feed the user-entered password in to soup_auth_authenticate(), in our 'authenticate' signal handler.

I tried hacking our signal handler (ews_connection_authenticate()) to behave as if retrying=0, and feed the user-entered password in anyway. It doesn't work; we just get called again immediately. That part might be a libsoup bug; I don't see why it's not using the password we gave it.

(In reply to comment #2)
> I tried hacking our signal handler (ews_connection_authenticate()) to behave as
> if retrying=0, and feed the user-entered password in anyway. It doesn't work;
> we just get called again immediately. That part might be a libsoup bug; I don't
> see why it's not using the password we gave it.

That part is bug 703186. However, even with my patch for that, libsoup is still emitting the *first* authenticate signal with 'retrying=TRUE', causing Evolution never to actually feed it a password.

There's a loop in e_source_registry_authenticate_sync() which will repeatedly ask for a password and attempt to authenticate to the server with it.

That loop seems to be wrong. It should attempt to authenticate to the server once *without* a password, for auth methods where that's appropriate (like NTLM).

Let's forget EWS/libsoup for now. This looks to be broken even when the authentication is done with camel-sasl-ntlm.

Evolution's mail_session_authenticate_sync() will actually check the result of camel_sasl_try_empty_password_sync(), and will not even *attempt* to call e_source_registry_authenticate_sync() if it returns TRUE. There's a comment complaining that …try_empty_password_sync() should return a CamelAuthenticationResult instead of a gboolean but I think that's because someone's missed the point. That function returns true if it's possible to *try* using automatic authentication. It doesn't mean it's actually tried it and it worked!

So we need to fix that, and still call into the e_source_registry_authenticate_sync() loop even for camel-sasl-ntlm users when camel_sasl_try_empty_password_sync() is TRUE.

And then we hit the same issue. The loop needs to try once *without* a password for sources which support that, and only start prompting for a password on the *second* time round the loop.

Simple test case:

 Fetch http://david.woodhou.se/ntlm_auth_v2.c
 Build it with *incorrect* password details:
   gcc -DTEST_HACK -DDOMAIN=foo -DUSERNAME=bar -DPASSWORD=fish $(pkg-config --cflags --libs glib-2.0) -o ntlm_auth ntlm_auth_v2.c

 Install it at /usr/bin/ntlm_auth
 Configure an IMAP account with NTLM authentication.

Watch it not even *ask* you for a password, even though the automatic one is failing.

In fact this new ESource authentication stuff is broken in IMAPX even if /usr/bin/ntlm_auth is *working*. Like EWS, it depends on camel_imapx_server_authenticate() being called.

Created attachment 247924 [details] [review]
EMailSession patch

The docs should be clarified that try_empty_password() means *you* try, not the method will try, as the name is otherwise misleading.

Here's roughly what I think needs to change in e-mail-session.c.

Not yet tested.  The rest is up to ews.

If the patch fixes imapx+ntlm then we should be able to make ews work, sure.

Thanks.

Evolution patch pushed to master and gnome-3-8 with minor fixes; thanks.

https://git.gnome.org/browse/evolution/commit/?id=046a17b
https://git.gnome.org/browse/evolution/commit/?h=gnome-3-8&id=447f7d3

There was another failure with IMAPX, because the NTLM SASL mechanism wasn't even trying the ntlm_auth helper unless camel_sasl_try_empty_password_sync() had been called on that specific sasl instance. Fixed in:

https://git.gnome.org/browse/evolution-data-server/commit/?id=2645a6e
https://git.gnome.org/browse/evolution-data-server/commit/?h=gnome-3-8&id=294e413

For EWS the fix looks something like this. But why is the auth-mechanism always NULL? It's always NULL when ews_auth_mech_to_use_ntlm() looks at it too.
 
--- a/src/camel/camel-ews-store.c
+++ b/src/camel/camel-ews-store.c
@@ -496,6 +496,8 @@ ews_connect_sync (CamelService *service,
 	EEwsConnection *connection;
 	CamelEwsStore *ews_store;
 	CamelSession *session;
+	CamelSettings *settings;
+	gchar *auth_mech;
 	gboolean success;
 
 	ews_store = CAMEL_EWS_STORE (service);
@@ -510,12 +512,17 @@ ews_connect_sync (CamelService *service,
 	}
 
 	session = camel_service_ref_session (service);
+	settings = camel_service_ref_settings (service);
 
 	/* Try running an operation that requires authentication
-	 * to make sure we have a valid password available. */
+	 * to make sure we have valid credentials available. */
+	auth_mech = camel_network_settings_dup_auth_mechanism (
+				       CAMEL_NETWORK_SETTINGS (settings));
 	success = camel_session_authenticate_sync (
-		session, service, NULL, cancellable, error);
+		session, service, auth_mech?:"NTLM", cancellable, error);
 
+	g_free (auth_mech);
+	g_object_unref (settings);
 	g_object_unref (session);
 
 	if (success)
@@ -966,14 +973,6 @@ ews_authenticate_sync (CamelService *service,
 
 	password = camel_service_get_password (service);
 
-	if (password == NULL) {
-		g_set_error_literal (
-			error, CAMEL_SERVICE_ERROR,
-			CAMEL_SERVICE_ERROR_CANT_AUTHENTICATE,
-			_("Authentication password not available"));
-		return CAMEL_AUTHENTICATION_ERROR;
-	}
-
 	settings = camel_service_ref_settings (service);
 
 	ews_settings = CAMEL_EWS_SETTINGS (settings);

I also get password prompts as soon as I start evolution-source-registry. And when I open the account preferences.

Current status: Evolution is half-fixed with the patch in comment 9 although there are open questions about that, and it isn't committed.

evolution-source-registry and probably the other factories are also still demanding passwords that they aren't going to use.

Matt, any further enlightenment you could offer in this would be much appreciated; thanks.

You don't have to really join a domain with samba/winbind; there's a simple test in comment 5. (Build it with a *real* user/password that works first time; let's not worry about the fallback case for now.)

*** Bug 700522 has been marked as a duplicate of this bug. ***

Created attachment 250716 [details] [review]
proposed eds patch

for evolution-data-server;

This adds a new virtual function ESourceAuthenticatorInterface::get_without_password plus a new D-Bus property org.gnome.evolution.dataserver.Authenticator::WithoutPassword (thus changes public API) which is used to determine whether the authenticator requires real password or not.

The authentication_session_execute_sync() asks for the property and if the password is not required, then it tries to authenticate with an empty password (NULL is not allowed, and I didn't want to change this constraint). If it fails for whatever reason (except of cancelled), then the user is asked for the password and the authentication continues as before. Quite like Camel does it.

Created attachment 250717 [details] [review]
proposed eds patch ][

for evolution-data-server;

Err, I forgot to update the patch with increased API versions. The text from the above comment still applies.

Created attachment 250718 [details] [review]
proposed ews patch

for evolution-ews;

Slightly painful to propagate the option to all the related places.
Anyway, please note of added ews_connection_schedule_abort(), for some reason, libsoup failed to authenticate without this call when the ntlm_auth returned failure. I guess it can have side-effects, but I do not have anything better right now. Maybe it's the libsoup bug.

It's a shame the libsoup package hasn't been fixed in Fedora yet. I have a scratch build at http://koji.fedoraproject.org/koji/taskinfo?taskID=5694202 which fixes GNOME bug #703186 and bug #703463 and should help.

Did you manage to find time for the patch testing, please?

Thanks for the patches. Yes, these appear to work.

Some minor nitpicks:
 - I don't like having another strcmp("PLAIN") when we already have something similar in ews_auth_mech_to_use_ntlm(). That's too much of a hack to have it in more than one place, especially when we are hoping to add Kerberos support into the mix soon. Not immediately obvious how to avoid the duplication though, unless we do something like reading the "use-ntlm" property on the soup session. Which is also not ideal.

 - EWS shouldn't simply assume that it can try without a password for NTLM, should it? The SASL try_empty_password() call doesn't. It returns true only if ntlm_auth at least *appears* to be trying to talk to us.

 - What about other back ends, if they use SASL directly (which EWS doesn't). Can we make this work for them automatically according to the SASL mech that they use? Or is that not viable? Do other back ends even *use* SASL or is that only really for camel, which isn't factory-ised yet?

 - I really don't like having to bump the soname just for *adding* a method. Normally we ought to be able to keep the soname the same, and just add the new method with a new version. We'd have to add the new field to the *end* of the ESourceAuthenticatorInterface structure, and maybe some other compatibility issues. But it should be do-able. But that's probably something we need to discuss separately rather than as part of this patch. I would *really* like to get some version of this into gnome-3-8 though, as SSO *partly* works there and I consider it a bug when my users are asked for a password which I'm *trying* to teach them they should never have to type after logging in. Especially when it isn't even *used* :)

 - Even with bug 703186 fixed, the ews_connection_schedule_abort() is needed. Otherwise, we end up in ews_connection_try_password_sync() with the password '' even after I've typed the *correct* password into the prompt. I'd like to understand why...

Aha, we need to abort because we are not using libsoup properly.

We shouldn't *be* playing silly tricks to determine whether we can try with the empty password or not.

The API is simple: We call libsoup. If it needs a password, it *asks* for one by invoking the 'authenticate' signal and we're supposed to call soup_auth_authenticate() with a password.

In my test case I have the standard Samba ntlm_auth but winbind doesn't know my password so it's failing fast and the SASL NTLM try_empty_password() method would actually have returned FALSE. There is no SSO here (which is the common case for most users).

But your EWS patch makes it try anyway. And libsoup wants a password, it so sends the authenticate signal. And ews_connection_authenticate() is called and is *expected* to call soup_auth_authenticate() with a password.

But it doesn't, because it doesn't have one.

So the code in soup-auth-ntlm.c just goes ahead and generates an NTLM request with the password hashes which are in its state structure, initialised to all zeroes. Which obviously doesn't work. And then when it fails, it sets its state to SOUP_NTLM_FAILED.

We then try again, with our password ready to hand to libsoup. But libsoup already failed, and doesn't even *try* the NTLM handshake again. Its state machine is still waiting for us to call soup_auth_authenticate() and provide a password, as it requested.

So I think the abort might be the right thing to do for now. 

Or maybe we should *freeze* the soup session, remember that it is awaiting a password, then return failure to the ->try_password_sync() caller. Next time we're invoked with an actual password, we can *immediately* call soup_session_authenticate() and unfreeze the session. Assuming we *are* called again, that is. The abort is probably simpler :)

As we spoke on IRC, the points are not blocking the fixes, and they can be discussed in separate bug reports.

Created commit b4c00af in eds master (3.9.90+)
Created commit addcca8 in ews master (3.9.90+)

Hrm, I reverted the ews part at commit d47bbcd. I see the abort is scheduled and even called before the next attempt for the password authentication (after ntlm_auth failed), but the soup session still avoids to continue properly and makes other sources unavailable. This is for the collection backend in evolution-source-registry module. Let's revisit this later, not immediately before the release. I left the eds part as is, it is no harm (except of the soname version bump).

Hm, odd. With the abort it was working fine for me in gnome-3-8. Although I still wasn't *happy* with it, as described in comment 19. I'll attempt to rebuild the world so I can try to test master.

What version of libsoup were you using, and is bug 703186 fixed in it?

I had installed libsoup-2.42.2-1.fc19.x86_64, then updated to more recent
libsoup-2.42.2-2.fc19.x86_64, but still no joy. Your bug is not closed yet, thus I do not have its fix either.

There's a scratch build 2.4.2-1x linked from comment #16, which also includes the fix that went into the -2 package despite appearing older.

I wonder if we should also (at least for testing) patch libsoup to abort or complain viciously if you continue trying to use a session after failing to call soup_auth_authenticate() when you're asked to. Dan? (cf. comment 19)

(In reply to comment #24)
> There's a scratch build 2.4.2-1x linked from comment #16, which also includes
> the fix that went into the -2 package despite appearing older.

Never mind, I built it myself and the patch from bug #703186 didn't change anything here.

> I wonder if we should also (at least for testing) patch libsoup to abort or
> complain viciously if you continue trying to use a session after failing to
> call soup_auth_authenticate() when you're asked to. Dan? (cf. comment 19)

It's not mandatory to be called, see documentation from "authenticate" signal:
> Emitted when the session requires authentication. If credentials are
> available call soup_auth_authenticate() on auth. If these credentials fail,
> the signal will be emitted again, with retrying set to TRUE, which will
> continue until you return without calling soup_auth_authenticate() on auth.

Created attachment 252205 [details] [review]
proposed ews patch ][

for evolution-ews;

This makes it partially work. The partial part is that it checks whether /usr/bin/ntlm_auth has a password or not. If not, then it tries with password immediately. Obviously, the things will break once the password available in ntlm_auth will be incorrect/outdated.

I also realized that the behaviour depends on Exchange server version. When I use Exchange 2010, then this works as expected even with no ntlm_auth password, with the initial patch, because the server returns 401 Unauthorised. Exchange 2007 server returns 403 Forbidden with the second message, and, interestingly, the "authenticate" callback is called twice with the first message, even no password was provided in the first round. I have a test application for Dan available, it shows this for Exchange 2007:
> test_thread: trying message 0x7fd3b0012040 without password
>    authenticate: msg:0x7fd3b0012040 retrying:0 no_pass:1
>    authenticate: msg:0x7fd3b0012040 retrying:1 no_pass:1
> test_thread: finished 0x7fd3b0012040 with code:401 (Unauthorized)
> test_thread: trying message 0x7fd3b0012120 with password
> test_thread: finished 0x7fd3b0012120 with code:403 (Forbidden)
> test_thread: done

where the 'no_pass:1' means the soup_auth_authenticate() was not called. The Exchange 2010 shows:

> test_thread: trying message 0x7f2d40012040 without password
>    authenticate: msg:0x7f2d40012040 retrying:0 no_pass:1
>    authenticate: msg:0x7f2d40012040 retrying:1 no_pass:1
> test_thread: finished 0x7f2d40012040 with code:401 (Unauthorized)
> test_thread: trying message 0x7f2d40012120 with password
>    authenticate: msg:0x7f2d40012120 retrying:0 no_pass:0
> test_thread: finished 0x7f2d40012120 with code:200 (OK)
> test_thread: done

(In reply to comment #19)
> But your EWS patch makes it try anyway. And libsoup wants a password, it so
> sends the authenticate signal. And ews_connection_authenticate() is called and
> is *expected* to call soup_auth_authenticate() with a password.
> 
> But it doesn't, because it doesn't have one.
> 
> So the code in soup-auth-ntlm.c just goes ahead and generates an NTLM request
> with the password hashes which are in its state structure, initialised to all
> zeroes.

This shouldn't happen; if libsoup needs a password, and you don't call soup_auth_authenticate() from authenticate, then it should just return the 401 error to the caller.

This works with other auth types; it must be messed up with NTLM because of the is_authenticated() / is_connection_ready() split, and some confusion between the SSO and non-SSO cases.

Dan, do you think it worth a bug in libsoup?

David, I'd appreciate your opinion on ews patch, I'm fine to commit this for 3.12 and figure out libsoup part before the final 3.12 is out.

Created attachment 263820 [details] [review]
SoupAuthNTLM: don't sent an NTLM_RESPONSE if we didn't get a password

If SoupAuthNTLM requested a password and didn't get it, it would send
the NTLM_RESPONSE packet anyway, with the username and password zeroed
out. Fix that and test it in ntlm-test.

(In reply to comment #27)
> > So the code in soup-auth-ntlm.c just goes ahead and generates an NTLM request
> > with the password hashes which are in its state structure, initialised to all
> > zeroes.
> 
> This shouldn't happen; if libsoup needs a password, and you don't call
> soup_auth_authenticate() from authenticate, then it should just return the 401
> error to the caller.

I think the attached patch should fix that... not sure what that means for the other patch here.

Oops, so this is going to miss 3.12. Pity.

Dan, did the libsoup patch get it into sources, and if so then when, please?

The patch in comment 29 still isn't quite doing the right thing, AFAICT.

It does prevent us from sending the request with a bogusly-generated NTLM response calculated with an empty password. However, it doesn't prevent us from sending the request... we just send it again with *no* Authorization: header. Surely it should cause the request to fail immediately?

It's worse than that.

Not only are we sending the request again without any Authorization: header when the server expects the NTLM response so we know it'll fail, but we actually leave the connection *open*. We don't reset our own NTLM state so when we get the next WWW-Authenticate: NTLM we ends state SOUP_NTLM_FAILED, and even when we're *given* a password for a future request, we never bother trying again.

Where you added that 
+		if (priv->password_state == SOUP_NTLM_PASSWORD_NONE)
+			break;

We need to do something more. I tried the evil hack of adding
	soup_message_headers_replace(msg->request_headers,
				     "Connection", "close");
... which made soup_message_is_keepalive return FALSE and forced the connection to work. That worked, but was horrid.

Another approach is to catch the "got-headers" signal on the message and use that trigger to reset our state to SOUP_NTLM_NEW. We can't do that immediately because of course that'd put us in an infinite loop on the same message:
--- a/libsoup/soup-auth-ntlm.c
+++ b/libsoup/soup-auth-ntlm.c
@@ -445,6 +445,14 @@ soup_auth_ntlm_is_connection_ready (SoupConnectionAuth *auth,
 }
 
 static void
+reset_failed_auth (SoupMessage *msg, gpointer data)
+{
+	SoupNTLMConnectionState *conn = data;
+
+	conn->state = SOUP_NTLM_NEW;
+}
+
+static void
 got_final_auth_result (SoupMessage *msg, gpointer data)
 {
 	SoupAuth *auth = data;
@@ -493,6 +501,16 @@ soup_auth_ntlm_get_connection_authorization (SoupConnectionAuth *auth,
 		conn->state = SOUP_NTLM_SENT_REQUEST;
 		break;
 	case SOUP_NTLM_RECEIVED_CHALLENGE:
+		if (priv->password_state == SOUP_NTLM_PASSWORD_NONE) {
+			/* This connection will probably be re-used, and we
+			 * need to reset our state so that it works for the
+			 * next message if we've been given a password.
+			 */
+			g_signal_connect (msg, "got-headers",
+					  G_CALLBACK (reset_failed_auth),
+					  state);
+			break;
+		}
 		if (conn->response_header) {
 			header = conn->response_header;
 			conn->response_header = NULL;

That works too, but I'm only marginally happier with it than I was the Connection: close hack. We ought to be *cancelling* the destined-to-fail message.

(In fact, why are we even sending the initial NTLM 'request' packet, when we have no username/password to complete a challenge. Can't we send the authenticate signal *then*, and only even *start* the NTLM exchange when we think we have what we need? That way we wouldn't *need* to suddenly decide half-way through that we can't continue.)

Ok, so that fixes the case where the user initially provides *no* password and our request fails. But still we're broken in the case where the user provides an *incorrect* password. this 'fixes' that one... but again needs further thought:

@@ -315,7 +324,7 @@ soup_auth_ntlm_update_connection (SoupConnectionAuth *auth, SoupMessage *msg,
                        priv->password_state = SOUP_NTLM_PASSWORD_NONE;
                } else {
 #endif
-                       conn->state = SOUP_NTLM_FAILED;
+                       conn->state = SOUP_NTLM_NEW;
                        priv->password_state = SOUP_NTLM_PASSWORD_REJECTED;
 #ifdef USE_NTLM_AUTH
                }

If the password is rejected, it puts us back in state SOUP_NTLM_NEW ready to start again when the user submits a new request. But is that the right thing to do, or does it put us into an endless loop in some circumstances?

(In reply to comment #34)
> Another approach is to catch the "got-headers" signal on the message and use
> that trigger to reset our state to SOUP_NTLM_NEW.

That assumes the message will be re-sent (and re-sent on the same connection). It might be better to set a flag on the SoupNTLMConnectionState to tell it to reset state when the next message is queued on it?

> That works too, but I'm only marginally happier with it than I was the
> Connection: close hack. We ought to be *cancelling* the destined-to-fail
> message.

You don't need to cancel it; just make sure it doesn't get requeued (ie, make sure soup_auth_ntlm_is_connection_ready() returns FALSE), and it will get returned to the caller with the 401 status.

> (In fact, why are we even sending the initial NTLM 'request' packet, when we
> have no username/password to complete a challenge. Can't we send the
> authenticate signal *then*, and only even *start* the NTLM exchange when we
> think we have what we need? That way we wouldn't *need* to suddenly decide
> half-way through that we can't continue.)

If NTLM is enabled then it sends an NTLM request on *every* new connection, before it knows whether the server even supports NTLM.

(In reply to comment #35)
> If the password is rejected, it puts us back in state SOUP_NTLM_NEW ready to
> start again when the user submits a new request. But is that the right thing to
> do, or does it put us into an endless loop in some circumstances?

I couldn't say...

(In reply to comment #36)
> (In reply to comment #34)
> > Another approach is to catch the "got-headers" signal on the message and use
> > that trigger to reset our state to SOUP_NTLM_NEW.
> 
> That assumes the message will be re-sent (and re-sent on the same connection).

The message *is* being sent at this point, on this connection. This whole thing happens once the connection has been chosen and the per-connection authentication stuff is being invoked to add an Authorization: header which is appropriate for this connection.

I don't actually *want* the message to be sent; when we fail to add an Authorization: header we *know* it's going to fail. But I can't see how to abort it. I'll settle for abusing the 'got-headers' signal on the inevitable failure :)

> It might be better to set a flag on the SoupNTLMConnectionState to tell it to
> reset state when the next message is queued on it?

That does seem cleaner; I'll see if I can make it work. Thanks.

OK, this version seems to be working. Automatically start trying again (without SSO) if we are invoked in state SOUP_NTLM_FAILED.

--- a/libsoup/soup-auth-ntlm.c
+++ b/libsoup/soup-auth-ntlm.c
@@ -489,10 +489,15 @@ soup_auth_ntlm_get_connection_authorization (SoupConnectionAuth *auth,
                 * request handling process.
                 */
 #endif
+       case SOUP_NTLM_FAILED:
                header = soup_ntlm_request ();
                conn->state = SOUP_NTLM_SENT_REQUEST;
                break;
        case SOUP_NTLM_RECEIVED_CHALLENGE:
+               if (priv->password_state == SOUP_NTLM_PASSWORD_NONE) {
+                       conn->state = SOUP_NTLM_FAILED;
+                       break;
+               }
                if (conn->response_header) {
                        header = conn->response_header;
                        conn->response_header = NULL;


I've tested it with a 'broken' ntlm_auth helper which fails, causing us to fall back to manual auth. And with a wrong password entered in manual auth, causing us to try again. It seems to be doing the right thing.

Now trying to interpret the output of tests/ntlm_test...

Yay, and I think I have a viable workaround for EWS in the meantime too:

--- a/src/server/e-ews-connection.c
+++ b/src/server/e-ews-connection.c
@@ -1933,9 +1933,15 @@ ews_connection_authenticate (SoupSession *sess,
 
        password = e_ews_connection_dup_password (cnc);
 
-       if (password != NULL)
-               soup_auth_authenticate (auth, user, password);
 
+       if (password && *password)
+               soup_auth_authenticate (auth, user, password);
+       else {
+               /* libsoup doesn't cope very well when we fail to provide
+                * a password. So cancel the message explicitly. Bug 703181 */
+               soup_session_cancel_message(cnc->priv->soup_session,
+                                           msg, SOUP_STATUS_UNAUTHORIZED);
+       }
        g_free (password);
        g_free (user);
 }

Created attachment 281480 [details] [review]
Fix recovery, update tests.

This fixes it. I've merged the tests you added in your patch (comment 29) but had to change them slightly to cope with the fact that we *do* retry after the user declines to provide a password:

@@ -399,12 +399,12 @@ do_ntlm_round (SoupURI *base_uri, gboolean use_ntlm,
 	 * get 401. Alice-via-NTLM is still authenticated, and so
 	 * won't get prompts, and Alice-via-Basic knows at this point
 	 * to send auth without it being requested, so also won't get
-	 * prompts. Nobody and Bob-via-NTLM will try (and fail) to
-	 * authenticate again.
+	 * prompts. Bob-via-NTLM will try (and fail) to authenticate again,
+	 * and Nobody will fail right away.
 	 */
 	do_message (session, base_uri,
 		    "/alice/404", have_auth,
-		    !alice, use_ntlm && !alice,
+		    !alice, bob_via_ntlm,
 		    !alice, alice_via_basic,
 		    alice ? SOUP_STATUS_NOT_FOUND :
 		    SOUP_STATUS_UNAUTHORIZED);

Fixed in EWS with a workaround for the libsoup bug:
 https://git.gnome.org/browse/evolution-ews/commit/?id=ba4f47aa (workaround)
 https://git.gnome.org/browse/evolution-ews/commit/?id=78afd10a (GSSAPI)
 https://git.gnome.org/browse/evolution-ews/commit/?id=ec6ffbb1 (NTLM)

And for 3.12:
 https://git.gnome.org/browse/evolution-ews/commit/?h=evolution-ews-3-12&id=c75a7a81
 https://git.gnome.org/browse/evolution-ews/commit/?h=evolution-ews-3-12&id=4097e977
 https://git.gnome.org/browse/evolution-ews/commit/?h=evolution-ews-3-12&id=8bfd63d5

I have tested with the EWS workaround, with the real libsoup fix from comment 40, and with *both* of them, the following cases:

 - ntlm_auth helper working.
 - ntlm_auth helper using out-of-date creds, fall back to asking for password.
 - EWS expecting the ntlm_auth helper but soup not actually using it.
 - no ntlm_auth helper, asking for password.

In each case where I'm asked for a password I've tried giving it a wrong password so it fails, then only giving it the correct password on a second (or later) attempt.

Everything seems to be working correctly.

Comment on attachment 281480 [details] [review]
Fix recovery, update tests.

ok, sounds like you've tested this thoroughly, so go ahead and commit it. (sorry for the delay)

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libsoup/issues/53.