Skip to content
This repository has been archived by the owner on Jan 23, 2023. It is now read-only.
/ corefx Public archive

Use HTTP Host header for Kerberos auth SPN calculation #38465

Merged
merged 1 commit into from
Jun 12, 2019
Merged

Use HTTP Host header for Kerberos auth SPN calculation #38465

merged 1 commit into from
Jun 12, 2019

Conversation

davidsh
Copy link
Contributor

@davidsh davidsh commented Jun 11, 2019

Fixed SocketsHttpHandler so that it will use the request's Host header,
if present, as part of building the Service Principal Name (SPN) when
doing Kerberos authentication. This now matches .NET Framework behavior.

Contributes to #34697 and #27745

Use HTTP Host header for Kerberos auth SPN calculation
0acbd3f 
Fixed SocketsHttpHandler so that it will use the request's Host header,
if present, as part of building the Service Principal Name (SPN) when
doing Kerberos authentication. This now matches .NET Framework behavior.

Contributes to #34697 and #27745
@davidsh davidsh added tenet-compatibility Incompatibility with previous versions or .NET Framework area-System.Net.Http.SocketsHttpHandler labels Jun 11, 2019
@davidsh davidsh added this to the 3.0 milestone Jun 11, 2019
@davidsh davidsh self-assigned this Jun 11, 2019
@davidsh
Copy link
Contributor Author

davidsh commented Jun 11, 2019

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 4 pipeline(s).

@davidsh davidsh requested review from wfurt, stephentoub and a team June 11, 2019 20:15
wfurt
wfurt reviewed Jun 11, 2019
View reviewed changes
src/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/AuthenticationHelper.NtAuth.cs
{
spn = authUri.IdnHost;
// Use the host name without any normalization.
Copy link
Member

Choose a reason for hiding this comment

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

if not FQDN, Kerberos libraries would fall back to default domain? (or fail)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not necessarily. In general a short name could be part of an SPN definition. On Windows we frequently see multiple SPNs registered such as "HTTP/myhost" and "HTTP/myhost.contoso.com".

Linux Kerberos is more complicated because it uses the KRB5.CONF file. And at the OS Linux layer there is additional transformation including another FQDN (and possible reverse IP) pass.

Right now, this PR is trying to get us closer to .NET Framework behavior at least on the managed layer. The additional issues I referenced above are about making this even better with more granular control down through the OS layer. That is future work.

Copy link
Member

Choose a reason for hiding this comment

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

thanks for explanation.

wfurt
wfurt approved these changes Jun 11, 2019
View reviewed changes
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.

@davidsh davidsh merged commit 6cb8546 into dotnet:master Jun 12, 2019
@davidsh davidsh deleted the spn_hostheader branch June 12, 2019 02:54
stephentoub
stephentoub reviewed Jun 12, 2019
View reviewed changes
src/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/AuthenticationHelper.NtAuth.cs
if (NetEventSource.IsEnabled)
{
NetEventSource.Info(connection, $"Authentication: {challenge.AuthenticationType}, Host: {authUri.IdnHost}, SPN: {spn}");
NetEventSource.Info(connection, $"Authentication: {challenge.AuthenticationType}, SPN: {spn}");
Copy link
Member

Choose a reason for hiding this comment

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

Could we just have one NetEventSource.Info call that logs uri, hostname, and spn, rather than three separate ones?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I had separate calls because I was trying to capture the logic of how the SPN was assembled (i.e. host header present or not, DNS resolution, etc.). But you raise a good point that we now have too many separate log entries for this.

I'll submit a follow-up PR to try to address this.

@wpbrown
Copy link

wpbrown commented Jul 10, 2019

I guess the "v3.0.0-preview6" tag is bogus, because this change is not in the official preview 6 builds 😢

@davidsh
Copy link
Contributor Author

davidsh commented Jul 10, 2019

I guess the "v3.0.0-preview6" tag is bogus, because this change is not in the official preview 6 builds

I'm not sure what tag you are referring to. I don't see that tag on this issue.

This fix should be in the Preview 7 which should be released this month.

@wpbrown
Copy link

wpbrown commented Jul 10, 2019

I was referring to the git repo tag. That git repo tag is not in sync with the actual build. Probably "v3.0.0-preview6.19303.8" is the real one. Anyway, I downloaded the latest daily SDK build and tested. This change works as advertised. Thanks david.

davidsh added a commit to davidsh/corefx that referenced this pull request Jul 31, 2019
@davidsh
Fix SocketsHttpHandler proxy auth for 'Negotiate' scheme
77cf888 
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 mentioned this pull request Jul 31, 2019
Merged
davidsh added a commit that referenced this pull request Aug 1, 2019
@davidsh
Fix SocketsHttpHandler proxy auth for 'Negotiate' scheme (#39933)
85f30cc 
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
davidsh added a commit to davidsh/corefx that referenced this pull request Aug 2, 2019
@davidsh
Fix SocketsHttpHandler proxy auth for 'Negotiate' scheme (dotnet#39933)
f678c68 
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 mentioned this pull request Aug 2, 2019
Merged
wtgodbe pushed a commit that referenced this pull request Aug 5, 2019
@davidsh @wtgodbe
Fix SocketsHttpHandler proxy auth for 'Negotiate' scheme (#39933) (#3…
1bb52e6 
…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
davidsh pushed a commit to davidsh/corefx that referenced this pull request Aug 7, 2019
Port Kerberos auth fixes to 2.1 branch
ba1d89d 
This PR ports some important Kerberos auth fixes from the 3.0 to 2.1 LTS
branch. These fixes help enterprise customers that have complex Kerberos
authentication scenarios that involve cross Windows (Active Directory)
and Linux (Kerberos) domains/realms.

These fixes are from PRs:

* dotnet#38465 - Use 'Host' header when calculating SPN for Kerberos auth
* dotnet#38377 - Use GSS_C_NT_HOSTBASED_SERVICE format for Linux Kerberos SPN

and are related to issue dotnet#36329.
@davidsh davidsh mentioned this pull request Aug 7, 2019
Merged
danmoseley pushed a commit that referenced this pull request Aug 8, 2019
@davidsh @danmoseley
Port Kerberos auth fixes to 2.1 branch (#40109)
7bb81c6 
This PR ports some important Kerberos auth fixes from the 3.0 to 2.1 LTS
branch. These fixes help enterprise customers that have complex Kerberos
authentication scenarios that involve cross Windows (Active Directory)
and Linux (Kerberos) domains/realms.

These fixes are from PRs:

* #38465 - Use 'Host' header when calculating SPN for Kerberos auth
* #38377 - Use GSS_C_NT_HOSTBASED_SERVICE format for Linux Kerberos SPN

and are related to issue #36329.
wtgodbe pushed a commit that referenced this pull request Aug 8, 2019
@dotnet-maestro-bot @wtgodbe
[automated] Merge branch 'release/2.1' => 'release/2.2' (#40148)
825477c 
* Update BuildTools to rc1-04230-01

* Port Kerberos auth fixes to 2.1 branch (#40109)

This PR ports some important Kerberos auth fixes from the 3.0 to 2.1 LTS
branch. These fixes help enterprise customers that have complex Kerberos
authentication scenarios that involve cross Windows (Active Directory)
and Linux (Kerberos) domains/realms.

These fixes are from PRs:

* #38465 - Use 'Host' header when calculating SPN for Kerberos auth
* #38377 - Use GSS_C_NT_HOSTBASED_SERVICE format for Linux Kerberos SPN

and are related to issue #36329.
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
@davidsh
Use HTTP Host header for Kerberos auth SPN calculation (dotnet/corefx…
78c1298 
…#38465)

Fixed SocketsHttpHandler so that it will use the request's Host header,
if present, as part of building the Service Principal Name (SPN) when
doing Kerberos authentication. This now matches .NET Framework behavior.

Contributes to dotnet/corefx#34697 and dotnet/corefx#27745

Commit migrated from dotnet/corefx@6cb8546
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
@davidsh
Fix SocketsHttpHandler proxy auth for 'Negotiate' scheme (dotnet/core…
fd89065 
…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.
Reviewers

@stephentoub stephentoub stephentoub left review comments

@wfurt wfurt wfurt approved these changes

Assignees

@davidsh davidsh

Labels
tenet-compatibility Incompatibility with previous versions or .NET Framework
Projects
None yet
Milestone
3.0
Development

Successfully merging this pull request may close these issues.
4 participants
@davidsh @wpbrown @stephentoub @wfurt