NTLM support is disabled since curl's migration from OpenSSL to NSS.  If you build the upstream libcurl on top of NSS, it doesn't support NTLM either.  I'll check if it is intentionally or not.

I've discussed the bug with Daniel Stenberg (CC'd).  The problem is that the NTLM code uses some crypto/hash algorithms from OpenSSL, which do not have compatible API in NSS:

http://github.com/bagder/curl/blob/master/lib/http_ntlm.c

Additionally MD4 does not seem to be supported by NSS even now: bug 258481

I see Mozilla has its own implementation of NTLM auth, but AFAIK that's not available from NSS itself:

https://bugzilla.mozilla.org/show_bug.cgi?id=224653

Bob, is there any easy way to address it?

There are still many companies who use Microsoft Exchange Servers.
To communicate with these servers NTLM support is, sadly enough, a necessity.

Would the following trunk i found be the solution?

http://svn.fedorahosted.org/svn/identity/common/trunk/nss_compat_ossl/

(In reply to comment #3)
> There are still many companies who use Microsoft Exchange Servers.
> To communicate with these servers NTLM support is, sadly enough, a necessity.

I see your point.  On the other hand, nobody noticed the missing NTLM support for 3 years, so I don't see it as frequented problem.

> Would the following trunk i found be the solution?
> 
> http://svn.fedorahosted.org/svn/identity/common/trunk/nss_compat_ossl/    

I don't think so.  Basically we have two choices while porting packages to NSS:

1) either use NSS libraries directly, as curl does

2) or use nss_compat_ossl (as e.g. elinks does)

There is no real benefit in mixing both approaches together.  Some statistics are available here:

http://fedoraproject.org/wiki/CryptoConsolidationScorecard

Anyway it does not solve the missing md4.  If NSS does not support it, then probably neither nss_compat_ossl does.  AFAIK nss_compat_ossl does not implement any crypto/hash algorithms on its own.

As upstream maintainer let me mention that I agree with Kamil on this.

If we'd add NTLM support to curl when built with NSS I figure the only sensible way would be to 1) use native NSS functions for md5 and des and then 2) provide a local md4 implementation in the same style curl already has a local md5 implementation for some circumstances.

But it takes someone to do the work good enough to make it get merged into mainline.

NSS will never add support for md4 so the only alternative would be to do a local implementation of it.

Right, nss_compat_ossl is a lightweight wrapper of NSS functions, it doesn't implement any crypto of its own. Definitely not a good idea to mix the two. The curl work helped inspire and drive the nss_compat_ossl work.

md4 should be treated as a non-cryptographic checksum, which is why NSS didn't implement it.

AFAIK the only use of md4 out there is NTLM. We had talked about having a specific NTLM library to use, but I guess that fell through. If we need to support NTLM, we could load md4 as a PKCS #11 module in nss_compat_ossl (which turns off when FIPS mode is on).

Certainly it looks like there needs to be more outside curl work to be done if this needs to be supported.

In any case, NSS will never use md4 as a first rate hash function, particularly in the a case where that hash is signed by something (like RSA).

bob

There are funky NTLM-libs that could be used for this, such as libntlm (http://josefsson.org/libntlm/) but in upstream project I've decided to not use that as the primary choice mostly due to the licensing (libntlm is LGPL while most of curl is MIT) and of course the fact that we already have an existing custom implementation.

Also, if you'd go with using an NTLM lib you would also have the problem with adding yet another crypto lib (which the NTLM lib would use) as part of the deal. If adding another crypto lib is a viable option, you could also just as well make sure that curl could be built with OpenSSL or gcrypt for the NTLM parts only and NSS for all the SSL functionality.

So, in the end, a local md4 implementation and code adjusted for NSS functions seems like the smoothest solution. If anyone feels like doing some coding...

(In reply to comment #8)
> So, in the end, a local md4 implementation and code adjusted for NSS functions
> seems like the smoothest solution. If anyone feels like doing some coding...

I completely agree.  Briefly looked at the code, I don't see any problem in implementing it such.  There are also 28 test-cases already that utilize the NTLM support of libcurl.  It could prevent me from the necessity of installing some obscure testing servers, at least in the beginning.  But to be honest, I don't see this task anyhow prioritized...

As for the licenses, I don't think the local implementation of md5 fits seamlessly into the rest of curl's code.  At least it's copyrighted by RSA Data Security, Inc.  So taking the same implementation of md4 seems harmless to me, but IANAL.

There's an MD4 implementation in tcllib (http://tcllib.cvs.sourceforge.net/viewvc/tcllib/tcllib/modules/md4/) that's derived from the RSA codebase. the TCL license is very similar to the MIT license, but again IANAL...

Paul, thanks for the pointer!  I've been looking at probably the same implementation from FreeBSD:

http://fxr.watson.org/fxr/source/kern/md4c.c

I believe it also has quite compatible interface with the OpenSSL one, which is already used in lib/http_ntlm.c:

    MD4_CTX MD4pw;
    MD4_Init(&MD4pw);
    MD4_Update(&MD4pw, pw, 2*len);
    MD4_Final(ntbuffer, &MD4pw);

patch proposed upstream:

http://article.gmane.org/gmane.comp.web.curl.library/28462

built as curl-7.21.0-2.fc14

pushed upstream:

http://github.com/bagder/curl/commit/f3b77e5

curl-7.20.1-3.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/curl-7.20.1-3.fc13

curl-7.19.7-12.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/curl-7.19.7-12.fc12

curl-7.20.1-3.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update curl'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/curl-7.20.1-3.fc13

curl-7.19.7-12.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update curl'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/curl-7.19.7-12.fc12

M. Hagoort, could you please test if the updated packages solve the problem for you?

I will test on tuesday if my new F13 install doesn't freeze up again (some issue with Xorg and firefox #525325 )

Thanks in advance!  Your input is appreciated.

Tested using an Exchange 2007 server but failed.
Sounds like there is no persistent connection used with bi-directional communication (at least that was a problem i had when writing my own implementation in PHP).
See my solution for PHP at: http://forums.fedoraforum.org/showthread.php?p=1267056

$ curl https://exchange2007/EWS/services.wsdl --ntlm --verbose --show-error --insecure --user [USER]
Enter host password for user '[USER]':
* About to connect() to exchange2007 port 443 (#0)
*   Trying exchange2007... connected
* Connected to exchange2007 (exchange2007) port 443 (#0)
* Initializing NSS with certpath: /etc/pki/nssdb
* warning: ignoring unsupported value (1) of ssl.verifyhost
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* Remote Certificate has expired.
* SSL certificate verify ok.
* SSL connection using TLS_RSA_WITH_AES_128_CBC_SHA
* Server certificate:
*       subject: CN=exchange2007,OU=Domain Control Validated - FreeSSL(TM),OU=See www.rapidssl.com/resources/cps (c)10,OU=GT15185388,O=exchange2007,C=NL,serialNumber=XQbYzOqv6sr2aB72icPJCNrjfuR8I9ay
*       start date: Feb 16 03:59:54 2010 GMT
*       expire date: Mar 19 03:48:37 2010 GMT
*       common name: exchange2007
*       issuer: OU=Equifax Secure Certificate Authority,O=Equifax,C=US
* Server auth using NTLM with user '[USER]'
> GET /EWS/services.wsdl HTTP/1.1
> Authorization: NTLM [BASE64]
> User-Agent: curl/7.20.1 (x86_64-redhat-linux-gnu) libcurl/7.20.1 NSS/3.12.6.2 zlib/1.2.3 libidn/1.16 libssh2/1.2.4
> Host: exchange2007
> Accept: */*
> 
< HTTP/1.1 401 Unauthorized
< Server: Microsoft-IIS/7.0
< WWW-Authenticate: NTLM [BASE64]
* gss_init_sec_context() failed: : Credentials cache file '/tmp/krb5cc_500' not found
< WWW-Authenticate: Negotiate
< X-Powered-By: ASP.NET
< Date: Tue, 06 Jul 2010 11:43:08 GMT
< Content-Length: 0
< 
* Connection #0 to host exchange2007 left intact
* Closing connection #0

"Connection #0 to host exchange2007 left intact" is what it says when the connection _is_ left alive aka persistent so that is not the problem here... Perhaps that gss problem is a sympthom?

curl-7.20.1-3.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

(In reply to comment #22)
> Tested using an Exchange 2007 server but failed.

Thanks for the testing!

> * Server auth using NTLM with user '[USER]'
> > GET /EWS/services.wsdl HTTP/1.1
> > Authorization: NTLM [BASE64]
> > User-Agent: curl/7.20.1 (x86_64-redhat-linux-gnu) libcurl/7.20.1 NSS/3.12.6.2 zlib/1.2.3 libidn/1.16 libssh2/1.2.4
> > Host: exchange2007
> > Accept: */*
> > 
> < HTTP/1.1 401 Unauthorized
> < Server: Microsoft-IIS/7.0
> < WWW-Authenticate: NTLM [BASE64]

I think the important part is here ^^^.  The server has just refused your NTLM authentication.  It does not say much about why it happened.  Are you able to connect the same server with anything else?

> * gss_init_sec_context() failed: : Credentials cache file '/tmp/krb5cc_500' not
> found
> < WWW-Authenticate: Negotiate

I don't think the later failure is anyhow related to the NTLM code.

(In reply to comment #25)
> Are you able to connect the same server with anything else?

Yes, Firefox and my custom PHP code (link above) work fine.

The NTLM (v1) connection has 5 steps:

1: open persistent connection
2: write() request to server
3: read() 401 reply with WWW-Authenticate: NTLM [BASE64]
4: write() request to server again (with Authorization: NTLM [BASE64])
5: read() response

I only see step 4 and then step 3 in the log and no retry for authentication after the 401.

With my knowledge, I will decode the base64 strings and use WireShark (when ssl is disabled) to see if i can find the issue.

You're right.  Nevertheless it's something really hard to debug for me as I don't have access to any such server.  Could you compare it to the OpenSSL powered libcurl if it makes any difference?  Should I prepare a scratch build for testing?

Daniel, any idea why gss_init_sec_context() is called at all, when --ntlm is explicitly given?

Because the server responds with a "WWW-Authenticate: Negotiate" and that is taken care of independently of what what the auth option is set to...

Curl_http_input_auth() gets invoked on WWW-Authenticate headers
Curl_input_negotiate() gets invoked due to the 'Negotiate' in that header
gss_init_sec_context() is called from within there

(In reply to comment #27)
> Could you compare it to the OpenSSL powered libcurl if it makes any difference?
> Should I prepare a scratch build for testing?    

I have an Ubuntu server nearby which uses OpenSSL.
Will run the same command to see what happens, and respond the results.

Using Ubuntu 9.10 it has the additional steps:
* About to connect() to EXCHANGE port 443 (#0)
*   Trying EXCHANGE... connected
* Connected to EXCHANGE (EXCHANGE) port 443 (#0)
* successfully set certificate verify locations:
* Server auth using NTLM with user '[USER]'
> GET /EWS/services.wsdl HTTP/1.1

> Authorization: NTLM [BASE64]

> User-Agent: curl/7.19.5 (i486-pc-linux-gnu) libcurl/7.19.5 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15

> Host: EXCHANGE

> Accept: */*

> 

< HTTP/1.1 401 Unauthorized

< Server: Microsoft-IIS/7.0

< WWW-Authenticate: NTLM [BASE64]

* gss_init_sec_context() failed: : Credentials cache file '/tmp/krb5cc_1000' not found
< WWW-Authenticate: Negotiate

< X-Powered-By: ASP.NET

< Date: Fri, 09 Jul 2010 08:59:03 GMT

< Content-Length: 0

< 

* Connection #0 to host EXCHANGE left intact
* Issue another request to this URL: 'https://EXCHANGE/EWS/services.wsdl'
* Re-using existing connection! (#0) with host EXCHANGE
* Connected to EXCHANGE (EXCHANGE) port 443 (#0)
* Server auth using NTLM with user '[USER]'
> GET /EWS/services.wsdl HTTP/1.1

> Authorization: NTLM [BASE64]

> User-Agent: curl/7.19.5 (i486-pc-linux-gnu) libcurl/7.19.5 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15

> Host: EXCHANGE

> Accept: */*

> 

< HTTP/1.1 200 OK

< Content-Type: text/xml

< Last-Modified: Wed, 31 Oct 2007 01:42:13 GMT

< Accept-Ranges: bytes

< ETag: "606c93425f1bc81:0"

< Server: Microsoft-IIS/7.0

< X-Powered-By: ASP.NET

< Date: Fri, 09 Jul 2010 08:59:03 GMT

< Content-Length: 53273

< 

{ [data not shown]

curl-7.19.7-12.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Doesn't look like this will work correctly. Using Samba's /usr/bin/ntlm_auth helper, firefox should authenticate automatically without demanding that I re-enter my password (which Samba has cached). It looks like cURL won't manage this.

Falling *back* to its own reimplementation of the NTLM challenge/response stuff would be OK, to avoid a dependency on Samba -- but just completely ignoring the Samba tool isn't good.

As I understand this isn't fixed yet and NTLM support for curl with NSS is still broken, reopening.

Just to be clear: it _does_ work if you provide a password, but the whole point of NTLM is that the user shouldn't _need_ to provide a password every time; the system should cache it.

Thanks for the clarification David, so it is fixed only partially.

(In reply to comment #35)
> Just to be clear: it _does_ work if you provide a password, but the whole point
> of NTLM is that the user shouldn't _need_ to provide a password every time; the
> system should cache it.    

Let me be clear (as upstream primary author of libcurl and the primary author of the NTLM code in libcurl):

NTLM does _not_ in any deal with passwords automatically. For NTLM to work, it needs a name and password (and a little more) and libcurl thus needs to get the name and password passed to it. As a matter of fact, NTLM does not differ from any other HTTP authentication scheme in that aspect.

Sure, "the system" may cache passwords or whatever and pass it on that's entirely possibly but that isn't something libcurl can do or can offer.

So in what way was this partially fixed again?

(In reply to comment #37)
> So in what way was this partially fixed again?    

When I have logged into my system using Windows credentials, an application can authenticate using NTLM *without* having to know my password, by invoking the ntlm_auth helper which handles the entire challenge-response process for it.

I can even do NTLM authentication for IMAP by connecting manually, issuing the 'xx AUTHENTICATE NTLM' command and then cutting and pasting from ntlm_auth...

[dwoodhou@i7 ~]$ ntlm_auth --username dwoodhou --helper-protocol ntlmssp-client-1 --use-cached-creds 
YR
YR TlRMTVNTUAABAAAABYIIYAMAAwAgAAAADgAOACMAAABHRVJEV09PREhPVS1NT0JMMg==

...etc.

Firefox uses this, and NTLM authentication should work seamlessly when using Firefox, without me ever having to provide my password again.

This *doesn't* work when using cURL, because cURL tries to do all the NTLM stuff for itself.

(Thank $DEITY that cURL doesn't take the same approach to Kerberos -- refusing to use GSSAPI and refusing to use the existing system-wide TGT in /tmp/krb5cc_500, and demanding that it obtain its *own* special copy of the credentials, obtained separately just for cURL so it can use its own reimplementation of all the Kerberos protocol code...)

Well, this doesn't address the RFE in this case. This bug is about reaching parity with other crypto providers, not rewriting major functions of curl. This sounds like an RFE should be raised in the curl upstream to address this. 

Based on comment #35 it sounds like an NSS-based libcurl is at least on-par with OpenSSL-based libcurl, correct?

David,

Please take a look at what NTLM actually is and consider that libcurl is a transfer library with no knowledge of any "system passwords" or whatever and further it also supports any local user to use N different users and passwords when doing HTTP+NTLM requests. libcurl will happily do NTLM for you for whatever user and password you give it.

I'll repeat: NTLM (the HTTP authentication mechanism) has _nothing_ to do with re-using or figuring out user names or passwords. It is just very often used like that and Windows and others may provide mechanisms that makes it work for their system libraries.

If you need curl or libcurl to somehow get a cached user name and password from somewhere, then you need to teach them how to get them. That is not a part of NTLM.

Rob, I quite agree that this recent adjustment made the support for NTLM in libcurl with NSS on par with how it works when built with OpenSSL or gcrypt (GnuTLS).

Daniel, all you say is true.

It's also true for Kerberos. And yet libcurl *does* thankfully manage to use the Kerberos credentials that were automatically obtained for me when I logged in, and doesn't insist on being given my password so that it can obtain its *own* TGT with its *own* implementation of the Kerberos protocol.

You're right that it's not a regression and not something that is worse when we're using NSS than when we're using OpenSSL or GnuTLS. It could be considered a separate RFE, so I'll come back when I have a patch.

Right,

But AFAIK (and I'm certainly not an expert on this area), GSS and kerberos have some sort of (de facto?) procedure to do this and the gss/krb-libraries support this feature.

I'm not aware of any such concepts for NTLM now, and I wasn't when I wrote the initial NTLM code for curl back in 2003. And there were no NTLM libraries nor existing NTLM implementations around that we could re-use.

But I'm all for improving curl and libcurl, so I'll certainly be interested in receiving patches that do that!

Samba does precisely this -- since 2002 it's had a helper tool called ntlm_auth which talks to the winbind back end.

[dwoodhou@i7 ~]$ ntlm_auth --username dwoodhou --helper-protocol ntlmssp-client-1 --use-cached-creds 
YR
YR TlRMTVNTUAABAAAABYIIYAMAAwAgAAAADgAOACMAAABHRVJEV09PREhPVS1NT0JMMg==

... etc.

We're talking about getting the GNOME keyring to offer the same functionality, and we'd do that with an ntlm_auth helper which behaves *exactly* the same as the Samba one, so it 'just works' with Firefox etc.

In both cases, they *won't* give the password; they'll just handle the challenge-response for you. For obvious reasons.

Of course, you'd want to keep your own NTLM auth code just in case the helper isn't available.

The ntlm_auth helper will ask you for a password if it needs it (i.e. if it doesn't already have it cached for you). The application needs to be able to respond to that request when it happens (so can't know in advance whether it needs the password or not). But cURL can handle that, right?

Well, you're the first person in 7 years to point this out... ;-)

And yeah, I would certainly think that curl should be able to use something like that. It in fact already supports SSPI just fine when built/run on Windows...

David, did you test the functionality with a real NTLM server?

Are you able to repeat the failure from comment #31?

If the negotiation works, we should probably close the bug as fixed.

Using the ntlm_auth helper for obtaining the password is of course another story.  You're welcome to open a separate bug for it.  But it will take you to write the patch as I am not going to work on that myself.  Nobody has noticed the missing NTLM support for three years, so that I am not convinced that Fedora users will really appreciate such an improvement.

(In reply to comment #45)
> David, did you test the functionality with a real NTLM server?
> 
> Are you able to repeat the failure from comment #31?

With curl-7.20.1-3.fc13 it works fine:

[dwmw2@i7 ews-sync]$ curl -k -L -v --ntlm  https://irsmsx501.ger.corp.intel.com/EWS/Exchange.asmx  -H 'Content-Type: text/xml' -u dwoodhou:$PASS -d @getcalitem.xml | xmlformat.pl 
* About to connect() to irsmsx501.ger.corp.intel.com port 443 (#0)
*   Trying 163.33.7.70...   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0connected
* Connected to irsmsx501.ger.corp.intel.com (163.33.7.70) port 443 (#0)
* Initializing NSS with certpath: /etc/pki/nssdb
* warning: ignoring unsupported value (1) of ssl.verifyhost
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using SSL_RSA_WITH_RC4_128_MD5
* Server certificate:
* 	subject: CN=irsmsx501.ger.corp.intel.com
* 	start date: Nov 04 23:11:31 2008 GMT
* 	expire date: Nov 04 23:11:31 2011 GMT
* 	common name: irsmsx501.ger.corp.intel.com
* 	issuer: CN=Intel Intranet Basic Issuing CA 2A,O=Intel Corporation,C=US
* Server auth using NTLM with user 'dwoodhou'
> POST /EWS/Exchange.asmx HTTP/1.1
> Authorization: NTLM TlRMTVNTUAABAAAABoIIAAAAAAAAAAAAAAAAAAAAAAA=
> User-Agent: curl/7.20.1 (x86_64-redhat-linux-gnu) libcurl/7.20.1 NSS/3.12.6.2 zlib/1.2.3 libidn/1.16 libssh2/1.2.4
> Host: irsmsx501.ger.corp.intel.com
> Accept: */*
> Content-Type: text/xml
> Content-Length: 0
> 
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0< HTTP/1.1 401 Unauthorized
< Content-Length: 1539
< Content-Type: text/html
< Server: Microsoft-IIS/6.0
< WWW-Authenticate: NTLM TlRMTVNTUAACAAAAAwADADgAAAAGgokCPR8CVpgKnVAAAAAAAAAAAKgAqAA7AAAABQLODgAAAA9HRVICAAYARwBFAFIAAQASAEkAUgBTAE0AUwBYADUAMAAxAAQAJABnAGUAcgAuAGMAbwByAHAALgBpAG4AdABlAGwALgBjAG8AbQADADgAaQByAHMAbQBzAHgANQAwADEALgBnAGUAcgAuAGMAbwByAHAALgBpAG4AdABlAGwALgBjAG8AbQAFABwAYwBvAHIAcAAuAGkAbgB0AGUAbAAuAGMAbwBtAAAAAAA=
< X-Powered-By: ASP.NET
< Date: Tue, 03 Aug 2010 12:18:25 GMT
< 
* Ignoring the response-body
{ [data not shown]
100  1539  100  1539    0     0   1345      0  0:00:01  0:00:01 --:--:--  1698* Connection #0 to host irsmsx501.ger.corp.intel.com left intact
* Issue another request to this URL: 'https://irsmsx501.ger.corp.intel.com/EWS/Exchange.asmx'
* Re-using existing connection! (#0) with host irsmsx501.ger.corp.intel.com
* Connected to irsmsx501.ger.corp.intel.com (163.33.7.70) port 443 (#0)
* Server auth using NTLM with user 'dwoodhou'
> POST /EWS/Exchange.asmx HTTP/1.1
> Authorization: NTLM TlRMTVNTUAADAAAAGAAYAEAAAAAYABgAWAAAAAAAAABwAAAACAAIAHAAAAACAAIAeAAAAAAAAAAAAAAABoKJAvSaT1bWiG8iAAAAAAAAAAAAAAAAAAAAAJU6RUqYaJmjXDduoSp8hwOotmuirUzlaWR3b29kaG91aTc=
> User-Agent: curl/7.20.1 (x86_64-redhat-linux-gnu) libcurl/7.20.1 NSS/3.12.6.2 zlib/1.2.3 libidn/1.16 libssh2/1.2.4
> Host: irsmsx501.ger.corp.intel.com
> Accept: */*
> Content-Type: text/xml
> Content-Length: 2406
> Expect: 100-continue
> 
< HTTP/1.1 100 Continue
} [data not shown]
< HTTP/1.1 200 OK
< Date: Tue, 03 Aug 2010 12:18:25 GMT
< Server: Microsoft-IIS/6.0
< X-Powered-By: ASP.NET
< X-AspNet-Version: 2.0.50727
< Cache-Control: private, max-age=0
< Content-Type: text/xml; charset=utf-8
< Content-Length: 1348
< 
{ [data not shown]
100  3754  100  1348  100  2406    797   1423  0:00:01  0:00:01 --:--:--  1423* Connection #0 to host irsmsx501.ger.corp.intel.com left intact

* Closing connection #0
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <soap:Header>
  <t:ServerVersionInfo MajorVersion="8" MinorVersion="2" MajorBuildNumber="254" MinorBuildNumber="0" xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types" />
 </soap:Header>
 <soap:Body>
  <m:GetItemResponse xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages">
   <m:ResponseMessages>
    <m:GetItemResponseMessage ResponseClass="Success">
     <m:ResponseCode>NoError</m:ResponseCode>
     <m:Items>
      <t:CalendarItem>
       <t:ItemId Id="AAAZAGRhdmlkLndvb2Rob3VzZUBpbnRlbC5jb20ARgAAAAAAC1lfIzWaQkSVrsfRo+opswcAMVKzN7WM30+n53HCmWrAXwAAACzU3AAAVRERcKZXcU2YafqGqv0dNQAABqEELQAA" ChangeKey="DwAAABQAAACDXSq+OFsATpKvyERyTXWCAACsFA==" />
       <t:Subject>sunscreen</t:Subject>
       <t:Body BodyType="Text">
-- 
dwmw2
</t:Body>
       <t:ResponseObjects>
        <t:AcceptItem />
        <t:TentativelyAcceptItem />
        <t:DeclineItem />
        <t:ReplyToItem />
        <t:ReplyAllToItem />
        <t:ForwardItem />
       </t:ResponseObjects>
       <t:Start>2010-07-20T11:00:00Z</t:Start>
       <t:IsAllDayEvent>false</t:IsAllDayEvent>
      </t:CalendarItem>
     </m:Items>
    </m:GetItemResponseMessage>
   </m:ResponseMessages>
  </m:GetItemResponse>
 </soap:Body>
</soap:Envelope>


> If the negotiation works, we should probably close the bug as fixed.
> 
> Using the ntlm_auth helper for obtaining the password is of course another
> story.  You're welcome to open a separate bug for it.  But it will take you to
> write the patch as I am not going to work on that myself.  Nobody has noticed
> the missing NTLM support for three years, so that I am not convinced that
> Fedora users will really appreciate such an improvement.    

Winbind is broken in Fedora anyway (bug 618201) so it does look like not a lot of people are using it. Having fixed winbind, I'll shortly be going on a crusade fixing libsoup/libcurl/e-d-s/chrome/etc. to delegate to Samba just like firefox does. Watch this space... :)

Thanks for the testing.  It looks like you have a lot of work to do ;-)  Wishing good luck!