-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NTLM authentication fails when Extended Protection is enabled server-side #352
Comments
Are you sure there is no difference in NTLM headers between DavMail and Chrome ? Your problem looks similar to mine but in my case there were differences in the NTLM exchange (payload was shorter than with Firefox), but they may have been a red herring. |
The domain and workstations were the same for DavMail and Chrome (empty and the local hostname, respectively). There were a couple of flags set differently, but enabling / disabling those so they matched between DavMail and Chrome didn't help unfortunately. |
I think you nailed it, managed to reproduce the 401 error by enabling extended protection on IIS. Also found Microsoft implementation of channel binding with NTLM in JDBC driver branch: Seems tricky to implement: reflection to get information from TLS layer, and additional fields in NTLM message |
Update: I discovered that HTTPClient 4 now includes an NTLM implementation with some channel binding code, however it's not active by default => will try to remove JCIFS and switch to this. |
#352 git-svn-id: https://svn.code.sf.net/p/davmail/code/trunk@3567 3d1905a2-6b24-0410-a738-b14d5a86fcbd
The latest revision (8e76f6e) works for me. Thanks! |
Awesome, thanks for your quick feedback. Will now be able to completely drop JCIFS as we rely on HttpClient implementation of NTLM |
When Extended Protection is enabled on IIS, DavMail cannot successfully complete an NTLM handshake. After the last negotiate message the server sends back a 401 response. See also the attached logs [1]. I've compared the decoded NTLM headers sent by DavMail to those sent by Chrome (which does authenticate successfully), and there is no structural difference. Swapping out the custom JCIFS NTLM implementation with the one with provided natively by HttpClient doesn't help.
This problem is similar to curl/curl#12511, so I'm guessing the HTTP client doesn't set up GSSAPI channel binding properly.
[1] davmail.log
The text was updated successfully, but these errors were encountered: