This HOWTO is intended to demonstrate how the iWebGate DMZ
Server (v2) can be used to improve the security of accessing your
Exchange Server from external and remote Exchange clients such as
laptop users running Outlook (PC) or Entourage (MAC), Mobile Smart Phones and web browsers without the need
for establishing VPN connections or exposing the Exchange Server to untrusted networks.
Exchange Server is one of the most popular personal management
solutions in use today and provides some very useful features when
working over the LAN. While remote users might already be able to
access the Exchange Server remotely using either Outlook Web Access
(Webmail) or by using Outlook with RPC over HTTPS, some network
administrators prefer not to expose the Exchange Server (or the IIS
Server) directly to untrusted networks.
In most cases, a VPN connection is used in order to access the Exchange
Server to overcome the closed access requirements of the private
network however VPNs can often be troublesome and unreliable and
ultimately raise frustration levels of the end user. VPNs can also have the adverse effect of exposing more than just the Exchange Server and can potentially weaken network security.
With the iWebGate DMZ Server, Exchange Servers can be "masqueraded"
and provide native access to remote users without exposing the Exchange
Server and the IIS Server directly to the untrusted network.
Additionally, the DMZ Server's SSL certificate can be used in place
of a self signed one that might be offered from Exchange Server.
Clients initially establish connections to the DMZ Server which in
turn connects to the internal Exchange Server on behalf of the remote
client and forwards traffic between the Exchange Server and the client.
At no stage is the Exchange Server or IIS Server exposed to the untrusted network. Any potential attack on the Exchange Server is
hindered by the DMZ Server.
Setting Up the iWebGate DMZ Server
Configuring
the DMZ Server to handle Exchange Server connections on behalf of
remote clients can be done with a few clicks of the mouse by using the
"Exchange Web Services", "Exchange Web Services with RPC"
or the "Exchange Web Services with RPC & ActiveSync" preset folder proxy in the Web Services feature of the DMZ Server
Setup Switchboard:
- Open the "Administration" set
- Click "Server Setup" to open the Setup Switchboard
- Click "Web Services" to open the Web Services manager
- Click the "Folder Proxy" tab
- Click the "Create Proxy Map" toolbar icon to create a new folder map
The
resulting window prompts you to enter the details of the new folder
proxy map. Start by entering a name and appropriate description for the
new map. Exchange Server prefers to accept connections from clients
using SSL, so check the "Enforce SSL connections only" check
box to ensure that the DMZ Server communicates with the Exchange
Server over SSL. This has no bearing on the connection from the client
as it will be using the SSL connection offered by the DMZ Server.
The remaining fields define the actual details of the folder proxy map itself.
As a preset folder map will be used, nothing needs to be entered into
the "Request" field so it should be left blank. In the "Route To"
field, enter the host name of the Exchange Server as it would be
reached from the DMZ Server. Note that the DMZ Server should have access to the Exchange Server residing in the trusted network using the supplied name or address.
From the "Custom Map" drop list, select "Exchange Web Services with
RPC" or "Exchange Web Services with RPC & ActiveSync" as this will ensure that remote Outlook clients will be able to
access the Exchange Server natively without the need for a VPN
connection. If you only need to offer Outlook Web Access (Webmail) for
remote clients, then select "Exchange Web Services" instead and RPC
and ActiveSync will not be offered so Outlook will not be able to access the
server without the use of VPN or similar. Once the desired preset has been selected, click the "Add"
button to populate the maps list with the required folder maps.
If everything is in order, click the "Save" button to save the maps to
the DMZ Server. The server should respond with "The maps were saved
successfully. Please refresh the list to show any new maps". Click "OK"
and then click the "Refresh" icon from the toolbar to show the new map
in the list. This indicates that the maps were saved to the database
but the maps will need to be deployed before they become available.
Click the "Deploy Proxy Maps" toolbar icon to commit the maps to the
DMZ Server configuration. This will need to be done successfully
before you are able to use the maps. If successfully deployed, you
might need to perform a "Background Restart" of the DMZ Server after which
remote clients should be able to access the Exchange Server as though
it was directly exposed to the Internet.
Exchange Server Settings
The Exchange Server must be configured to accept connections using HTTP Basic Authentication in order for RPC to work. As an encrypted SSL connection is used between the DMZ Server and the remote client, using this authentication type is completely safe. The authentication selection can be set through the Internet Information Server Management Console by editing the properties of the RPC folder under the "Default Website" host.
Please refer to Microsoft Internet Information Server documentation for more information on configuring HTTP Basic Authentication.
Client Settings
If
"Exchange Web Services with RPC" or "Exchange Web Services with RPC & ActiveSync" was selected from the preset maps
list, then the Exchange clients may need to be reconfigured by setting
the Exchange Server address to that of the DMZ Server. For example,
if your DMZ Server's address is dmzserver.example.com, the remote
exchange clients should set dmzserver.example.com as the Exchange Server
address. All other settings can remain as they are, however the account
may need to be resynchronized if this is not the first time the client
has connected to the Exchange Server.
Alternatively, it is possible to provide the DMZ Server with an Fully Qualified Domain Name (FQDN) alias through the DMZ Server's "Network Settings" tool in the "Setup Switchboard" and configure the host record in the external domain to point to the DMZ Server IPv4 address. This will allow users to continue using the usual FQDN of the Exchange Server without having to alter their client software configuration.
NOTE:
If the same remote clients will also be accessing the Exchange Server
via the trusted network from time-to-time, they can still access the
DMZ Server from the trusted network the same way they access it
remotely. This may require a DNS server that supports multiple views
for a singe domain. For example, the DNS server should have a view for
requests coming from the Internet and resolve host names to external
addresses and should also have a view for local requests coming from
the internal network that resolves the same host names to local private
IP addresses. Alternatively, the external domain configuration could be replicated in the DNS server for
the trusted network but using local IP addresses in place of external
ones to achieve the same result as a DNS server configured with multiple views.
If RPC support was
not selected, then nothing needs to happen at the client side as the
Exchange Server will only be able to be accessed remotely using a web
browser. Users should be able to browse to
https://dmzserver.example.com/exchange to access Outlook Web Access
(OWA) and should be prompted for a user name and password in order to
login.
Additional Features: Multi-DMZ Exchange Tunneling
One
useful scenario that can be implemented is Multi-DMZ Server Exchange
Tunneling. This involves two (or more) DMZ Servers and an Exchange
Server behind one of these DMZ Servers. Consider the following
network infrastructure:
+-----------------------------------+ +-----------------------------------+
| Internal Network A (London) | | Internal Network B (Sydney) |
| +-------------+ +-------------+ | | +-------------+ +-------------+ |
| | Exchange |___| DMZ |___Internet___| DMZ |___| Exchange | |
| | Server | | Server A | | | | Server B | | Client | |
| +-------------+ +-------------+ | | +-------------+ +-------------+ |
| | | |
+-----------------------------------+ +-----------------------------------+
Both networks in the above diagram are private networks that
communicate via the public Internet without the use of VPN or any other
type of private IP tunneling. The public IP address in London is 44.221.78.3 while the public IP address in Sydney is 61.19.186.34. DMZ Server A (10.0.0.1) in London is configured with at least an "Exchange Web Services with RPC" proxy map that accepts connections on behalf of the Exchange Server (10.0.0.2) on the same network. DMZ Server B (172.18.48.12) is configured with at least an "Exchange Web Services with RPC" proxy map that accepts connections from the Exchange Client and forwards them to DMZ Server A using the Internet.
Because this setup uses two DMZ Servers, a effective "SSL tunnel" is
established by using the proxy maps described in the previous
description. The Exchange Client is configured with DMZ Server B as the Exchange Server and DMZ Server B is configured to route the incoming requests from the client DMZ Server A using HTTPS (encrypted) requests over the Internet. DMZ Server A accepts the requests from DMZ Server B and forwards them on to the Exchange Server on the same network. Apart from the possible bandwidth limitations of the Internet, the Exchange Client has no idea that the Exchange Server resides in London and believes DMZ Server B to be the Exchange Server.
The Exchange Server and Exchange Client
both remain securely behind their respective firewalls and DMZ Servers and are never exposed directly to the Internet. No VPN or
private IP tunneling is needed and connections are performed purely
over HTTPS to improve security and performance and minimize bandwidth
use.
Additional Features: Automatic Logins to Outlook Web Access
When
configured correctly, it is possible to have the iWebGate DMZ Server
authenticate Outlook Web Access (OWA) automatically so that users need
only sign into the DMZ Server (single sign on). This will only needs
to work for OWA as native Outlook access to Exchange Server (RPC) does
not require users to be logged into the DMZ Server in order to work
remotely.
In order for single sign
on to be achieved, the DMZ Server must be configured to log users in
via HTTP Basic Authentication over SSL (so that passwords are not
transmitted in the clear). To configure the DMZ Server to prompt for
logins using HTTP Basic Authentication:
- Open the "Administration" set
- Click "Server Setup" to open the Setup Switchboard
- Click "Users & Authentication"
- Select "HTTP Basic Authentication" from the "Authentication Type" drop list
- Click "Save"
The DMZ Server should now prompt users to login using the browser's
built in login dialog requesting a user name and password. Users
continue to login with their usual DMZ Server user name and password. If
the user name and password corresponds to those used to login to the
OWA service, then the browser will provide the previously obtained
credentials to the Exchange Server and the user should not be prompted
to login to OWA.
To simplify the administration of users and their passwords, the
iWebGate DMZ Server can be configured to authenticate against the
Active Directory services on the same network. This should ensure that
user names and passwords will always be in sync. To learn how to
configure the DMZ Server to authenticate using Active Directory,
refer to
DMZ Server HOWTO: Windows Active Directory Authentication.
Congratulations, you should now have an understanding of how the DMZ Server can be used to strengthen the security of your Exchange Server
and how multiple DMZ Servers can be used to establish an SSL enabled
Exchange tunnel for geographically separate networks.
