Connect-DbaInstance fails in PowerShell 7.5 with "untrusted domain" error while System.Data.SqlClient works

[githubsqltoolsse]

Verified issue does not already exist?

I have searched and found no existing issue

What error did you receive?

Error: Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication.

Steps to Reproduce

Failing dbatools test:

Connect-DbaInstance -SqlInstance "FQDN\Instance"
Error: Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication.

Please confirm that you are running the most recent version of dbatools

dbatools Version : 2.7.27
dbatools.library Version : 2025.12.28
Microsoft.Data.SqlClient Version : 6.0.0.0

Other details or mentions

Working connection test:
$conn = New-Object System.Data.SqlClient.SqlConnection("Server=FQDN\Instance;Integrated Security=true")
$conn.Open() # Works perfectly
$conn.Close()

Failing dbatools test:
Connect-DbaInstance -SqlInstance "FQDN\Instance"

Error: Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication.

This error happens when I try to connect to a server in another network segment but in the same AD. It fails when I run powershell 7.5 but works with powershell 5.1. Connecting directly with smo also works as well.

Some details about my environment.
Issue : Connect-DbaInstance fails with untrusted domain error in PS7
PowerShell Version : 7.5.4
PowerShell Edition : Core
OS : Microsoft Windows 10.0.20348
dbatools Version : 2.7.27
dbatools.library Version : 2025.12.28
Microsoft.Data.SqlClient Version : 6.0.0.0
System.Data.SqlClient Works : YES - Kerberos auth successful
Connect-DbaInstance Works PS5.1 : YES
Connect-DbaInstance Works PS7.5 : NO - untrusted domain error
Server Type : Named instance with FQDN
Auth Method : Windows Integrated (Kerberos)
Network : Cross-domain/forest scenario

What PowerShell host was used when producing this error

PowerShell Core (pwsh.exe), VS Code (terminal)

PowerShell Host Version

PowerShell Version : 7.5.4
PowerShell Edition : Core
OS : Microsoft Windows 10.0.20348

SQL Server Edition and Build number

Microsoft SQL Server 2019 (RTM-CU32-GDR) (KB5068404) - 15.0.4455.2 (X64) Oct 7 2025 21:10:15 Copyright (C) 2019 Microsoft Corporation Standard Edition (64-bit) on Windows Server 2019 Datacenter 10.0 (Build 17763: ) (Hypervisor)

.NET Framework Version

.NET 9.0.10

[wsmelton]

Can you provide the verbose output of the failed run?

[githubsqltoolsse]

Yes, Here is my verbose output:

Connect-DbaInstance -SqlInstance "MyServer\MyInstance" -Verbose
VERBOSE: [16:54:53][Connect-DbaInstance] Starting loop for 'MyServer\MyInstance': ComputerName = 'MyServer', InstanceName = 'MyInstance', IsLocalHost = 'False', Type = 'Default'
VERBOSE: [16:54:53][Connect-DbaInstance] String is passed in, will build server object from instance object and other parameters, do some checks and then return the server object
VERBOSE: [16:54:53][Connect-DbaInstance] authentication method is 'local integrated'
ConnectionError:
Line |
105783 | throw $records[0]
| ~~~~~~~~~~~~~~~~~
| Error connecting to [MyServer\MyInstance]: Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication.

[andreasjordan]

Most of the helpful output of Connect-DbaInstance is in Debug-Level only. Can you run with -Debug and share the output?

@claude do you have an idea?

[claude]

Claude finished @andreasjordan's task in 3m 16s —— View job

---

Analysis of Connect-DbaInstance PS7.5 Untrusted Domain Error

• Gather context
• Analyze Connect-DbaInstance authentication logic
• Identify root cause and share findings

---

What's happening

The verbose output confirms: authentication method is 'local integrated'. This means dbatools uses Microsoft.SqlServer.Management.Common.SqlConnectionInfo with UseIntegratedSecurity=True, which generates a connection string like Integrated Security=True;.

The problem is that the behavior of this path differs between PS5.1 and PS7.5 due to the underlying .NET runtime:

Environment	.NET Runtime	SSPI/Negotiate impl
PS5.1	.NET Framework 4.x	Native Windows SSPI (P/Invoke → secur32.dll)
PS7.5	.NET 9	Managed System.Net.Security.NegotiateStream

System.Data.SqlClient.SqlConnection (the old API the user tested with) always uses native Windows SSPI, which is why it works. Microsoft.Data.SqlClient 6.0 (what dbatools.library uses) uses the managed Negotiate implementation on .NET 9, which can behave differently in cross-domain/cross-subnet Kerberos scenarios.

Root cause theory

The "Login failed from an untrusted domain" error is SQL Server rejecting an NTLM authentication attempt. This means Kerberos failed silently and fell back to NTLM — which the SQL Server likely rejects for cross-domain clients.

Why Kerberos might fail in Microsoft.Data.SqlClient 6.x on .NET 9 but not native SSPI:

1. SPN resolution difference for named instances: SQL Browser resolves FQDN\InstanceName → port. The Kerberos SPN format may differ — MSSQLSvc/FQDN:InstanceName vs MSSQLSvc/FQDN:Port. Native SSPI may handle the fallback differently than the managed implementation.

2. Microsoft.Data.SqlClient 6.0 regression: There have been reports of Kerberos auth regressions in newer Microsoft.Data.SqlClient versions specifically in cross-domain scenarios under .NET Core.

Recommended diagnostic step

Andreas is right — the -Debug output is critical here. It will show:

• The exact (masked) connection string passed to SMO (line ~1089: "The masked server.ConnectionContext.ConnectionString is ...")
• The value of EncryptConnection and TrustServerCertificate
• Whether any AdditionalParameters are being appended

Connect-DbaInstance -SqlInstance "FQDN\Instance" -Debug 2>&1 | Select-String "masked|Connection|Auth|Encrypt"

Potential workarounds to test

Option 1: Explicitly pass current user credentials (forces ConnectAsUser path in SMO rather than integrated security, bypasses the managed Negotiate issue):

$cred = Get-Credential -Message "Enter your Windows credentials (domain\user)"
Connect-DbaInstance -SqlInstance "FQDN\Instance" -SqlCredential $cred

Option 2: Append explicit authentication hint to the connection string:

Connect-DbaInstance -SqlInstance "FQDN\Instance" -AppendConnectionString "Authentication=Active Directory Integrated"

Option 3: Check if this is a known Microsoft.Data.SqlClient bug — the team may have a fix or workaround documented in the MDS GitHub issues.

Likely fix direction

If this is confirmed as a Microsoft.Data.SqlClient 6.0 regression on .NET 9 for cross-domain Kerberos, the fix would be in dbatools.library (updating the SqlConnectionInfo to add Authentication=Active Directory Windows or equivalent for on-premises Windows auth when running on PS7+). That would be a separate issue for the dbatools.library repo.

Please share the -Debug output — it will confirm which code path is being taken and what connection string is actually sent.

[githubsqltoolsse]

This is the output with -debug active:
Connect-DbaInstance -SqlInstance "MyServer\MyInstance" -Debug
DEBUG: 4473 | [09:21:49][Connect-DbaInstance] Starting process block
DEBUG: 4475 | [09:21:49][Connect-DbaInstance] Starting loop for 'MyServer\MyInstance': ComputerName = 'MyServer', InstanceName = 'MyInstance', IsLocalHost = 'False', Type = 'Default'
DEBUG: 4486 | [09:21:49][Connect-DbaInstance] Immediately checking for Azure
DEBUG: 4521 | [09:21:49][Connect-DbaInstance] String is passed in, will build server object from instance object and other parameters, do some checks and then return the server object
DEBUG: 4730 | [09:21:49][Connect-DbaInstance] authentication method is 'local integrated'
DEBUG: 4769 | [09:21:49][Connect-DbaInstance] ApplicationName will be set to 'dbatools PowerShell module - dbatools.io'
DEBUG: 4801 | [09:21:49][Connect-DbaInstance] ConnectionTimeout will be set to '15'
DEBUG: 4813 | [09:21:49][Connect-DbaInstance] EncryptConnection will be set to 'True'
DEBUG: 4833 | [09:21:49][Connect-DbaInstance] PacketSize will be set to '4096'
DEBUG: 4852 | [09:21:49][Connect-DbaInstance] Pooled will be set to 'True'
DEBUG: 4877 | [09:21:49][Connect-DbaInstance] TrustServerCertificate will be set to 'False'
DEBUG: 4941 | [09:21:49][Connect-DbaInstance] Building ServerConnection from SqlConnectionInfo
DEBUG: 4943 | [09:21:49][Connect-DbaInstance] ServerConnection was built
DEBUG: 4961 | [09:21:49][Connect-DbaInstance] Building Server from ServerConnection
DEBUG: 4963 | [09:21:49][Connect-DbaInstance] Server was built
DEBUG: 4982 | [09:21:49][Connect-DbaInstance] Setting ConnectionContext.StatementTimeout to '0'
DEBUG: 4987 | [09:21:49][Connect-DbaInstance] The masked server.ConnectionContext.ConnectionString is Data Source=MyServer\MyInstance;Integrated Security=True;Multiple Active Result Sets=False;Encrypt=True;Trust Server Certificate=False;Packet Size=4096;Application Name="dbatools PowerShell module - dbatools.io"
DEBUG: 5000 | [09:21:49][Connect-DbaInstance] We connect to the instance by running SELECT 'dbatools is opening a new connection'
DEBUG: [09:21:49][Connect-DbaInstance] Failure | Error connecting to [MyServer\MyInstance]: Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication.
ConnectionError:
Line |
105783 | throw $records[0]
| ~~~~~~~~~~~~~~~~~
| Error connecting to [MyServer\MyInstance]: Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication.

[andreasjordan]

@claude does the debug output help?

[claude]

Claude finished @andreasjordan's task in 1m 51s —— View job

---

Analysis of Debug Output

• Gather context
• Analyze Connect-DbaInstance code around encryption/auth settings
• Provide findings

---

Yes, the debug output is very helpful — it reveals the exact issue.

What the debug output tells us

The key lines:

EncryptConnection will be set to 'True'
TrustServerCertificate will be set to 'False'
The masked connection string is: ...Integrated Security=True;...Encrypt=True;Trust Server Certificate=False;...

dbatools defaults sql.connection.encrypt to $true (sql.ps1, line 21), following Microsoft's own defaults for Microsoft.Data.SqlClient. So the connection uses Encrypt=True;Trust Server Certificate=False.

Root cause

The error chain is:

1. Encrypt=True → TLS handshake occurs first
2. Kerberos must then bind its ticket to the TLS channel via a Channel Binding Token (CBT) — this is Extended Protection for Authentication
3. On PS5.1 / .NET Framework: native Windows SSPI (secur32.dll) handles CBT correctly for named instances
4. On PS7.5 / .NET 9: Microsoft.Data.SqlClient 6.0 uses a managed security stack — CBT generation for named instances (where SQL Browser resolves the actual port) differs from native SSPI
5. Result: Kerberos auth fails → silent fallback to NTLM → SQL Server rejects NTLM for cross-domain clients → "Login failed. The login is from an untrusted domain"

This is why System.Data.SqlClient (old API, always uses native SSPI) works, and why PS5.1 works — both use native Windows SSPI, bypassing the managed CBT implementation.

Workarounds to try (in order of preference)

Option 1 — Add TrustServerCertificate (disables the CBT requirement in most configs):

Connect-DbaInstance -SqlInstance "MyServer\MyInstance" -TrustServerCertificate

Option 2 — Disable encryption entirely (matches what the working System.Data.SqlClient test did):

Set-DbatoolsConfig -FullName 'sql.connection.encrypt' -Value $false
Connect-DbaInstance -SqlInstance "MyServer\MyInstance"

Option 3 — Force explicit Windows authentication mode via AppendConnectionString:

Connect-DbaInstance -SqlInstance "MyServer\MyInstance" -AppendConnectionString "Authentication=Active Directory Windows"

Long-term fix

This is a Microsoft.Data.SqlClient behavior difference on .NET 9 for cross-domain Kerberos + encryption. The proper fix would be in dbatools.library where the SqlConnectionInfo is constructed, potentially adding logic to use Authentication=Active Directory Windows when running on PS7+ in a cross-domain scenario. Alternatively, this may need to be reported upstream to the dotnet/SqlClient repo as a regression.

Could you test Option 1 first and report back if it resolves the connection?

[githubsqltoolsse]

None of the workarounds are working for me.

[andreasjordan]

Then I am running out of ideas. We mainly test with PS 5.1, but I can try to test with 7.5 (or even with 7.6) in my lab. Give me some days...

[andreasjordan]

I just tested dbatools and Connect-DbaInstance with pwsh 7.5.4 and I don't have any problems. But I might not have the exact situation you have. But I don't see a chance to help you.

I will leave this open in case some other contributors have more ideas, but adding the "wontfix" label to help me organizing the issues.