Repository navigation
Enterprise authentication tests are failing with PlatformNotSupportedException #68366
Description
Starting: System.Net.Http.Enterprise.Tests (parallel test collections = on, max threads = 4)
System.Net.Http.Enterprise.Tests.HttpClientAuthenticationTest.HttpClient_ValidAuthentication_Success(url: "http://apacheweb.linux.contoso.com/auth/kerberos/", useDomain: False, useAltPort: False) [STARTING]
Unhandled exception. System.PlatformNotSupportedException: Requested protection level is not supported with the GSSAPI implementation currently installed.
at System.Net.Security.NegotiateStreamPal.InitializeSecurityContext(SafeFreeCredentials& credentialsHandle, SafeDeleteContext& securityContext, String spn, ContextFlagsPal requestedContextFlags, Byte[] incomingBlob, ChannelBinding channelBinding, Byte[]& resultBlob, ContextFlagsPal& contextFlags) in /repo/src/libraries/Common/src/System/Net/Security/NegotiateStreamPal.Unix.cs:line 384
at System.Net.NTAuthentication.GetOutgoingBlob(Byte[] incomingBlob, Boolean throwOnError, SecurityStatusPal& statusCode) in /repo/src/libraries/Common/src/System/Net/NTAuthentication.Common.cs:line 215
at System.Net.NTAuthentication.GetOutgoingBlob(Byte[] incomingBlob, Boolean thrownOnError) in /repo/src/libraries/Common/src/System/Net/NTAuthentication.Common.cs:line 201
at System.Net.NTAuthentication.GetOutgoingBlob(String incomingBlob) in /repo/src/libraries/Common/src/System/Net/NTAuthentication.Common.cs:line 182
at System.Net.Http.AuthenticationHelper.SendWithNtAuthAsync(HttpRequestMessage request, Uri authUri, Boolean async, ICredentials credentials, Boolean isProxyAuth, HttpConnection connection, HttpConnectionPool connectionPool, CancellationToken cancellationToken) in /repo/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/AuthenticationHelper.NtAuth.cs:line 198
at System.Net.Http.HttpConnectionPool.SendWithVersionDetectionAndRetryAsync(HttpRequestMessage request, Boolean async, Boolean doRequestAuth, CancellationToken cancellationToken) in /repo/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/HttpConnectionPool.cs:line 1033
at System.Net.Http.AuthenticationHelper.SendWithAuthAsync(HttpRequestMessage request, Uri authUri, Boolean async, ICredentials credentials, Boolean preAuthenticate, Boolean isProxyAuth, Boolean doRequestAuth, HttpConnectionPool pool, CancellationTo
This seems to be regression from #66879 @filipnavara. I look at the change again and nothing obvious pop up but I sync code just before the change and everything would pass.
It seems to fail on chat that confidentiality is set but was not requested. I don't know why that would matter but I would not expect behavior differences in Kerberos from the managed NTLM.
The test should runable again with #68311
Activity
filipnavara commentedon Apr 22, 2022
I will have a look, probably on Monday. The weird thing is that the PR should not change anything at all for Linux builds.
filipnavara commentedon Apr 22, 2022
Ah, actually there's the change to verify the last token after successful authentication (in AuthenticationHelper.NtAuth.cs). That could be related.
filipnavara commentedon Apr 22, 2022
FWIW here's the commit that added the check. It may have just never been run for the HTTP authentication because of the ignored last negotiation token. (Furthermore, it is totally valid and normal for NTLM to upgrade to confidentiality.)
filipnavara commentedon Jun 8, 2022
I managed to reproduce this locally. Removing the extra check from 7fc2995, as done in #68700, does make the problem go away. I'll do some additional tracing to see what is happening.
The exception was thrown for these inputs:
This is the MIC check added in #66879. The
requestedContextFlags/contextFlagsconsistency check was previously never executed in the Negotiate scenario and most likely the flags never matched in the first place.filipnavara commentedon Jun 8, 2022
Part of the problem is that the CMake check for
GSS_KRB5_CRED_NO_CI_FLAGS_Xdoesn't work. It is never used and the code doesn't even compile. Since the feature doesn't work in the native code it also fails the check in managed code that depends on it.If I hack it to actually send
GSS_KRB5_CRED_NO_CI_FLAGS_Xto native API it does the right thing w.r.t. the context flags. I don't even know how to start fixing it though (CMake check is wrong; code needs to be fixed to be compilable withHAVE_GSS_KRB5_CRED_NO_CI_FLAGS_X;GSS_KRB5_CRED_NO_CI_FLAGS_Xis sent even for NTLM where it always fails).wfurt commentedon Jun 9, 2022
I think it would be OK to have confidentiality on if we have reasonable confidence this is caused by the MIC calculation.
And we will have to anyway since the support is only in 1.14 and above.
filipnavara commentedon Jun 9, 2022
I don't know what was the original intention with the
GSS_KRB5_CRED_NO_CI_FLAGS_Xcommit from 2016 (which never worked as intended). If it was up to me I would remove the check from the managed side. It's trying to outsmart the native libraries for Kerberos but the same case for NTLM is not checked, and NTLM also optionally upgrades integrity/confidentiality.Apparently the only supported platform with KRB5 older than 1.14 is RHEL7, and even there I am not entirely sure what the deal is. CentOS 7 ships 1.15 at least, and I cannot check if it was ever serviced in Red Hat or not.
wfurt commentedon Jun 9, 2022
I think we build on Centos7 but I'm not sure how this would work on RHEL7 since we use same binaries.
cc: @tmds
filipnavara commentedon Jun 9, 2022
That's what I am seeing, actually. The builds use the runtime
dlopen/dlsymshim for all the APIs. The two optional symbols don't exist on RHEL7 which is already tested on the CI. I modified to code in #70447 to support runtime detection of the APIs, as long as the compilation of the GSS shim is done with KRB5>1.14.