This is the notice we received in regards to our site:Outlook Web Access (OWA) 2003 is vulnerable to an attack in which a client's browser can be tricked into redirecting to another site after the user clicks theLogOn button. The attack is performed by getting the client to follow a link to "owalogon.asp" that has the "url" parameter set to a URL of the attacker's chosing(ex http://yourwebsite/exchweb/bin/auth/owalogon.asp?url=http://[attackerdomain].com). This could allow an attacker to redirect the client's browser to a maliciouswebsite. Please note that the severity of this vulnerability has been escalated in accordance with the National Vulnerability Database CVSS score.This was their correction:Remediation Action: A manual workaround can be implemented by the system administrator to remove the capability for users to provide a redirect URL via theFBA (Form Based Authentication) QueryString: 1. Navigate to 'C:\Program Files\Exchsrvr\exchweb\bin\auth\usa' 2. Backup logon.asp 3. Edit logon.asp 4. Editthe redirectPath variable on line 54 to your desired path. In the case of Microsoft's OWA servers it should look similar to the following example: redirectPath ="http://email.yoursite.com/exchange/" 5. Close and save logon.asp 6. Modify and use the URL below to verify that arbitrary redirection has been disabled. If theworkaround was successful you should not be redirected to phishersite.com. http://email.yoursite.com/exchweb/bin/auth/owalogon.asp?url=http://phishersite.com/Manually editing the destination/redirect URL prevents users from being able to navigate directly to mapped virtual directories on the OWA server. If thisfunctionality is required, step 4 could be modified to only allow a virtual directory to be passed by adding the protocol and host name before allowing the 'url'parameter to be concatenated. As with any workaround these steps should be thoroughly tested for your particular setup prior to going live in a production system.I have applied this fix and we passed; however, now when we go to login we were using the authenticated forms and it was working fine and now since we have applied this fix we now receive the kerberos login prompt; what can I do to clean this up and return it back to how end users were able log on before the change was made.Is this possible?

Hi, On my lab, after applying the hotfix, I am able to authenticate to my Exchange server and access OWA with no problem by using Form Based authentication. Would you please capture a screenshot to me (v-mishen@microsoft.com) when the Kerberos login prompt is received? In addition, would you please let me know your topology? Whether is it Front End/Back End topology or single server topology? Thanks, Mike