5

Extended Protection (link) (link) is a feature in Windows 7 and Windows 2008 R2 that prevents certain MITM attacks.

Does anyone have a primer (or explanation in plain English) what this feature is, and if there are any other benefits besides MITM protection?

How do I audit, control and verify that my applications are using this technology?

Is there a way I can identify applications that are not using this technology, and report on them or administratively disable them?

Are there cases when Extended Protection is undesired, or otherwise incompatible?

2 Answers 2

7

Extended Protection is Microsoft’s implementation of Request For Comments (RFC) 5056, and it exists to verify the authenticity the transport layer in an Integrated Windows Authentication (IWA) exchange. Extended Protection does not provide any other documented features.

In an IWA exchange there are two channels created; an outer transport channel (TLS/SSL) and an inner authentication channel (Kerberos, Digest or NTLM).

Extended Protection checks that the outer channel that arrives at the server-side matches the outer channel opened on the client-side. The server verifies that the outer channel at the client-side matches based on information supplied by the client in the inner channel exchange. If the two channel ends do not match, the server rejects the client’s request.

The IWA authentication exchange is susceptible to a replay attack specifically “credential relaying” when Extended Protection is not used.

For Extended Protection to work

  1. Apply updates mentioned in KB973811 http://support.microsoft.com/?kbid=973811 as required.
  2. Set registry key for clients to enable opt-in functionality as specified here KB968389 (http://support.microsoft.com/kb/968389).
  3. Configure IIS 7.5, 7.0, 6.0 as specified in KB973917 (http://support.microsoft.com/kb/973917 or http://www.iis.net/ConfigReference/system.webServer/security/authentication/windowsAuthentication or http://blogs.technet.com/b/srd/archive/2009/12/08/extended-protection-for- authentication.aspx).
  4. Some changes to clients and server applications may be required as specified in here http://msdn.microsoft.com/en-us/library/dd639324.aspx if custom authentication mechanisms are used.

Controlling Extended Protection

Extended Protection operates in three modes Off (also referred to as Never), Accept (also referred to as WhenSupported) and Always. When set to Always Extended Protection is required for communications. When using this mode clients that do not support Extended Protection are rejected.

Client’s rejected by Extended Protection will log messages to a HttpListener trace If configured in applications for more information on how to do this see http://msdn.microsoft.com/en-us/library/ty48b824.aspx.

Support for Extended Protection

Not all situations support Extended Protection. If you are running end-to-end newer versions of Windows then Extended Protection is likely to be easy to deploy. If you are have a mixed environment with Kerberos or NTLM through non-Windows proxy servers or delegates your implementation may require more work.

Third-party browsers that are not based .NET or Internet Explorer (such as Chrome and Firefox, Safari) will generally not support Extended Protection even though they may support IWA. This may be an issue if you need to interoperate with systems outside your corporate network or your corporate network uses a mix of browsers.

2
  • 1
    As of 2015.02.22, Extended Protection is not supported by Chrome. So if it's on, Chrome cannot be used to login to a Windows server that uses Extended Protection. Whether that's a bug or feature is up to you....
    – Larry K
    Commented Feb 22, 2015 at 13:43
  • @LarryK Good point, added that one in. Commented Feb 22, 2015 at 21:59
1

The most recent stable version of Chrome (Version 51.0.2704.84) now support extended protection and the SSO experience is similar to IE

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .