Exchange front-end back-end

May 8 2008   5:49AM GMT

Microsoft Exchange Edge Subscription Process

Posted by: John Bostock
Exchange, ADAM, Microsoft Edge Subscription Process, Edge Transport, Edge Transport Agents, Exchange front-end back-end, Exchange Roles, Exchange Server Roles 2007, Edge Transport Server Role

This post provides information about Edge Subscriptions and the EdgeSync synchronization process. Edge Subscriptions are used to populate the Active Directory Application Mode (ADAM) directory service instance on the Microsoft Exchange Server 2007 Edge Transport server role with Active Directory directory service data.

If you have been following these posts you will see from this extract that ADAM has a role.

The computer that has the Edge Transport server role installed doesn’t have access to the Active Directory directory service. All configuration and recipient information is stored in the Active Directory Application Mode (ADAM) directory service

The Edge Subscription Process

Creating an Edge Subscription establishes secure, automatic replication of information from Active Directory to ADAM. The Edge Subscription process provisions the credentials that are used to establish a secure Lightweight Directory Access Protocol (LDAP) connection between Hub Transport servers and a subscribed Edge Transport server. The Microsoft Exchange EdgeSync service that runs on Hub Transport servers then performs periodic one-way synchronization to transfer data to ADAM and keep that data up to date. This process reduces the administration that you must perform in the perimeter network by letting you perform required configuration on the Hub Transport server role and then write that information to the Edge Transport server.

You subscribe an Edge Transport server to an Active Directory site. Subscribing the Edge Transport server to the Active Directory site enables the Edge Transport server to receive updates to ADAM from Active Directory and creates a synchronization relationship between the Edge Transport server and the Hub Transport servers deployed in that site. The Edge Subscription process also creates an Active Directory site membership affiliation for the Edge Transport server. The site affiliation enables Hub Transport servers in the Exchange organization to relay messages to the Edge Transport server for delivery to the Internet without having to configure explicit Send connectors.

One or more Edge Transport servers can be subscribed to a single Active Directory site. However, an Edge Transport server cannot be subscribed to more than one Active Directory site. If you have more than one Edge Transport server deployed, each server can be subscribed to a different Active Directory site. Each Edge Transport server requires an individual Edge Subscription. A subscribed Edge Transport server can support only one Exchange organization.

In my next post I’ll talk about the process itself..

May 7 2008   3:14PM GMT

Exchange 2007 Edge Transport Agents

Posted by: John Bostock
Exchange, Edge Transport Agents, 10 Reasons for Exchange 2007, Edge Transport, Exchange front-end back-end, Exchange Roles, Exchange Server roles, Front End, Front-end Exchange Server, Edge Transport Server Role

 In my last post you would have noticed that Exchange 2007 comes with additional protection in the form of agents. Maybe someone at Microsoft is a big fan of the Matrix I dont know. But i briefly wanted to cover agent roles on the Edge Server…

Additional layers of message protection and security are provided by a series of agents that run on the Edge Transport server and act on messages as they are processed by the message transport components. These agents support the features that provide protection against viruses and spam and apply transport rules to control message flow.
Edge Transport Rules

Edge Transport rules are used to control the flow of messages that are sent to or received from the Internet. The Edge Transport rules help protect corporate network resources and data by applying an action to messages that meet specified conditions. These rules are configured for each server. Edge Transport rule conditions are based on data, such as specific words or text patterns in the message subject, body, header, or From address, the spam confidence level (SCL), or attachment type. Actions determine how the message is processed when a specified condition is true. Possible actions include quarantine of a message, dropping or rejecting a message, appending additional recipients, or logging an event. Optional exceptions exempt particular messages from having an action applied.

Address Rewriting

You use address rewriting to present a consistent appearance to external recipients of messages from your Exchange 2007 organization. You configure the Address Rewriting agent on the Edge Transport server role to enable the modification of the SMTP addresses on inbound and outbound messages. Address rewriting is especially useful when a newly merged organization that has several domains wants to present a consistent appearance of e-mail addresses to external recipients.

Edge Rules Agent

The Edge Rules agent, which runs on the Edge Transport server, helps you control the number of unwanted messages that enter your organization. If your internal network is compromised, the Edge Transport rule agent can also apply the same or different rules to outgoing messages. In this manner, the Edge Rules agent helps you prevent infected or unwanted messages that are generated by infected computers in your internal network from leaving your organization. The following list provides some examples of when the Edge Rules agent can help you protect your organization:

Virus outbreaks   Thousands of new viruses are created each year. Most antivirus software providers are reactive when they update their software. To update their software, antivirus software providers have to identify the virus, create an update for their software, and then send the update to their customers. This causes a gap in protection where an infected message can enter an organization unexpectedly.

Denial of service attacks   Malicious individuals who want to do harm to organizations may use denial of service (DoS) attacks to draw attention to themselves or to cause damage. These attacks are typically unannounced and can be difficult or impossible to predict.

The Edge Rules agent is designed to help you reduce the impact of each of these risks. The Edge Rules agent lets you configure conditions and exceptions to identify both unwanted and wanted messages and to act on those messages by using configured actions.

Anti-Spam and Antivirus Scanning

In Exchange 2007, the anti-spam and antivirus features provide services to block viruses and spam, or unsolicited commercial e-mail, at the network perimeter. Most viruses use spam-like tactics to gain access to your organization and to entice users to open an e-mail message. If you can filter out most of your spam, you are also more likely to capture viruses before they enter your organization.

Spammers use a variety of techniques to send spam into your organization. Servers that run the Edge Transport server role help prevent users in your organization from receiving spam by providing a collection of agents that work together to provide different layers of spam filtering and protection. Establishing tarpitting intervals on connectors makes e-mail harvesting attempts ineffective.

The Sender ID agent

The Sender ID agent relies on the RECEIVED Simple Mail Transfer Protocol (SMTP) header and a query to the sending system’s domain name system (DNS) service to determine what action, if any, to take on an inbound message.

When you configure anti-spam agents on an Edge Transport server, the agents act on messages cumulatively to reduce the number of unsolicited e-mail messages that enter the organization.

Sender ID is intended to combat the impersonation of a sender and a domain, a practice that is frequently called spoofing. A spoofed mail is an e-mail message that has a sending address that was modified to appear as if it originates from a sender other than the actual sender of the message.

Spoofed mails typically contain a From: address that purports to be from a certain organization. In the past, it was relatively easy to spoof the From: address, in both the SMTP session, such as the MAIL FROM: header, and in the RFC 822 message data, such as From: “Michael Smith” Michael@mydomain.com, because the headers were not validated.

May 3 2008   2:48PM GMT

Exchange Server Front and Back-ends.

Posted by: John Bostock
Exchange Server roles, Exchange DMZ, Front-end Exchange Server, Backend Exchange server, Backend, Front End, Exchange front-end back-end, Exchange

I currently running a Front –end / Back-end scenario in a DMZ and have been for two years. It’s worked well… but has been compromised so it’s not full proof, although that was down to other circumstances. The Front-end / Back-end configuration is available in both Microsoft Exchange 2000 Server and Microsoft Exchange Server 2003 and the basic principal is to divide server roles. The distinction is made between a front-end server that accepts requests from clients and then proxies them to an appropriate server for processing, making this effectively a Back-end server.

Scenarios

• According to the Microsoft documentation a Front-end / Back-end scenario comes to play when you experience or foresee experiencing performance, scalability or security issues with Microsoft Exchange:

Performance

• From a performance point of view you can deploy Front-end servers to lift the burden of SSL securing your Outlook Web Access (OWA) and Outlook Mobile Access (OMA), POP3 and IMAP from your Back-end server. Blocking Unsolicited Bulk E-mail (UBE or Spam) at the Front-End might speed up your Back-end to Outlook clients connected to the Back-end server.

Scalability

• From a scalability point of view you can use the configuration to make a neat Network Load Balanced (NLB) cluster of Front-end servers. Don’t use Clustering Services though to scale your Front-end servers, it won’t work.

Security

• Despite the performance and scalability improvements you can gain from implementing a Front-end / Back-end configuration you cannot use it by itself in any security scenario. Encrypting traffic with IPSec, Using the Security Configuration Wizard in Windows Server 2003 SP1 and even pinning down RPC ports will get you far, but in my opinion not far enough.

  In my opinion the security design flaw in the current Front-end / Back-end configuration is you actually install a fully fledged Exchange Server, which you afterwards strip of its databases and configure to relay everything to the back-end Exchange Server. It stays an Exchange Server however, which needs access to the Active Directory, DNS and other Exchange Servers. If you implement your Front-end server inside a DMZ you’ll be required to open up a whole lot of UDP and TCP ports, eventually rendering your DMZ pretty useless if the box gets compromised.

Yes I’m knocking it and Yes it works. In my next post I’ll look at the new flavours from Exchange Server2007