Exchange Server

dexx · Guest

Ive read that an OWA server has to be a member of the same AD as the
exchange servers it communicates with. Is this true? Our OWA is
planned to go in a DMZ. Wouldnt the AD be exposed if the OWA server was
ever compromised? Would it be better to make the OWA standalone, or at
least in a separate forest, and then use ldap or kerberos to
authenticate users?

Mark Arnold [MVP] · Guest

On 5 Aug 2005 00:33:41 -0700, "dexx" <D3xx@hotmail.com> wrote:

dexx · Guest

Mark Arnold [MVP] · Guest

On 7 Aug 2005 18:29:22 -0700, "dexx" <D3xx@hotmail.com> wrote:

Aaron Guilmette · Guest

Yes, the OWA server needs to be a member of your AD environment.

Despite what Microsoft says about it not being a "best practice" to place
your OWA servers in the DMZ, most people I know do just that because their
OWA servers are also SMTP relays for the company. And, most of my clients
already have existing firewall infrastructures and they don't want to
introduce ISA into the mix.

Under these circumstances, you need to either put OWA servers in the DMZ or
port-forward all 80/25/443 requests to the internal network. Either way, AD
isn't directly exposed to the internet, because you should only be allowing
inbound 80/443 (all email traffic happens over 443; I typically leave 80
open and redirect the default web site to
https://server.domain.com/exchange) and inbound/outbound 25 for SMTP (if
it's acting as a relay).

If you do put your OWA servers in the DMZ, there's 12-16 ports that you need
to open between OWA and Exchange/AD (depending on whether or not you're
going to use RPC/HTTPS and SMTP routing), and 2-3 between OWA and the
internet (depending on whether or not you're going to use SMTP routing).
You can calm your firewall guys down a bit because all of the requests to
internal resources are sourced from your OWA server(s) in the DMZ, so you're
not opening everything up as bad as it sounds.

Internet to OWA servers in DMZ
- 25 TCP, Internet to OWA in DMZ
- 80 TCP, Internet to OWA in DMZ
- 443 TCP, Internet to OWA in DMZ

- MAIL ROUTING
- 25 TCP, OWA to Exchange Back-End
- 80 TCP, OWA to Exchange Back-End
- 691 TCP, OWA to Exchange Back-End

- DIRECTORY SERVICES / AUTHENTICATION
- 389 UDP, OWA to Active Directory
- 389 TCP, OWA to Active Directory
- 445 TCP, OWA to Active Directory
- 3268 TCP, OWA to Active Directory
- 88 UDP, OWA to Active Directory
- 88 TCP, OWA to Active Directory

- DNS
- 53 UDP, OWA to DNS (typically GC/DC running DNS)
- 53 TCP, OWA to DNS (typically GC/DC running DNS)

- RPC
- 135 TCP, OWA Active Directory (this is the one your firewall guys will
hate)
- 9910 TCP OWA to Active Directory (this is a fixed RPC port instead of
opening 1024+ for RPC; it can be any port you like; I choose 9910 because
it's not used by any known trojans or viruses (yet), specify reg key on DCs
per Q224196)

- RPC over HTTPS
- 6001 TCP, OWA to Exchange Back-End
- 6002 TCP, OWA to Exchange Back-End
- 6004 TCP, OWA to Exchange Back-End

"dexx" <D3xx@hotmail.com> wrote in message
news:1123464561.894181.38430@g47g2000cwa.googlegroups.com...

Aaron Guilmette · Guest

:-) I'm not saying I recommend it, and Microsoft certainly doesn't
recommend it, but there it is if someone wants to or needs to do it. There
can be a number of reasons that it happens this way (usually trying to do
too much with too little), so I think it's good to know your options. I
probably should been a little more "not recommended," but I figured if the
question had gotten this far, then I at least might as well offer a little
guidance.

Al Mulnick · Guest

Oh, they want to take logic out of the equation. I suppose that anything
goes then, right?
I agree that it can be a tough sell. Then again, doing things in a way that
works for the corporation vs. the individual ego seems to be a common
problem that has to be dealt with.

I've seen very similar to what you describe. I've also seen it where the
application owner [1] is responsible for the application including the ISA
appliance. In your description, this would be the same as deploying OWA in
the DMZ except more secure because the application owner would still manage
the server! I think this is why Microsoft should consider including an
Exchange-only version of ISA for deployment of these scenarios. In the end,
it's the same to the customer, but there is no more wondering if they bought
a solution to secure a solution they already bought just so they could
deploy the solution without the security (say that ten times fast <G>)

I know, that's the logical view and many people would say that Microsoft has
a name in security; just not a good one :) To those, I would say they
should take a very long and hard look at the glass house they live in and
figure out if they are really doing the best thing for their company.

I understand Aaron. I really do. I think you're right that you have to
provide options and let the customer shoot themselves in the foot when they
deem it to be necessary and in their best interest. Can't be helped.

I figured having this conversation publicly might be of use to some folks
when they try to put this into perspective of their own architectures.

[1] Some might even call e-mail a "service" to describe Exchange (or
whatever MTA you're using) and the ecosystem used to provide "e-mail
services" such as HTTP access, authentication, name resolution, delivery,
address book, anti-virus etc :)

Al

"Aaron Guilmette" <aguilmette@w3r.com> wrote in message
news:OdfcFBDnFHA.3448@TK2MSFTNGP12.phx.gbl...

Al Mulnick · Guest

It's a shame that people still view deploying ISA as an OWA front-end as
being the same as deploying an additional firewall. That's just a crying
shame. Of course, it's also a shame Microsoft doesn't make it easier (i.e.
better licensing for such a configuration; maybe an Exchange only version of
ISA? ;) to deploy in this type of scenario. Could even be part of, I dunno,
the trusted computing initiative that Exchange-specific ISA comes in every
box of Exchange (marketing slogan: Now with more ISA in every box!) <G>

As a clarification Aaron, I think you should mention that it's usually port
<> any active directory server vs. just one. Unless you are otherwise
controlling which servers the FE server is using making sure that all
domains are accounted for (vs. 389 UDP, OWA to Active Directory ).

Deploying OWA in a DMZ environment really doesn't buy you anything vs.
deploying OWA in your internal network and then allowing just TCP 443 or TCP
80 to that machine. No difference other than complexity and realibility
really.

From a security viewpoint, all the cracker needs to do is exploit your OWA
server and they have full run of your important servers [1]. Since we can
pretty much assume there is no perfect application on any platform, it's a
race to see if you can patch the OWA machine as fast as the cracks come out.
Deploying a layer-7 device that understands the protocol intent and prevents
a malicious user from owning that machine (it is an application layer
firewall by the way) offers a lot of additional protection you don't
otherwise get. Here's the bigger value in my mind: it can offer SSL
bridging and third-party plug-ins. What does that mean? It means you
terminate the SSL conversation at the external interface, evaluate the
packets (anti-virus, signature checking, etc.) and then re-encrypt the
packets to the FE server thereby keeping clear traffic off your DMZ network.
IPSec is required to protect your traffic from a FE to BE server and the
DC's and DNS servers if you don't do that. That means you have no way to
check the packets at all to see if anything unexpected or malicious is going
on. Is that important? Hmm... I would think so. I would think that if you
go to the trouble of deploying SSL to protect the traffic, you wouldn't want
to protect a cracker from you knowing they're working diligently against
your defenses. That's me though.

I always recommend ISA or similar (ISA first because it comes from the
vendor who's application I'm deploying right?) to protect the OWA
infrastructure. Two-factor authentication is also a normal recommendation.
Deploying a member of my trusted forest to the DMZ is never recommended but
usually discouraged. That also is in keeping with Microsoft's best
practices of not deploying forest members (from the trusted network) to a
DMZ or 'semi-trusted' network.
FE servers were never meant as a security architecture.

[1] Ok, if you place this in the DMZ, you may be able to slow down the move
to the non-AD, Exchange and DNS servers. But let's face it, if they've
gotten that far, they're going to figure out how to use a port redirection
technique to own the rest of the organization anyway. Likely with more
authority than you really want because they've had unrestricted and
encrypted access (no IDM useful if encryption is in place) to your AD
servers. Still several levels of magnitude more difficult. If you were to
place this server internally, it would likely have fewer restrictions
(depending on configurations) to other machines. A very small road bump in
the progress of owning your network because they could just wreak havoc with
Exchange, AD, DNS, etc and from those machines have access to the kingdom.
Since you still need a way to securely (that's risk vs. reward) deploy this,
ISA's reverse proxy deployment scenarios are a far better risk/reward ratio
in my opinion.

My $0.04 anyway.

-ajm

"Aaron Guilmette" <aguilmette@w3r.com> wrote in message
news:OPsge5BnFHA.2904@TK2MSFTNGP14.phx.gbl...

	Exchange Server Forum Index -> Design	All times are GMT
Page 1 of 1