ISA 2000: Handling Apps That Don't Like Proxy Authentication

  • Article

Quite often, we're faced with a situation where an application has its own Web Proxy client mechanism, and that mechanism has various issues, like:

  • It doesn't support NTLM authentication, and only NTLM is enabled on the ISA Server
  • It doesn't support more than one Proxy-Authenticate header
  • It doesn't support proxy authentication at all (a 407 response kills it)

There are a few methods that can be used to work around the issues above which I'll go through, starting with…

 

Avoiding The Whole Issue With The Firewall Client

Configure a given application to not use a proxy at all, and use the Firewall Client. This generally works best on client machines, and where the port involved isn't a standard HTTP port (for example, java applets that connect to ports other than 80).

 

The problem with the Firewall Client approach (and it may not be a problem for you) is that by default, the ISA HTTP Redirector Filter intercepts firewall client requests, forwards them to the Web Proxy service, but doesn't supply any credentials when doing so. Best-case, your application gets unauthenticated web access. Worst-case, your app fails because of your Site and Content ruleset.

 

Disabling the HTTP Redirector Filter (it's an Application Filter) means that Firewall and SecureNAT clients can connect directly to the target server if the rules permit it - Firewall clients will be able to authenticate transparently, without the application being challenged or otherwise bothered.

 

If the HTTP Redirector filter is disabled, you lose transparent caching of web requests, but most will be configured to use the Web Proxy anyway, right? You'll also need to look in the FWSEXT (Firewall service) logs, rather than the WEBEXT (Web Proxy service) logs to see the client traffic.

 

This is mainly useful for client applications, but can be applied to servers if really necessary.

 

 

Applications That Speak Only Basic Authentication

 

If you're having authentication problems with an application that supports the use of a proxy server, chances are it fits into this category.

 

ISA 2000 comes configured out-of-the-box to offer only NTLM authentication to Web Proxy clients, which means that this type of application won't be able to traverse the proxy.

 

Enabling Basic authentication is simple - just enable it in the properties of the Outgoing Web Requests listener.

 

Now, this means that the credentials used by the application are being sent in near-to-plaintext over the network, which is usually undesirable.

 

If you're in this category, you might want to consider using the Firewall client if it's a client application, or (more useful for server applications) creating an IPSec policy that encrypts communications between the application and the proxy; something like "TCP traffic destined for port 8080 on <ISA Server internal IP> from <application server>", and apply the policy to the ISA Server and the Application Server.

 

 

Applications That Don't Support Multiple Proxy-Authenticate Headers

 

Rarer - IIRC, older versions of the Sun JVM used to do this before they spoke NTLM.

 

This is more or less the same as the suggestion for the Basic set above, except that it's mandatory to add another internal IP address and listener for these applications, because having more than one authentication option ticked breaks the application.

 

So, you create a new IP for the internal interface, enable only Basic authentication for this  IP address in Outgoing Web Requests, and configure only this client application to use the new IP address (give it a different CNAME, like BASICPROXY, perhaps…).

 

 

Applications That Don't Understand Proxy Authentication

(AKA how to turn off authentication for certain sites but retain authentication for others).

 

ISA uses what I call the "law of least effort", which translates to applications finding the laziest possible path through the ISA Server's rule set.

 

If you have an application that just can't handle proxy authentication, you can configure your proxy rules to allow anybody going to that destination to do so anonymously.

 

To do this, there are a couple of prerequisites:

  • Your Outgoing Web Listener must be configured not to ask users for authentication. If authentication is required, make it part of the Site and Content rules that apply to clients.
  • The applicable Protocol Rule must allow All Requests or use a Client Address Set, but not use user-based authentication.

To look at a simple example, here's how you'd configure unauthenticated access to www.BarryIsGood.dom (in a destination set called "Unauthenticated Sites") while requiring authentication for all other sites:

 

Site and Content Rules:
Allow <Domain Users> <Anywhere> Anytime
Allow <Anyone> <Destination Set: Unauthenticated Sites> Anytime

 

Protocol Rules:
Allow <Anyone> <HTTP> Anytime

 

And that's it. Destination sets can be locked down to the point where only a certain part of a path can be accessed, so if you know the specific URL being accessed at the target site, you can restrict it using the Dest Set.

 

Web Proxy clients always try to get to sites anonymously, making a simple GET request for the target site. ISA then checks to see if a user is allowed to get there anonymously, and if so, stops processing rules and executes the request.

 

Using the rules above, if someone were to type in "www.barryisgood.dom", the rule processing would look like this:

 

Client Request: GET www.barryisgood.dom /

ISA processing: Is <anyone> allowed to use HTTP? Yes
ISA processing: Is <anyone> allowed to get to www.barryisgood.dom ? Yes

ISA Response to client: 200 page contents from barryisgood.dom .

 

If the same person were to type in "www.authenticateddomain.dom" (which isn't part of the Unauthenticated Sites destination set):

 

Client Request: GET www.authenticateddomain.dom /

ISA processing: Is <anyone> allowed to use HTTP? Yes
ISA processing: Is <anyone> allowed to get to www.authenticateddomain.dom ? Not without authenticating.

ISA Response to client: 407 Proxy Authentication Required

 

If the "Ask users for authentication" tickbox had been enabled, the 407 would have immediately followed the client request, which would break the scenario for someone getting to barryisgood.dom without needing to supply credentials.

 

It's a solution I've used for a few similar issues in the past, and it seems to work pretty well…

 

Comments? Questions? Leave them below...