Hi, The problem that I see in this scenario is that Front End needs to communicate with Back End Exchange server and domain controllers in LAN. Unfortunately this means that you have to open access from DMZ to LAN to (at least) all domain controllers in same Active Directory Site that Exchange Front End is in -- unless you want to statically specify to which domain controllers Front End Server can connect to (not recommended).
If you are thinking about IPSec policies in Windows then you have to know that IPSec between client (e.g. your Front End Server) and domain controller is not supported -- specially if you plan to use IPSec with Kerberos authentication. Things you can do: - you can set up IPSec between Front End, Back End and domain controller (but you are not supportable any more) - you can fix ports that Exchange and Active Directory server(s) will use and then open these ports from DMZ to LAN Still one question remains... What is DMZs role in all this? It is unfortunately not protecting LAN :-). Now if someone hacks your server (for any reason) -- the attacker can simply use IPSec connection to gain access to Back End and Active Directory (and if you have IDS it will not even see the attack). Depending on the attack options (did the attacker get the domain admin permissions) he could simply run dcpromo on this server and promote it to domain controller. Now you have a domain controller in DMZ... Mike -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 16, 2006 2:51 AM To: [email protected] Subject: Re: Front End/Back End communication I know the ISA 2004 is the recommended way to deploy but at this point using ISA isn't an option. What I meant by opening each individual port was that for some reason I was thinking that instead of opening ports, 443, 389, 3268, 88, and whatever else, I could tunnel everything via IPSEC. I would only have to allow that to pass through the firewall instead of each one of the ports that are required for the Front End Server to communicate with the Back End Server. So I thought all of that information would traverse the IPSEC tunnel and then the application/server itself would decrypt the tunnel and then use whatever ports it needs. I wish I could draw in e-mail....I think it would less non-sense if I could draw a diagram. Either way I guess I was wrong. So now it's starting to look like I don't have too many options? I don't have an ISA Server. What types of functionality might it break if we try to use NAT-T? Everything I've read from microsoft so far says to use ISA server. So I've been trying to figure out a secure, reliable alternative. Devin Ganger <[EMAIL PROTECTED]> wrote: At Monday, May 15, 2006 10:29 AM, [EMAIL PROTECTED] wrote: > I'm curious about how people are implementing FE/BE Exchange > communication. It absolutely kills me that all of this traffic is > being transported through all of these ports via clear text. IPSec is the recommended way to secure it. > I thought about encrypting all of it using IPSEC but we are using NAT > between the DMZ and the Internal firewall. So all the traffic will > get dropped. You can pass IPSec through NAT firewalls: NAT-T (NAT Traversal). However, that design has got to breaking other functionality. Your FE server (in your DMZ) has to be a member of the AD domain/forest, which means it needs to be able to initiate connections into the protected network. At the very least, you need to get these two subnets on a routing relationship with each other (that is, have your firewall perform NAT if it's coming from the protected network destined externally, but not between the protected network and the DMZ). Your firewall people (if they're not you) will probably stop listening right about now, but you should remind them that NAT *is not* a security measure and is intended to conserve publicly routable IP addresses. > Another > question is, even if you do use IPSEC do you still need to open the > individual ports? My understanding is that you don't but someone is > telling me that you do. What do you mean by "open the individual ports"? You're not using IPSec to tunnel traffic in this config, so you can just say "Encrypt all communications to IP address M.N.O.P" -- but then the intervening firewall will need to allow the proper protocols through (and there are a LOT of them for an FE in the DMZ). Better yet, get an ISA Server 2004 box and put *that* in your DMZ. Then you can move the FE back to the protected network where it belongs, with all of the advantages: 1) You can easily apply a single IPsec policy via Group Policies for your Exchange servers. Any new Exchange servers you stand up in the future will automatically use IPSec just by being a member of the correct OU. 2) Your firewall configuration between the DMZ and protected network stops resembling Swiss cheese, as you can close down the holes for Kerberos, LDAP, GC lookups, SMB, DNS, SMTP, MAPI, and more. 3) You get an application-level proxy that filters incoming SMTP and HTTP requests and drops malformed/corrupt ones on the floor before they ever get to your Exchange server. Microsoft publishes some good guidance on the various FE/BE options and their security implications. The first guide you should read (if you haven't already) is the _Exchange Server 2003 and Exchange 2000 Server Front-End and Back-End Topology_ guide: http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/febet op.mspx -- Devin L. Ganger Email: [EMAIL PROTECTED] 3Sharp LLC Phone: 425.882.1032 x 109 15311 NE 90th Street Cell: 425.239.2575 Redmond, WA 98052 Fax: 425.702.8455 (e)Mail Insecurity: http://blogs.3sharp.com/blog/deving/ ------------------------------------------------------------------------ --- ------------------------------------------------------------------------ --- --------------------------------------------------------------------------- ---------------------------------------------------------------------------
