There seems to be some confusion as to how TLS connectivity to Exchange 2007 works. Many people think, that by default, Client to Server SMTP communication to Exchange 2007 is not encrypted and are asking, “How to secure Client to Server SMTP communication.” Well the answer is, it already is…. Let me explain.
By default, in Exchange Server 2007, there are two receive connectors. One is for Server to Server SMTP and the other is for Client to Server SMTP which is really used for POP3/IMAP clients to send mail via SMTP. I will talk a bit later about clients who are directly connected via MAPI. For this article, we will be talking about Client to Server SMTP.

When creating a Receive Connector, there are several Usage Types that can be selected:

  • Client (Unavailable on Edge Transport Servers — External Client to Server SMTP must require direct access to the Hub Transport Server (not recommended) or use ISA 2006 to publish port 587 directly to a Hub Transport Server)
  • Custom
  • Internal
  • Internet
  • Partner

Depending on which Usage Type you select, certain Authentication Groups will be selected. For example, for our scenario, the Client Usage Type will allow the Permission Group of Exchange Users which is exactly what we need.
In Exchange 2007, Microsoft wanted to comply with updated RFC standards and kept Server to Server SMTP communication over port 25 and segregated Client to Server communications over port 587. More details are formalized in RFC 4409.

So how do we really restrict only authenticated clients to use TLS when talking over the SMTP protocol with Exchange Server 2007. This is really a combination of the Authentication and Permission Groups Tab. First, we will have a look at the Permission Groups Tab.

As you can see, this Client Receive Connector only allows the Exchange Users group by default. This means that when a user connects to Exchange and authenticates, they are defined as an Exchange User and are allowed access to use this connector and use the SMTP protocol over the port defined in the Network Tab; this case being port 587. Once authenticated, the Exchange Users are granted the following permissions:

  • Ms-Exch-SMTP-Submit
  • Ms-Exch-SMTP-Accept-Any-Recipient
  • Ms-Exch-Bypass-Anti-Spam
  • Ms-Exch-Accept-Headers-Routing

As you can see, the Exchange Users are allowed to Submit SMTP using this Receive Connector.
Now, we have to define if the Client to Server SMTP authentication for the selected Permission Groups is encrypted or not encrypted. This is done on the Authentication tab.

By default, Client to Server Authentication is encrypted using TLS via this Client Receive Connector. TLS is advertised and when using POP3/IMAP4, basic authentication, credentials will only be available after initiating a TLS encrypted connection.
As a side note, if you want to allow an anonymous application such as a Web Application to relay off of your Exchange 2007 server, you would do the following:

  1. Create a new Receive Connector with the Custom Usage Group
  2. For Remote Network Settings, remove 0.0.0.0-255.255.255.255, and then add the IP Address of the remote server that requires relaying permissions
  3. Once the new Custom Receive Connector is created, go into the properties of this connector, go to the Permission Groups Tab > Add Anonymous Users

If you look at the Authentication Tab, only Transport Layer Security will be selected. This is called Opportunistic TLS which means that TLS will be accepted and is the preferred method for communication, but TLS will not be required.
To activate Anonymous users to use this connector for relaying, you must issue the following command:
Get-ReceiveConnector “Receive Connector Name” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”
Note: If you enable Anonymous users on a connector, that does not give them the permission to relay. The above command gives the Anonymous Logon account permission to Ms-Exch-SMTP-Accept-Any-Recipient (relaying) on the specified connector. That way, once you have allowed anonymous users to use that connector as well as grant them Ms-Exch-SMTP-Accept-Any-Recipient, they will now be able to relay via the specified connector.
If your application will be relaying SMTP using separate domain names, make sure you create the necessary Accepted Domains with the appropriate Internal Relay or External Relay settings for those domains. You do not want to choose Authoritative because Exchange will think it is authoritative for these mailboxes, and when Exchange sees these mailboxes do not exist, an NDR will be sent back to the sending server.
For more information about when to choose Internal Relay vs External Relay, visit the following site:
http://technet.microsoft.com/en-us/library/bb124423(EXCHG.80).aspx
Now what about clients who are connected to their Exchange 2007 mailbox via MAPI? Clients using Remote Procedure Call (RPC) to connect to their Mailbox Server. This RPC connection is encrypted by default.
With Outlook being connected to its Mailbox Server with encrypted RPC, the Outlook Client will send a message and the Mailbox Server will place this item in the Outbox. The Mailbox Server will then submit the mail item to the Hub Transport Server with the Mail Submission Service which lives on the Mailbox Server. The Mailbox Submission Service will Round Robin between the Hub Transport Servers so not any given Hub Transport Server will be over utilized. One thing to keep in mind here is that if the Mailbox Server also contains the Hub Transport Role, this Hub Transport Role will be utilized 100% of the time unless the service stops. In this case, the Mailbox Server will start sending to other Hub Transport Servers. The Hub Transport’s Store Driver will pull this item from the Outbox and then place it into the Submission Queue which then starts the routing process.
As you can see, Outlook by default encrypts traffic between itself and Exchange.

If you want to enforce MAPI Encryption to your Exchange Server 2007 box, you can configure specific Exchange 2007 servers to force all MAPI connections to be encrypted by issuing the following command:
Set-MailboxServer ServerName -MAPIEncryptionRequired:$true
You can then install the Office Group Policy Templates to force all Outlook clients to use MAPI encryption:
Outlook 2003: Administrators can use Office policy templates with the Group Policy settings of Windows
Outlook 2007: How administrators can use Office policy templates together with the Group Policy settings of Windows
Now I will show you how you can load the Outlook 2007 template into Group Policy, and force all Outlook 2007 clients to use MAPI Encryption.
From the link above, I downloaded the Office 2007 templates and extracted the outlk12.adm file. I will now open the Group Policy Management Console and import this ADM file. To do this, expand Forest > Domains > Your Domain > Group Policy Objects > Right-Click and choose New. From here, specify the name of the GPO you want created.

From here, we can right-click our new Outlook 2007 GPO and choose edit which will bring us into the Group Policy Object Editor. Expand User Configuration and Right-Click Administrative Templates > choose Add/Remove Templates…

Once we choose Add/Remove Templates, will be presented with the following screen:

Choose Add and navigate to the location to where you extracted the outlk12.adm file. You will then be presented with the Microsoft Office Outlook 2007 Group Policy settings in the Administrative Templates.

Navigate to Microsoft Office Outlook 2007 > Tools | Account Settings > Exchange > Enable RPC Encryption

Right-Click Enable RPC Encryption and choose Enabled and then select OK.

Once this is done, you will need to link the GPO to any of your Organizational Units or to the root container of your domain alongside your Default Domain Policy. This all depends on your Group Policy/OU design. After this, it will take 90-120 minutes for all your clients to obtain this new setting. This can be expedited by running the following command on your clients:
gpupdate /force


Elan Shudnow



موضوعات مشابه: