EDIT: this post was edited on 9/25/2007 to clarify information related to the hotfix mentioned in KB 937031. Thanks to Vanitha for the edit! As we mention in Exchange 2007 documentation, the...
Updated Jul 01, 2019
Version 2.0
Blog Post
2 MIN READ
Maintaining ActiveSync access to Exchange 2003 mailboxes after deployment of Exchange Server 2007 CAS role
Hi Scathew,
Great points! And a topic we spent many hours discussing as we designed Ex2007.
Whenever you deploy access to an intranet server on the Internet, you will need to select which level of security you apply.
The #1 most effective way to mitigate the risk you mention is to do "pre-authentication" on the ISA server or other reverse proxy you have in your Perimeter network (aka. "DMZ"). By authenticating users there before their requests reach your intranet, you reduce your CAS surface area considerably.
ISA 2006 is an example of a reverse proxy/firewall product which includes support for pre-authentication for various Ex2007 services.
Putting CAS servers in the Perimeter network seems like a good idea since they interpret and execute HTTP requests which were formulated by clients out on the Internet (after, as you say, those requests have been inspected by ISA and other reverse proxies + firewalls).
Putting CAS servers in the Perimeter network turns out to do little good though, because the CAS servers are so well connected to everything on the intranet that you'd have to open your internal Perimeter network firewall up so it would look like Swiss Cheese.
Eg. CAS servers must be members of the same AD forest/site as the MBX servers they access.
Eg. CAS servers have lots of access rights to your AD infrastructure.
Eg. CAS servers have lots of access rights to other Exchange servers such as your MBX servers.
Eg. CAS servers use quite a few different ports, and a few protocols, to talk to the different intranet servers they interact with.
For these reasons, there is little value in putting a CAS in the perimeter network. There are two significant drawbacks:
1. You'll be weakening your internal perimeter network firewall, since you would need to open up a bunch of ports.
2. From past experience we know that many Exchange customers who try to put E2003 FE servers (which were supported running in the perimeter network) in the perimeter network run into all kinds of configuration and functionality problems related to firewall configuraton. This translates to lots of deployment complexity.
For Exchange roles that we feel need to be in the perimeter network (this only applies to Ex2007 Edge servers), because they are the first autheticating server and the first protocol-filter server for Internet traffic, we spent lots of time ensuring you can deploy them in the perimeter without the two issues listed above. Eg. an Edge server does not need to be a member of the AD forest/site of the other Exchange servers it communicates with.
Hope that makes sense,
/K
Great points! And a topic we spent many hours discussing as we designed Ex2007.
Whenever you deploy access to an intranet server on the Internet, you will need to select which level of security you apply.
The #1 most effective way to mitigate the risk you mention is to do "pre-authentication" on the ISA server or other reverse proxy you have in your Perimeter network (aka. "DMZ"). By authenticating users there before their requests reach your intranet, you reduce your CAS surface area considerably.
ISA 2006 is an example of a reverse proxy/firewall product which includes support for pre-authentication for various Ex2007 services.
Putting CAS servers in the Perimeter network seems like a good idea since they interpret and execute HTTP requests which were formulated by clients out on the Internet (after, as you say, those requests have been inspected by ISA and other reverse proxies + firewalls).
Putting CAS servers in the Perimeter network turns out to do little good though, because the CAS servers are so well connected to everything on the intranet that you'd have to open your internal Perimeter network firewall up so it would look like Swiss Cheese.
Eg. CAS servers must be members of the same AD forest/site as the MBX servers they access.
Eg. CAS servers have lots of access rights to your AD infrastructure.
Eg. CAS servers have lots of access rights to other Exchange servers such as your MBX servers.
Eg. CAS servers use quite a few different ports, and a few protocols, to talk to the different intranet servers they interact with.
For these reasons, there is little value in putting a CAS in the perimeter network. There are two significant drawbacks:
1. You'll be weakening your internal perimeter network firewall, since you would need to open up a bunch of ports.
2. From past experience we know that many Exchange customers who try to put E2003 FE servers (which were supported running in the perimeter network) in the perimeter network run into all kinds of configuration and functionality problems related to firewall configuraton. This translates to lots of deployment complexity.
For Exchange roles that we feel need to be in the perimeter network (this only applies to Ex2007 Edge servers), because they are the first autheticating server and the first protocol-filter server for Internet traffic, we spent lots of time ensuring you can deploy them in the perimeter without the two issues listed above. Eg. an Edge server does not need to be a member of the AD forest/site of the other Exchange servers it communicates with.
Hope that makes sense,
/K