locked
Firewall Ports for Exchange Server 2007 RRS feed

  • Question

  • Hi,

    I have Windows 2003 server kept in DMZ zone on which we have installed the Exchange 2007 SP2 Managment Console and this server is being used by our Support team which is sitting outside our organization.

    This Windows 2003 Server is a member of our domain in which exchange 2007 SP2 is installed. Our Support team will use this server to do the mailbox provisioning. Also, in our Exchange Environment, static port mapping has been done.

    So, here, i would like to understand that what are all the firewall ports that needs to be opened from Windows 2003 Server which is kept in DMZ zone so that our support team will be able to do the mailbox provisioning.

    Regards,

    Vikas

     


    Vikas Kumar
    Thursday, September 15, 2011 1:30 PM

Answers

  • Personally, I would have considered a different approach as well. With Exchange 2010, it could have been accomplished easier due to the PowerShell Remoting feature, which uses WS-Management. With Exchange 2007, all cmdlets run in the host process of the management server itself. The management server then establishes RPC connections to the Exchange servers that you are manipulating.

    I'm not sure how you do static port mappings for this kind of service access, and I cannot see that this is covered in the Data Path Security Reference.  

    Then don't forget this server is a domain member. You need to initialize tcp/udp 53 (DNS), tcp/udp 88 (Kerberos), udp 123 (Time Synchronization, tcp 389 (LDAP), tcp 445 (SMB, logon, LDAP conversion), tcp 3268 (LDAP to global catalogs). Then there's tcp 135 (Endpoint Mapper), which by default will return ports above 1024 (or higher, depending on your Windows version).

    I think you'll have to initialize a lot too many ports from your DMZ to your internal network. Another solution would be to publish RDP with ISA 2006 / TMG 2010 and have your Exchange 2007 Management Server in your internal network.

    ISA / TMG would either be part of a workgroup in the DMZ, or domain-joined, with on leg in the DMZ and one leg internally. ISA / TMG are hardened servers that are not very vulnerable to attacks.

    Microsoft Forefront TMG – Publishing RD Web Access with RD Gateway (Part 1)
    http://www.isaserver.org/tutorials/Microsoft-Forefront-TMG-Publishing-RD-Web-Access-RD-Gateway-Part1.html

    Publishing Remote Desktop Service with Forefront TMG 2010
    http://msmvps.com/blogs/wssra/archive/2010/01/14/publishing-remote-desktop-service-with-forefront-tmg-2010.aspx


    MCTS: Messaging | MCSE: S+M
    • Marked as answer by Xiu Zhang Friday, September 23, 2011 5:01 AM
    Thursday, September 15, 2011 8:48 PM
    • Marked as answer by Xiu Zhang Friday, September 23, 2011 5:00 AM
    Thursday, September 15, 2011 1:31 PM

All replies

    • Marked as answer by Xiu Zhang Friday, September 23, 2011 5:00 AM
    Thursday, September 15, 2011 1:31 PM
  • Personally, I would have considered a different approach as well. With Exchange 2010, it could have been accomplished easier due to the PowerShell Remoting feature, which uses WS-Management. With Exchange 2007, all cmdlets run in the host process of the management server itself. The management server then establishes RPC connections to the Exchange servers that you are manipulating.

    I'm not sure how you do static port mappings for this kind of service access, and I cannot see that this is covered in the Data Path Security Reference.  

    Then don't forget this server is a domain member. You need to initialize tcp/udp 53 (DNS), tcp/udp 88 (Kerberos), udp 123 (Time Synchronization, tcp 389 (LDAP), tcp 445 (SMB, logon, LDAP conversion), tcp 3268 (LDAP to global catalogs). Then there's tcp 135 (Endpoint Mapper), which by default will return ports above 1024 (or higher, depending on your Windows version).

    I think you'll have to initialize a lot too many ports from your DMZ to your internal network. Another solution would be to publish RDP with ISA 2006 / TMG 2010 and have your Exchange 2007 Management Server in your internal network.

    ISA / TMG would either be part of a workgroup in the DMZ, or domain-joined, with on leg in the DMZ and one leg internally. ISA / TMG are hardened servers that are not very vulnerable to attacks.

    Microsoft Forefront TMG – Publishing RD Web Access with RD Gateway (Part 1)
    http://www.isaserver.org/tutorials/Microsoft-Forefront-TMG-Publishing-RD-Web-Access-RD-Gateway-Part1.html

    Publishing Remote Desktop Service with Forefront TMG 2010
    http://msmvps.com/blogs/wssra/archive/2010/01/14/publishing-remote-desktop-service-with-forefront-tmg-2010.aspx


    MCTS: Messaging | MCSE: S+M
    • Marked as answer by Xiu Zhang Friday, September 23, 2011 5:01 AM
    Thursday, September 15, 2011 8:48 PM
  • I'm not sure how you do static port mappings for this kind of service access, and I cannot see that this is covered in the Data Path Security Reference.  

    Look under  "Admin remote access" under the Mailbox server data paths section.

     

     

     

    Thursday, September 15, 2011 9:03 PM
  • I see these two items:

    * Admin remote access (Remote Registry) 135/TCP (RPC)
    * Admin remote access (SMB/File) 445/TCP

    But there must be more to it than this, to run PowerShell in the context of the local Admin box and do RPC calls to Exchange and global catalogs. How would you do static port mappings for the RPC-based communication between the Exchange admin server and the Exchange servers (mailbox, Hub, CAS)?

    I believe, but am not sure at all, that this type of communications belongs to the type of MAPI RPC that has made Microsoft tell us that Exchange servers in the DMZ is unsupported.


    MCTS: Messaging | MCSE: S+M

    Thursday, September 15, 2011 9:24 PM
  • Well, I am assuming he already has that covered since that server is apparently already part of the AD domain and they already have static ports mapped. Of course once the actual work is done if things dont work, its a matter of checking the firewall logs to see which packets are being dropped.

     

    Now, you and I, we wouldnt do this. And I certainly wouldnt recommend it to anyone. I would rather provide VPN access to a dedicated mgmt server on the LAN or RDP from the DMZ, but perhaps there is some business value to them.  :)

     

     

     

    Thursday, September 15, 2011 9:40 PM
  • Cool, thanks man !

    /* Server Support Specialist */

    Friday, September 6, 2013 3:04 AM