When using KCD users always get presented with the Forms-Based Authentication page from Exchange for OWA and ECP

In certain situations when attempting configuring ESP for OWA or ECP access in Exchange (Edge Security Pack) and KCD (Kerberos Constrained Delegation) is set as the Server Side Authentication Protocol a user will always be presented with the Exchange Forms-Based Authentication (FBA) Page despite the fact that the client was able to successfully generate a KCD ticket.

This article cover the steps required to resolve the issue server side on the Exchange Server.

Product: LoadMaster

Version: Any

Platform: Any

Application: Exchange OWA, Exchange ECP

When attempting to do KCD server side for access to exchange OWA and ECP virtual Services the client is always presented with the Exchange Forms Based Authentication page.

Windows Integrated Authentication (WIA) has been enabled using the Exchange UI but clients are still being presented with FBA.

FBA has been disabled on the Exchange Server using the Exchange UI but clients are still seeing a FBA login page.

This issue is a server side problem that is to do with the Exchange Server and a stuck process on the Exchange Server. To Resolve this issue the Exchange server needs to have FBA disabled manually using the PowerShell command line and then have WIA enabled manually afterwards.

After the changes have been completed an IIS Reset will need to be preformed on the Exchange Server in order for the changes to take affect.

This is an issue with the Exchange Server and is unrelated to the LoadMaster Operating System or configuration. 

To resolve the issue we had to run the following command directly on the Exchange server:
 
To work around this issue, make sure that to specify -FormsAuthentication $false when disabling FBA and enabling other authentication types in the OWA or ECP virtual directories. To do this, follow these steps:
 
Enable forms-based authentication.
 

• For OWA, run the following command:

Set-OwaVirtualDirectory -Identity "CAS1\owa (Default Web Site)" -FormsAuthentication $True

• For ECP, run the following command:

Set-ECPVirtualDirectory -Identity "CAS1\ECP (Default Web Site)" -FormsAuthentication $True

 
Enable the desired Authentication types, and specify -FormsAuthentication $false.
 

• For OWA, run the following command:

Set-OwaVirtualDirectory -Identity "CAS1\owa (Default Web Site)" -FormsAuthentication $False -WindowsAuthentication $true -BasicAuthentication $true

• For ECP, run the following command:

Set-ECPVirtualDirectory -Identity "CAS1\ECP (Default Web Site)" -FormsAuthentication $False -WindowsAuthentication $True -BasicAuthentication $True

After the mentioned commands have been run on the affected Exchange Server ensure that an IIS Reset is performed before proceeding with another Authentication test.

IMPORTANT NOTE: All configuration changes that are to take place in production environments should be carried out outside peek production hours or during a scheduled maintenance window when possible in order to minimize disruption and impact to production traffic.

Configuration changes to either the LoadMaster or in this case Real Server should be carried out outside of production hours.

For further details please refer to the Microsoft Documentation which has been appended to the "Note" section of this article.

Users always get the FBA page when they access OWA or ECP in Exchange Server:

Users always get the FBA page when they access OWA or ECP in Exchange Server 2013 - Microsoft Support

How to Restart IIS:

How to Restart IIS | Microsoft Learn