Yes, we currently are doing that in EX2010. Removed most (if not all) virtual directories except for ActiveSync. Remove-ECPVirtualDirectory, Remove-owaVirtualDirectory, Remove-autodiscoverVirtualDirectory, Remove-OABVirtualDirectory, etc, etc. You can also do it with reverse proxying I think, or IP rules in IIS.
On Fri, May 9, 2014 at 11:50 AM, Orlebeck, Geoffrey < [email protected]> wrote: > I'm curious if the below methodology applies to Exchange 2010 as well > (removing OWA/ECP/EWS directories so external CAS is ActiveSync only)? > > > > Thanks. > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *ccollins9 > *Sent:* Friday, May 09, 2014 8:34 AM > *To:* exchange > *Subject:* Re: [Exchange] CAS exposure - Exchange 2013 SP1 > > > > 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 > > > Confidentiality Notice: This is a transmission from Community Hospital > of the Monterey Peninsula. This message and any attached documents may be > confidential and contain information protected by state and federal medical > privacy statutes. They are intended only for the use of the addressee. If > you are not the intended recipient, any disclosure, copying, or > distribution of this information is strictly prohibited. If you received > this transmission in error, please accept our apologies and notify the > sender. Thank you. >
