My customer decided that they needed to block OWA externally but leave it open internally. Why? OWA does pose a security risk having e-mail open to the internet. Yes, passwords, firewalls, etc all provide levels of protection, but it is still an opening for someone to get in through. They use OWA internally for those who do not have a full Outlook client, so we have to leave that portion open. They presently have Exchange 2003, but will be moving to 2010 relatively soon. The difficulty here comes from mobile devices that still need access to the Internet, so we could not just turn off the whole website in IIS as ActiveSync leverages that service.
First, there are a few ways to accomplish this. The best way would be to use ISA/TMG to filter the OWA requests before they ever reached the front end servers.
Exchange Services Publishing Deployment Options
Publishing Exchange with Forefront
Everyone runs UAG or has a advanced firewall to do this, right? No? Well then, let’s move on. The second option would be to block requests from the load balancers. Unfortunately, we needed internal access as well, so this would not really be a solid option. That left us with changing something inside IIS on the FE.
For Exchange 2003, we could add the external VIP of the router to the list of blocked IPs inside of IIS on the FE box. Thus, any requests coming into the Windows IIS would receive a blocked IP error, and this would block access. We chose this route because it was simple (we did not need to get the network team involved), easily testable, and leaves it inside a Microsoft supported environment. The downside is that we had to make the change to every front end box that faced the external interface, which was six.
Granting or Denying Access to a Computer (IIS 6)
Now, this ONLY works if you have segregated FE/BE servers. If you have an all-in-one, this will NOT work because the FE has to proxy to the BE. The BE, which uses the same IIS configuration of FE, would block the IP as well.
One thing we also did was to give the users “this service is no longer available, please contact the help desk.” This would (hopefully) tell the users that OWA is gone and they can no longer use it. Users also received notifications during the week, but they may have been on vacation or similar, or, like me, just not read the email.
Creating Custom Error Messages
Looking forward, in 2007 and 2010, there are easier ways. I would suggest creating a new website with a unique IP in IIS and only adding ActiveSync to that website using a cmdlet. That would give us a website hosted on the box that served the ActiveSync devices but nothing else, leaving the OWA open for internal access. The firewall would point to this website/IP on the CAS. We could also create a virtual directory under there for /OWA and /Exchange which would serve up the generic ““this service is no longer available, please contact the help desk” message as the default webpage. This makes it easy to mange, monitor, and control traffic to. You could also do the same in 2003 with a new website with a ActiveSync virtual directory, but in 2003, this is a little more complicated because of the lack of powershell to create the site for you.
How to Create an Exchange ActiveSync Virtual Directory