-
Bug
-
Resolution: Unresolved
-
P4
-
None
-
8u172
I apologize in advance as this issue is rather technical and difficult to reproduce.
We have an ADFS server running on which we try to log on from clients. We are querying ADFS through the JavaFX WebView and we try to negotiate using NTLM.
We are using the right credentials when asked in our BasicAuthenticator but the authentication is failing.
We dig into the issue and we saw in ADFS logs that we had this similar log : https://social.msdn.microsoft.com/Forums/vstudio/en-US/40f56d75-58b2-48d2-ab7d-473915ac8de7/0xc000035b-error-during-windows-integrated-login?forum=Geneva
If you google that specific error : 0xC000035B , you can find this https://support.microsoft.com/fr-fr/help/2903333/terminal-services-client-connection-error-0xc000035b-when-you-use-lmco
It says : "the authentication fails and generates the 0xC000035B "Client's supplied SSPI channel bindings were incorrect" error message. This indicates that the channel bindings are not valid. "
On our ADFS server, we have indeed our ExtendedProtectionToken set to "require" :
PS C:\Windows\system32> Get-ADFSProperties | Select -ExpandProperty ExtendedProtectionTokenCheck
Require
If we change it to the value "Allow", then the authentication is working.
So my guess is that something around the Channel Binding is not done correctly. I know that if I use Fiddler as a proxy using that (https://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/AuthenticateWithCBT), the authentication is working. So Fiddler is capable of doing with the ChannelBinding that we can't.
I don't know if this issue is related to the JavaFX WebView or on the core java layers.
I don't know if you have internal way of reproducing the configuration for this issue. We have ADFS configured on our side, if you have a ServiceProvider, we are willing to declare it on our ADFS server if that could ease your tests.
We have an ADFS server running on which we try to log on from clients. We are querying ADFS through the JavaFX WebView and we try to negotiate using NTLM.
We are using the right credentials when asked in our BasicAuthenticator but the authentication is failing.
We dig into the issue and we saw in ADFS logs that we had this similar log : https://social.msdn.microsoft.com/Forums/vstudio/en-US/40f56d75-58b2-48d2-ab7d-473915ac8de7/0xc000035b-error-during-windows-integrated-login?forum=Geneva
If you google that specific error : 0xC000035B , you can find this https://support.microsoft.com/fr-fr/help/2903333/terminal-services-client-connection-error-0xc000035b-when-you-use-lmco
It says : "the authentication fails and generates the 0xC000035B "Client's supplied SSPI channel bindings were incorrect" error message. This indicates that the channel bindings are not valid. "
On our ADFS server, we have indeed our ExtendedProtectionToken set to "require" :
PS C:\Windows\system32> Get-ADFSProperties | Select -ExpandProperty ExtendedProtectionTokenCheck
Require
If we change it to the value "Allow", then the authentication is working.
So my guess is that something around the Channel Binding is not done correctly. I know that if I use Fiddler as a proxy using that (https://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/AuthenticateWithCBT), the authentication is working. So Fiddler is capable of doing with the ChannelBinding that we can't.
I don't know if this issue is related to the JavaFX WebView or on the core java layers.
I don't know if you have internal way of reproducing the configuration for this issue. We have ADFS configured on our side, if you have a ServiceProvider, we are willing to declare it on our ADFS server if that could ease your tests.