Skip to content

transport-security-database-mirroring-always-on-availability.md

Latest commit

 

History

History
99 lines (70 loc) · 9.67 KB

transport-security-database-mirroring-always-on-availability.md

File metadata and controls

99 lines (70 loc) · 9.67 KB
title Transport Security: Availability Groups & Database Mirroring
description Learn how to secure messages between databases participating in an Always On availability group or in a database mirroring session hosted on SQL Server.
author MikeRayMSFT
ms.author mikeray
ms.reviewer randolphwest
ms.date 05/19/2026
ms.service sql
ms.subservice database-mirroring
ms.topic concept-article
helpviewer_keywords
sessions [SQL Server], database mirroring
cryptography [SQL Server], database mirroring
certificates [SQL Server], database mirroring
encryption [SQL Server], database mirroring
Windows authentication [SQL Server]
authentication [SQL Server], database mirroring
transport security
database mirroring [SQL Server], security

Transport security in availability groups and database mirroring

[!INCLUDE SQL Server]

Transport security involves authentication and, optionally, encryption of messages exchanged between the databases. For database mirroring and [!INCLUDE ssHADR], authentication and encryption are configured on the database mirroring endpoint. For an introduction to database mirroring endpoints, see The database mirroring endpoint (SQL Server).

Authentication

Authentication is the process of verifying that a user is who the user claims to be. Connections between database mirroring endpoints require authentication. Connection requests from a partner or witness, if any, must be authenticated.

The type of authentication used by a server instance for database mirroring or [!INCLUDE ssHADR] is a property of the database mirroring endpoint. Two types of transport security are available for database mirroring endpoints: Windows Authentication (the Security Support Provider Interface (SSPI)) and certificate-based authentication.

Windows Authentication

Under Windows Authentication, each server instance logs in to the other side using the Windows credentials of the Windows user account under which the process is running. Windows Authentication might require some manual configuration of login accounts, as follows:

  • If the instances of [!INCLUDE ssNoVersion] run as services under the same domain account, no extra configuration is required.

  • If the instances of [!INCLUDE ssNoVersion] run as services under different domain accounts (in the same or trusted domains), the login of each account must be created in master on each of the other server instances, and that login must be granted CONNECT permissions on the endpoint.

  • If the instances of [!INCLUDE ssNoVersion] run as the Network Service account, the login of each host computer account (<domain-name>\<computer-name>$) must be created in master on each of the other servers, and that login must be granted CONNECT permissions on the endpoint. This is because a server instance running under the Network Service account authenticates using the domain account of the host computer.

Note

For an example of setting up a database mirroring session using Windows Authentication, see Example: Configure database mirroring using Windows authentication.

Certificates

In some situations, such as when server instances aren't in trusted domains or when [!INCLUDE ssNoVersion] is running as a local service, Windows Authentication is unavailable. In such cases, instead of user credentials, certificates are required to authenticate connection requests. The mirroring endpoint of each server instance must be configured with its own locally created certificate.

The encryption method is established when the certificate is created. For more information, see Database Mirroring - Use Certificates for Outbound Connections. Carefully manage the certificates that you use.

A server instance uses the private key of its own certificate to establish its identity when setting up a connection. The server instance that receives the connection request uses the public key of the sender's certificate to authenticate the sender's identity. For example, consider two server instances, Server_A and Server_B. Server_A uses its private key to encrypt the connection header before sending a connection request to Server_B. Server_B uses the public key of Server_A's certificate to decrypt the connection header. If the decrypted header is correct, Server_B knows that the header was encrypted by Server_A, and the connection is authenticated. If the decrypted header is incorrect, Server_B knows that the connection request is inauthentic and refuses the connection.

Data Encryption

By default, a database mirroring endpoint requires encryption of data sent over mirroring connections. In this case, the endpoint can connect only to endpoints that also use encryption. Unless you can guarantee that your network is secure, we recommend that you require encryption for your database mirroring connections. However, you can disable encryption or make it supported, but not required. If encryption is disabled, data is never encrypted and the endpoint can't connect to an endpoint that requires encryption. If encryption is supported, data is encrypted only if the opposite endpoint either supports or requires encryption.

Note

Mirroring endpoints created by [!INCLUDE ssManStudioFull] are created with encryption either required or disabled. To change the encryption setting to SUPPORTED, use the ALTER ENDPOINT [!INCLUDE tsql] statement. For more information, see ALTER ENDPOINT.

Optionally, you can control the encryption algorithms that can be used by an endpoint, by specifying one of the following values for the ALGORITHM option in a CREATE ENDPOINT statement or ALTER ENDPOINT statement:

ALGORITHM value Description
RC4 (default) Specifies that the endpoint must use the RC4 algorithm.

Warning: The RC4 algorithm is deprecated. [!INCLUDE ssNoteDepFutureAvoid] We recommend that you use AES.
AES (recommended) Specifies that the endpoint must use the AES algorithm.
AES RC4 Specifies that the two endpoints negotiate for an encryption algorithm with this endpoint giving preference to the AES algorithm.
RC4 AES Specifies that the two endpoints negotiate for an encryption algorithm with this endpoint giving preference to the RC4 algorithm.

If connecting endpoints specify both algorithms but in different orders, the endpoint accepting the connection wins.

Caution

Though considerably faster than AES, RC4 is a relatively weak algorithm, while AES is a relatively strong algorithm. Therefore, you should use the AES algorithm.

The RC4 algorithm is only supported for backward compatibility. Data can only be encrypted using RC4 or RC4_128 when the database is in compatibility level 90 or 100 (Not recommended). Use a newer algorithm such as one of the AES algorithms instead. In [!INCLUDE sssql11-md] and later versions, data encrypted using RC4 or RC4_128 can be decrypted in any compatibility level.

For information about the [!INCLUDE tsql] syntax for specifying encryption, see CREATE ENDPOINT.

Configure transport security for database mirroring endpoints

Related content