Re: OWA in DMZ - HowTo
- From: "Al Mulnick" <amulnick_No_SPAM@xxxxxxxxxxx>
- Date: Tue, 21 Jun 2005 10:32:24 -0400
Not to pick, but...
While it is supported, I think there may be some issues with recommended. I
say that because in order to deploy a FE server, you must deploy it as a
member of a domain in the same forest. That indicates that you would break
a different recommendation, which is to not put domain members from your
internally trusted network, into the semi-trusted DMZ network or directly on
the internet.
Another recommendation would be to not allow internet originated traffic
directly into your trusted network but rather have some sort of checking on
that traffic as well as a cut-off point. Checking might be something like
IDS. SSL connections typically make that difficult, especially in the FE
scenario without some sort of SSL bridging device because by nature, SSL is
private communications between the client and server.
Enter the layer-7 firewall recommendations. Whether opensource, firewall
based, or ISA you should really consider using one to deploy internal
resources externally to your consumers.
ISA is a lot easier to deploy (think time-savings), offers a lot of benefits
and flexibility while being tightly integrated with your Exchange software
investment. RPC/HTTPS, POP/S, IMAP/S, SMTP/S and OWA are much much easier
to deploy if you use ISA. And you don't need to rearchitect your security
infrastructure to make it work. It's drop and play technology that works
well with the existing infrastructure. I typically recommend considering it
part of your Exchange infrastructure vs. calling it something like a
firewall or reverse proxy. IMHO, it should be included with Exchange as
part of the out of the box architecture. At least some of the components
should be included. "Maybe an ISA-lite, Exchange Version"?
Some of the opensource solutions can be used (I've seen some traffic on
Apache for OWA publishing as well as SQUID being used; I haven't used either
so I can't speak to how easy or possible or how well it works.)
If you still have to deploy FE in the DMZ, you may want to consider allowing
all traffic from the FE server to your Exchange BE and DC's on your network.
That assumes you have AD-integrated DNS, but if you do not, you'll need to
allow that as well. Depending on your DMZ policy, you may have other
settings as well.
If that doesn't suffice in your environment, you may want to consider IPSec
tunnels from the FE server to the BE server and the DCs and DNS servers (if
separate).
If that doesn't suffice, you may want to permit the exact list of ports and
protocols required to each of the BE, DC, and DNS servers.
In the end, if you allow that much traffic from the FE server to those
servers, you may as well put it internal and allow the traffic from the
internet clients to your trusted network IMHO. Especially since IDS won't
be effective without a bridging technology. HIDS might be helpful at some
point, but only if it captures the traffic after it's been decrypted.
Anyhow, I think those docs need to at least mention the AD recommendations
and how that conflict in recommendations between AD and Exchange deployments
is reconciled before saying that it's recommended to deploy Exchange FE
servers in a DMZ.
Lee, is there any conversation internally regarding those recommendation
conflicts?
Al
"Lee Li [MSFT]" <v-leeli@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:MaO%23O$gdFHA.940@xxxxxxxxxxxxxxxxxxxxxxxx
> Hi Stefano,
>
> Thanks for posting here. Thanks for Mark and Aaron for sharing experience.
>
> Actually, your questions appear to be more consulting in nature. Although
> this newsgroup is here to provide break/fix resolution, we are happy to
> provide general information and suggestions on it here and you may receive
> suggestions from other partners on this topic.
>
> We would also like to introduce you to the Customer Service and Support
> (CSS) Advisory Services team.
>
> Advisory Services is a remotely delivered, hourly fee-based, consultative
> support option that provides a comprehensive result beyond your break-fix
> product maintenance needs. This support option includes working with the
> same technician for assistance with issues like product migration, code
> review, or new program development.
>
> For more info in the US and Canada:
> http://support.microsoft.com/default.aspx?pr=AdvisoryService
>
> Outside of the US/Canada:
> http://support.microsoft.com/default.aspx?scid=%2finternational.aspx
>
> Regarding official information about the license of Exchange Server, we
> have Microsoft licensing specialist to answer your question.
>
> You can call 1-800-426-9400 (select option 4), Monday through Friday, 6:00
> A.M. to 6:00 P.M. (Pacific time) to speak directly to a Microsoft
> licensing
> specialist. Worldwide customers can use the Guide to Worldwide Microsoft
> Licensing Sites to find contact information in their locations.
>
> General Information:
> ===============
>
>
> Actually, it is supported and recommended to place Front-End Server in
> DMZ.
> More detailed info here:
>
> Exchange Server 2003 and Exchange 2000 Server Front-End and Back-End
> Topology
> http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/febetop.m
> spx
>
> 280132 XCCC: Exchange 2000 Windows 2000 Connectivity Through Firewalls
> http://support.microsoft.com/?id=280132
>
> Q1: Is it confirmed that OWA cannot be installed on a stand-alone server?
>
> Yes, unlike Exchange Server 5.5, you need to install Exchange Server in
> order to implement OWA 2003.
>
>
> Q2: If installing front-end servers is the only solution, will I need 3
> server licenses (2 for each front-end + 1 for the back-end server)?
>
> Yes, for detailed information, please contact Microsoft licensing
> specialist by 1-800-426-9400 (select option 4).
>
>
> Q3: Considering this last configuration, may I install STD version of Exch
> on front-end and ENT on back-end?
>
> Unlike Exchange 2000, both Exchange 2003 Standard Edition and Enterprise
> Edition can work as Front-End/Back-End Server.
>
> Hope this helps. If you have more concern, please contact our Advisory
> Services team. Thanks and have a nice day!
>
> Lee Li
> Microsoft Online Partner Support
>
> Get Secure! - www.microsoft.com/security
>
> =====================================================
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> =====================================================
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
.
- Follow-Ups:
- Re: OWA in DMZ - HowTo
- From: Lee Li [MSFT]
- Re: OWA in DMZ - HowTo
- References:
- OWA in DMZ - HowTo
- From: Stefano Rivoli
- RE: OWA in DMZ - HowTo
- From: Lee Li [MSFT]
- OWA in DMZ - HowTo
- Prev by Date: Re: Recovering my exchange emails from hdd
- Next by Date: Outlook 2000 hangs after migration form 5.5 to Exchange 2003
- Previous by thread: RE: OWA in DMZ - HowTo
- Next by thread: Re: OWA in DMZ - HowTo
- Index(es):
Relevant Pages
|
Loading
