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 this part of the series, we’ll look at the security headers for AD FS implementations.

Note:
This blogpost assumes you’re running AD FS Servers as domain-joined Windows Server 2016 Server Core installations. The same information applies to AD FS Servers running Windows Server 2016 with Desktop Experience (Full).

Why look at Security Headers?

To prevent malicious attacks, many new protections for websites utilize security headers. Through security headers, you can prevent malicious scripts from running in browsers visiting your AD FS infrastructure, prevent the acceptance of forged TLS certificates and prevent clickjack attacks.

Reasons why

Through security response headers, the information security level of the AD FS infrastructure can be upgraded to a higher level.

Possible negative impact (What could go wrong?)

When the security response headers to tighten the security of the AD FS sign-in experience are configured wrongly, scripts can be blocked and the entire functionality of the AD FS implementation can be severely crippled.

When AD FS is used in default scenarios, the default settings for the AD FS security response headers can be safely used.

Getting ready

To change the security headers throughout the AD FS infrastructure, make sure to meet the following requirements:

SYSTEM REQUIREMENTS

Make sure the AD FS servers run Windows Server 2016, or above, and are installed with the latest cumulative Windows Updates. At a minimum, make sure AD FS Servers running Windows Server 2016 have the July 2019 Cumulative update (KB4507459) installed.

Note:
The ability to manage security headers is built into Active Directory Federation Services (AD FS) on Windows Server 2019.

PRIVILEGE REQUIREMENTS

Make sure to sign in with an account that has privileges to manage the AD FS farm.

In case of Windows Internal Database (WID) as the storage method for the AD FS Configuration database, sign in with an account that has local administrator privilege on the primary AD FS server.

How to change the Security Response Headers

There are five security headers of interest:

1. HTTP Strict-Transport-Security (HSTS)
   The HSTS reponse header indicates to the browser that HTTPS is available and should always be used. This way, the connection cannot be downgraded to HTTP for the time period defined. The recommended value is 31536000 seconds (1 year)
2. X-Frame-Options
   The X-Frame-Options response header defines the ways the AD FS sign-in experience can be a part of an iFrame. To prevent attacks, it shouldn’t be, so deny is the best option for this header.
3. X-XSS-Protection
   The X-XSS-Protection response header used to stop web pages from loading when cross-site scripting (XSS) attacks are detected by browsers. This is referred as XSS filtering. The value 1; block is the most effective, as the browser will not render the AD FS sign-in experience when an XSS attack is detected.
4. Cross-origin Resource Sharing (CORS)
   Web browsers prevent web pages from making cross-origin requests initiated from within scripts. This can be enabled to allow accessing resources in other origins (domains). CORS is disabled by default and should remain disabled.
5. Content-Security-Policy (CSP)
   The CSP response header is used to prevent cross-site scripting, clickjacking and other data injection attacks by preventing browsers from inadvertently executing malicious content.

The step to enabling the above security response headers is to run the following line of Windows PowerShell in an elevated PowerShell window:

Set-AdfsResponseHeaders -EnableResponseHeaders $true

It should be enabled by default, but if not, running the above line of Windows PowerShell sets the X-Frame-Options security response header to deny on Windows Server 2016.

Note:
On Windows Server 2019, it enables the other four security response headers, too.

Then, run the following four lines of Windows PowerShell in an elevated PowerShell window:

Set-AdfsResponseHeaders -SetHeaderName “Strict-Transport-Security” -SetHeaderValue “max-age31536000; includeSubDomains”

Set-AdfsResponseHeaders -SetHeaderName “X-Frame-Options” -SetHeaderValue “deny”

Set-AdfsResponseHeaders -SetHeaderName “X-XSS-Protection” -SetHeaderValue “1; mode=block”

Set-AdfsResponseHeaders -SetHeaderName “Content-Security-Policy” -SetHeaderValue “default-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’; img-src ‘self’ data:”

This will enable the above security response headers with the following settings:

AD FS uses JavaScript in the authentication process and therefore enables JavaScript by including ‘unsafe-inline’ and ‘unsafe-eval’ sources in default policy. While this is not the safest value for the Content Security Policy header, it’s needed to allow the onload.js script to run, to enable customizations of this Javascript and/or to replace the built-in Javascript to switch to the Paginated User Experience for AD FS.

Testing Security Response Headers

SecurityHeaders.com offers a great web interface to query the security response headers of your AD FS infrastructure.

Concluding

Deep in the basement of AD FS, a couple of values live, that true security admins will try to tame: security response headers. Use the information in this blogpost to tame these response headers and prevent common attacks against AD FS.

Further reading

Customize HTTP security response headers with AD FS 2019
An Introduction to HTTP Response Headers for Security
The 8 HTTP Security Headers Best Practices
HTTP Security Headers: 5 Headers You Must Implement on Your Site
Hardening your HTTP response headers

The post HOWTO: Change the Security Response Headers on AD FS appeared first on The things that are better left unspoken.