From: The Netherlands
We have a dmz protected by cisco pix firewalls netscreens etc. No the company wants to use an outlook web access server.
Because the owa server need so many open ports i want to place a standalone single nic isa server in the dmz and publish the owa server on the internal network so only one port needs to be open on the internet firewall and the intranet firewall. So when i publish the owa server i don't use the form based authentication option in ISA.
(i already used an linux box with reversed apache proxy, but company policy wants no linux server, because the don't have the experts)
I think this is a pretty good setup, what do you guys think???
From: The Netherlands
tom thanks for your reply,
but the isa server will not be joined to the domain. It's our defense for users who connect from the internet, behind there is a pix firewall in place, that will not be replaced with an isa server. Making the isa server part of the domain, is bad for security, because, we have to open a million ports just to join it to the domain.
I will harden the server as much as possible.
We have a split dns in place, so internal users kan connect without any problems.
All we want is open port 443 on the internet firewall en port 443 on dmz firewall and only allow port 443 to the internal outlook web access server.
1. Placing you OWA server in the LAN is not a good security design.
When you refer to OWA I supose you use an Exchange mail server; your front-end server should be placed in a seperated security zone from you back-end. Why ? --> a) Instinct and best-practices recommend placing your Internet facing servers in a serperate security zone; when they are compromised you can easily seperate them from other servers and you can granullary control ALL traffic to and from the server. b) By placing an inteligent application layer firewall as ISA between your FE and BE exchange, you can filter the RPC traffic between the two by using the RPC filter;
PS: If you consider to publish your back-end server as OWA server than you're taking even bigger risks :)
2. You should try to authenticate your connections as soon as possible i.e. you should authenticate your connections to your OWA server before they arrive at the OWA server. You can do this with ISA via domain membership or RADIUS. So it is worth the effort to consider joining the ISA server to a domain (via IPSEC perhaps?).
3. I hope you're bridging your SSL connection otherwise you shouldn't bother using the ISA firewall and just open the ports on your cisco pix to the inside...I don't see the added value for ISA in this case
From: The Netherlands
i am definitly not waiting on standard ms answers.
* making the isa server a member of the domain is opening a lot of ports, and you do not want that * putting the owa server in the dmz and making it a member of the domain is no good, yes you can control the traffic, but you have to open ports to the dc's (and nobody wants that) *i dont see the point of using radius, we have to open more ports on the firewall.
Futhermore i never ever connect any server directly to the internet, i allways use a pix or netscreen, because these things are build for it, no server can compete against it.
In my desing only port 443 is openend, that's one port.
The standard MS answer is to put the OWA in the LAN... besides that:
1. "making the isa server a member of the domain is opening a lot of ports, and you do not want that": as I already mentioned you could consider IPSEC 2. "but you have to open ports to the dc's (and nobody wants that)" In your design when you publish OWA you're opening ALL ports to your DC's via the OWA server...
So in general you prefer to open a connnection that:
a) can not be authenticated before it hits your production server (OWA) b) can not be inspected (unless you use SSL bridging).
But hey... it's your design and you do make some points but... it would not be my prefered solution...
Although I believe that the managability and monitoring benefits that come from ISA in a domain can lead to increased security, you are getting enough flack on that so I will focus on a couple other issues. First and foremost - you should AWLAYS pre-authenticate on ISA. If you are so concerned about security that you don't want ISA in the domain then I am confused how the organization can justify allowing un-authenticated users all the way into a domain member. By pre-authenticating on ISA you limit the number of people that can try application layer attacks on your web servers to only those with valid credentials and it is the most important security benefit that can be provided by ISA. By also leveraging an FBA you can time-out the users session.
You can also use an advanced authentication filter like FlexAuth from www.collectivesoftware.com for more advanced authentication and security options such as some protections against account lockout DOS attacks and the option of using Secure LDAP instead of Radius.