I implemented different ISA 2006 Reverse Proxy servers in conjunction with Microsoft Exchange 2003 or Windows Exchange 2007.
Today I configured ISA 2006 with Exchange 2007. I configured the Reverse Proxy server as I did always. And the connection from outside the network works perfectly. On the internal Exchange server I configured Basic and Integrated Authentication on the OWA virtual directory. The problem is that internal users now automatically log in to their webmail box when entering the URL from the Exchange server.
This is not the desired configuration, because internal users should be able to open other people’s mailboxes by logging in as that user. The customer also has an ISA 2006 on the internal network for forwarding proxy purposes.
I decided to publish Exchange 2007 on the internal ISA 2006 server as well. The configuration should use Form Based Authentication (FBA) over HTTP. After configuring and trying the connection, the user can’t access the ISA logon page. In the logging you find that Authentication over HTTP isn’t allowed.
Error Code: 403 Forbidden. ISA Server is configured to block HTTP requests that require authentication. (12250)
This is a default setting in ISA 2006 which can be disable. To allow Authentication over HTTP go to the Listener configuration. Go to the Authentication tab and Select Advanced. In the next tab enable the option Allow client authentication over HTTP. This option enables the using FBA over HTTP.
Today I have be working on publishing Microsoft Exchange Outlook WebAccess and Active Sync to the Internet. We had some discussions with some Microsoft Consultants about a secure way to publish Outlook Web Access to the Internet, especially the authentication part of such a solution.
Some people are talking about publishing OWA directly to the Internet. In my opinion, this results in a major security thread, because you directly publish a TCP/80 and TCP/443 connection from the Exchange server to the Internet. An vulnerability or exploit in these services could end up in an hacker who takes over the Exchange server.
A second solution is placing a front-end server in a DMZ segment, but making the server a domain member for authentication. In my opinion still a security leak, because somebody who hacks the DMZ server has maybe the ability to hack or corrupt the Active Directory.
The third solution, and the solution we advise, is using a Microsoft ISA 2006 server as a front-end server in the DMZ. We configure a RADIUS or LDAPS (if you would like the option to change the password) connection to a RADIUS server or a domain member on the internal LAN segment. This ensures a secure way of authenticating users and even if somebody hacks the ISA server, he still hasn’t hacked a domain member server or a vulnerability in TCP/80 or TCP/443 of the Exchange server.
I have had a lot of help of an article on isaserver.org from Thomas Shinder while configuring the solution. I had some problems with publishing Active Sync. Ended up with enabling Basic Authentication on the Active Sync virtual directory (Microsoft-Server-ActiveSync).