Connect to the Database Engine Using Extended Protection

Article
06/13/2017

SQL Server supports Extended Protection beginning with SQL Server 2008 R2. Extended Protection for Authentication is a feature of the network components implemented by the operating system. Extended Protection is supported in Windows 7 and Windows Server 2008 R2. Extended Protection is included in service packs for older Microsoft operating systems. SQL Server is more secure when connections are made using Extended Protection.

Important

Windows does not enable Extended Protection by default. For information about how to enable Extended Protection in Windows, see Extended Protection for Authentication.

Description of Extended Protection

Extended Protection uses service binding and channel binding to help prevent an authentication relay attack. In an authentication relay attack, a client that can perform NTLM authentication (for example, Windows Explorer, Microsoft Outlook, a .NET SqlClient application, etc.), connects to an attacker (for example, a malicious CIFS file server). The attacker uses the client's credentials to masquerade as the client and authenticate to a service (for example, an instance of the Database Engine service).

There are two variations of this attack:

In a luring attack, the client is lured to voluntarily connect to the attacker.
In a spoofing attack, the client intends to connect to a valid service, but is unaware that one or both of DNS and IP routing are poisoned to redirect the connection to the attacker instead.

SQL Server supports service binding and channel binding to help reduce these attacks on SQL Server instances.

Service Binding

Service binding addresses luring attacks by requiring a client to send a signed service principal name (SPN) of the SQL Server service that the client intends to connect to. As part of the authentication response, the service validates that the SPN received in the packet matches its own SPN. If a client is lured to connect to an attacker, the client will include the signed SPN of the attacker. The attacker cannot relay the packet to authenticate to the real SQL Server service as the client, because it would include the SPN of the attacker. Service binding incurs a one-time, negligible cost, but it does not address spoofing attacks. Service Binding occurs when a client application does not use encryption to connect to the SQL Server.

Channel Binding

Channel binding establishes a secure channel (Schannel) between a client and an instance of the SQL Server service. The service verifies the authenticity of the client by comparing the client's channel binding token (CBT) specific to that channel, with its own CBT. Channel binding addresses both luring and spoofing attacks. However, it incurs a larger runtime cost, because it requires Transport Layer Security (TLS) encryption of all the session traffic. Channel Binding occurs when a client application uses encryption to connect to the SQL Server, regardless of whether encryption is enforced by the client or by the server.

Warning

SQL Server and Microsoft data providers for SQL Server support TLS 1.0 and SSL 3.0. If you enforce a different protocol (such as TLS 1.1 or TLS 1.2) by making changes in the operating system SChannel layer, your connections to SQL Server might fail.

Operating System Support

The following links provide more information about how Windows supports Extended Protection:

Settings

There are three SQL Server connection settings that affect service binding and channel binding. The settings can be configured by using the SQL Server Configuration Manager, or by using WMI, and can by viewed by using the Server Protocol Settings facet of Policy Based Management.

Force Encryption

Possible values are On and Off. To use channel binding, Force Encryption must be set to On, and all clients will be forced to encrypt. If it is Off, only service binding is guaranteed. Force Encryption is on the Protocols for MSSQLSERVER Properties (Flags Tab) in SQL Server Configuration Manager.
Extended Protection

Possible values are Off, Allowed, and Required. The Extended Protection variable lets users configure the Extended Protection level for each SQL Server instance. Extended Protection is on the Protocols for MSSQLSERVER Properties (Advanced Tab) in SQL Server Configuration Manager.
- When set to Off, Extended Protection is disabled. The instance of SQL Server will accept connections from any client regardless of whether the client is protected or not. Off is compatible with older and unpatched operating systems, but is less secure. Use this setting when you know that the client operating systems do not support extended protection.
- When set to Allowed, Extended Protection is required for connections from operating systems that support Extended Protection. Extended Protection is ignored for connections from operating systems that do not support Extended Protection. Connections from unprotected client applications that are running on protected client operating systems are rejected. This setting is more secure than Off, but is not the most secure setting. Use this setting in mixed environments, where some operating systems support Extended Protection and some do not.
- When set to Required, only connections from protected applications on protected operating systems are accepted. This setting is the most secure but connections from operating systems or applications that do not support Extended Protection will not be able to connect to SQL Server.
Accepted NTLM SPNs

The Accepted NTLM SPNs variable is needed when a server is known by more than one SPN. When a client attempts to connect to the server by using a valid SPN that the server does not know, service binding will fail. To avoid this problem, users can specify several SPNs that represent the server by using Accepted NTLM SPNs. Accepted NTLM SPNs is a series of SPNs separated my semicolons. For example, to allow the SPNs MSSQLSvc/ HostName1.Contoso.com and MSSQLSvc/ HostName2.Contoso.com, type MSSQLSvc/HostName1.Contoso.com;MSSQLSvc/HostName2.Contoso.com in the Accepted NTLM SPNs box. The variable has a maximum length of 2,048 characters. Accepted NTLM SPNs is on the Protocols for MSSQLSERVER Properties (Advanced Tab) in SQL Server Configuration Manager.

Enabling Extended Protection for the Database Engine

To use Extended Protection, both the server and the client must have an operating system on that supports Extended Protection, and Extended Protection must be enabled on the operating system. For more information about how to enable Extended Protection for the operating system, see Extended Protection for Authentication.

SQL Server supports Extended Protection beginning with SQL Server 2008 R2. Extended Protection for some earlier versions of SQL Server will be made available in future updates. After enabling Extended Protection on the server computer, use the following steps to enable Extended Protection:

On the Start menu, choose All Programs, point to Microsoft SQL Server and then click SQL Server Configuration Manager.
Expand SQL Server Network Configuration, and then right-click Protocols for <InstanceName>, and then click Properties.
For both channel binding and service binding, on the Advanced tab, set Extended Protection to the appropriate setting.
Optionally, when a server is known by more than one SPN, on the Advanced tab configure the Accepted NTLM SPNs field as described in the "Settings" section.
For channel binding, on the Flags tab, set Force Encryption to On.
Restart the Database Engine service.

Configuring Other SQL Server Components

For more information about how to configure Reporting Services, see Extended Protection for Authentication with Reporting Services.

When using IIS to access Analysis Services data using an HTTP or HTTPs connection, Analysis Services can take advantage of Extended Protection provided by IIS. For more information about how to configure IIS to use Extended Protection, see Configure Extended Protection in IIS 7.5.

Share via