Introducing Exchange Online Protection (EOP)

If you have yet to hear, Microsoft has retired their entire Forefront product suite.  For products which will continue such as Forefront Identity Manager, these products have been moved to the System Center product suite.

As part of this move to remove the Forefront product family, Forefront protection for Exchange (FPE) and Forefront Online Protection for Exchange (FOPE) are also being removed.
Forefront Protection for Exchange (FOPE) is being replaced with a new product called Exchange Online Protection (EOP).  When I say new, it is actually the next release of FOPE.  Exchange Online Protection is an online Microsoft cloud service for filtering email.  It can be implemented for both cloud based Exchange customers such as Office 365 as well as on-premises implementations of Exchange.

In terms of Forefront Protection for Exchange (FPE), a product which is installed on a Windows server in the customers environment - there is no replacement I'm currently aware of.  Apart from the integrated spam filtering functionality which comes as part of Microsoft Exchange, Microsoft do not offer an on-premises product which customers can install for filtering email spam.  Customers will be encouraged moving forward to adopt Microsoft's online cloud services for filtering spam which can be found under EOP.

Exchange Online Protection offers customers the following functionality:

• URL lists for spam filtering that block messages containing specific URLs within their message body. EOP includes additional lists beyond those available in FOPE.
• The ability to skip spam filtering for trusted senders, based on subscription lists
• The ability to filter messages written in specific languages, or sent from specific countries or regions
• Malware filtering that can delete and strip unsafe attachments
• The capacity to mark bulk email (such as advertisements) as spam through the user interface
• The capability to search for, view, or release quarantined email messages in the EAC
• Transport rules which you can use to control mail flow, based on a message’s content
• Message tracing capability, which allows you to search for and view details about a specific message
• Inbound connectors and outbound connectors you can use to enforce secure communication between you and a partner, or to make hybrid mail flow (where you host a portion of your mailboxes on-premises and a portion in the cloud) possible New reports, which you can use to monitor your organization’s mail flow, available in the Office 365 portal, by using a Microsoft Excel download application, or by using a Web service.

Previously FOPE had a seperate user interface to Office 365 for users to manage spam settings.  Microsoft has now consolidated this under the new Exchange Administrative Center (EAC).  For Exchange Online (Office 365) customers, EOP has now been intergrated directly into the EAC console, however for on-premises customers users will still need to go to another web address to access the online EAC for configuring Exchange Online Protection.

 

Below is a screenshot of the configuation interface for Exchange Online Protection (EOP):

 

 

Microsoft Axes the Forefront Product Suite

Today, Microsoft has announced that the Forefront product suite is no longer being continued.  Gartner started the rumours quite some time ago claiming that Microsoft was no longer going to continue Threat Management Gateway, however who would have thought this was to extend to the entire Forefront product suite.

Please read the following article by Forefront TMG MVP, Richard Hicks:

http://tmgblog.richardhicks.com/2012/09/12/forefront-tmg-2010-end-of-life-statement/

For the official annoucement from Microsoft please see:

http://blogs.technet.com/b/server-cloud/archive/2012/09/12/important-changes-to-forefront-product-roadmaps.aspx

Hybrid Office 365 Deployment with Threat Management Gateway

After working with a Hybrid Office 365 deployment with Threat Management Gateway performing SSL offloading to an Exchange 2010 SP2 hybrid server for one of my customers I experienced a number of gotcha's which are not documented.

MRSProxy with SSL Offloading

The first issue was with MRSProxy. I found out the hard way that MRSProxy "/EWS/mrsproxy.svc" does not support SSL offloading. The MRSProxy connection must hit the Exchange 2010 Client Access Server on TCP443 using a secure SSL connection. When using SSL offloading with Forefront Threat Management Gateway as soon as unsecure HTTP port 80 connections were passed to MRSProxy on the Exchange 2010 Hybrid server we were receiving was (404) Not Found in the IIS logs.

We created a separate TMG firewall rule with a path rule of "/EWS/mrsproxy.svc" which is processed before our Hybrid firewall rule. This path rule re-encrypts and forwards to the Hybird server on TCP443. All other connections come through on TCP80.

Free/Busy with Office 365

The second issue was with free/busy. Users on-premises were able to view Free/Busy for users in Office 365, however users in Office 365 were unable to view Free/Busy for users on-premises. This was caused by the Web Listener being configured for Basic or Windows Integrated authentication. Free/Busy over an Organization Relationship uses Microsoft.Web.Services.SoapContext to authenticate free/busy... in other words the authentication is handled by the .NET framework. Threat Management Gateway must pass through authentication requests to /EWS/*. Setting the TMG listener to No Authentication achieves this.

Forefront Threat Management Gateway - Workgroup Configuration with Exchange 2010

In this post I will give you some information around publishing Exchange 2010 with Forefront Threat Management Gateway (TMG) or ISA 2006 and weather or not these servers should have domain membership.

Microsoft's recommended deployment is that you add your TMG servers as members of your Active Directory domain. For the TMG setup whitepaper please see the following link. This whitepaper explains how to setup TMG step by step with domain membership.

http://download.microsoft.com/download/E/5/6/E56ACB6E-7BCC-40F1-8F18-E636B7BFE088/PublishingExchangeServer2010withForefront.doc

When Microsoft initially released Threat Management Gateway, it did not support workgroup configuration. It's a product that is designed to run as a member of your Active Directory domain and configuring it any other way results in significant loss in functionality and in some cases security. I managed to find a copy of the original release notes published by Microsoft which is available here... stating that TMG does not support workgroup configuration. http://technet.microsoft.com/en-us/library/cc487898.aspx

Previous versions of the product such as ISA2006 did support workgroup configuration and some companies implemented it in this method. There was an outcry and as a result Microsoft changed their stance on this and updated the product to support domain membership.

Can you publish Exchange 2010 using TMG without adding the Threat Management Gateway server as a member of your internal Active Directory domain? Yes you can, there are 3 ways to do this:

- Configure another Active Directory domain to hold TMG. Create a Transitive Forest Trust between your production forest and your TMG forest. Create domain local groups on the TMG Active Directory forest and nest any groups that require access rules inside the TMG forest’s domain local groups.

- Configure an internal PKI, if you want security you need to ensure you have an offline root stand-alone CA, and a subordinate enterprise issuing CA which is AD Integrated. Issue a digital certificate to each domain controller and configure your environment to support LDAP over SSL for AD Authentication. To configure your domain controllers to support LDAPS using SSL see http://support.microsoft.com/kb/321051

- Configure a RADIUS server on your internal network. Configure the TMG server as a RADIUS client to pass through authentication requests to the RADIUS server. The RADIUS server will then pass the authentication request through to Active Directory. You will not get Outlook Anywhere working if your using RADIUS authentication, see http://blogs.isaserver.org/pouseele/2007/02/06/a-quest-for-strong-user-authentication-with-rpc-over-http-services-and-isa-server-2006/

All three of these options have the following disadvantages:

- Will require additional servers weather its certificate authorities, radius servers or domain controllers to run a new AD forest.

- Will extend the project life cycle from an originally estimated 2 weeks to 4-8 weeks depending which of the 3 options you wish to go down.

- Increase complexity of your network and increase downtime periods should infrastructure fail as this is not a highly available deployment.

Neither of these solutions add any significant layer of security and are not seen as efficient solutions due to the Administrative overhead they create.

In a Microsoft whitepaper written by Greg Taylor "Publishing Outlook Anywhere Using NTLM Authentication With Forefront TMG or Forefront UAG", Greg dedicated a section around joining Forefront TMG/Forefront UAG to an Active Directory domain or leaving it workgroup. For a copy of this article see the following URL:

http://www.microsoft.com/download/en/details.aspx?id=22723

Here is an extract from Greg Taylors whitepaper:

"Domain Joining Forefront TMG/Forefront UAG or Leaving in a Workgroup"

In most organizations, the decision whether to domain join the server hosting Forefront TMG/Forefront UAG to your production domain may be one of the more contentious parts of the deployment.

For Forefront UAG deployments, the guidance is clear. Because Forefront UAG is not a firewall, it should be placed behind some other device that acts as a firewall on the corporate network. Also, it's recommended that Forefront UAG be domain joined to make authentication simple and flexible. Forefront TMG is installed on the Forefront UAG computer during installation, but that's done only to protect the host system and for the underlying functionality it provides to Forefront UAG.

Forefront TMG deployments are more complex to discuss because Forefront TMG is considered a firewall and can protect the network edge. Domain joining Forefront TMG offers many advantages: it allows certificate based authentication to be used at Forefront TMG, using Kerberos Constrained Delegation to communicate to Exchange; it allows easy use of Active Directory groups and user objects in publishing rules to restrict access; and it provides other benefits. For an impartial view on whether to domain join Forefront TMG, see Debunking the Myth that the ISA Firewall Should Not be a Domain Member. For more information about identifying your infrastructure design requirements, see Domain and workgroup requirements.

The link Greg Taylor mentions in his white paper "Debunking the Myth that the ISA Firewall Should Not be a Domain Member" by Thomas W Shinder, Microsoft MVP is an excellent read. Please view it here:

http://www.isaserver.org/tutorials/Debunking-Myth-that-ISA-Firewall-Should-Not-Domain-Member.html

In Thomas's article he mentions:

ISA/TMG that is a domain member machine is more secure and more flexible than a non-domain member machine and that they do themselves and their companies a disservice by not joining the ISA firewall to the domain. This is a significant issue and not something to be taken lightly because there is a serious security hit you take when you don’t join the ISA firewall to the domain.

He also covers in his article the primary reason companies go through all this effort of not joining the TMG/ISA server to the internal domain, compliance managers and external auditors that believe in this myth. He writes:

Should the ISA firewall array be placed in a domain or a workgroup? That is the question. Is it nobler to place the ISA firewall in a workgroup where you can avoid the catcalls of clueless compliance managers, "hardware" firewall know-nothings, or “network guys” who think of network security as "port opening and closing", or should you bear the slings and arrows of the same harridan housewives and carping screws for placing the ISA firewall in the domain, where you can get a higher level of overall security and substantially improve your security position?

The last article I would like to point you at is a TechNet article published by Microsoft around considerations when and when not you would place your TMG server as a member of your internal Active Directory domain. Please view this article here:

http://technet.microsoft.com/en-us/library/dd897048.aspx

I would like to finalise by saying majority of TMG deployments should all be a member of your Active Directory domain especially if your just publishing Exchange 2010. However there may be circumstances where your using your TMG server for things other then just Exchange and you may need to look at implementing TMG in a workgroup configuration.

Joining Forefront Threat Management Gateway 2010 to an Active Directory domain to publish Exchange 2010 services to the Internet is not a security threat to your network.

Forefront Client Security Server Components Supported Operating Systems

Forefront Client Security (FCS) Server Components are not supported on all operating systems.

The Management Server must be setup on one of the following windows operating systems:

- Windows Server 2003 SP2 or later, Standard or Enterprise

- Windows Server 2008 Standard or Windows Server 2008 Enterprise

- Windows Server 2008 Standard SP1 or later, or Windows Server 2008 Enterprise SP1 or later

The following operating systems are not supported:

- Windows Server 2008 Server Core installation

- Windows Server 2008 R2

- x64 and Itanium server editions

- Microsoft Windows Small Business Server 2003

- Windows Small Business Server 2003 R2

- Windows Small Business Server 2008

For more information please see:

http://technet.microsoft.com/en-us/library/bb404245.aspx

Autodiscover issue with ISA2006 or Forefront TMG

I had a client where autodiscover was working fine internally however external clients could not perform autodiscover requests. The client is running forefront threat management gateway 2010.

When running the exchange remote connectivity analyzer from http://www.testexchangeconnectivity.com I received the following error:

ExRCA is attempting to send an Autodiscover POST request to potential Autodiscover URLs.
Autodiscover settings weren't obtained when the Autodiscover POST request was sent.
Test Steps
Attempting to Retrieve XML AutoDiscover Response from url https://autodiscover.vnc.qld.edu.au/AutoDiscover/AutoDiscover.xml for user administrator@vnc.qld.edu.au
Failed to obtain AutoDiscover XML response.
Tell me more about this issue and how to resolve it
Additional Details
An HTTP 403 error was received because ISA Server denied the specified URL.

ExRCA is attempting to contact the Autodiscover service using the HTTP redirect method.
The attempt to contact Autodiscover using the HTTP Redirect method failed.
Test Steps
Attempting to resolve the host name autodiscover.vnc.qld.edu.au in DNS.
Host successfully resolved
Additional Details
IP(s) returned: 203.206.132.236

Testing TCP Port 80 on host autodiscover.vnc.qld.edu.au to ensure it is listening and open.
The port was opened successfully.
Checking Host autodiscover.vnc.qld.edu.au for an HTTP redirect to AutoDiscover
ExRCA failed to get an HTTP redirect response for Autodiscover.
Tell me more about this issue and how to resolve it
Additional Details
An HTTP 403 error was received because ISA Server denied the specified URL.

ExRCA is attempting to contact the Autodiscover service using the DNS SRV redirect method.
Failed to contact AutoDiscover using the DNS SRV redirect method.
Test Steps
Attempting to locate SRV record _autodiscover._tcp.vnc.qld.edu.au in DNS.
The Autodiscover SRV record wasn't found in DNS.
Tell me more about this issue and how to resolve it




To resolve this open the exchange rule on your ISA server or TMG. On the public names tab add the autodiscover record.



On the paths tab add in the autodiscover directory.

Exchange 2010 with Threat Management Gateway

How to publish Exchange 2010 through Threat Management Gateway (TMG)

http://download.microsoft.com/download/E/5/6/E56ACB6E-7BCC-40F1-8F18-E636B7BFE088/PublishingExchangeServer2010withForefront.doc

Microsoft Forefront TMG Standard vs Enterprise

Your looking at implementing Microsoft Forefront TMG (Threat Management Gateway). This is the new version of ISA (Internet Security and Acceleration) server.

Forefront only comes in x64... but do you need Standard Edition or Enterprise Edition. With a big difference in price you want to know what your getting.

A feature comparison chart between the two versions can be found on the following Microsoft website:

http://technet.microsoft.com/en-us/library/ee207137.aspx