| title | description | author | ms.author | ms.date | ms.service | ms.subservice | ms.topic | helpviewer_keywords | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Connect to the Database Engine Using Extended Protection |
Learn how Extended Protection uses service binding and channel binding to help prevent authentication relay attacks. See how to enable this feature. |
VanMSFT |
vanto |
08/11/2021 |
sql |
configuration |
conceptual |
|
[!INCLUDE SQL Server] [!INCLUDEssNoVersion] supports Extended Protection beginning with [!INCLUDEsql2008r2]. 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 [!INCLUDEmsCoName] operating systems. [!INCLUDEssNoVersion] 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.
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, [!INCLUDEmsCoName] 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 [!INCLUDEssDE] 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.
[!INCLUDEssNoVersion] supports service binding and channel binding to help reduce these attacks on [!INCLUDEssNoVersion] instances.
Service binding addresses luring attacks by requiring a client to send a signed service principal name (SPN) of the [!INCLUDEssNoVersion] 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 [!INCLUDEssNoVersion] 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 [!INCLUDEssNoVersion].
Channel binding establishes a secure channel (Schannel) between a client and an instance of the [!INCLUDEssNoVersion] 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 [!INCLUDEssNoVersion], regardless of whether encryption is enforced by the client or by the server.
Warning
[!INCLUDEssNoVersion] and [!INCLUDEmsCoName] data providers for [!INCLUDEssNoVersion] 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 [!INCLUDEssNoVersion] might fail. Make sure that you have the latest build of SQL Server to Support TLS 1.1 or TLS 1.2. For more information, see https://support.microsoft.com/topic/kb3135244-tls-1-2-support-for-microsoft-sql-server-e4472ef8-90a9-13c1-e4d8-44aad198cdbe.
The following links provide more information about how Windows supports Extended Protection:
There are three [!INCLUDEssNoVersion] connection settings that affect service binding and channel binding. The settings can be configured by using the [!INCLUDEssNoVersion] 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 [!INCLUDEssNoVersion] Configuration Manager.
-
Extended Protection
Possible values are Off, Allowed, and Required. The Extended Protection variable lets users configure the Extended Protection level for each [!INCLUDEssNoVersion] instance. Extended Protection is on the Protocols for MSSQLSERVER Properties (Advanced Tab) in [!INCLUDEssNoVersion] Configuration Manager.
-
When set to Off, Extended Protection is disabled. The instance of [!INCLUDEssNoVersion] 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 [!INCLUDEssNoVersion].
-
-
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 [!INCLUDEssNoVersion] Configuration Manager.
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.
[!INCLUDEssNoVersion] supports Extended Protection beginning with [!INCLUDEsql2008r2]. Extended Protection for some earlier versions of [!INCLUDEssNoVersion] 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 [!INCLUDEssDE] service.
For more information about how to configure [!INCLUDEssRSnoversion], see Extended Protection for Authentication with Reporting Services.
When using IIS to access [!INCLUDEssASnoversion] data using an HTTP or HTTPs connection, [!INCLUDEssASnoversion] 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.
Server Network Configuration
Client Network Configuration
Extended Protection for Authentication Overview
Integrated Windows Authentication with Extended Protection