Publishing a Front End server in Exchange 2000, 2003 and 2007 today is a little like taking an Exchange box and stripping it down to "enough" features for; all required Exchange services to work and of course, the Web components and dependencies such as IIS. While this is a great way to start working towards security but it still introduces concerns to administrators for possible administrative and certain security issues for example, Active Directory membership (since the Exchange server needs to be part of the domain) ports need to published between DMZ to Internal DCs, securing the Windows server in which Exchange server reside (since it's being placed in a DMZ) and configuring firewalls to allow communication between internal mailbox servers (which can be rather complex since you need to codehack ports in which the information store listens on etc). Other concerns could also be the inability to implement multiform factor authentication (which is not possible with just Exchange FE-s). Here's a good (detailed) sample article one can use to do just Exchange FE publication on DMZs or alike http://www.msexchange.org/tutorials/OWA_Exchange_Server_2003.html
Fortunately, there's a much easier, secure and "cheaper" way. Yes, you guessed it, USE ISA SERVER 2006. Cheaper? (i leave this to you to do the math here).
Lets continue this topic by simply looking at key differences which an organization can directly benefit by using ISA Server as their FE for Exchange OWA. Here, i present, my oh-so-familiar way of presenting benefits:
ISA Server's top 10+1 reasons as an Exchange OWA Front End
- Its a firewall - Once installed, it's a dead Windows box which only do stuff you allow it to do. You do not need to crack your head open on how to block ports and secure this secure that. Of course, you still need the basic hardening guides to help enhance the ISA box..la.
- It can publish one or more Exchange OWA or backend servers with OWA enabled and do a better load balancing job (like application response-e.g. http/s-get) than WNLB (network level only)
- You can do all the HTTP filtering you would normally do with an ISA server like URL filters like HTTP signatures filtering, headers, extensions, methods, HTTP redirection to HTTPS (which you would normally use a ASP script in OWA 2K3 or lower) setup concurrent connections and connection limits (anti DoS), etc...
- Perform higher degree of control by using Forms based authentication via ISA server like the use of persistent cookies, HTML customization and password management.
- Single Sign On - Yes, once you sign on to OWA, you could also be signed on to say your intranet web servers!
- You can filter out users at the ISA server level itself and lockdown on users whom are not suppose to use OWA or enforce limits on time for instance. You can also specify sources like directory based users groups, IP addresses, domain names, etc.
- You can choose to bridge SSL! That hundreds of thousands of dollars application filtering IPS can finally see what's going on with OWA on SSL
- It can support multiform authentication - Yes, multifactor auth is possible meaning you could have your OWA users sign on to a certificate and/or an RSA token or a combination.
- Setting it up is a breeze, you do not need to introduce an additional Exchange server in your organization (or the Exchange SM ). All done through wizards and its up and running when you click APPLY!
- It can cache!, compress, you can do other fun stuff like taking the OWA offline by sending users to a "...this page is unavailable page.." for maintenance and you do it all from ISA rules!
- BONUS POINT: You could also perform attachment rules, customized logoff pages etc straight from the ISA server rule line itself.
Happy ISAlating your Exchange