So I was actually in the United States for a couple of days last week and decided to get the long overdue ISA server running at home. After all, how hard could this be? In ISA 2004, with the new “firewall configuration by cartoon” interface, you just pick the cartoon that looks most like your network. Heck, since I have SBS, it actually clicks the right cartoon for you.
And what was the reason for this excursion you might ask? Why not spend the time with kids, or whisky, or maybe both, instead? Well, part of me just wants to learn more about ISA. Part of me is mostly interested in blocking my 7-year olds administrative account from surfing the web. You see, he needs to have an administrative account because of all the bad software out there that won’t run as a regular user. To manage that I gave him two accounts, one that is a local administrator and one that is not. Then I am now trying to block the one that is a local admin from surfing the web. I actually think this is a very useful thing to do. One of the major ways malware gets installed is when well-meaning people who surf the web with too high privileges accidentally or intentionally click the wrong button. If we can keep them from surfing the web using privileged accounts we can stop much of the malware right there. ISA server has the ability to do this because it has the ability to identify users. This is one of those very useful things that not many firewalls allow you to do. However, it turned out to be a little trickier than I thought, so I figured it would make sense to tell people about some of the problems I encountered and how I solved it.
Theoretically, all this should be simple. You install SBS, then install ISA from the SBS Premium Technologies disk. The installer will create the “SBS Internet Users Group” and you just remove the users you want to block from the web from that group. If only things were so easy. Once you start restricting things like this SecureNAT clients (clients without the ISA client, or clients with the ISA client that can’t authenticate to the domain) can no longer connect anywhere. This happens because the SBS Internet Users Group needs to replace All Users in the outbound web rule. Once it does that, you must authenticate to connect out. Otherwise you are anonymous and it does not work. SecureNAT clients do not authenticate. This causes a major problem with my work laptop since it cannot be a domain member (it is already a domain member elswhere) and hence cannot authenticate out.
To solve that Chad Gross suggested setting up DHCP reservations for the laptop and setting up an ISA rule and allow those addresses to connect out. (Susan Bradley suggested ditching ISA, but what would be the fun in that?) Kind of cumbersome, but it works. Thanks Chad!
The next thing I notice is that my FrontPage webs do not work. I host a few of them and now I could not get to any of them via FrontPage. This caused a huge problem for my wife because she hosts all the pictures on her blog on one of them and of course it was a critical business requirement to be able to upload new ones immediately. The oddest part was that they work from my work laptop when I am VPNd into work. Checking the ISA logs I see requests for http://<IP address>/_vti_bin/_vti_aut/author.dll which are blocked. That’s odd, but explains why they are blocked, or do not work. If they do not have the right host headers the IIS server won’t find them. I fire up netmon, however, and don’t see them at all. Even stranger.
To figure out what was going on I set up a temporary rule to allow one of my internal machines to send http to anyone, all networks. Now it works and of course ISA shows that it is the new rule that is letting the traffic through. Going to netmon I don’t see anything on the external interface. Going to the internal interface, however, I see a very standard request from my internal client to the local machine, using the proper host header. The only thing I can think of is that ISA gets paranoid. Basically, there is a request here to the external address, but it is coming from the inside. That can’t be good, let’s block it. But why? The key was in the logs really. The request was anonymous. I had the firewall client turned off on that machine. I also had that rule that blocked certain users from getting to the Internet (no local admins are allowed to surf the web). Since the firewall client was disabled, the user was anonymous and ISA blocked it. Turn on the firewall client and now it can get there.
It looks like the magic combination was the override rule for the corp laptop that Chad suggested, and ensure the firewall client is on. If you also have a need to allow non-domain members out you need exception rules for those. I also have to add “All Users” to the SBS Internet Access Rule” for the same reason. Once I do that, everything seems to work, but there are a lot of magic rules that need to be there.
ISA is doing exactly the right thing here. The problem exists, as usual, between the chair and keyboard (PEBCAK). The trick is to use a judicious combination of Network Monitor and ISAs log, pay particular attention to who is making the requests, and really analyze the impact of all the rules. Keep in mind that if any of the rules apply to anything other than “all users” you must have a firewall client or an override rule to get through.