We allow OWA from internally controlled clients only, no external OWA allowed. It's a long story that goes back in my org longer than I've been there. So the two internal CAS servers allow all standard connectivity and the one external CAS only can do ActiveSync. I was going to do two externally accessible CAS, but our external user footprint is small and we have fast VM recovery if that server ever tanks. I wanted to just do a reverse proxy only to the ActiveSync virtual directory on the internal CAS servers, but we require client certificates on our devices/ActiveSync and the load balancers aren't able to support decrypting with client certs. It can do normal SSL decryption/acceleration for or internal clients, but not for ActiveSync. If anyone has a better solution---im all ears. We are still in testing with EX2013 and won't be going live for a few more weeks.
On Fri, May 9, 2014 at 11:41 AM, Michael B. Smith <[email protected]>wrote: > Yes, that changed in 2013. It is actually one of the recommended > scenarios now, for datacenter DR. > > > > Why do you send all EAS traffic through a single CAS? (You can do what > you've done, it's fine, but I'm just interested in knowing the "why"?) J > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *ccollins9 > *Sent:* Friday, May 9, 2014 11:36 AM > *To:* exchange > *Subject:* Re: [Exchange] CAS exposure - Exchange 2013 SP1 > > > > Another thought, I know EX2010 had issues when the CAS server was in one > AD site and the mailbox was in another AD site. It would try to proxy you > to a CAS in the site where the mailbox resided. I think they may have > changed that in EX2013, not sure. > > > > On Fri, May 9, 2014 at 11:33 AM, ccollins9 <[email protected]> wrote: > > With EX2013 CAS, all client connectivity is over port 443, so that's nice > because there is no need to open RPC, etc., all which I'm sure you know. I > would leave the CAS in the internal network and just open port 443 to it. > There is no real security threat unless MS has unpatched vulnerabilities > in IIS/Exchange. The second best option is to use either NAT or a reverse > proxy in front, or in our case, load balancers that can do reverse proxy. > I agree with Jim, it sounds like you have some old school thinking running > around there that any and all internet accessible servers must be in DMZ no > exceptions. Where I am, we have three CAS servers in the same internal AD > site. Two service the internal and one services external connections. In > the load balancer we have mail.domain.com that points to the two internal > CAS and mobile.domain.com that points to the one CAS for external. Our > external CAS does ActiveSync only, so we removed all OWA/ECP/EWS virtual > directories from that one externally accessible CAS server. Maybe someone > can weigh in why this is a bad idea, but we were able to get the security > team to sign off on it. > > > > On Fri, May 9, 2014 at 11:17 AM, Kennedy, Jim < > [email protected]> wrote: > > "A reverse proxy is not wanted..." > > > > I have to ask why because in my mind that is the best thing to do in this > situation. If they won't allow access to 443 from the outside to a specific > location why have an internet connection? > > > > "....and NAT through the firewall to the CAS array is deemed too dangerous. " > > > > And again why, because that would be the second best solution imho. This > sounds like predisposed beliefs that exposing Exchange OWA to the world is > dangerous. Back in 5.5 days I would have been on that page but I don't > think that is the case now. > > > > "...for the single CAS in the DMZ." > > > > And this sounds like the worst idea of them all. You will have lots of > ports open from the CAS to the internal to make that CAS work. So now that > box gets popped out there and the bad guy now has the whole world of all > the AD ports at their disposal to your internal network. > > > > Be interesting to see what my learned colleges here on the list think. But > the above is what I am going with. > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Tommy Fudge > *Sent:* Friday, May 9, 2014 11:08 AM > *To:* [email protected] > *Subject:* [Exchange] CAS exposure - Exchange 2013 SP1 > > > > Morning, > > > > My work is concerned about exposing our CAS array to the public internet. > Initial thoughts are to place a single CAS in the DMZ with ports open to > our internal network. I have obvious concerns with this approach, but it > is gaining traction, so I need to know if this will even work. On our > internal network are two AD sites, each site contains 2 CAS and 2 MBX > (single DAG) and each has independent internet connectivity. Varying > thoughts are floating around such as using mail.domain.com for the > internal CAS array, and mobile.domain.com for the single CAS in the DMZ. > Autodiscover will point to "mail" which should allow internal clients to > auto configure. There is no desire for external clients to auto configure > (or even laptops to function out of the office using Outlook Anywhere). > Mobile devices would be statically configured to use the "mobile" namespace > by IT, and external clients would connect to OWA via "mobile" as well. > > > > A reverse proxy is not wanted, and NAT through the firewall to the CAS > array is deemed too dangerous. I know the single CAS is a hole in the > firewall anyway and also unsupported by MS, but would this scenario even > work? Is there any impact to Outlook clients on the internal network > seeing the CAS in the DMZ? Would I need to make the internal CAS array non > internet-facing and the single DMZ based CAS internet-facing? Can a single > AD site support both internet-facing and non facing CAS? > > > > Definitely open to suggestions here. This is not production yet - no > coexistence as we use an old Linux mail server right now. > > > Thanks, > > > Tommy > > > > >
