First, thanks Tom for your help with the several minor issues I've had during setup; It's thanks to you I've widdled things down to one remaining issue.
I've found something that I think is a possible bug in ISA...
It involves using a webserver on the local machine (unavoiadable in my situation). There are 2 IP's on the machine, on the same network adapter: 10.10.10.58, and 10.10.0.125. A host header called "webserve" points to the second IP.
When the proxy client is set up not to force authentication, everything works fine, and users can access the internal website by typing http://webserve in their browsers' address bars. But, I need to authenticate users so I set it (internal network) to force integrated authentication. When this happens, they are given the standard ISA URL denial screen.
After studying this problem using logging queries, I found a key difference in the way requests for the local machine are seen by ISA when using authentication vs. not using it.
When NOT using authentication, a user request for "http://webserve/websites" will show in the logs like this: - HTTP Allowed connection Accessrule1 Local Host GET http://10.10.0.125/websites
While WITH integrated auth forced it looks like this: - HTTP Denied connection (Blank under "rule" column) Local Host GET /websites
So, somehow when authentication is forced the IP is being stripped out of the request that ISA sees.
I have tried: * web listeners specifically for the host headers, per microsoft's site's instructions. * adding 10.10.0.125 and webserve to local lists to be bypassed
Should I open a case with Microsoft?
Thanks in advance
P.S. I heard the suggestion once that I should apply authentication via access rules but have not seen a way to do this.
[ August 09, 2004, 11:52 PM: Message edited by: Ross G ]
Just a quick tip here. You should not loop back through the ISA firewall for internal access. The users should connect directly to the Internal network server and bypass the ISA firewall to internal network resources.