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


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:  http://mail.contoso.com/exchweb/bin/auth/owalogon.asp?url=http://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


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


10.20.20.1    10.20.20.10    HTTP  HTTP:Request, GET /Exchange


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


10.20.20.1    10.20.20.10    HTTP  HTTP:Request, GET /Exchange


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


10.20.20.1    10.20.20.10    HTTP  HTTP:Request, GET /Exchange


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


10.20.20.1    10.20.20.10    HTTP  HTTP:Request, GET /Exchange


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


10.20.20.1    10.20.20.10    HTTP  HTTP:Request, GET /Exchange


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


 


 


4. The Resolution


 


After researching more and more I found that the conditions for this problem were perfectly matching with KB935206. Not only the conditions but also the symptoms were similar. The solution was exactly that! Read KB935206 to better understand the resolution (and the cause) before apply it and notice that the hotfix itself doesn’t fix the problem; you have to run the script to make it happen.

Comments (0)

Skip to main content