The Exchange 2010 Edge Transport server
role can provide you with an additional layer of email protection
between your mail servers and the Internet, with the added advantage of
using the same management interface as the rest of Exchange 2010.
1. Some Background Information on Edge Transport
Microsoft decided shortly after the release of
Exchange Server 2003 that the Exchange server platform was not the best
place for preliminary virus and spam inspection. Neither was it a good
idea to put Active Directory member servers in the perimeter network.
After all, an Exchange server is a member of the Active Directory and
requires connectivity to other Exchange servers as well as the Active
Directory domain controllers and global catalog servers. To build an
Exchange 2000/2003 server for handling just message transfer, a number
of unnecessary components had to be installed. The Information Store
service even had to remain running. If this server were compromised,
the entire network could be exposed.
The Edge Transport server was developed with minimal
messaging functionality but with a certain amount of "knowledge" of
your internal recipients and infrastructure. Essentially, it is nothing
more than a message transport engine that allows for the plug-in of
additional components such as transport rules, antispam agents, and
antivirus software. Edge Transport does not communicate directly with
or even require Active Directory; instead, Edge Transport uses the
Microsoft Active Directory Lightweight Directory Services (AD LDS)
module (formerly known as Active Directory Application Mode
Application, or ADAM) database for its configuration.
The Hub Transport server runs a service called
Microsoft Exchange EdgeSync that pushes configuration data, recipient
information, and safe sender, blocked sender, and safe recipient lists.
The EdgeSync process replicates the following data from the internal
Active Directory to the AD LDS database:
A list of all Exchange recipient data, including the following:
Recipient
information, such as the list of recipients in the Exchange
organization. Each recipient is identified by the GUID assigned to it
in Active Directory. If you configure a recipient's user account to
deny receipt of mail from outside the organization, the recipient is
not replicated to the AD LDS database. If you disable or delete the
mailbox for a recipient, it is not replicated to AD LDS.
SMTP
email addresses for all valid recipients (mail-enabled users, contacts,
groups, and public folders). All proxy addresses assigned to each
recipient are replicated to AD LDS as hashed data. This is a one-way
hash that uses Secure Hash Algorithm (SHA) 256. SHA-256 generates a
256-bit message digest of the original data. Storing proxy addresses as
hashed data helps secure this information in case the Edge Transport
server or AD LDS is compromised. Proxy addresses are referenced when
the Edge Transport server performs the recipient lookup antispam task.
Safe sender, blocked sender, and safe recipient lists for each user
Per-user anti-spam settings (configured via the Set-Mailbox cmdlet)
The list of internal accepted domains
The list of remote domains
Configured message classifications
Send connector configuration
TLS Send and Receive Domain Secure lists
The Internal SMTP Servers list
The list of Hub Transport servers in the subscribed Active Directory site
Edge Transport rules are based on SMTP addresses,
not Active Directory objects—but you can use the SMTP addresses of
mail-enabled groups. For the most part, the Edge Transport rules are a
subset of hub rules—the exception is Quarantine, which is available
only on the edge, because it is intended for spam.
As an added advantage, the Edge Transport server is
managed using the same management tools (the EMC, EMS, Queue Viewer,
Best Practices Analyzer, and so on) you use to manage other Exchange
2010 server roles, so no steep learning curve is associated with
deploying the Edge Transport server role.
2. Placement of the Edge Transport Server
To maximize the security benefits, we recommend that
the Edge Transport server be deployed in your perimeter network, as
shown in Figure 1. The organization's DNS MX record directs inbound email to the Edge Transport server that is located in the perimeter network.
The Edge Transport server performs antispam and
antivirus functions and then passes messages on to an internal Hub
Transport server. The firewall is configured so that TCP port 25
inbound from the Internet is allowed only to the Edge Transport server.
Likewise, the internal firewall only allows inbound TCP port 25 from
the Edge Transport server in the perimeter network and only to the Hub
Transport server on the internal network.
The Edge Transport server has specific antispam
transport agents installed that handle different types of filtering,
analysis, and transport rules. Table 1
shows the transport agents that are installed on an Edge Transport
server. All the transport agents are installed and enabled by default.
Table 1. Edge Transport Server Transport Agents
| Agent | Features Provided |
|---|
| Address Rewriting Inbound agent | Messaging policy and compliance |
| Address Rewriting Outbound agent | Messaging policy and compliance |
| Attachment Filter agent | Antispam and antivirus |
| Connection Filter agent | Antispam and antivirus |
| Content Filter agent | Antispam and antivirus |
| Edge Rule agent | Messaging policy and compliance |
| Protocol Analysis agent | Antispam and antivirus |
| Recipient Filter agent | Antispam and antivirus |
| Sender Filter agent | Antispam and antivirus |
| Sender ID agent | Antispam and antivirus |
2.1. Setting Up the Edge Transport
This section goes through a sample configuration of the Edge Transport server and the Hub Transport server, as illustrated in Figure 2.
The internal firewall must first be configured to allow certain types
of inbound and outbound connectivity between the internal network and
the perimeter network. Specifically, connectivity is required between
the Edge Transport server and the Hub Transport server. We have kept
this example really simple; you would need to scale this for additional
Hub Transport servers and Edge Transport servers.
This setup has the following requirements:
The Edge Transport server must be able to send SMTP (TCP port 25) to the Hub Transport server.
The Edge Transport server must have its fully qualified domain name (FQDN) configured.
The
Hub Transport server should be able to send SMTP to the Edge Transport
server if the Edge Transport server will be used for outbound mail.
The
Hub Transport server must also be able to communicate using the ports
designated for LDAP synchronization to the AD LDS database.
These
are either TCP port 50389 for regular LDAP or TCP port 50636 for secure
LDAP. You will usually use port 50389 unless you have configured AD LDS
on the Edge Transport to use SSL.
You might need to open additional ports through the
internal firewall and to the Edge Transport server if you want to use
the Remote Desktop Connection (RDP) client to manage the Edge Transport
server remotely. The RDP client uses TCP port 3389.
To configure simple mail flow between an Edge
Transport server and a Hub Transport server, you could just configure
the necessary send and receive connectors, but you would not be
receiving the full benefits of the Edge Transport role. To do so, you
need to configure Edge Synchronization (EdgeSync). This process
involves five basic steps:
Perform prerequisite checks and configuration settings.
Create an Edge Subscription file on the Edge Transport server.
Copy the Edge Subscription file to the Hub Transport server.
Import the Edge Subscription file and create a send connector for the Edge Subscription.
Start the Microsoft Exchange EdgeSync service on the Hub Transport server (if it's not already started).
You should perform all these steps within 24 hours
because the bootstrap account that is created with the Edge
Subscription file is only good for 24 hours from the time it was
created.
The Edge Subscription that you are creating will
work for all existing Hub Transport servers at the time you create it.
However, if you add additional Hub Transport servers into the Active
Directory site, you must create a new Edge Subscription for each Hub
Transport server that will communicate with the Edge Transport.
