Skip to content
This repository was archived by the owner on Jan 23, 2023. It is now read-only.

Fix SocketsHttpHandler proxy auth for 'Negotiate' scheme#39933

Merged
davidsh merged 2 commits intodotnet:masterfrom
davidsh:proxyauth_kerberos
Aug 1, 2019
Merged

Fix SocketsHttpHandler proxy auth for 'Negotiate' scheme#39933
davidsh merged 2 commits intodotnet:masterfrom
davidsh:proxyauth_kerberos

Conversation

@davidsh
Copy link
Contributor

@davidsh davidsh commented Jul 31, 2019

Issue #39887 reported that proxy authentication with 'Negotiate' scheme broke between
.NET Core 3.0 Preview 6 and Preview 7. The base64 blob was no longer using SPNEGO protocol
but instead was always using NTLM. While 'Negotiate' scheme can use either SPNEGO or NTLM,
it should always use SPNEGO if possible. And many enterprises have a setting which requires
it and rejects NTLM protocol.

This issue was caused by PR #38465 which fixed some other SPN issues with Kerberos
authentication. That PR regressed the SPN calculation for the proxy authentication by
using the wrong host name in the SPN. A mismatch of the SPN will cause NTLM to be used
instead of SPNEGO.

The fix is to check if proxy authentication is being used instead of server authentication.
If so, it ignores any 'Host' header and always will use the uri, which in this case is the
uri of the proxy server.

This was tested manually. It is impossible right now to test Kerberos and proxy scenarios in
CI because they require machine configuration to register SPNs in a Windows Active Directory
environment.

This PR will be ported for release/3.0 for ASK mode consideration since it affects a mainline
enterprise scenario.

Fixes #39887

Issue #39887 reported that proxy authentication with 'Negotiate' scheme broke between
.NET Core 3.0 Preview 6 and Preview 7. The base64 blob was no longer using SPNEGO protocol
but instead was always using NTLM. While 'Negotiate' scheme can use either SPNEGO or NTLM,
it should always use SPNEGO if possible. And many enterprises have a setting which requires
it and rejects NTLM protocol.

This issue was caused by PR dotnet#38465 which fixed some other SPN issues with Kerberos
authentication. That PR regressed the SPN calculation for the proxy authentication by
using the wrong host name in the SPN. A mismatch of the SPN will cause NTLM to be used
instead of SPNEGO.

The fix is to check if proxy authentication is being used instead of server authentication.
If so, it ignores any 'Host' header and always will use the uri, which in this case is the
uri of the proxy server.

This was tested manually. It is impossible right now to test Kerberos and proxy scenarios in
CI because they require machine configuration to register SPNs in a Windows Active Directory
environment.

This PR will be ported for release/3.0 for ASK mode consideration since it affects a mainline
enterprise scenario.

Fixes #39887
@davidsh davidsh added this to the 5.0 milestone Jul 31, 2019
@davidsh davidsh self-assigned this Jul 31, 2019
@davidsh
Copy link
Contributor Author

davidsh commented Jul 31, 2019

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 4 pipeline(s).

@davidsh davidsh requested review from a team and stephentoub July 31, 2019 22:27
@davidsh davidsh added the tenet-compatibility Incompatibility with previous versions or .NET Framework label Jul 31, 2019
Copy link
Member

@wfurt wfurt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.
Could we add test? (can be done post 3.0)

@davidsh
Copy link
Contributor Author

davidsh commented Jul 31, 2019

Could we add test? (can be done post 3.0)

I am thinking about how to write a test for this. It would build on the work done in these tests

private static bool IsNtlmInstalled => Capability.IsNtlmInstalled();
private static bool IsWindowsServerAvailable => !string.IsNullOrEmpty(Configuration.Http.WindowsServerHttpHost);
private static bool IsDomainJoinedServerAvailable => !string.IsNullOrEmpty(Configuration.Http.DomainJoinedHttpHost);
private static NetworkCredential DomainCredential = new NetworkCredential(
Configuration.Security.ActiveDirectoryUserName,
Configuration.Security.ActiveDirectoryUserPassword,
Configuration.Security.ActiveDirectoryName);
[ConditionalFact(nameof(IsDomainJoinedServerAvailable))]
public async Task Credentials_DomainJoinedServerUsesKerberos_Success()

where they run only if running in a domain joined Windows ActiveDirectory environment. The trick is to have a proxy server that can report whether SPNEGO or NTLM tokens were used for authentication and then we can test against that. I have a proxy server I wrote that I'm working on to support that.

@wfurt
Copy link
Member

wfurt commented Jul 31, 2019

I know this is tricky. But in this case all we need to do is to verify that correct mechanism was selected, right?

@davidsh
Copy link
Contributor Author

davidsh commented Aug 1, 2019

I know this is tricky. But in this case all we need to do is to verify that correct mechanism was selected, right?

Thanks for the feedback. I was able to write a new test that builds on the existing set of tests we have that can run in a domain joined environment (when enabled via the required environment variables).

@davidsh
Copy link
Contributor Author

davidsh commented Aug 1, 2019

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 4 pipeline(s).

@davidsh davidsh merged commit 85f30cc into dotnet:master Aug 1, 2019
@davidsh davidsh deleted the proxyauth_kerberos branch August 1, 2019 20:54
davidsh added a commit to davidsh/corefx that referenced this pull request Aug 2, 2019
Issue #39887 reported that proxy authentication with 'Negotiate' scheme broke between
.NET Core 3.0 Preview 6 and Preview 7. The base64 blob was no longer using SPNEGO protocol
but instead was always using NTLM. While 'Negotiate' scheme can use either SPNEGO or NTLM,
it should always use SPNEGO if possible. And many enterprises have a setting which requires
it and rejects NTLM protocol.

This issue was caused by PR dotnet#38465 which fixed some other SPN issues with Kerberos
authentication. That PR regressed the SPN calculation for the proxy authentication by
using the wrong host name in the SPN. A mismatch of the SPN will cause NTLM to be used
instead of SPNEGO.

The fix is to check if proxy authentication is being used instead of server authentication.
If so, it ignores any 'Host' header and always will use the uri, which in this case is the
uri of the proxy server.

This was tested manually. It is impossible right now to test Kerberos and proxy scenarios in
CI because they require machine configuration to register SPNs in a Windows Active Directory
environment.

This PR will be ported for release/3.0 for ASK mode consideration since it affects a mainline
enterprise scenario.

Fixes #39887
wtgodbe pushed a commit that referenced this pull request Aug 5, 2019
…9981)

Issue #39887 reported that proxy authentication with 'Negotiate' scheme broke between
.NET Core 3.0 Preview 6 and Preview 7. The base64 blob was no longer using SPNEGO protocol
but instead was always using NTLM. While 'Negotiate' scheme can use either SPNEGO or NTLM,
it should always use SPNEGO if possible. And many enterprises have a setting which requires
it and rejects NTLM protocol.

This issue was caused by PR #38465 which fixed some other SPN issues with Kerberos
authentication. That PR regressed the SPN calculation for the proxy authentication by
using the wrong host name in the SPN. A mismatch of the SPN will cause NTLM to be used
instead of SPNEGO.

The fix is to check if proxy authentication is being used instead of server authentication.
If so, it ignores any 'Host' header and always will use the uri, which in this case is the
uri of the proxy server.

This was tested manually. It is impossible right now to test Kerberos and proxy scenarios in
CI because they require machine configuration to register SPNs in a Windows Active Directory
environment.

This PR will be ported for release/3.0 for ASK mode consideration since it affects a mainline
enterprise scenario.

Fixes #39887
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
…fx#39933)

Issue dotnet/corefx#39887 reported that proxy authentication with 'Negotiate' scheme broke between
.NET Core 3.0 Preview 6 and Preview 7. The base64 blob was no longer using SPNEGO protocol
but instead was always using NTLM. While 'Negotiate' scheme can use either SPNEGO or NTLM,
it should always use SPNEGO if possible. And many enterprises have a setting which requires
it and rejects NTLM protocol.

This issue was caused by PR dotnet/corefx#38465 which fixed some other SPN issues with Kerberos
authentication. That PR regressed the SPN calculation for the proxy authentication by
using the wrong host name in the SPN. A mismatch of the SPN will cause NTLM to be used
instead of SPNEGO.

The fix is to check if proxy authentication is being used instead of server authentication.
If so, it ignores any 'Host' header and always will use the uri, which in this case is the
uri of the proxy server.

This was tested manually. It is impossible right now to test Kerberos and proxy scenarios in
CI because they require machine configuration to register SPNs in a Windows Active Directory
environment.

This PR will be ported for release/3.0 for ASK mode consideration since it affects a mainline
enterprise scenario.

Fixes dotnet/corefx#39887 



Commit migrated from dotnet/corefx@85f30cc
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

tenet-compatibility Incompatibility with previous versions or .NET Framework

Projects

None yet

Development

Successfully merging this pull request may close these issues.

WebClient http proxy broken in .Net Core 3 Preview 7

4 participants