Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.

In the pervious post of this series, we discussed encrypting traffic between AD FS Servers, servers running Azure AD Connect and SQL Servers hosting their databases. Today, let’s dive into enabling Extended Protection for Authentication.

Why enable Extended Protection for Authentication?

Extended Protection for Authentication is a feature of the network components implemented by the Operating System (OS). The feature enhances the protection and handling of credentials when authenticating network connections using Integrated Windows Authentication (IWA). SQL Server is more secure when connections are made using Extended Protection.

Extended Protection offers service binding or channel binding, depending on the SQL client using encryption to communicate with the SQL Server(s) or not:

• Service Binding (when encryption is not used)
  Service binding requires AD FS Servers and Azure AD Connect installations 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 is its own SPN.
• Channel Binding (when encryption is used)
  Channel binding establishes a secure channel between the AD FS Servers, Azure AD Connect installations and the instance of the SQL Server service hosting the databases for these services. The SQL Server service verifies the authenticity of the client by comparing the client's channel binding token (CBT) specific to that channel, with its own CBT.

This way, Extended Protection for Authentication addresses up to two specific authentication relay attacks, where an attacker would use the credentials to masquerade as a legitimate server and authenticate to the Microsoft SQL Server(s)hosting the AD FS and Azure AD Connect databases :

1. Luring attacks
   In a luring attack, the AD FS Server and/or Azure AD Connect installation is lured to voluntarily connect to the attacker instead of the SQL Server. Service Binding and Channel Binding both protect against this type of attacks.
2. Spoofing attacks
   In a spoofing attack, the AD FS Server and/or Azure AD Connect installation 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. Channel binding protects against this type of attacks.

However, Windows Server does not enable Extended Protection, by default.

Why wouldn’t you enable Extended Protection for Authentication?

There are several reasons why you might not want or be able to enabled Extended Protection for Authentication:

Increase in SQL Server load

Depending on encryption being used or not, the impact of enabling Extended Protection for Authentication is significant on the load of the SQL Server service.

Service Binding incurs a one-time, negligible cost, but it does not address spoofing attacks. Channel Binding, on the other hand, incurs a larger runtime cost, because it requires Transport Layer Security (TLS) encryption of all the session traffic.

Note:
When you have encryption enabled for the traffic between AD FS Servers, servers running Azure AD Connect and SQL Servers hosting their databases, the increase in load is nihil; all traffic already uses TLS.

Operating System and SQL Server version requirements

Extended Protection for Authentication requires your SQL Server(s), your AD FS Server(s), your Azure AD Connect server(s), but also all other services, applications and systems that access databases on the SQL Server(s) to run Windows 7, or a newer version of Windows, or Windows Server 2008 R2, or a newer version of Windows Server.

Additionally, the Microsoft SQL Server installation must run SQL Server 2008 R2, or a newer version of Microsoft SQL Server.

Getting ready

To configure Extended Protection for Authentication, you’ll need an account that has local administrator privileges on the Windows Server and system admin (sa) privileges within Microsoft SQL Server.

These privileges are required on each SQL Server, but they do not have to be the same credentials for every SQL Server hosting AD FS and Azure AD Connect databases.

Enabling Extended Protection for Authentication

To enable Extended Protection for Authentication for AD FS Servers, servers running Azure AD Connect and SQL Servers hosting the AD FS and Azure AD Connect databases, perform these steps:

Configure Windows Server

To configure Windows Server to offer Extended Protection for Authentication, run the following lines of Windows PowerShell in an elevated Windows PowerShell window:

$RegPath = "HKLM:\System\CurrentControlSet\Control\LSA\"

New-ItemProperty -Path $RegPath -Name SuppressExtendedProtection -Value 0 -PropertyType DWORD

New-ItemProperty -Path $RegPath -Name LmCompatibilityLevel -Value 3 -PropertyType DWORD

Restart-Computer

Configure SQL Server

To configure Microsoft SQL Server to take advantage of Extended Protection for Authentication, perform these steps:

• Open SQL Server Configuration Manager.
• In SQL Server Configuration Manager, expand SQL Server Network Configuration, right-click Protocols for <server instance>, and then select Properties.
• In the Protocols for <instance name> Properties dialog box, on the Advanced tab, make the following changes:
  • For the Accepted NTLM SPNs field, define all service principal names for the SQL Server.

Note:
Service Principal Names are typically created for the NetBIOS hostname and the fully qualified domain name. Be sure to include both.

• • For the Extended Protection field, choose Required, instead of Off (default) or Allowed from
    the drop-down list.
• Click Apply, and then click OK to close the dialog box.
• Restart the SQL Server service.

Concluding

Most of the blogposts in this Hardening Hybrid Identity series cover protections , preventing malicious people from gaining access from outside of the network to the network. Just like encrypting the traffic, this particular protection prevents insider threats. Specifically, Extended Protection for Authentication prevents replaying authentication requests when a malicious person is already on the network.

Further reading

Connect to the Database Engine Using Extended Protection
Microsoft Security Advisory 973811 – Extended Protection for Authentication
Extended Protection available in SQL Server 2008 R2
SQL Server's Extended Protection
Packt | Using extended protection to prevent authentication relay attacks

The post HOWTO: Enable Extended Protection for Authentication on the SQL Servers hosting the AD FS and Azure AD Connect databases appeared first on The things that are better left unspoken.