Connection when both "Force Enryption" and "Extended Protection" are active

Question

I'm trying to connect to a SQL Server (2012) using Windows Authentication where both Force Enryption is set to true and Extended Protection is set to required.

What I'm getting on the Client side is:

Login failed. The login is from an untrusted domain and cannot
be used with Windows authentication.
ClientConnectionId:<redacted>

Server side:

SSPI handshake failed with error code 0x80090346, state 46 while 
establishing a connection with integrated security; the connection 
has been closed. Reason: The Channel Bindings from this client are
missing or do not match the established Transport Layer Security (TLS) 
Channel. The service might be under attack, or the data provider
or client operating system might need to be upgraded to support
Extended Protection. Closing the connection. Client's supplied SSPI
channel bindings were incorrect
[CLIENT: <redacted>]

I've tried many different configuration options (client side) including:

sslProtocol all options
trustStore alongside trustStorePassword with a self signed cert
trustServerCertificate
serverSpn alongside corresponding server setting
encrypt

All results in the same error combination. OS instances are identical on Windows Sever 2012 R2 latest SP.

Any hints would be highly appreciated.

Thanks
Michael

michaelenglert

Hi michaelenglert

Please confirm if Client (Windows Server 2012 R2 in your case) has enabled Extended Protection support.

This blog will be worth looking into on how to enable it:
https://blogs.technet.microsoft.com/srd/2009/12/08/extended-protection-for-authentication/

More details about Windows Update required for Extended Protection support: https://support.microsoft.com/en-us/help/973917/description-of-the-update-that-implements-extended-protection-for-auth

Cheena Malhotra (@cheenamalhotra)

Hi Cheena Malhotra (@cheenamalhotra),

confirmed as this is enabled by default in Windows Server 2012 R2.

Just to put myself better on this, the error you are receiving "The login is from an untrusted domain and cannot be used with Windows authentication" is coming due to lack of configuration on client side.

From the links above, you may wanna check

if extended protection is enabled by setting the value of the registry key HKLM\System\CurrentControlSet\Control\LSA\SuppressExtendedProtection to 0 on Client OS.
if SPN as provided in serverSPN connection property is registered in <extendedProtection> section of ApplicationHost.config file on server.

Since you are working with Kerberos negotiation, it is expected to be supported by default, further configuration for LmCompatibilityLevel may not be mandatory.

On the contrary, please also confirm:

Connection succeeds on disabling Extended Protection on Server and Kerberos setup is done properly.
What happens if a test application attempts connection from the same OS where SQL Server is present.

Please also provide your connection string with repro code if possible in a standalone Java class.

Cheena Malhotra (@cheenamalhotra)

thanks for helping Cheena Malhotra (@cheenamalhotra)

Using this Connection String jdbc:sqlserver://192.168.56.101:1433;serverSpn=MSSQLSvc/WIN-097Q29SOILR.corp.michi.com:1433;integratedSecurity=true;authenticationScheme=JavaKerberos;trustServerCertificate=true

Force Enryption is set to false --> Successful connection
Force Enryption is set to false --> Errors happen as seen above

I've checked the Kerberos setup using the Kerberos config tool and also registered the registry key HKLM\System\CurrentControlSet\Control\LSA\SuppressExtendedProtection to 0

michaelenglert

Hi michaelenglert

I hope you wanted to mention error occurs if Force Encryption is set to true and are you not passing encrypt=true in connection string?

Cheena Malhotra (@cheenamalhotra)

Hi Cheena Malhotra (@cheenamalhotra)

I'm sorry. I lost track of all the different setups. Same error happens also with encrypt=true in

Cheena Malhotra (@cheenamalhotra)

Hi Cheena Malhotra (@cheenamalhotra) it would be great if you have another hint for me :-)

michaelenglert

Hi michaelenglert

I'll try to reproduce this in my environment, as I'm not entirely sure if this is a configuration problem or something else. Let me know if you have any pointers to problem root cause.

Cheena Malhotra (@cheenamalhotra)

that would be awesome Cheena Malhotra (@cheenamalhotra) there is not much I did on the setup. Here's what I did on the Server side:

Basic Windows Server 2012 R2 Installation
Basic SQL Server 2012 Installation
Installed Active Directory on the same host
Configured Active Directory User to "Trust this User for delegation"
Configured Active Directory Computer to "Trust this computer for delegation"
Set Extended Protection for SQL Server to Required
Set Force Encryption for SQL Server to Yes - if set no No it works
Created a self signed certificate and configured the SQL Server to use it - also tried without it

On the Client Side I tried/used:

serverSpn=serverSpn
integratedSecurity=true
authenticationScheme=JavaKerberos
trustServerCertificate=true
encrypt=true
trustStore=storeName
trustStorePassword=storePassword

michaelenglert

Thanks michaelenglert for the details.

Out of curiosity, have you tried to connect with any of the other SQL Server drivers?

michaelenglert

Hi michaelenglert

I configured Force Protocol Encryption + Extended Protection on SQL Server 2012 and am able to connect using Kerberos.

I could connect with below properties set using SQLServerDataSource.

TrustStore trustStore = new TrustStore();
SQLServerDataSource ds = new SQLServerDataSource();
ds.setServerName("<your server name>");
ds.setTrustStore(trustStore.getFileName());
ds.setTrustStorePassword(TrustStore.TRUST_STORE_PASSWORD);
ds.setIntegratedSecurity(true);
ds.setEncrypt(true);
try (Connection con = ds.getConnection()) {
     System.out.println("Connected");
}

Also, it works without adding ds.setAuthenticationScheme("JavaKerberos"); as default Negotiation is set to Kerberos.

I followed same steps defined in https://blogs.technet.microsoft.com/srd/2009/12/08/extended-protection-for-authentication/ for configuring Client and Server. No extra configurations were needed.

On the contrary, if you face any problems with Certificate validation, you may try to provide "trustServerCertificate=true" in connection and can avoid setting any TrustStore.

Ok, looks like I am able to reproduce the error now, but the issue isn't dependent on Force Encryption Turned On/Off but on Extended Protection when set to "Required" on SQL Server Instance configuration window.

Anyways, I'll investigate more into it and let you know soon!

michaelenglert

Hi michaelenglert

Upon investigations I discovered that in order to work with both Extended Protection and Encryption on Connection, client needs to supply Channel Binding which is accomplished by the client transferring the SPN and the CBT to the server in a tamperproof fashion. In absence of which server will not accept any requests from client. More details can be found here.

As of now, the driver does not implement Channel Binding and thus this combination of Extended Protection + Force Encryption during connection is not supported. Turning one of them OFF will result in a successful connection, as you must have figured out too.

I stumbled across this issue as well. A pity that it is now waiting on external factors.
Please clarify: I have tested with the following configs at the server:

Force Encryption: On; Exteded Protection:Required ---> Error (as detailed above)...was to be expected
Force Encryption: On; Extended Protection: Allowed --> Same error ...why?
Force Encryption: On; Extended Protection: Off --> works without error

Why is Extended Protection: Allowed not possible? AFAIK this is the setting at the server side which does not enforce Extended Protection.

Java is missing public APIs that allow channel binding to be implemented. The POC described above was accomplished via methods that are not suitable to production-level code.

David Engel (@David-Engel)

Hi are there any updates on this issue?
As per the last comment from David Engel (@David-Engel) and Terry Chow (@tkyc), this feature was put on hold.

user1oc

user1oc No new updates. Lack of appropriate public Java APIs is still a blocker for this issue. I don't see that changing any time soon.

BTW it’s also an issue for http and ldap and really needs reconsideration on openjdk level. Maybe escalate it to the Microsoft Java team?

Bernd (@ecki)

Bernd (@ecki) Yeah, we've considered that as an option, but for now even with support from the Microsoft Java team I don't see the openjdk team consenting to the required Java API changes to make this happen as these types of changes were requested in the past.

martin-guth

Force Encryption: On; Extended Protection: Allowed --> Same error ...why?

martin-guth thats indeed problematic, I suspect the SSPI on the client think it can/should negotiate it and then Java does not add the token therefore corrupting the handshake which the server uses to abort. Would maybe a good idea to filter it out in the driver so it does not get negotiated.

I would actually relabel the Issue from 'Enhancement' to 'Security Issue' as we are forced to downgrade the complete Instance, because if just 1 Client still can't use Channel binding nowadays, all other clients have to use the downgraded security as well.

any update on when this will be fixed?

Anat Dror (@ADror-Quest)

hi Anat Dror (@ADror-Quest)

Unfortunately we don't have a timeline to address this as this feature is still currently blocked by a lack of TLS APIs in Java required to implement it.

We did work on this in a feature branch where we worked around this using reflection (channel-bindings) or Bouncy Castle (channel-bindings-bc) . These are not official solutions they will not be merged however you are welcome to take a look and build a version of the driver for your needs but please be aware this is not something that we officially support. Until there is a proper API available in Java this will not be something that will be supported in the driver.

If the driver Not yet accept Channel binding, it should not propose it (i.e. Filter the Bit out in the negotiation message), otherwise the opportunistic („allowed“) setting does not work.

any update on when this will be fixed?

Navigation Menu

Repository navigation

Connection when both "Force Enryption" and "Extended Protection" are active #963

Question

32 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Connection when both "Force Enryption" and "Extended Protection" are active #963

Description

Question

Activity

cheenamalhotra commented on Feb 14, 2019

michaelenglert commented on Feb 14, 2019

cheenamalhotra commented on Feb 14, 2019

michaelenglert commented on Feb 14, 2019

cheenamalhotra commented on Feb 14, 2019

michaelenglert commented on Feb 15, 2019

michaelenglert commented on Feb 20, 2019

cheenamalhotra commented on Feb 20, 2019

michaelenglert commented on Feb 21, 2019

cheenamalhotra commented on Feb 22, 2019

cheenamalhotra commented on Feb 25, 2019

cheenamalhotra commented on Feb 25, 2019

cheenamalhotra commented on Feb 26, 2019

cheenamalhotra commented on Feb 27, 2019

32 remaining items

martin-guth commented on Aug 24, 2023

David-Engel commented on Aug 24, 2023

user1oc commented on Jan 31, 2024

David-Engel commented on Jan 31, 2024

ecki commented on Feb 2, 2024

tkyc commented on Feb 2, 2024

ecki commented on Feb 2, 2024

postfach33 commented on Oct 4, 2024

ADror-Quest commented on Jan 27, 2025

lilgreenbird commented on Jan 29, 2025

ecki commented on Feb 2, 2025

postfach33 commented on Jan 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions