thunderbird 38.0.1: cannot send email through exchange server (NTLM)

RESOLVED FIXED in Thunderbird 41.0
(Needinfo from 2 people)

Status

MailNews Core
Networking: SMTP
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: hoffmann.martin, Assigned: rkent, NeedInfo)

Tracking

(Blocks: 1 bug, {regression})

Thunderbird 41.0
regression
Dependency tree / graph

Thunderbird Tracking Flags

(thunderbird39 fixed, thunderbird40 fixed, thunderbird41 fixed, thunderbird_esr3839+ fixed, seamonkey2.35+ fixed, seamonkey2.36 fixed, seamonkey2.37 fixed, seamonkey2.38 fixed)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.125 Safari/537.36

Steps to reproduce:

I used thunderbird 38.0.1 to send an email through an exchange server (STARTTLS, NTLM). 


Actual results:

I get "Login to server XXXX failed.", and the email is not sent.


Expected results:

The email should have been sent without the popup window.

This happens on Linux with the Arch repo version and the official mozilla build as well. I am using nss 3.19.1-1 from the Arch repo. 

FYI, when downgrading to 31.7.0-1 (from Arch repo, official not tested) it works.

Comment 1

2 years ago
Does it work if you set network.auth.force-generic-ntlm-v1 true (under Prefernces | Advanced | General | Config Editor)
Keywords: regression
Summary: thunderbird 38.0.1: cannot send email through exchange server → thunderbird 38.0.1: cannot send email through exchange server (STARTTLS, NTLM)
(Reporter)

Comment 2

2 years ago
Using network.auth.force-generic-ntlm-v1 true works! Thank you Magnus!
(Assignee)

Comment 3

2 years ago
I've received multiple reports of this issue from ExQuilla users as well, and the fix in comment 1 fixed it for at least one.

I think we should keep this bug open to consider whether we need a fix in Thunderbird (such as setting that preference by default). Not saying we should, just want to ask the question.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

2 years ago
Yes it's a tricky question. Basically NTLMv1 is insecure. NTLMv2 was implemented in bug 423758, and v1 disabled.
Perhaps Andrew has some input?
Blocks: 423758
(Assignee)

Comment 5

2 years ago
At least for ExQuilla, NTLM is being used over SSL. Many users are actually using Basic authentication which is even less secure when sent open, but is in fact OK when over SSL.

So I think that the issue is NTLM in combination with SSL.

Comment 6

2 years ago
What this preference does is change the from sending an NTLMv2 response to sending the older NTLM response. 

Both are a material improvement over basic authentication, because both are a challenge-response authentication scheme.  I know NTLM has a bad reputation, but it remains far superior to basic (plaintext) authentication and is quite reasonable over SSL.

To further understand why the new NTLMv2 implementation causes a regression, the first step would be to take a PCAP network trace (eg wireshark) of the failing operation in a test domain with:
 - SSL (and supply the SSL private key)
and
 - without SSL.

and if possible, the same two things on Windows where SSPI is in use. 

I'm particularly interested if this works without SSL, as that might imply that Extended Protection (bug 630315) might need to be implemented.
Flags: needinfo?(hoffmann.martin)

Updated

2 years ago
Flags: needinfo?(rkent)
(Assignee)

Comment 7

2 years ago
I don't actually experience this myself, I only have 3 customers who have hit it (and 2 of the 3 have tried the preference workaround and confirms that it works). At least one mentioned they were using Exchange Server 2007, so I assumed that the issue was that just using really old software. These customers are using Exchange Web Services, which is over https:// So I really don't have a direct way to do the test that you are requesting.

My comparison to Basic is just mentioning that the security gain from this is not really useful when the connection is over SSL, as it is in my Exchange Web Services application (over https). But back to normal email, forget Basic, many sites use Plaintext over SSL connections, which even makes Basic look good!

I am assuming that for whatever reason, the sites that are failing do not support NTLMv2 responses. Is there any reason to suspect that something else may be going on?

Andrew, is there any way easy way that we could make the preference work only when the connection type is SSL? That would solve my problem sufficiently that I might recommend setting the preference by default in ExQuilla.

As to other possible fixes, I don't think that the correct thing to do is to by default set this preference by default in Thunderbird, or even in ExQuilla, if it applies to all connection types. If we did a workaround at all, it would be some sort of prompt when a problem was detected.

A more complex workaround might be I suppose to detect that failed connection over NTLMv2, and offer NTLMv1 when the connection is otherwise secure (SSL). But that is more code than I am willing to write (and I have done necko code changes in the past in support of NTLM issues).
Flags: needinfo?(rkent) → needinfo?(abartlet)

Comment 8

2 years ago
I should be able to get logs for a system where it fails for NTML v2 without SSL. Would that be useful? SSL isn't available for the server so I can't check working NTML+SSL to compare with.
status-thunderbird_esr31: --- → affected
tracking-thunderbird_esr31: --- → ?
(Assignee)

Comment 9

2 years ago
Doesn't that support request (and our general understanding of this bug) say that esr31 is not affected?

Comment 10

2 years ago
Our university's Thunderbird users have been prevented from sending mail through our central Exchange 2010 server since upgrading to Thunderbird 38.0.1.  Thanks a lot :-(

Magnus Melin's Comment 1 workaround fixes the problem:
network.auth.force-generic-ntlm-v1=true 

We simply can't explain to all our hundreds of trusty Thunderbird users that they have to fix this undocumented "feature" in Thunderbird! IMHO, it's urgent to revert to NTLM being the default!  If people really need NTLMv2 it should be made a separate Authentication Method under the SMTP server menu, alongside with the old NTLM method.
status-thunderbird_esr31: affected → ---
tracking-thunderbird_esr31: ? → ---
(Assignee)

Comment 11

2 years ago
(In reply to Ole Holm Nielsen from comment #10)
> Our university's Thunderbird users have been prevented from sending mail
> through our central Exchange 2010 server since upgrading to Thunderbird
> 38.0.1.  Thanks a lot :-(
> 

Ole, would it be possible for a Thunderbird developer to be given a temporary account on that server so that we could test this?

Comment 12

2 years ago
(In reply to Kent James (:rkent) from comment #11)
> (In reply to Ole Holm Nielsen from comment #10)
> > Our university's Thunderbird users have been prevented from sending mail
> > through our central Exchange 2010 server since upgrading to Thunderbird
> > 38.0.1.  Thanks a lot :-(
> > 
> 
> Ole, would it be possible for a Thunderbird developer to be given a
> temporary account on that server so that we could test this?

I'm at a university department, so I'll forward your request to our central IT Service people.
But probably any MS Exchange 2010 server would do.  FYI, our SMTP AUTH server uses either SSL or STARTTLS.

Comment 13

2 years ago
(In reply to Kent James (:rkent) from comment #11)
> (In reply to Ole Holm Nielsen from comment #10)
> > Our university's Thunderbird users have been prevented from sending mail
> > through our central Exchange 2010 server since upgrading to Thunderbird
> > 38.0.1.  Thanks a lot :-(
> > 
> 
> Ole, would it be possible for a Thunderbird developer to be given a
> temporary account on that server so that we could test this?

The answer from our central IT Service people is that our Exchange 2010 server uses a Loadbalancer device which apparently can't be set up for NTLMv2 at this time. 

So I urge the Thunderbird developers to revert to NTLM quickly. Otherwise I predict that Thunderbird users world wide (those using Exchange servers) will very soon be migrating to other mail clients.

Comment 14

2 years ago
Another confirmation of the NTLMv2 issue: My wife is a Thunderbird user too, and her organization uses an Exchange server as well.  Since upgrading to Thunderbird 38.0.1 she's been unable to send any mail at all, but Magnus' workaround in Comment 1 solves the problem.  Conclusion: Thunderbird 38 and Exchange server is indeed a bad cocktail.
Duplicate of this bug: 1174696

Comment 16

2 years ago
(In reply to Ole Holm Nielsen from comment #13)
> (In reply to Kent James (:rkent) from comment #11)
> > (In reply to Ole Holm Nielsen from comment #10)
> > > Our university's Thunderbird users have been prevented from sending mail
> > > through our central Exchange 2010 server since upgrading to Thunderbird
> > > 38.0.1.  Thanks a lot :-(
> > > 
> > 
> > Ole, would it be possible for a Thunderbird developer to be given a
> > temporary account on that server so that we could test this?
> 
> The answer from our central IT Service people is that our Exchange 2010
> server uses a Loadbalancer device which apparently can't be set up for
> NTLMv2 at this time. 
> 
> So I urge the Thunderbird developers to revert to NTLM quickly. Otherwise I
> predict that Thunderbird users world wide (those using Exchange servers)
> will very soon be migrating to other mail clients.

Can you please get us some details as to the Load balancer?  I'm quite surprised to hear it doesn't support NTLMv2, as in CIFS/SMB this upgrade has been standard in Windows clients for a number of releases now. 

A comparison between this and what Outlook or some other Microsoft mail client does when configured in a similar way (using IMAP and SMTP, assuming that is possible) may be illuminating.
Flags: needinfo?(Ole.H.Nielsen)

Comment 17

2 years ago
(In reply to Kent James (:rkent) from comment #7)

> A more complex workaround might be I suppose to detect that failed
> connection over NTLMv2, and offer NTLMv1 when the connection is otherwise
> secure (SSL). But that is more code than I am willing to write (and I have
> done necko code changes in the past in support of NTLM issues).

This could perhaps be done during the first-time configuration, but if you do it at login time, every time, you risk bumping the bad password count each login.  Sadly NTLMv2 isn't something that is negotiated (for various reasons).
Flags: needinfo?(abartlet)
(Assignee)

Comment 18

2 years ago
I was able to test IMAP NTLM authentication on a Linux system, using both TB 31 and TB 38.  Both work, for TB 38 I can clearly see in the NTLM:5 log that NTLM Type 2 response is being handled.

So at this point, there are two possibilities:

1) Thunderbird SMTP authentication does not work properly with NTLM 2 responses (in which case we should probably force NTLM 1 until we resolve this).

2) Many Exchange server installations have for some reason NTLM version 1 in use.  I think this is the most likely scenario. If that is the case, I don't think that we should by default force the less secure NTLM version 1 on everybody else, particularly since there is a solid workaround. We could add a release note and perhaps a support article that mentions this issue and the workaround.

It would be good if I could test a failing SMTP installation, as the reports (except for ExQuilla which is https) are for smtp not imap. If anyone could provide a test account for an SMTP server that is failing without the workaround preference setting, that would be appreciated.
tracking-thunderbird_esr38: --- → +

Comment 19

2 years ago
I'm not yet convinced that this is an NTLMv1 vs. NTLMv2 issue.

I've used an MITM TLS proxy to observe the actual communication. It gave me this with TB 38:

  S->C 98 '220 SRV-SBS.example.local Microsoft ESMTP MAIL Service ready at Thu, 18 Jun 2015 10:44:19 +0200\r\n'
  C->S 23 'EHLO [ip.ip.ip.ip]\r\n'
  S->C 250 '250-SRV-SBS.example.local Hello [ip.ip.ip.ip]\r\n250-SIZE\r\n250-PIPELINING\r\n250-DSN\r\n250-ENHANCEDSTATUSCODES\r\n250-STARTTLS\r\n250-X-ANONYMOUSTLS\r\n250-AUTH NTLM\r\n250-X-EXPS GSSAPI NTLM\r\n250-8BITMIME\r\n250-BINARYMIME\r\n250-CHUNKING\r\n250-XEXCH50\r\n250 XRDST\r\n'
  C->S 10 'STARTTLS\r\n'
  S->C 29 '220 2.0.0 SMTP server ready\r\n'
  C->S 23 'EHLO [ip.ip.ip.ip]\r\n'
  S->C 222 '250-SRV-SBS.example.local Hello [ip.ip.ip.ip]\r\n250-SIZE\r\n250-PIPELINING\r\n250-DSN\r\n250-ENHANCEDSTATUSCODES\r\n250-AUTH NTLM LOGIN\r\n250-X-EXPS GSSAPI NTLM\r\n250-8BITMIME\r\n250-BINARYMIME\r\n250-CHUNKING\r\n250-XEXCH50\r\n250 XRDST\r\n'

At this point TB 38 stops communicating with the server and the GUI is requesting a password for the account. The password is of course already known to TB. Entering it again does not help.

TB 37 on the other hand goes on with NTLM authentication as expected by sending

  C->S 56 'AUTH NTLM XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=\r\n'

and so on.

So for some reason TB 38 does not perform the NTLM authenticaton without the workaround (network.auth.force-generic-ntlm-v1=true).

Lan Manager Authentication Level on the server side is set to "Send NTLMv2 response only".

Comment 20

2 years ago
My situation is different, but related:

I used IMAP+STARTTLS+Kerberos/GSSAPI against an Exchange server.  After the upgrade to TB 38.0.1 TB complains "The IMAP server ... does not support the selected authentication method.

Of course, for me the workaround "network.auth.force-generic-ntlm-v1=true" doesn't make sense and doesn't work.

So it looks something regarding authentication method detection broke.
(Assignee)

Comment 21

2 years ago
Michael, is your issue for IMAP or SMTP?

Comment 22

2 years ago
(In reply to stackeffect from comment #19)
> I'm not yet convinced that this is an NTLMv1 vs. NTLMv2 issue.
> 
> I've used an MITM TLS proxy to observe the actual communication. It gave me
> this with TB 38:

Can you please try for me:
 - An earlier version that supported NTLM (it was blacklisted for a bit in Firefox, I'm not sure about Thunderbird)
 - Windows vs Linux platforms
 - A Microsoft client of some kind using SMTP and NTLM.

Seeing the exchange in these different situations would help a lot in understanding what is going on here. 

The trouble I have with your suggestion is that the NTLMv1 vs NTLMv2 choice should not be visible to layers about the NTLM lib.  Indeed, what is really strange is that even load balancers shouldn't break it, unless the are quite rudely intrusive.

I remain rather puzzled.  We made the same upgrade in Samba quite some time ago for SMB clients and had very few issues.
Flags: needinfo?(stackeffect)

Comment 23

2 years ago
(In reply to Andrew Bartlett from comment #22)
> Can you please try for me:
>  - An earlier version that supported NTLM

Not sure what you mean by "earlier version". TB 37 is the earlier version working OK in this situation.

>  - Windows vs Linux platforms

I can try that this WE.

>  - A Microsoft client of some kind using SMTP and NTLM.

Nope.

> Seeing the exchange in these different situations would help a lot in
> understanding what is going on here. 

To make my observation more clear: TB 38 just stops the protocol. It is not sending the "AUTH NTLM" message required to initiate the authentication. Instead it is asking the user for the password although it has that same password already. The password is known to the password manager and the master password worked: all incoming mails are pulled from the server without problems (via IMAP, no NTLM involved).

There is no failed authentication attempt included in this scenario. TB 38 just does not (try to) authenticate.
(Assignee)

Comment 24

2 years ago
(In reply to Johannes from comment #23)

From the log that you gave in comment 19, this issue can be tested on the client side without having any valid credentials. I just need to confirm whether the NTLM response is sent, and if not why not.

What I need is a server URL to test against. If you could send me the address and port of a server that does SMTP TLS with NTLM, I could trace this out with a debugger. You could send the address to me privately if you wish using rkent@caspia.com.

Comment 25

2 years ago
(In reply to Kent James (:rkent) from comment #21)
> Michael, is your issue for IMAP or SMTP?

In comment #20 I only talked about an issue with IMAP.  I didn't try to send anything, as I had no mails to reply to...

I just tried sending an email.  It doesn't work anymore.  I use Port 587, StartTLS and Kerberos/GSSAPI for sending.  Looking with Wireshark, the TCP connection is reset by Thunderbird at some point after the TLS handshake (I don't have an SMTP MITM proxy, so can't look inside). Our SMTP banner before StartTLS looks like this:

 220 ...servername... Microsoft ESMTP MAIL Service ready at Fri, 19 Jun 2015 12:32:09 +0200
 EHLO [192.168.xxx.xxx]
 250-servername Hello [192.168.xxx.xxx]
 250-SIZE 20971520
 250-PIPELINING
 250-DSN
 250-ENHANCEDSTATUSCODES
 250-STARTTLS
 250-AUTH GSSAPI NTLM
 250-8BITMIME
 250-BINARYMIME
 250 CHUNKING

Hope this helps.
(Assignee)

Comment 26

2 years ago
I setup a Microsoft SMTP server on one of my test servers, enabled only Integrated Windows Authentication (NTLM). Otherwise this is a default configuration of a Windows 2010 server, with no STARTTLS.

I can confirm that NTLM authentication fails with network.auth.force-generic-ntlm-v1 set to the default false, and succeeds with the true, on a Thunderbird 38 build.

This is a much more severe regression than I had feared, in two ways: 1) it affects Windows clients, and 2) it happens with default configuration of a Microsoft SMTP server that requires NTLM authentication.

I'll post complete transaction logs in a few minutes. I'm modifying the source so that I can log the normally suppressed responses.
(Assignee)

Comment 27

2 years ago
Turns out to be a simple issue: SMTP is limiting the length of the response to 256 characters, when the actual NTLMv2 response is closer to 400 characters. The SMTP line itself (including CRLF) can be 512 characters, so this limit is not needed:

1432     else if (m_currentAuthMethod == SMTP_AUTH_NTLM_ENABLED ||
1433              m_currentAuthMethod == SMTP_AUTH_MSN_ENABLED)
1434     {
1435       MOZ_LOG(SMTPLogModule, mozilla::LogLevel::Debug, ("NTLM/MSN auth, step 2"));
1436       nsAutoCString response;
1437       rv = DoNtlmStep2(m_responseText, response);
1438       PR_snprintf(buffer, sizeof(buffer), "%.256s" CRLF, response.get());
1439     }

Increase the .256 to .510 and the authentication works.
(Assignee)

Updated

2 years ago
Component: Untriaged → Networking: SMTP
Product: Thunderbird → MailNews Core
Summary: thunderbird 38.0.1: cannot send email through exchange server (STARTTLS, NTLM) → thunderbird 38.0.1: cannot send email through exchange server (NTLM)
(Assignee)

Comment 28

2 years ago
Created attachment 8624891 [details] [diff] [review]
Allow longer length NTLMv2 response
Assignee: nobody → rkent
Status: NEW → ASSIGNED
Attachment #8624891 - Flags: review?(neil)
(Assignee)

Comment 29

2 years ago
Given the debugging, let me make sure it is clear what this bug is about. This bug is only about NTLMv2 issues in SMTP. That means that it does not cover the failed https:// logins that my ExQuilla users are seeing, nor does it cover the IMAP issues of comment 19. Not saying those are not real issues, just saying they are not this bug.

Comment 30

2 years ago
Comment on attachment 8624891 [details] [diff] [review]
Allow longer length NTLMv2 response

Please make that response size dynamic, or at least truly massive.  

All it will take is someone using a very long domain name, or us adding in Extended Protection for #630315 and we will all be back where we started.
Attachment #8624891 - Flags: feedback-
(Assignee)

Comment 31

2 years ago
Andrew, thanks for the feedback. Allowing a longer response makes sense, but at the moment this bug is a critical blocker for Thunderbird 38. I would appreciate your feedback on likely lengths, but I still think that we need to have this minimum fix in for Thunderbird 38.1.0

I'm not an SMTP protocol expert, but reading the specs it looks like 512 characters is a recommended line limit, so going above that is more work as we have to support a multi-line response. Or assume that we can violate the recommended 512 character limit.

Comment 32

2 years ago
Upgrading made Thunderbird stop working with Exchange (2010, IMAP) in my case, too. The suggested workaround of toggling the NTLM settings makes no difference in my case.

Comment 33

2 years ago
(In reply to dnh from comment #32)
> Upgrading made Thunderbird stop working with Exchange (2010, IMAP) in my
> case, too. The suggested workaround of toggling the NTLM settings makes no
> difference in my case.

Please file IMAP bugs under a different bug, this is getting very confusing.

Comment 34

2 years ago
(In reply to Kent James (:rkent) from comment #31)
> Andrew, thanks for the feedback. Allowing a longer response makes sense, but
> at the moment this bug is a critical blocker for Thunderbird 38. I would
> appreciate your feedback on likely lengths, but I still think that we need
> to have this minimum fix in for Thunderbird 38.1.0

Assuming a 50 char domain name, this appears at least 3 times in the packet, which will bring at least 300 bytes (and 200 bytes additional) of output, before base64 encoding.  Other variables include the username (unicode, so 2x, once per packet), and the first element of the server name (likewise unicode, 2x, twice per packet). 

With a long username and server name, 512 / 1.33 (base64 overhead) bytes = 386 bytes still seems quite easy to reach, we need a longer buffer. 

> I'm not an SMTP protocol expert, but reading the specs it looks like 512
> characters is a recommended line limit, so going above that is more work as
> we have to support a multi-line response. Or assume that we can violate the
> recommended 512 character limit.

I'm not sure on this part, sorry.  Perhaps see what a Microsoft clients does with a really long domain and username (need not actually exist to see how it gets output).
Comment on attachment 8624891 [details] [diff] [review]
Allow longer length NTLMv2 response

>+      PR_snprintf(buffer, sizeof(buffer), "%.510s" CRLF, response.get());
Nit: sizeof(buffer) is 512 so if response's length is at least 510 then you'll chop off the LF so that the null terminator will fit. r=me with that fixed.

(The original 256 appears to be an arbitrary value from the initial version of this file that was cargo-culted through to this point.)
Attachment #8624891 - Flags: review?(neil) → review+
(Assignee)

Comment 36

2 years ago
http://hg.mozilla.org/comm-central/rev/fbb26b3fc314

I'll file a followup bug with the issue of needed longer response length.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-thunderbird39: --- → affected
status-thunderbird40: --- → affected
status-thunderbird41: --- → fixed
status-thunderbird_esr38: --- → affected
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 41.0
(Assignee)

Comment 37

2 years ago
Comment on attachment 8624891 [details] [diff] [review]
Allow longer length NTLMv2 response

I'll uplift this patch in a couple of days.
Attachment #8624891 - Flags: approval-comm-esr38+
Attachment #8624891 - Flags: approval-comm-beta+
Attachment #8624891 - Flags: approval-comm-aurora+
(Assignee)

Updated

2 years ago
Blocks: 1176503

Updated

2 years ago
status-seamonkey2.35: --- → affected
status-seamonkey2.36: --- → affected
status-seamonkey2.37: --- → affected
status-seamonkey2.38: --- → fixed
tracking-seamonkey2.35: --- → +

Comment 38

2 years ago
I can confirm this happens without SSL (in fact TB 38 is disconnecting immediately after the welcome if using SSL or after the new welcome after STARTTLS).

But in any case.

TB can auth to IMAP server fine using NTLM
TB cannot auth to SMTP server without the workaround, and no TLS/SSL is involved.

Server is no exchange, and uses SSPI on 2k12R2, so I very much doubt it cannot handle v2.  I would be looking up another tree.

Comment 39

2 years ago
sorry - re-read the problem (buffer size).

We see NTLM buffer sizes increase with every new version of Windows.  I would allow minimum 4kb.

Also I'm pretty sure SASL spec allows for longer lines.
(Assignee)

Comment 40

2 years ago
https://hg.mozilla.org/releases/comm-aurora/rev/b9e684c286be
https://hg.mozilla.org/releases/comm-beta/rev/a62f8a4e3c1e
status-seamonkey2.36: affected → fixed
status-seamonkey2.37: affected → fixed
status-thunderbird39: affected → fixed
status-thunderbird40: affected → fixed

Updated

2 years ago
Duplicate of this bug: 1177034
https://support.mozilla.org/en-US/questions/1068346

Updated

2 years ago
Duplicate of this bug: 1177352
(Assignee)

Comment 44

2 years ago
http://hg.mozilla.org/releases/comm-esr38/rev/a2c209b23910
status-thunderbird_esr38: affected → fixed
tracking-thunderbird_esr38: + → 39+

Updated

2 years ago
Blocks: 1177041

Comment 45

2 years ago
Comment on attachment 8624891 [details] [diff] [review]
Allow longer length NTLMv2 response

[Approval Request Comment]
This approval request is for comm-release+SEAMONKEY_2_35_RELEASE_BRANCH
Regression caused by (bug #): N/A
User impact if declined: SeaMonkey 2.35 cannot send email through exchange server (NTLM)
Testing completed (on c-c, etc.): Thunderbird 41, 40, 39, esr38
Risk to taking this patch (and alternatives if risky): bug fix. No risk.
Attachment #8624891 - Flags: approval-comm-release?

Comment 46

2 years ago
Thunderbird 38.1.0 does not fix the problem for me.
After updating to v 38.1.0 I set the pref network.auth.force-generic-ntlm-v1 back to false, and immediately run into the problem again when sending a message: the password prompt pops up, and the password isn't accepted.
There was no such problem with TB 31.
This only affects SMTP, receiving mail via IMAP from the Exchange server works fine.

Comment 47

2 years ago
I've also updated to Thunderbird 38.1.0 (on Windows 7) and used the Config editor to reset the pref network.auth.force-generic-ntlm-v1 to the default value of false.  I have no problems sending mail with SMTP AUTH to our Exchange 2010 server.
Flags: needinfo?(Ole.H.Nielsen)

Updated

2 years ago
status-seamonkey2.35: affected → fixed

Comment 48

2 years ago
Comment on attachment 8624891 [details] [diff] [review]
Allow longer length NTLMv2 response

uplift to comm-release+SEAMONKEY_2_35_RELEASE_BRANCH CLOSED TREE
http://hg.mozilla.org/releases/comm-release/rev/c8490761484d
Attachment #8624891 - Flags: approval-comm-release?

Comment 49

2 years ago
I have installed Thunderbird 38.2.0 (Windows 10) and the network.auth.force-generic-ntlm-v1 = true
work around does not seem to work.
For former version of Thunderbird is WAS working for me.
Anybody knows a solution?

Comment 50

2 years ago
(In reply to Birger from comment #49)
> I have installed Thunderbird 38.2.0 (Windows 10) and the
> network.auth.force-generic-ntlm-v1 = true
> work around does not seem to work.
> For former version of Thunderbird is WAS working for me.
> Anybody knows a solution?

Not a solution but I have tried the "network.auth.force-generic-ntlm-v1 = true" workaround with Thunderbird 38.2.0 right now and it works (I was hit by the bug earlier today). The only difference is that I am under Ubuntu 14.04.

Comment 51

2 years ago
Same story here on Mac OSX (10.9.5) with TB 38.2.0. Couldn't connect to the exchange SMTP with "network.auth.force-generic-ntlm-v1 = false", but now can when changed to true.

This bug is not resolved.

Here's the log without the option set to 'false':

2071745296[100341370]: SMTP auth: server caps 0x24914, pref 0xC000, failed 0x0, avail caps 0x4000
2071745296[100341370]: (GSSAPI = 0x800, CRAM = 0x2000, NTLM = 0x4000, MSN =  0x8000, PLAIN = 0x200, LOGIN = 0x100, EXTERNAL = 0x400)
2071745296[100341370]: trying auth method 0x4000
2071745296[100341370]: SMTP entering state: 16
2071745296[100341370]: SMTP AuthLoginStep1() for etienne.gaudrain@xxxxx.xx@??2
2071745296[100341370]: NTLM/MSN auth, step 1
2071745296[100341370]: Logging suppressed for this command (it probably contained authentication information)
2071745296[100341370]: SMTP entering state: 0
2071745296[100341370]: SMTP Response: 334 TlRMTVNTUAACAAAAEAAQADgAAAAFgokCf7JNpJnHhnYAAAAAAAAAANIA0gBIAAAABgGxHQAAAA9DAE8AUgBFAC0AUgBFAFMAAgAQAEMATwBSAEUALQBSAEUAUwABABIAQwBOAEMASAAwADEAVwBWAFAABAAuAGMAbwByAGUALQByAGUAcwAuAHIAbwBvAHQAYwBvAHIAZQAuAGwAbwBjAGEAbAADAEIAYwBuAGMAaAAwADEAdwB2AHAALgBjAG8AcgBlAC0AcgBlAHMALgByAG8AbwB0AGMAbwByAGUALgBsAG8AYwBhAGwABQAcAHIAbwBvAHQAYwBvAHIAZQAuAGwAbwBjAGEAbAAHAAgAnHNM/gbr0AEAAAAA
2071745296[100341370]: SMTP entering state: 18
2071745296[100341370]: SMTP Login response, code 334
2071745296[100341370]: SMTP entering state: 17
2071745296[100341370]: SMTP AuthLoginStep2
2071745296[100341370]: NTLM/MSN auth, step 2
2071745296[100341370]: Logging suppressed for this command (it probably contained authentication information)
2071745296[100341370]: SMTP entering state: 0
2071745296[100341370]: SMTP Response: 535 5.7.3 Authentication unsuccessful
2071745296[100341370]: SMTP entering state: 18
2071745296[100341370]: SMTP Login response, code 535
2071745296[100341370]: marking auth method 0x4000 failed
2071745296[100341370]: SMTP auth: server caps 0x24914, pref 0xC000, failed 0x4000, avail caps 0x0
2071745296[100341370]: (GSSAPI = 0x800, CRAM = 0x2000, NTLM = 0x4000, MSN =  0x8000, PLAIN = 0x200, LOGIN = 0x100, EXTERNAL = 0x400)
2071745296[100341370]: no auth method remaining
2071745296[100341370]: SMTP: ask user what to do (after login failed): new password, retry or cancel
2071745296[100341370]: cancel button pressed
2071745296[100341370]: SMTP Send: QUIT
2071745296[100341370]: SMTP entering state: 0
2071745296[100341370]: SMTP entering state: 0
2071745296[100341370]: SMTP Response: 221 2.0.0 Service closing transmission channel
2071745296[100341370]: SMTP entering state: 11


And here's the log with the option set to 'true':

2071745296[100341370]: SMTP auth: server caps 0x24914, pref 0xC000, failed 0x0, avail caps 0x4000
2071745296[100341370]: (GSSAPI = 0x800, CRAM = 0x2000, NTLM = 0x4000, MSN =  0x8000, PLAIN = 0x200, LOGIN = 0x100, EXTERNAL = 0x400)
2071745296[100341370]: trying auth method 0x4000
2071745296[100341370]: SMTP entering state: 16
2071745296[100341370]: SMTP AuthLoginStep1() for etienne.gaudrain@xxxxxx.xx@??2
2071745296[100341370]: NTLM/MSN auth, step 1
2071745296[100341370]: Logging suppressed for this command (it probably contained authentication information)
2071745296[100341370]: SMTP entering state: 0
2071745296[100341370]: SMTP Response: 334 TlRMTVNTUAACAAAAEAAQADgAAAAFgokCmJeEJdLQEVQAAAAAAAAAANIA0gBIAAAABgGxHQAAAA9DAE8AUgBFAC0AUgBFAFMAAgAQAEMATwBSAEUALQBSAEUAUwABABIAQwBOAEMASAAwADEAVwBWAFAABAAuAGMAbwByAGUALQByAGUAcwAuAHIAbwBvAHQAYwBvAHIAZQAuAGwAbwBjAGEAbAADAEIAYwBuAGMAaAAwADEAdwB2AHAALgBjAG8AcgBlAC0AcgBlAHMALgByAG8AbwB0AGMAbwByAGUALgBsAG8AYwBhAGwABQAcAHIAbwBvAHQAYwBvAHIAZQAuAGwAbwBjAGEAbAAHAAgArGf/cAbr0AEAAAAA
2071745296[100341370]: SMTP entering state: 18
2071745296[100341370]: SMTP Login response, code 334
2071745296[100341370]: SMTP entering state: 17
2071745296[100341370]: SMTP AuthLoginStep2
2071745296[100341370]: NTLM/MSN auth, step 2
2071745296[100341370]: Logging suppressed for this command (it probably contained authentication information)
2071745296[100341370]: SMTP entering state: 0
2071745296[100341370]: SMTP Response: 235 2.7.0 Authentication successful
2071745296[100341370]: SMTP entering state: 18
2071745296[100341370]: SMTP Login response, code 235

Also, authentication through telnet/openssl works like a charm.
(Assignee)

Comment 52

2 years ago
(In reply to egaudrain from comment #51)
> Same story here on Mac OSX (10.9.5) with TB 38.2.0. Couldn't connect to the
> exchange SMTP with "network.auth.force-generic-ntlm-v1 = false", but now can
> when changed to true.
> 
> This bug is not resolved.

This bug is now interpreted as dealing with the specific issue of inadequate buffer length when used with SMTP with NTLMv2 authentication. A fix was done for that which fixed a real issue that many people were having, and the bug then resolved. Any further related issues would need to be filed in a new bug.

But given that, your particular issue appears to be that your network is not properly supporting NTLMv2 so that you are forced to use a fallback to the quite insecure NTLMv1. There is no reasonable way that Mozilla is going to implement automatic fallback to the insecure NTLMv1 without forcing the user to go through some manual action such as the setting of the preference. So there is no reasonable way that this is going to change in Mozilla code. You are currently successfully using the Mozilla code as it was designed to be used.

But if you disagree, please file a new bug and try to make your case.

Comment 53

2 years ago
Hmm, I am having similar issue I think. I have tried the suggestion of setting the "network.auth.force-generic-ntlm-v1 = true". It did not seem to have an effect for me.

My issue is perhaps different. When I try to see e-mails in the Inbox it works fine. I also have many subfolders under the Inbox (for mailing lists sorting etc). If I try to access the mail in any of the subfolders it fails and I get the 'login failed' window popping up.

I activated the logging as explained here: https://wiki.mozilla.org/MailNews:Logging

What I in particular noticed is that in the log I only saw references to mail01.our.host.se, while we recently changed to mail02.our.host.se for the IMAP server address. I have changed to mail02 in the account settings but based on the log output it looks like this is perhaps not applied correctly? Is this perhaps a different issue? If I look in the config editor, I see that values such as 'mail.server.server3.hostname' is set to mail01.our.host.se, while the one item 'mail.server.server3.realhostname' is set to mail02.our.host.se. So maybe this is OK.

I am also using SSL and NTLM to connect to our MS Exchange server using the IMAP protocol. I am on OSX 10.10.5, running Tbird 38.4.

I also see this item is marked as fixed already, so I should perhaps not report here in any case.
You need to log in before you can comment on or make changes to this bug.