The Case of Eternal Loop while Publishing OWA through ISA Server 2006

Article
02/25/2009

1. Introduction

This post is about a very interesting case that I worked this week, the initial scenario was:

· ISA Server 2004 Publishing OWA

· FBA Enabled on Exchange Server

· ISA Server using RSASecurID as authentication on the Web Listener

On this particular scenario we were doing “two factor authentication”, first using RSASecurID and second using FBA on CAS as explained below:

Figure 1 – How the scenario was setup

This whole scenario was working fine until they change from ISA Server 2004 to ISA Server 2006.

2. The Issue

After replacing the ISA Server 2004 to ISA Server 2006 the following behavior was notice:

· If we try to access https://mail.contoso.com/owa it works just fine. We had the RSA screen first and then the OWA FBA Page that was coming from CAS Server.

· If we try to access https://mail.contoso.com/exchange we got the RSA page, authenticate but then instead of receiving the OWA FBA page we got a blank page. Internet Explorer appears to be processing something in background but never opens the page.

The reason why we needed to use the “/exchange” in the OWA URL is because there is still some user’s mailbox that were residing on Exchange 2000 Back End Server. For backward compatibility Exchange 2007 keeps /exchange, /public and /exchweb virtual directories to allow users in this scenario to access their mailbox through OWA. When you have FBA enabled on the /exchange folder, what happens is that the request will be redirect to /exchweb since it is in there that the forms reside.

Interesting facts:

· ISA Monitoring / Logging not showing any error or deny, all the communication was green and flowing normally.

· If we try to connect from inside (bypassing ISA) it works fine.

· If we change the authentication method on the /exchange folder for basic instead of FBA it works. In this case the second authentication (after the RSA) is a prompt (since is basic) so the user can type his credential.

With that we had the following component as main suspicious at that time:

· Folders /exchange and /exchweb on CAS Server were having some type of issue when the traffic was coming from outside (passing through ISA) since internally was working fine.

At that point I engaged an Exchange Team to validate the settings for those virtual directories. My friend Vandy Rodrigues, from the Exchange CSI Team started to review that.

3. The Eternal Loop

After reviewing the whole configuration, validated all the settings, permissions and everything he told me: Yuri, all the Exchange settings are clear, no errors. What should I say to him at that point? Nothing more than: Roger that buddy!

Moving further in the collaboration we got a netmon trace in the CAS Server while client was trying to perform the logon to https://mail.contoso.com/exchange. The result was a beautiful eternal loop, check this out:

ISA Sends the GET Request to the CAS Server:

10.20.20.1 10.20.20.10 HTTP HTTP:Request, GET /exchange

- Http: Request, GET /exchange

Command: GET

+ URI: /exchange

ProtocolVersion: HTTP/1.1

Reverse-Via: ISACONTOSO

Host: mail.contoso.com:443

Accept-Encoding: gzip, deflate

UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;.NET CLR 1.1.4322)

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/x-shockwave-flash, */*

Accept-Language: en-us

Connection: Keep-Alive

Front-End-Https: On

HeaderEnd: CRLF

The CAS Server sends the 302 Redirects saying that the request needs to go to /exchweb:

10.20.20.10 10.20.20.1 HTTP HTTP:Response, HTTP/1.1, Status Code = 302, URL: /exchange

- Http: Response, HTTP/1.1, Status Code = 302, URL: /exchange

ProtocolVersion: HTTP/1.1

StatusCode: 302, Moved temporarily

Reason: Moved Temporarily

Location: https://mail.contoso.com/exchweb/bin/auth/owalogon.asp?url=https://mail.contoso.com/exchange&reason=0&replaceCurrent=1

Set-Cookie: sessionid=; path=/; expires=Thu, 01-Jan-1999 00:00:00 GMT

Set-Cookie: cadata=; path=/; expires=Thu, 01-Jan-1999 00:00:00 GMT

Connection: close

ContentLength: 0

HeaderEnd: CRLF

…and this GET and Redirect keeps going on and on forever:

10.20.20.1 10.20.20.10 HTTP HTTP:Request, GET /Exchange