Resolving Kerberos vs NTLM Authentication Issue in Cross-Domain SQL Server Connection

113 Views Asked by At

I am encountering an issue with Kerberos authentication in a multi-domain Microsoft SQL Server setup. Here are the details of my configuration:

  1. Microsoft SQL Server is hosted on a server that is part of the Windows Active Directory xyz.com domain.
  2. Host1, also in the xyz.com domain.
  3. Host2, part of the Windows Active Directory abc.com domain, which has a two-way trust relationship with xyz.com.
  4. A separate DNS server registers the SQL Server endpoint A record as sqlserver-instance.differentdomain.com.
  5. I registered the Service Principal Name (SPN) MSSQLSvc/sqlserver-instance.differentdomain.com in the xyz.com domain.
  • Connecting to sql server from SSMS on Host1, can connect to SQL Server using Kerberos authentication.
  • Connecting to sql server from SSMS on Host2, defaults to NTLM authentication instead of Kerberos when connecting to SQL Server.

Despite this configuration, when Host2 tries to connect to sqlserver-instance.differentdomain.com, it uses NTLM instead of Kerberos.

Is there a solution that allows Host2 to use Kerberos authentication to connect to SQL Server while maintaining the endpoint sqlserver-instance.differentdomain.com? Additionally, I found a guide on configuring Kerberos with realms for Java applications (https://learn.microsoft.com/en-us/sql/connect/jdbc/using-kerberos-integrated-authentication-to-connect-to-sql-server?view=sql-server-ver16). Can a similar approach be applied for non-Java environments, or is there an alternative method for my situation?

1

There are 1 best solutions below

3
user1686 On

Try one of the following to map the domain to the correct realm (note: Kerberos realm, not AD domain; realms are almost always upper-case as seen in klist):

  1. Manual ksetup /addhosttorealmmap .differentdomain.com XYZ.COM.

  2. The corresponding Group Policy setting.

In Windows, typically it's not the client itself but the client's KDC responsible for mapping service domains to Kerberos realms. (The client requests a "local" ticket and potentially gets a referral to another realm.) So if possible, I would attempt to deploy this mapping to the domain controllers instead of client machines.