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 is a property of its database mirroring endpoint. Two types of transport security are available for database mirroring: Windows Authentication and certificate-based authentication.

Windows Authentication supports two authentication protocols: NT LAN Manager (NTLM) and Kerberos. A database mirroring endpoint can be configured to use only one protocol or to negotiate between them. By default, negotiation is used. The default value, NEGOTIATE, causes the endpoint to use the Windows negotiation protocol to choose either NTLM or Kerberos. If a specific authorization method (NTLM or Kerberos) is specified on an endpoint, it can use only that method. If the opposite endpoint is configured to use only the other method, the endpoints cannot connect with each other. For more information about these methods, see Endpoint Authentication Types.

Note:
For information about this endpoint, see Database Mirroring Endpoint.

A database mirroring connection uses either Windows Authentication (the Security Support Provider Interface (SSPI)) or certificate-based authentication.

Windows Authentication

Certificates

In some situations, such as when server instances are not in trusted domains or when SQL Server 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 How to: Allow Database Mirroring to Use Certificates for Outbound Connections (Transact-SQL). 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.

Security Note:
Only install certificates from trusted sources.

There is no automated method for configuring database mirroring security using certificates. Using Transact-SQL is required. For an example of using certificate-based authentication for setting up a database mirroring session, see Example: Setting Up Database Mirroring Using Certificates (Transact-SQL).

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 cannot 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 SQL Server Management Studio are created with encryption either required or disabled. To change the encryption setting to SUPPORTED, use the ALTER ENDPOINT Transact-SQL statement. For more information, see ALTER ENDPOINT (Transact-SQL).

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:

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

Note:
Though considerably faster than AES, RC4 is a relatively weak algorithm, while AES is a relatively strong algorithm. Therefore, we recommend that you use the AES algorithm.

For information about the Transact-SQL syntax for specifying encryption, see CREATE ENDPOINT (Transact-SQL).

Concepts

Other Resources

Help and Information