Repository navigation
Enterprise authentication tests are failing with PlatformNotSupportedException #68366
Description
Activity
I will have a look, probably on Monday. The weird thing is that the PR should not change anything at all for Linux builds.
Ah, actually there's the change to verify the last token after successful authentication (in AuthenticationHelper.NtAuth.cs). That could be related.
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.)
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:
incomingBlob: A1143012A0030A0100A10B06092A864886F712010202 outgoingBlob: requestedContextFlags: Connection, AcceptStream contextFlags: Confidentiality, AcceptStreamThis 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.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).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.I think it would be OK to have confidentiality on if we have reasonable confidence this is caused by the MIC calculation.
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.And we will have to anyway since the support is only in 1.14 and above.
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.
I think we build on Centos7 but I'm not sure how this would work on RHEL7 since we use same binaries.
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.- ghost locked as resolved and limited conversation to collaborators
on Jul 16, 2022
https://dnceng.visualstudio.com/public/_build/results?buildId=1730894&view=logs&j=47c231e8-52e2-5eb6-8574-66afcfcee82a&t=df5b78b1-c065-5bb1-4636-fc7a07ab8e6a
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