Maintaining ActiveSync access to Exchange 2003 mailboxes after deployment of Exchange Server 2007 CAS role

Checking my current Exchange 2003 config I see only basic authentication selected. Would it harm anything if I set it to both basic and integrated now in preparation for upgrade?

Hi Mitchel,

If your topology has an Exchange "Front End" which mobile devices hit directly and a "Back-End" which is your actual Mailbox Server then having both Integrated and Basic Authentication enabled will not be a problem.  

There will only be a problem if your "Front End" is on the same server as the Mailbox Server and this will impact Windows Mobile 5.0 MSFP devices or earlier .  

Please let me know if you have any further questions.


--Michael

Is this picked up by exbpa?

Max,

The BPA rule is coming soon.

will a CA service a x7 mailbox server is a different AD site?  with x3 all our ISA and FE's are in one AD site and service mailbox servers in many AD sites.  

I read somewhere that the CAS server system is not supported in the DMZ.  Is that correct?  So if I need to provide users external access to CAS functionalities I have to either open a hole in the firewall or use ISA server?

Hi Andrew,

Yes, that's correct, it is recommended not to place the CAS inside the DMZ.

A best practice is to place the CAS on the internal network and have a reverse proxy direct traffic from the internet to the CAS.  ISA or other comparable products have the ability to publish CAS.  

This Technet Article provides a good level of information to use ISA 2006 to publishing CAS (and other details related to Exchange 2007).

Let me know if you have any questions.


--Mike

The fact that the CAS isn't within a sandwich of firewalls (ie: a DMZ perimeter network) seems very concerning to me. I know that an ISA will in theory filter via proxying any threats, but what if it's some sort of new zero day buffer overflow attack?

I assume that at some level of the data the HTTP/HTTPS requests are forwarded verbatim through the ISA proxying to the CAS. If some new attack on the CAS were found with some sort of constructed known HTTP(S) payload, not yet known to ISA developers, it could be forwarded to the CAS via the ISA and a compromise happen.

Yes, there are a number of mitigating difficulties for an attacker, but this scenario seems relatively plausible and given what a high value target CAS servers might be to a hacker, it might be well worth one's effort.

With the CAS on the inside with no further firewalling, clearly this would place the rest of your networks wide open for attack.

I'm not sure why the CAS can't (shouldn't) be firewalled and/or why there aren't instructions to do so. We use a enterprise class firewall that has 5gb of throughput, so in theory the high bandwidth requirements could be met. Anything can and should be firewall-able. This is what host intrusion prevention is often about. It should just be a case of defining the required ports and making sure sufficient bandwidth/performance exists through the firewall.

I suppose one option would be to place the entire Exchange infrastructure in a DMZ, including Mailbox Server, Hub Transport Server, and Client Access Server and just pinhole the Exchange services into that, leaving access between the Exchange components wide open. Is this what some do?

Really, putting the CAS on the inside gives me the willies. It doesn't seem "best practice" at all to me.

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

Is the problem DS2MB resolved yet? This keeps disabling Intergrate Authentication in my environment.