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

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: However, you expect ISA Server to prevent the user from changing "HTTPS" to "HTTP" in step 4.

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.

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

To work around this problem, follow these steps:

1. Split the combination (HTTP/HTTPS) Web listener into two separate listeners. Configure one of them for HTTP and the other for HTTPS.
2. 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.

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

For more information about software update terminology, click the following article number to view the article in the Microsoft Knowledge Base: