284538 - NTLM authentication in Thunderbird for IMAP/etc does not use SSPI (sys-ntlm extension)

Status: NEW

(MailNews Core :: Networking: IMAP, enhancement)

Description

[Jason Gunthorpe]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050210 Firefox/1.0 (Debian package 1.0+dfsg.1-6)
Build Identifier: Thunderbird 1.0 (windows)

This is a feature request bug for single sign on NTLM support on Windows in
the mail/news component (ie for IMAP). This appears to already be implemented
in the HTTP part of Mozilla. Specifically through this code:
extensions/negotiateauth/nsNegotiateAuthSSPI.cpp

Theory goes, the above module accesses the windows SSPI interface to generate
the NTLM messages. The SSPI interface can access the username/password that
was supplied when the user logged into the computer without prompting and pass
it to the IMAP/etc server directly. Thus ThunderBird should never need to know
or ask for the user's password or username. This would be very welcome in
corporate environments with either Exchange, or UNIX servers using Samba's
ntlm_auth program.

However, the NTLM stuff for mail/news does not use this module.

After studying the source for awhile I think this is fairly straightforward
to fix. The code in netwerk/protocol/http/src/nsHttpNTLMAuth.cpp
nsHttpNTLMAuth::ChallengeReceived suggests that calling do_CreateInstance
with the module name "sys-ntlm" will invoke the nsNegotiateAuthSSPI
extension module.

I strongly suspect that changing nsMsgProtocol::DoNtlmStep1 so that
it also uses "sys-ntlm" when asked is essentially all that is necessary.
Hopefully the extension is already compiled and linked into ThunderBird.
Due to the asserts in nsNegotiateAuthSSPI the module Init call would
also have to drop the user/password data.

Since releasing the stored login password over NTLM to an untrusted host can
be a security risk this entire feature ought to be controlled by a checkbox
'Use NTLM Single Sign On' or some such. When checked it would supress password
request dialogs and only use 'sys-ntlm', otherwise, it would act as it
does now.


Reproducible: Always

Steps to Reproduce:
Use a Windows 2000 machine that logs into a Windows Domain on boot
Select 'Use secure authentication' and configure Thunderbird for a corporate
exchange IMAP server
Connect to the IMAP server and note via a packet sniffer that Thunderbird
does not send any authenication data prior to asking for a password - ie it
definately did not try to use the SSPI.

Comment 1

[David :Bienvenu]

Darin can probably say what this would entail...

Comment 2

[Darin Fisher]

David, "sys-ntlm" is another supported implementation of nsIAuthModule.  Like
the "negotiate" implementation, this one does not require any domain, username,
or password values passed to its Init method.  What we do for HTTP is failover
to the regular "ntlm" nsIAuthModule implementation whenever the "sys-ntlm"
module fails on its own.  For web authentication we check a whitelist of
hostnames before using the "sys-ntlm" module, but you shouldn't have to worry
about that sort of thing with IMAP.  So, given that you already have code for
"negotiate" and "ntlm", it should be fairly easy to implement support for
"sys-ntlm".

Comment 3

[Justin Chambers]

Is there any chance this will be fixed in the future?  It is going to be hard to deploy Thunderbird in Ubuntu as a replacement for some of our Outlook users with this working.  I notice this bug report is quite old.

Comment 4

[Jason Gunthorpe]

So, a few years have passed and this no longer seems like a significant problem.

These days thunderbird does support GSSAPI using the SSPI interface which will use the login credentials to SSO using Kerberos with Active Directory. Samba/etc has improved to the point where setting up the Linux side to do compatible GSSAPI is straightforward.

There are few reasons to use NTLM, certainly *very* few to use it 'bare', but it may be would be worthwhile to support SPNEGO through SSPI as well as GSSAPI. That would allow kerberos to function if tickets are available, but it can also fall back to NTLM. I've heard that this is what Windows can do in roaming cases.

So in short, with an Active Directory domain, setup Samba and Winbind on the IMAP/POP server and configure the servers to do Kerberos then single sign on works fine. We are doing this here and have SSO working through Thunderbird to Exim and Dovecot.

Comment 5

[Justin Chambers]

We use a Microsoft Exchange server (unfortunately), is there anyway to make Thunderbird use SSO with it?  I have Firefox working with SSO to a Microsoft IIS based intranet site.  I would only hope I can get Thunderbird to do the same.

Comment 6

[Phoenix]

Very need this feature for migrating from MS Outlook to Thunderbird in AD/Exchange environment.
Installing MIT Kerberos for Windows on each PC is not acceptable.

Comment 7

[Nikolay Shopik]

Simon, does your patch only implement support for Kerberos through GSSAPI? I though it was more generic as GSSAPI suppose to be.

Comment 8

[David :Bienvenu]

we use SSPI on Windows, by default, not Kerberos, with GSSAPI.  So afaik, you don't need to install MIT Kerberos for Windows at all.

Comment 9

[Phoenix]

Seems like Exchange 2003 doesn't support GSSAPI on IMAP... ((
"* OK Microsoft Exchange Server 2003 IMAP4rev1 server version 6.5.7638.1 (server.fqdn) ready.
A01 CAPABILITY
* CAPABILITY IMAP4 IMAP4rev1 IDLE LOGIN-REFERRALS MAILBOX-REFERRALS NAMESPACE LI
TERAL+ UIDPLUS CHILDREN AUTH=NTLM
A01 OK CAPABILITY completed."
So patch will be very usefull.

Comment 10

[Simon Wilkinson]

So, here's where it all gets complicated. First, some definitions...

GSSAPI, the API and wire protocol, is mechanism independent. There are implementations of multiple different security mechanisms presented through it, including Kerberos and NTLM.

GSSAPI, the SASL mechanism, only supports using the Kerberos GSSAPI mechanism. This is because its specification has no ability to negotiate which GSSAPI mechanism to use, so implementations must always use the Kerberos mechanism.

SSPI is a Microsoft API, which can be used to produce wire protocol packets which are compatibile with GSSAPI. As with GSSAPI, it is a mechanism independent framework which implements (amongst many others) NTLM and Kerbeors.

Kerberos for Windows (KfW) is a third party Kerberos implementation for Windows. Its main selling point is that it makes it possible to use Kerberos on Windows machines which aren't bound to an Active Directory realm.

Now, let's simplify. This bug report is about NTLM support, so we can immediately remove any thought of Kerberos. As Darin said back in 2005, we've already got a Windows-only module which provides native NTLM support. This uses SSPI, and the NTLM SASL mechanism. So, let's get rid of "GSSAPI" from the confusion too.

This would actually be a trivial fix for someone with the appropriate development and testing environment - we just need to use the system NTLM implementation on Windows. Sadly, I am not that person.

Comment 11

[c.mammoli]

Any news about this bug?

Comment 12

[Ivan]

Unfortunately, this is the only thing why we can't migrate from Outlook to Thunderbird in our organization (we are using Exchange and it doesn't support Kerberos and GSSAPI with IMAP/SMTP). I was very surprised and sad...

Comment 13

[David Mårtensson]

I think Exchange now support Kerberus and GSSAPI with IMAP/SMTP

At least I use that combo to our Exchange server without any problem.

Just for information.