In your book on page 775 about RADIUS you write "We prefer not to join the front-end firewall to the user domain". Is this "old school" or does your arguments in this article distinguish between front-end and back-end ISA servers?
No, I still don't see any reason to join the front-end ISA Firewall to the domain, since I'm using it for mostly stateful packet inspection and some app layer inspection, but not using it for pre-authentication.
Hi, I just read the article. I have ISA running as a workgroup member (in my domain). Are there any issues I have to consider before I add the ISA server to the domain? ISA is very basically configured (HTTP out, SMTP in/out for Exchange). Thanks Thomas
Sorry, I see, it was not very clear: ISA is in WORKGROUP. 3 Computers in Domain A, 1 Server in Domain A. Internet traffic: Workstation / Server (in Domain A) to ISA Firewall (in WORKGROUP) to ADSL Modem/Firewall. Thanks and sorry again...
The only thing to watch out for is the possible effects of domain Group Policy. You might want to create your own OU for the ISA Firewall and prevent the default domain GPO and any other GPOs from being applied to the ISA Firewall's OU, then create a custom GPO for the ISA Firewall's OU.
Thanks for the quick reply Tom. I need to work on this server tomorrow so please help to clear the below question.
As of right now my ISA is a domain member (ISA 2004 EE). I want to make it ISA 2004 SE or ISA 2006 SE.
1)In a single ISA Firewall environment, ALWAYS make the ISA Firewall a domain member. This is the most secure configuration. What's the article I need to follow to harden ISA Box? I have already followed instruction from your book which talks about TCP/IP properties. What else I need to do?
2)Can I backup configuration and uninstall ISA 2004 EE than re-install ISA 2004 SE or 2006 SE and import configuration?
1)In a single ISA Firewall environment, ALWAYS make the ISA Firewall a domain member. This is the most secure configuration. What's the article I need to follow to harden ISA Box? I have already followed instruction from your book which talks about TCP/IP properties. What else I need to do? TOM: There's really only two things required: first, run the Security Configuration Wizard on the ISA Firewall, and second, closely review the System Policy and lock it down based on your own network requirements.
2)Can I backup configuration and uninstall ISA 2004 EE than re-install ISA 2004 SE or 2006 SE and import configuration? TOM: No. There is no cross pollination between ISA SE and EE policies.
Tom, I am confused. I agree 100% about making ISA member of a domain in a forward proxy scenario. But what about a reverse proxy (web publishing scenario)? According to this article: "Keeping your ISA Server computers in a workgroup configuration reduces the attack surface and simplifies the deployment of ISA Server". Secure Application Publishing http://www.microsoft.com/technet/isa/2006/secure_web_publishing.mspx Should I have at least 2 ISA Servers? One as a forward proxy (domain member) and the other as a reverse proxy (workgroup, in a DMZ)? And may be a 3erd ISA as a firewall (edge)? What do you think? Thanks.
I disagree wholeheartedly with that statement in the article you pointed out, and some of the most sophisticated ISA Firewall consultants and devs and security engineers at MS disagree with it too.
You lose out on many security features of the ISA Firewall when you don't make it a domain member, so I almost always join my ISA Firewalls to the domain, both for inbound and outbound access control.
The only time I don't make the ISA Firewall a domain member is in a back to back ISA Firewall config. In this scenario, the edge ISA Firewall is performing only stateful packet inspection, like a pix or check point. No authentication is taking place, so domain memberhsip isn't an issue. Then the backend ISA Firewall is configured as a domain member, so that I can take full advantage of all the ISA Firewall's security features.
It is true that separating the outbound and inbound access control to different ISA firewalls is a best practice, but I always make them domain members whenever authetication is required (either for inbound or outbound access control).
Tom... i read your arcticle, you wrote about knowing no "securityhole" in intraside DC communication.. But that is not the problem.
If i put TMG into DMZ i need to open highports for communication with the inside world, if that world is secured e.g. by an ASA that is not real fun.
Those highport are the reason for my headach, because the TMG will not trigger a special DC in the inside world if it needs GPO-Updates or AD-Inforamtion at all, it will trigger all DC at least in the AD-side the TMG is hoted.
That means highports from TMG to all inside DCs... ARGH. Those mass of "connection-posibilty" from DMZ to inside is THE problem for me.
Fine feature would be an AUTO VPN for TMG. So TMG should use IPSec to tunnel all AD-Requests, than it would be only necessary to open "ONE" Port for the TMG, and you can be sure i would be the first to implement it. If you build up IPSec manualy in a large evironment you get mad, or do you own a good ToDo ?
Something like TMG-Authentication Gateway could handle that, too.
Ideas over ideas from me....
90 % of all computerrelated problems are sitting 60 cm in front of the screen.