Possible bug in AuthenticationHelper

[ymassad]

I think that there might be a bug in the following file:

https://github.com/dotnet/runtime/blob/master/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/AuthenticationHelper.NtAuth.cs

Lines 100-118 is where the Spn is being calculated.

It seems that the port is not taken into account when calculating the spn.

That is, you get something like HTTP/machine.domain.lab instead of HTTP/machine.domain.lab:5000

The reason I am posting this is that I am troubleshooting a WCF client problem that happens in .NET Core but not in .NET framework.

The Spn I am passing to System.ServiceModel.ClientBase is being ignored. I am passing HTTP/machine.domain.lab:5000, but it seems that the code in AuthenticationHelper.NtAuth recalculates the SPN and does not use the port. This causes an exception to be thrown. The exception message is "The target principal name is incorrect". I am assuming that the SPN is the issue.

I think that another issue is the fact that the Spn I am passing from WCF is being ignored.

I am using .NET Core 3.1 and System.ServiceModel.Http 4.7.

Tagging subscribers to this area: @dotnet/ncl
Notify danmosemsft if you want to be subscribed.

Tagging subscribers to this area: @dotnet/ncl
Notify danmosemsft if you want to be subscribed.

[davidsh]

Thank you for the bug report. This is likely a bug in .NET Core. In .NET Framework, we do add the port number to the SPN calculation if the port is non-standard (i.e. not '80' nor '443').

[ymassad]

Thanks. Is there a work around?

[davidsh]

Thanks. Is there a work around?

You might try explicitly adding a 'Host' header to the HTTP request. Doing so will result in using that header value exactly for the 'hostname' of the SPN.

See:

runtime/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/AuthenticationHelper.NtAuth.cs

Lines 86 to 99 in d9b006b

	// Calculate SPN (Service Principal Name) using the host name of the request.
	// Use the request's 'Host' header if available. Otherwise, use the request uri.
	// Ignore the 'Host' header if this is proxy authentication since we need to use
	// the host name of the proxy itself for SPN calculation.
	string hostName;
	if (!isProxyAuth && request.HasHeaders && request.Headers.Host != null)
	{
	// Use the host name without any normalization.
	hostName = request.Headers.Host;
	if (NetEventSource.IsEnabled)
	{
	NetEventSource.Info(connection, $"Authentication: {challenge.AuthenticationType}, Host: {hostName}");
	}
	}

However, since you are using WCF you might not have direct control over adding that 'Host' request header since WCF is calling HttpClient itself.

[ymassad]

Thanks. In code you showed, can request.Headers.Host contain the port? Or just the host name?

[davidsh]

Thanks. In code you showed, can request.Headers.Host contain the port? Or just the host name?

It should contain hostname and port.

[ymassad]

I have tried to add a Host header via a custom implementation of IClientMessageInspector in Wcf.

It doesn't work because HttpChannelFactory explicitly doesn't take the Host header from the Message:

https://github.com/dotnet/wcf/blob/42b5572be18cb6d0d60718f24143a541b5dea755/src/dotnet-svcutil/lib/src/FrameworkFork/System.ServiceModel/System/ServiceModel/Channels/HttpChannelFactory.cs#L1109

I was able to add custom headers (just for testing), and they show up all the way down the call stack, but the Host header gets ignored explicitly by HttpChannelFactory.

We have migrated one product from .NET Framework to .NET Core, and this issue might force us to go back to .NET Framework until a fix is released.