OCDB Driver 18 for SQL Server connection from Windows Server 2025 client to SQL Server 2019 connection error

Question

OCDB Driver 18 for SQL Server connection from Windows Server 2025 client to SQL Server 2019 connection error

MikeDBA 0

We have created some new servers as part of a rolling upgrade to Windows Server 2025 Datacenter. One of the servers runs an application that connects to SQL Server using the ODBC Driver 18 for SQL Server. The connection attempt fails with "the login is from an untrusted domain and cannot be used with Integrated authentication". The server is in fact a member of the same domain as the SQL Server instance. Further testing reveals this is an issue on all Windows Server 2025 computers. We spun up another server using Windows Server 2022 and the connection succeeded. SQL Server has a certificate issued from our corporate CA (we use a cert on all servers) and valid SPNs. On the SQL Server, we capture TSQL errors in an extended event. The error there is 17806 SSPI handshake failed with error code 0x8009030c state 14, severity 20.

We are at a loss as to the steps needed to resolve this issue. Any advice?

0 comments

1 answer

Your answer

Answer 1

James Gamble 0

Hola MikeDBA,

Based on what you’ve tested, I’d focus on Windows Server 2025 authentication changes rather than the SQL certificate or ODBC encryption settings.

Since the same application and SQL Server work on Server 2022 but fail on Server 2025 with SQL error 17806 and SSPI error 0x8009030c, that points to Windows Integrated Authentication failing during the SSPI/Kerberos negotiation, not to a TLS trust problem.

Two Server 2025 changes are relevant here: Credential Guard is enabled by default on eligible domain-joined Server 2025 systems, and Microsoft has also tightened Kerberos encryption handling, including RC4 restrictions.

I would suspect that the SQL Server service account or SPN is still relying on an older Kerberos encryption path, typically RC4, and the Server 2025 clients are no longer successfully negotiating it the same way Server 2022 does.

I’d verify the SQL service account supports AES: Get-ADUser sqlserviceaccount -Properties msDS-SupportedEncryptionTypes | Select-Object SamAccountName,msDS-SupportedEncryptionTypes

If SQL runs under a gMSA, use Get-ADServiceAccount instead.

I’d also force a service-ticket request from one of the failing Server 2025 systems:

klist purge

klist get MSSQLSvc/sqlserver.domain.example:1433

If that fails, it would confirm that the problem lies in Kerberos ticket issuance rather than in SQL Server itself.

Another useful check is a successful Server 2022 connection: SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID;

If that comes back as NTLM rather than KERBEROS, that would explain why 2022 appears healthy even though the Kerberos path is actually broken.

I don’t think the corporate CA certificate is the primary issue here. ODBC Driver 18 enforces encryption by default, but a certificate issue would normally surface as an SSL Provider or certificate validation error, not SSPI 0x8009030c.

Thanks,

James

MikeDBA 0 Reputation points

2026-09-08T18:20:34.2233333+00:00

Thanks, James. I will check that. The SQL Server is also running Windows Server 2025 Datacenter. Connections from non-2025 clients all connect with Kerberos based on the auth_scheme column. On another Windows 2025 machine, I ran klist as suggested using the SPN for the target database server. The ticket was retrieved successfully. I'm thinking it's something to do with the ciphers. In PowerShell, Get-TlsCipherSuites shows quite a few ciphers, including several with a SHA1 hash. Is the registry no longer used for this? In HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers, there are only 3 (RC4 128/128, RC4 40/128, and RC4 56/128. I expected to see others. Protocols are configured the same as our Windows 2019 servers with only TLS 1.2 enabled. I'll focus on cipher suite area and engage our domain admins. Thanks again for your help.
James Gamble 0 Reputation points

2026-09-08T18:39:09.7233333+00:00
Hola MikeDBA,

That additional testing narrows this down quite a bit.

Since the Server 2025 client can successfully obtain the MSSQLSvc Kerberos ticket, and non-2025 clients are connecting to the same SQL Server using KERBEROS, I’d move SPNs, basic Kerberos ticket issuance, and the SQL service account itself much lower on the list. At this point, I’d focus on what happens after the Kerberos ticket is acquired, when SSPI and Schannel establish the protected SQL connection.

One important clarification: I wouldn’t interpret the sparse SCHANNEL\Ciphers registry key to mean that Server 2025 only has those three RC4 ciphers available. On modern Windows, the effective TLS cipher suite configuration isn’t represented by a complete list under that registry path. Get-TlsCipherSuite is a much better reflection of what Schannel can actually negotiate. Microsoft also still enables several TLS 1.2 AES-based suites by default on Server 2025, including AES-GCM and AES-CBC suites.

The SHA1 entries you’re seeing in Get-TlsCipherSuite also aren’t necessarily a red flag. In names such as TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, the SHA portion refers to the TLS record MAC used by that particular TLS 1.2 suite. It doesn’t mean Kerberos is using SHA-1, and it isn’t the same as a SHA-1-signed server certificate.

What I find more interesting here is the interaction between TLS and Integrated Authentication. SQL Server can use channel binding when the connection is encrypted. In that flow, Schannel establishes the TLS session, and SSPI can bind the Windows authentication exchange to that specific TLS channel using a Channel Binding Token. Microsoft specifically documents this as part of SQL Server Extended Protection.

That means you can have a perfectly valid Kerberos service ticket and still fail later during the SSPI handshake if the client and server don’t agree on the protected channel information. That would fit your symptoms much better than a basic Kerberos failure.

Windows Server 2025 also enables Credential Guard by default on eligible domain-joined member servers. That changes how credentials and some authentication operations are isolated. Microsoft has already had to disable the newer Server 2025 Credential Guard machine-account protection feature because of Kerberos machine-password issues, so there have definitely been authentication-stack changes in Server 2025 that don’t exist in Server 2019/2022 in the same form.

I’d therefore be cautious about changing cipher suites broadly at this stage. If the issue were simply “no common TLS cipher,” I’d normally expect a Schannel or SQL TLS negotiation error rather than SQL 17806 with 0x8009030c, which is SEC_E_LOGON_DENIED from SSPI.

My current suspicion would be one of these areas:

A Server 2025 Schannel/SSPI interaction with SQL Server’s encrypted Integrated Authentication path.

Channel Binding / Extended Protection behavior.

Credential Guard or another Server 2025 authentication hardening change affecting SSPI after the Kerberos service ticket has already been obtained.

If you can temporarily test the same connection with SQL Server Extended Protection set to Off, or with encryption behavior changed in a controlled test environment, that would be very informative. I wouldn’t make either of those permanent security changes, but they’d help identify whether channel binding/TLS is actually involved.

One Microsoft reference I’d keep handy for this is the SQL Server Extended Protection documentation.

Given your latest results, I’d definitely involve the domain/security team, but I wouldn’t spend too much time trying to make the Server 2025 cipher list look like Server 2019. The evidence points more toward the SSPI/Schannel boundary than to a missing cipher suite on its own.

Thanks,

James
MikeDBA 0 Reputation points

2026-09-09T00:27:30.62+00:00

Again, I appreciate your time and effort. Extended Protection is not enable in SQL Server Configuration Manager and Credential Guard is not enabled because we don't use Secure Boot. These machines are all AWS EC2 instances. I'm thinking we should open a case with Microsoft.

Thanks.

Mike