Excel to a Partner's SQL Server Without a Domain Trust

An Excel workbook opening a table on another organization's SQL Server needs three things usually discussed as one: an identity the server accepts, a transport the client validates, and a network path both sides permit. A domain trust is one way to satisfy the first, and the broadest. TLS satisfies the second and says nothing about the first. The path satisfies the third and protects nothing by itself.

Separating the three turns the spreadsheet into a small, reviewable request instead of an administrative relationship.

Three Decisions the Question Hides

Identity is who the database believes you are: a Windows account from a trusted domain, a SQL login with its own password, or a certificate-based identity. Transport is whether the session is encrypted and whether the client checks the server's certificate chain. Path is how packets reach the listener, which may be a VPN, a private link or a public endpoint with firewall rules. Each lives in a different place and each can fail on its own.

A forest trust answers the first broadly and is a relationship between organizations rather than a setting for one workbook. It also encrypts nothing, which surprises people who assumed the trust was the security control.

Identity Without a Forest Trust

A deliberately provisioned account in the target environment can serve a narrower requirement without any trust, provided the client workflow can use it. SQL authentication is the other common answer when policy permits: the login carries its own credential lifecycle and does not join domains or produce Windows integrated authentication. Certificate or token-based identity is a third option on newer platforms. Whichever you pick, grant only the database permissions the workbook actually needs.

Prefer a dedicated account over somebody's personal login. A shared credential in a spreadsheet is a support problem waiting to happen, and a named account makes revocation possible when the project ends.

Encrypt Yes, Trust the Certificate Anyway?

With ODBC Driver 18, Encrypt=Yes;TrustServerCertificate=No asks for an encrypted session whose certificate is actually checked. The connection string must then name the server the certificate covers, and the client must trust its chain. Driver 18 also defaults to encryption, unlike earlier versions, so an old connection string may now negotiate TLS without saying so. Explicit settings make the intended policy visible across machines, which matters when several people maintain the same workbook.

TrustServerCertificate=Yes encrypts and skips validation, which is not an equivalent repair for a name mismatch or an untrusted chain. It removes the signal that would have told you the client reached the wrong endpoint, so fix the certificate or the name instead.

Server-side enforcement is a separate control. If encryption must apply to every client, configure and verify the server's force-encryption setting, because one cooperative connection string enforces nothing.

The Network Path Is Not the Protection

A private listener reached through a VPN reduces exposure, and the VPN must carry the right destination and return routes for that to work. A working tunnel does not remove the need for authentication or certificate validation, and TLS does not restrict which remote systems may attempt a connection. Those are three separate observations: a TLS handshake, a VPN login and an authorized query. Only the third proves the workbook read the data it was allowed to read.

So resist the shortcut of answering a trust question by exposing the database to the internet. The narrow answer is usually a dedicated account, validated encryption and one approved path, in that order.

Verify with the ordinary Excel workflow: the accepted identity, the effective permissions and the negotiated encryption, each checked through the server's own session view.