Migration Security and Authentication

Migration: security and authentication

Home / Migrate / Security

Keep certificate validation enabled and test authentication on the deployment host. A successful connection after weakening TLS settings is not a completed migration.

Encryption defaults

MDS 4.0 changed the default Encrypt setting to True; MDS 5.0 introduced SqlConnectionEncryptOption, with Mandatory as the default. TrustServerCertificate still defaults to False.

Situation	Safe next action
Certificate chain is not trusted	Provision an appropriate server certificate and install its issuing trust chain in the client environment.
DNS alias does not match the intended certificate identity	Confirm the correct server identity; consider HostNameInCertificate for that expected CN/SAN. It does not repair an untrusted chain.
Certificate pinning is required	ServerCertificate identifies a file that must exactly match the server certificate. It is not a CA-bundle path. Plan certificate-file deployment and rotation.
Considering Encrypt=Strict	Confirm TDS 8.0 support for the endpoint. TrustServerCertificate does not bypass validation in Strict mode.
Considering Encrypt=Optional	It can allow unencrypted application traffic and is not a production security fix. Server-forced encryption still affects validation.
Considering TrustServerCertificate=True	It bypasses normal trust/name validation outside Strict mode. Do not make it the standard migration recommendation.

MDS documents certificate-file matching for Mandatory or Strict. The 6.1.7/7.0.3 servicing fixes enforce configured certificate matching on managed SNI even when ordinary chain/name checks succeed. An invalid or inaccessible pin file can now correctly fail the handshake; repair the file/configuration rather than bypassing the check.

The existing self-signed-certificate walkthrough is a Windows development reference. Check its subject/SAN values against the actual hostnames and configure client trust explicitly. Creating a certificate alone does not establish a trusted production deployment.

Entra authentication in 7.x

The driver-provided Entra authentication implementation moved from the core package to Microsoft.Data.SqlClient.Extensions.Azure in 7.0.

Your application uses	Required review
Driver-provided Authentication=Active Directory ... modes	Add the Azure extension. For the aligned 7.0.2+ family, match the driver version.
SQL authentication or Integrated Security=true	The Azure extension is not required for those mechanisms.
Application-supplied AccessToken / AccessTokenCallback	The extension is not required just to supply a token. Reference whichever token-acquisition libraries your own code actually uses.
A custom authentication-provider implementation	Check its package and assembly references; using a custom implementation is not the same as using the driver's Entra provider.

Installing the extension supplies the built-in providers; applications directly referencing relocated provider types may also need rebuilding. ActiveDirectoryPassword is obsolete in 7.0. Prefer a supported interactive, managed identity, workload identity, or service-principal approach appropriate to the host and security policy.

For user-assigned managed identity, verify that User Id supplies the client ID expected by the selected driver version. Windows/Kerberos integrated authentication and Entra integrated authentication are different mechanisms, not interchangeable remedies.

Next: Runtime behavior and compatibility.

Sources: TLS behavior, connection options, Entra migration, 6.1.7 fixes, 7.0.3 fixes.