Description/Symptoms

Issue

Connecting to a SQL Server database using Windows Authentication works on Windows, but fails on non-Windows systems (macOS/Linux) when using a JDBC connection with integratedSecurity=true.

How to replicate the issue (step-by-step)

1. On macOS or Linux, configure a JDBC connection to SQL Server using Windows Authentication (Integrated Security), for example, with:

   • integratedSecurity=true

   • without explicitly setting authenticationScheme

2. Attempt the connection from your client application.

3. Result: the connection fails.

Error message 

Environment

• Product: WTab

• Client application types:  Tableau

Cause

1. Integrated Security on macOS/Linux cannot use native Windows authentication (DLL-based).
   Native Windows Authentication relies on Windows-specific components (DLLs) and is not compatible with Linux/macOS.

2. JDBC default behavior can trigger the wrong authentication method.
   If integratedSecurity=true is set without explicitly settingauthenticationScheme, the driver may default to native Windows authentication, which fails on non-Windows platforms.

3. The SSL/PKIX error usually means the SQL Server certificate isn’t trusted by the client JVM.
   On macOS/Linux, the Java truststore may not contain the certificate chain used by SQL Server, causing the connection handshake to fail when encrypt=true and trustServerCertificate=false.

Resolution

Step 1 — Confirm Kerberos is available and configured on the client (macOS/Linux)

Because DLL-based authentication is not available, the cross-platform path is Kerberos.

Confirm with the customer that Kerberos is set up, for example:

• A valid Kerberos configuration file is present (krb5.conf / /etc/krb5.conf)

• The user can obtain a ticket (e.g., kinit succeeds)

• The realm/KDC settings are correct

• If using keytabs, the keytab is present and valid

Optional guidance (high level) — Kerberos on macOS/Linux

• Install/enable Kerberos client tools (common on Linux; on macOS, it’s typically available or installable).

• Configure krb5.conf with the correct realm and KDC.

• Obtain a Kerberos ticket (kinit user@REALM) or configure a keytab for non-interactive use.

• Ensure DNS/SPN alignment is correct for SQL Server Kerberos authentication.

Exact Kerberos deployment steps depend on the customer’s domain/identity setup, so this is typically handled with their IT/security team.

Step 2 — Update the JDBC URL to use Kerberos explicitly

Set authenticationScheme=JavaKerberos explicitly.

Example JDBC URL:

jdbc:sqlserver://[serverName]:[portNumber];
authenticationScheme=JavaKerberos;
integratedSecurity=true;
domain=[domainName];
databaseName=[databaseName];
encrypt=true;
trustServerCertificate=true;

Notes

• authenticationScheme=JavaKerberos is the key change for macOS/Linux.

• The SSL settings depend on the customer's security requirements (see Step 3).

Step 3 — Fix the SSL certificate trust (recommended approach)

If the error includes PKIX path building failed, use one of these approaches:

Option A (recommended): Import the SQL Server certificate chain into the JVM truststore

1. Obtain the SQL Server certificate (and intermediate/root certificates if applicable).

2. Import them into the Java truststore used by the client/tool.

3. Keep:

   • encrypt=true

   • trustServerCertificate=false (more secure)

Option B (quick workaround): Temporarily set trustServerCertificate=true

• This bypasses certificate validation and may be acceptable for testing, but it is less secure than Option A.

Additional information 

• This KBA targets non-Windows clients (macOS/Linux) attempting to use Windows Authentication with SQL Server over JDBC.