The authentication methods allowed for the Web Proxy clients are a property of the Networks (Web Proxy tab). Therefore, that property is bound to an interface adapter and the allowed authentication method applies to all subnets reachable through that interface.
From: So cal
I hope you can help me solve this problem i am havig with my isa 2004 server.
My server is also a VPN server for remote usres. I have configured an allow all rule for all protocols and to all destinations and i ahve applied this rule to all users.
Now i am trying to block all protocols and sites and apply this rule to a windows AD group, but when i aply the rule user who VPN into the network are unable to access our CRM server on the internal network, as soon as i disable the rule access is restored. I have alos tried making acceptions on the rule for VPN, and local host, but i still get the same problem.
P.s I have moved the denay rule above the allow all rule.
I am trying to change the http filtering to enable our MS Sharepoint portail to work properly. The problem is that the "Configure HTTP" option is NOT visible when I right click on a firewall rule. I have read that web proxy must be enabled but that is already enabled on the firewall.
I searched everywhere and I could not find an explanation why this is not visible on my isa server 2004. I have another firewall in another office and that option is visible...
Did you create a custom protocol for HTTP and specify it in the rule?
The only time I have seen this is when a custom protocol has been created and the admin didn't associate the Protocol with the Web Proxy filter, or the admin has dis-associated the Web Proxy filter from the HTTP protocol definition.
In the main Firewall Policy screen, in the Protocols column of the rule you're trying to configure, double click on the HTTP protocol and you should get a General and Parameters screen for the protocol itself - on the Parameters tab under Application Filters, is Web Proxy enabled?
I encountered the problem "proxy chain loop" and the workaround described at "http://www.microsoft.com/technet/isa/2004/plan/ts_proxy_traffic.mspx#traffic" did work for me. But I still not understand the reason to "Add a deny rule from the Local Host network to the External network for HTTP, and set it as the second rule", and according to what you said, that rule seems to be unreachable. :-(
How does this work with Enterprise & Array rules? I'm a newbie to ISA EE, though not to SE. What I'm finding so far is that post-array rules are not being processed.
Summary: My rules are all "Allow" Access rules and Publishing rules, all duplicated from the existing (and working) ISA 2004 SE config. Some are anonymous, some authenticated. Since Publishing rules must be Array rules, I've had to disregard your first "Best Practice" recommendation, but that aside, I've arranged it as follows:
Enterprise Access rules, anonymous
Array Publishing rules
Array Access rules, anonymous
Array Access rules, authenticated
Enterprise Access rules, authenticated
What I've found from the ISA log is that the only post-array rule applied is the Enterprise default rule, so access for those rules is denied. If I move a post-array rule to become a pre-array rule, it starts working. This is true even when there are no array rules that match the connection attempt.
It's always puzzled me that it was there, but without any other EE experience to know it didn't belong there, or other EE machines to compare it to, I figured ISA just ignored it. I didn't realize I was the one who put it there.
I found this screen shot in another ISAServer.org article which confirms there is not supposed to be a default deny rule in the Firewall Policy Rules. (Presumably the "All Open" rule isn't normally found there, either!)
Last Enterprise Default Rule should be the only Default Rule. That makes sense, and explains my problem.
Looking at the XML, it looks like the read-only attribute is easy to flip. Hopefully I can export, edit, and import the Array Default Rule. Then delete the rule. Worst case is export the whole EE config to XML, edit the XML to remove the Default Rule, uninstall/reinstall ISA, and import the modified XML. The server's not in production yet so that's not a big deal.
This is a BIG gotcha for using that article to move from ISA SE to ISA EE: I know now I should have exported the rules one at a time, omitting the default rule, or else edited the "all rules" export to remove SE's Default Rule before importing to EE.
(Or do it Microsoft's way, from scratch, where I'd still be manually re-creating Rules and Elements for another week before I'd be able to try it! They really need to work on making ISA SE to EE upgrades efficient.)
[Edit] Yup...that was it. So this question turned out to be off-topic; sorry! To bring it back on-topic, the order I showed in my first post was correct. The Default Rule at the Array level was the problem.
Interestingly, ISA Logging identified it as the Enterprise-level Default Rule. That's part of what threw me off. Evidently this was a scenario Microsoft (reasonably) did not anticipate! Their logic: If a Default Rule is used, it must be the Enterprise default rule because there isn't one at the array level, so that's how we'll display it.
< Message edited by JeffVandervoort -- 19.Oct.2007 11:28:39 AM >