This came from in internal support discussion about a customer scenario.
Is your feature request related to a problem? If so, please give a short summary of the problem and how the feature would resolve it
Summary
In a cross-realm connection scenario, the driver may decipher the REALM portion of the serverSPN incorrectly for some configurations. For example, in a scenario where the SQL Server service is running as a service account from a trusted realm that is different from the realm that the server belongs to.
Example Environment:
AD with one way trust between two forests, Forest (forest.com) and ForestExternal (forestexternal.com, ForestExternal trusts Forest).
Windows Server in ForestExternal, named server22-test.forestexternal.com, running SQL Server service running as a Forest service account.
CNAME testdb.forest.com -> server22-test.forestexternal.com
Linux JDBC client on ForestExternal machine using driver version 8.2 connecting to SQL via: jdbc:sqlserver://testdb.forest.com;databaseName=JavaPOC;failoverPartner=testdb-replica.forest.com;integratedSecurity=true;authenticationScheme=JavaKerberos;sendStringParametersAsUnicode=false;jaasConfigurationName=SQLJDBCDriver;
Results in Kerberos error -
>>> KDCRep: init() encoding tag is 126 req type is 13
>>>KRBError:
sTime is Fri Oct 16 12:42:11 PDT 2020 1593845499000
suSec is 795070
error code is 7
error Message is Server not found in Kerberos database
sname is MSSQLSvc/server22-test.forestexternal.com:[email protected]
msgType is 30
CNAMEs are used to minimize required connection string changes. The one way trust maximizes security.
Right now, the driver fails to connect because it auto-detects the server SPN as MSSQLSvc/server22-test.forestexternal.com:[email protected], which is incorrect. We can connect correctly if we specify serverSPN=MSSQLSvc/server22-test.forestexternal.com:1433@forest.com. However this does not work well with the goal of minimizing connection string changes.
Describe the preferred solution
If we could simply specify the correct authentication REALM for the driver, rather than it trying to decipher it from DNS resolution, that would be ideal.
Describe alternatives you've considered
Setting the serverSPN (causes a lot of connection string maintenance)
Using CNAMES in the serverSPN does not work.
Using less secure authentication methods like SQL authentication.
This came from in internal support discussion about a customer scenario.
Is your feature request related to a problem? If so, please give a short summary of the problem and how the feature would resolve it
Summary
In a cross-realm connection scenario, the driver may decipher the REALM portion of the serverSPN incorrectly for some configurations. For example, in a scenario where the SQL Server service is running as a service account from a trusted realm that is different from the realm that the server belongs to.
Example Environment:
AD with one way trust between two forests, Forest (forest.com) and ForestExternal (forestexternal.com, ForestExternal trusts Forest).
Windows Server in ForestExternal, named server22-test.forestexternal.com, running SQL Server service running as a Forest service account.
CNAME testdb.forest.com -> server22-test.forestexternal.com
Linux JDBC client on ForestExternal machine using driver version 8.2 connecting to SQL via: jdbc:sqlserver://testdb.forest.com;databaseName=JavaPOC;failoverPartner=testdb-replica.forest.com;integratedSecurity=true;authenticationScheme=JavaKerberos;sendStringParametersAsUnicode=false;jaasConfigurationName=SQLJDBCDriver;
Results in Kerberos error -
CNAMEs are used to minimize required connection string changes. The one way trust maximizes security.
Right now, the driver fails to connect because it auto-detects the server SPN as MSSQLSvc/server22-test.forestexternal.com:[email protected], which is incorrect. We can connect correctly if we specify serverSPN=MSSQLSvc/server22-test.forestexternal.com:1433@forest.com. However this does not work well with the goal of minimizing connection string changes.
Describe the preferred solution
If we could simply specify the correct authentication REALM for the driver, rather than it trying to decipher it from DNS resolution, that would be ideal.
Describe alternatives you've considered
Setting the serverSPN (causes a lot of connection string maintenance)
Using CNAMES in the serverSPN does not work.
Using less secure authentication methods like SQL authentication.