How to enable epa in iis?
The
Extended protection enhances the existing Windows authentication functionality in order to mitigate authentication relay or "man in the middle" attacks. This mitigation is accomplished by using security information that is implemented through two security mechanisms:
The
There are two attributes of the
Consider the following example scenarios:
More information about Extended Protection is available in the following topic:
The default installation of IIS 7 and later does not include the Windows authentication role service. To use Windows authentication on IIS, you must install the role service, disable Anonymous authentication for your Web site or application, and then enable Windows authentication for the site or application.
The
The following sample displays a
The following examples demonstrate configuring Windows authentication with extended protection for the Default Web Site, and adds two SPN entries to the collection of SPNs.
- Open Control Panel and click Programs and Features > Turn Windows features on or off.
- Enable Internet Information Services.
- Expand the Internet Information Services feature and verify that the web server components listed in the next section are enabled.
- Click OK.
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 extended protection for authentication feature with AD FS.
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).
To help secure your Hybrid Identity deployments, you can set and use the extended protection for authentication feature with AD FS. This setting specifies the level of extended protection for authentication supported by the AD FS servers in the farm.
Extended protection for authentication helps protect against Man-in-the-Middle (MitM) attacks. In this type of attack, a malicious person intercepts client credentials and forwards them to a server. Protection against such attacks is made possible through a Channel Binding Token (CBT) which can be either required, allowed, or not required by the server when it establishes communications with clients.
Extended Protection for Authentication aims to prevent this type of credential relay. It does this by implementing a protocol based on RFC5056 “On the Use of Channel Bindings to Secure Channels”.
When the client doesn’t support the Channel Binding Token (CBT), the authentication will fail. As Windows Authentication is the first negotiated authentication methods for the intranet, clients will use this authentication method by default. When this type of authentication fails, the client may resort to other authentication methods, like Forms authentication, Certificate authentication, Device authentication or Microsoft Passport authentication, if enabled.
Note: By default, Forms authentication, Windows Authentication and Microsoft Passport authentication are enabled as authentication methods for the intranet on Windows Server 2016-based AD FS farms.
Windows 7 and up, and Windows Server 2008 R2 and up support the feature and have the feature enabled, by default. However, older Windows clients, that have not received KB968389, do not support the feature.
Chrome browser versions below version 51 .0.2784 (released on January 24th, 2017) and Firefox don’t support the Extended Protection for Authentication feature.
To enable the Extended Protection for Authentication feature, make sure to meet the following requirements:
If you expect clients to fail integrated Windows authentication when you enable the Extended Protection for Authentication feature, it is wise to assess the impact clearly. You can do so with a test Windows Server that runs Internet Information Services (IIS) version 7.5 or up, and configure it with Extended Protection for Authentication using the steps described here.
The information gathered this way clearly defines the scope and impact. Then, an informed choice can be made to enable and it, or not.
Make sure the AD FS servers are installed with the latest cumulative Windows Updates.
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.
As the AD FS servers operate as part of a chain, notify all stakeholders in the chain. This means sending a heads-up to the load balancer guys and gals, the networking guys and gals, the rest of the Active Directory team and the teams that are responsible for Azure AD, Office 365 and cloud applications. It’s also a good idea to talk to the people responsible for backups, restores and disaster recovery.
As the Extended Protection for Authentication feature is an AD FS feature that mainly impacts client systems, go and have a chat with the people responsible for managing workstations in the organization. Do they see the same things in terms of scope and impact?
When all stakeholders are informed and the organization is in agreement that the Extended Protection for Authentication feature adds value, perform these steps:
Check the Extended Protection for Authentication feature status by running the following line of Windows PowerShell:
Get-ADFSProperties | Select ExtendedProtectionTokenCheck
On an AD FS farm running Windows Server 2016 and/or Windows Server 2019 AD FS servers with default settings, the above line of Windows PowerShell would return Allow.
This means the AD FS server in the farm are partially hardened, because the Extended Protection for Authentication is enforced only when clients have been patched to support it.
To fully harden the AD FS Farm, set the Extended Protection for Authentication feature to Require, use the following line of PowerShell on an elevated Windows PowerShell prompt:
Set-ADFSProperties –ExtendedProtectionTokenCheck Require
After enabling the Extended Protection for Authentication feature, it’s time to test. Everyone involved should sign off (not literally, unless that’s procedure) on the correct working of the AD FS servers. Does authentication to cloud applications still work? Is the user experience on down-level clients and non-Microsoft browsers still adequate?
In the case of the Extended Protection for Authentication feature, this security feature can stand in the way of user satisfaction. If so, you might need to roll it back.
To roll-back the AD FS Farm in terms of the Extended Protection for Authentication feature, use the following line of PowerShell on an elevated Windows PowerShell prompt:
Set-ADFSProperties –ExtendedProtectionTokenCheck Allow
Windows Server 2016, by default, comes with the Extended Protection for Authentication feature enabled, but not fully hardened. Configure Extended Protection for Authentication to Require to get the most out of it.
Related Questions
- Sgx disabled by bios?
- How to convert wav to mp3 windows?
- How to mac screen record?
- How to convert tph to tps?
- How to prep for hysterectomy?
- How to change pokemon in legends arceus?
- How to build a sbc for boost?
- How to connect cdj to laptop?
- How to calculate cubic inches for shipping?
- How to create textures for daz studio?