OWA 2003 Ports Lockdown - Please help

[SpideySMJ]

Greetings,
We are trying to get OWA 2003 setup in our DMZ so users can access it from outside our network. We used OWA 5.5 for this purpose for many years and it's vital that we continue to have this available for our users. However, our Network Engineering team has become concerned at the number of ports that need to be poked in our firewall so OWA can talk to the back end server and DC/GC's. The documentation that I have found have listed the following ports necessary for communication between the OWA frontend server in the DMZ and the backend server on our internal network:

Port 80 for HTTP
Port 691 for Link State Algorithm routing protocol
Port 389 for LDAP (TCP and UDP)
Port 3268 for Global Catalog Server LDAP (TCP)
Port 88 for Kerberos Authentication (TCP and UDP)
Port 53 for DNS (TCP and UDP)
Port 135 ? RPC endpoint mapper (TCP)
Ports 1024 and higher for RPC services

The "Ports 1024 and higher" is the setting that is causing the most greif. I did find one article that gave a reg hack that would allow you to specify a specific port, but it sounded like you had to lock your DCs/GCs to that same port...which I would assume would cause alot of havoc with other programs/apps internally. Unfortunately, I can't really seem to find any other documentation about it. Has any one had any experience with this? Are all these ports necessary? Can we lock it down to just one without issue? Do we have to reg hack the DCs/GCs as well?

Or...is there a better way? I know that ISA server is out there, but I'm trying to avoid spending money. Any advice, help, or links would be appreciated!!

ScottJ

 

[Anonym0us]

The better way is to use ISA Server.

However, a more elegant solution is to use open source software instead of ISA Server. If you are familiar with Apache and a UNIX OS (i.e. Linux, *BSD, Solaris, etc.), then the setup is straight forward. You can set up an Apache server to act as a reverse proxy server.

Do a Google on apache reverse proxy outlook owa. Also, do a search for some of my previous posts. They'll have some links for you.

 

[gbiello]

Have a look at KB259240

http://support.microsoft.com/default.aspx?scid=kb;en-us;259240

"How to configure OWA to connect to Exchange through a firewall"

- gbiello

 

[AndyPeck]

Spidey

Should ISA server not be an option for any reason, and both FE & BE Servers are W2K3, then you should setup IPsec between the servers, you then only require 4 ports open esp,dns,isakmp,Kerberos and all traffic is secure.

Andy

 

[SpideySMJ]

Thanks for all the solutions so far everyone!

Andy, I was just reading up on the IPSec option. It mentions that using IPSec may decrease performance. Do you have any idea how much of a performance hit OWA will have? Is it a big performance hit...or negligible?

 

[AndyPeck]

We have it configured on serveral hosted solutions up to 500 users, all using RPC over HTTPS. No complaints as yet.

 

[SpideySMJ]

Excellent. What are the four ports that I need to open? You mentioned esp, DNS, and Kerberos. Color me stupid, but I'm not sure what port ISAKMP is. One of the documents I found listed these ports:

Port 500 for IKE (UDP)
Port 51 for Authentication Header (AH)
Port 50 for Encapsulation Protocol (ESP)

But that's obviously only three. Just want to make sure I'm opening the right stuff.

 

[AndyPeck]

That would be Cisco PIX speak for Port 500 (excuse my bad language).

I think you'll also need Kerberos 88 usp/tcp, we also have DNS open, but I'm not 100% sure if this is required (I dare not turn it off to find out).

I think we experianced issues locating the AD/DC from the FE when DNS was trying to tunnel down IPsec, Open DNS seemed to resolve the issue for us.

Used this as a guide

http://support.microsoft.com/default.aspx?scid=kb;en-us;816514

 

[jcasetnl]

I can respond to the "ports 1024 and higher" issue. I used to set up multi-tiered apps with DCOM. DCOM uses RPC.

Our dcom server was inside the firewall. Our dcom client was in the DMZ.

The initial RPC connection happens over 135. After that, under a normal config, a random port above 1024 is used for communication. You can restrict that "random" range to maybe 10 ports on the server. You could probably do it with a single port, but we always used about 10.

So basically, the server will contact the client (your OWA server) on a port in that range and the conversation will be carried out from there. Nutshell, you don't have to do anything on the OWA server, just the Exchange server. Restrict it to a port, or range of ports, and then make sure that your client and server can talk to each other through the firewall on that range. Make sure, of course, that the port or range is only available to your OWA server, and not the whole planet, but you probably already knew that.

Btw, there was a tool that came with exchange called RPC ping.

http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/rpcping-o.asp

Basically you run it on both server and client and you "ping" RPC. This is especially helpful in firewall situations for troubleshooting. Make your port changes and then kick off rpc ping. This should minimize your downtime.

And as for all that DC stuff, can you refer to me the kb that was saying that? We certainly never did that and had no problems. As long as your DC can talk to your exchange server on that port range you specified there should be no problems.

Last thing to do is monitor the ports on your exchange box for a little while before you set the range to make sure the port or range doesn't hijack some obscure app(monitoring, for example).

 

[jcasetnl]

Oh, I just read the other posts. When I was doing the dcom stuff, RPC over http wasn't a usuable product. It just didn't really work. But if that technology is matured, as it seems to be, that would be the way to go. Still, if your OWA server is in a DMZ and your Exchange has another FW in front of it, I think you are basically secure.

 

[SpideySMJ]

OK, I've tried to setup IPSec between my front-end server in the DMZ and my back-end server on our internal network and I'm still having some problems. Specifically, when I try and setup IPSec on the back-end server it completely locks it down. No other servers can communicate with it. I can't even connect to it via Terminal Services. I don't want the other internal servers to have to use IPSec to talk to this server...only the Front-end server need use IPSec. Is that possible? Or is it an all or nothing deal?