Skip to content
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

Closed
teake opened this issue May 10, 2024 · 6 comments
Closed

Comments

@teake
Copy link

teake commented May 10, 2024

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

@ldoub
Copy link

ldoub commented May 14, 2024

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.
In my case this authentication started to fail after (I suppose) some server side change... "Extended Protection" may well be what was recently enabled !
I'm going to watch your issue in case it ends up solving mine too.

@teake
Copy link
Author

teake commented May 14, 2024

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.

@mguessan
Copy link
Owner

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:
microsoft/mssql-jdbc@71f06b7

Seems tricky to implement: reflection to get information from TLS layer, and additional fields in NTLM message

@mguessan
Copy link
Owner

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.

@teake
Copy link
Author

teake commented May 28, 2024

The latest revision (8e76f6e) works for me. Thanks!

@teake teake closed this as completed May 28, 2024
@mguessan
Copy link
Owner

Awesome, thanks for your quick feedback.

Will now be able to completely drop JCIFS as we rely on HttpClient implementation of NTLM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants