From: Seattle, Washington
We have a customized portal environment for our users, using ISA 2004 to do web publishing. As we do not want clear text passwords traversing the Internet, and we donĂt want to run everything under SSL, the connection between the userĂs browser and ISA requires digest mode authentication. Since ISA 2004 does not allow the credentials from the incoming request to be passed along to the published web servers using basic mode authentication, we have installed a custom web filter. When the web filter receives the incoming request, it takes the user name and looks it up in a database, retrieves the password and populates the header with basic mode authentication credentials. These credentials are then used by ISA when accessing the internal web servers. To reduce the number of database calls the filter makes to grab the userĂs password, once it has made the call, it places the user name and password in its own personal cache. On susequant requests the web filter checks its cache for the password, converts the request and passes it on for use by ISA. Everything so far works flawlessly.
Password management for the user is another issue. When a userĂs password is about to expire (14 days before the 45 day limit) the user is prompted to change their password. If they select to change their password (or it has already expired), they are presented with a custom change password ASP page. The code on this page updates the database and then sends a call to the web filter on the ISA server to clear its cache for the user changing their password. In ISA 2000, all we needed for this to work was a listener on port 80 on the internal interface. In ISA 2004 however, I can not gets things to work properly. I have configured a web listener on port 80 and the internal interface, just like we did on ISA 2000. It doesnĂt work as it appears a listener has to be tied to a web publishing rule to be effective. I then created a web publishing rule to take request on address 10.0.0.1 port 80 and send them to 10.0.0.1 port 80. In this configuration the web filter does appear to clear the cache entry but does not reply with a status 200 to the calling server. It sends back a 500 with a ˘proxy chain loop error detected÷ error. I understand the loop error since I am listening on an interface and then taking the request and sending it to the same interface. I just canĂt figure out how to get the request to the filter with any other configuration. I have tried a plain vanilla access rule with every port allowed and that doesnĂt work either as it isnĂt tied to the web listener.
I have been working on this for a couple of weeks and asking anyone with any ideas to toss them out. Without this solution in place I can not roll out ISA 2004 for our portal.