Select the product you need help with

FIX: Users can unexpectedly bypass the ISA Server 2006 redirection rule for HTTPS when they try to access Outlook Web Access

Article ID: 958607 - View products that this article applies to.

Expand all | Collapse all

SYMPTOMS

Consider the following scenario:

You use Microsoft Internet Security and Acceleration (ISA) Server 2006 to publish a Microsoft Exchange Outlook Web Access (OWA) server.
The relevant Web listener is configured to accept both HTTP and HTTPS connections.
The relevant Web listener is also configured to redirect all HTTP connections to HTTPS connections.
A user performs the following procedure:
1. The user connects to the OWA site by using the following URL:
  http://<FQDN>/owa
  Note The <FQDN> placeholder represents the fully qualified domain name (FQDN) of the Exchange server.
  
  ISA Server sends an HTTP 302 response that includes the following HTTPS URL instead of an HTTP URL:
  https://<FQDN>/owa
2. The browser connects to the HTTPS side of the Web listener and then issues a "GET /owa" request.
3. ISA Server sends a response that includes the Forms Based Authentication (FBA) page through the HTTPS connection, and then ISA Server assigns a cookie for this session.
4. The user edits the URL in the browser to delete the "s" from the protocol, and then the user clicks Go or presses ENTER. For example, the user changes the URL from "https://<FQDN>/cookieauth.dll?<parameters>" to "http://<FQDN>/cookieauth.dll?<parameters>."
5. The browser issues a "GET /cookieauth.dll" request through the HTTP connection. This request includes the cookie that was assigned in step 3.
6. ISA Server sends a response that includes the FBA page over the HTTP connection.
7. The user enters the credentials and clicks Log On. The user’s credentials are sent over the HTTP connection.

If the user is successfully authenticated in this scenario, ISA Server redirects the browser to the following URL:

https://<FQDN>/owa

However, you expect ISA Server to prevent the user from changing "HTTPS" to "HTTP" in step 4.

Back to the top | Give Feedback

When ISA Server sends the HTTP 302 response in step 1, neither ISA Server nor the browser closes the HTTP connection. In step 5, the browser issues the "GET /cookieauth.dll" request through the existing HTTP connection, and the request includes a cookie that ISA Server has assigned for this session. Therefore, ISA Server recognizes the session as a pre-existing session and responds to the request by issuing the FBA page.

Back to the top | Give Feedback

RESOLUTION

To resolve this problem, apply the hotfix that is mentioned in the following Microsoft Knowledge Base article:

960148

(http://support.microsoft.com/kb/960148/ )

Description of the ISA Server 2006 hotfix package: November 19, 2008

Back to the top | Give Feedback

WORKAROUND

To work around this problem, follow these steps:

Split the combination (HTTP/HTTPS) Web listener into two separate listeners. Configure one of them for HTTP and the other for HTTPS.
Create a Web publishing rule, and configure it as follows:
Name = OWA redirect
Action = Deny
Redirect HTTP requests to this Web page: https://<FQDN>/owa
Public name = <FQDN>
Paths = /owa/*, /clientauth.*
Listener = HTTP only
When the user tries to change the URL (as in step 4) after you apply this Web publishing rule, ISA Server redirects the HTTP request back to HTTPS.

Back to the top | Give Feedback