'No, it doesn't do that..'
Today, a wise man reminded me of a fundamental truth: 'People just expect it to work'.
Unfortunately, the reason that there are people who specialize in certain areas is because, well, most of the time it doesn't just work. It takes a certain insight in the technical details of things to sort out that little glitch that doesn't 'just work'.
My phone rang at around 11ish. A colleague from HQ had an issue at a customer with ISA Server and wasn't able to pinpoint the problem. The situation was as follows:
A lovely shiny ISA 2006 server was installed at the site. Now, we all know that with ISA we can use AD groups to authenticate and naturally, the customer was eager to use this feature. So, off they went, creating an access rule that allowed a certain AD group to gain access to the wonders of the World Wide Web.
A client machine was hauled up the stairs (in a manner of speaking) and the first session was launched.
But what ho! No success.
So, like any good engineer, monitoring was done and logs examined. Apparently, the client built a SecureNAT session to the ISA which was immediately cut off. To further analyse the problem, the group All Users was placed in the rule instead of the AD group. Again, the session was fired up and.. what do you know.. it worked!
Anyone who has any affinity with ISA Server can spot the problem here. For those who cannot, allow me to fill in the gaps.
Requests made by a SecureNAT client have no way of authenticating themselves. As the traffic is basically just routed to the ISA Server (which functions as the default gateway) without additional information, authentication of any form is off the charts. So how does one make sure that these clients can still been given secure access without extra fuss ?
The answer to this is rather simple: Transform the SecureNAT client into a Web Proxy client.
(the exact nature of these requests is related to the Firewall Service and the HTTP redirector, the latter capable of doing hideous things to innocent packets. I'll write a more elaborate post on that in the near future).
To accomplish this, the client machine must have its browser configured to use the ISA Server as a proxy server (bypassing local addresses if required, which is often desirable). When done correctly, the following will happen:
The client will still send its request the old-fashioned way. When the request arrives at the ISA Server, it will be redirected to the Web Proxy Service (this is done for both SecureNAT and Firewall clients). The service will, at this point (provided that you have changed the access rule back to use an AD group and not anonymous), request the client to authenticate. In a plain SecureNAT situation, the client will be unable to do so. However, as the browser is configured as a Web Proxy client (which is a teeny bit more intelligent than SecureNAT), it is able to service this request. Authentication is sent to the service, which checks it against the rules in place and.. we're off!
Conclusion
When it comes to ISA Server, it is vital to have a decent understanding of how client requests are handled. What I recall from my Proxy and ISA exams is that most questions dealt with the configuration of the client and access rules, and for good reason. Despite what some people might say, the days that ISA Server 'just made things happen' (ISA 2000, anyone ?) are over and you will need to define both how requests are handled AND how requests are made from the client.
Epilogue
After discussing the situation with the customer, I advised them to configure the client's browsers as Web Proxy clients, briefly explaining how different requests are handled and why it did work with anonymous access and not with a group (with anonymous access, the web proxy service doesn't require authentication and therefore lets SecureNAT do its merry thing, building up a nice anonymous Web Proxy session). I got a call half an hour later that the situation now works perfectly, though they will have to examine how to deal with future scenarios, such as outside consultants needing access with the minimum amount of fuss and configuration. But hey, that is for another day.