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:
- Create a new Receive Connector with the Custom Usage Group
- 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
- 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:
https://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: https://support.microsoft.com/kb/826170
Outlook 2007: https://support.microsoft.com/kb/924617
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
yaron says
very good article
Bunmi Taiwo says
Hi, I have a mail server hosted in Houston using smarter mail facilities while my Exchange server reside in Nigeria. My Exchange server in Nigeria pull mails from the mail server in Houston using POP3 on Port 110. I later introduced an anti spam equipment SENDIO ESP which is an SMTP based machine.I want all my inbound emails to pass through the SENDIO ESP for filtering the mails from spams. Make challenges is that my mails just enter my Exchange server directly. How can I configure the Houston mail server to start forwarding mails to my SENDIO ESP machine.
brett says
hi i am trying to modify calendar permissions VIA GPO but i'm unable to find the setting that controls if users can read e free/busy time,or free/busy time,subject, location or full details
i have modified the control calendar option so Allow calendar sharing with 'Availability Only' and 'Limited Details' detail level is enabled but still i can choice between the three different levels.
I have applied this GPO to an OU with my domain user account and computer account assigned to it.
Matt says
dumb question here, but what if I am receiving email from an external smtp server inbound to my server using a different authorized domain name and I want to require TLS from their IP range but not require authentication, while also having a receive connector for my main domain name open on 25 from my spam system? Would I just create a new connector with anon access only and the TLS checked listening on 587? (assumed that I have added the second domain name to server)
John says
Elan,
Actually I was talking about the -RequireTLS switch in that last comment. But this is a fantastic post and extremely useful. Thanks for everything.
John says
Elan,
HOLY MOLY!!! Thank you so much. I've been looking for that setting for two days! Perfect!
Vikas Kumar says
Hello,
Could you please tell me that after running the below command, what will be the server impact in terms of performance?
Set-MailboxServer ServerName -MAPIEncryptionRequired:$true
Regards,
Vikas Kumar
Elan Shudnow says
Mike, check out the following page:
http://technet.microsoft.com/en-us/library/bb125140.aspx
There’s a -RequireTLS $true option there which you can use to force Auth.
When you connect to telnet and establish EHLO, you should see: 250-STARTTLS
If you send from a system that doesn’t accept STARTTLS, the sending system should get:
“451 5.7.3 Require STARTTLS to do basic authentication.”
Mike says
We want to force authentication over TLS. Ie, Basic but only allow basic with TLS. How do we test/prove this is working via telnet? I can test basic auth with telnet- but not if we are requiring TLS.
Dave says
For Aaron, but other like myself who followed all the myriad blogs and had problems. If all you want is a simple mail server to accept mail for your users and allow your authenticated users (whether they are inside or outside the network doesn’t matter) to send mail to anyone, just do these simple steps:
1. Delete your existing receive connectors.
2. Use the wizard to create an Internet intended use – just take the defaults.
3. Use the wizard to create an internal intended use – just take the defaults.
4. Edit the Internet one and on Permission Groups, check off Exchange users and on the authentication tab, check what methods you want to allow them to authenticate by.
Done! That’s it. Authenticated users will automagically be able to send to anyone, unauthenticated users can only send to your Exchange users. No open relay.
robert says
This does not work for me, is there someting that i am missing?
robert says
what i keep geting is message was rejected becuase the server does not allowing relaying
Tony says
Hi Robert, I think I found the solution to your relay problem here: http://msexchangeteam.com/archive/2006/12/28/4320… . You have to create a second receive connector, with externally secured enabled. Let me know if that works.
Moshe says
Very Usefull.
Thanks
Aaron says
How would I use the info provided here to setup SMTP AUTH for an email appliance to use so my external users can relay mail through our exchange server if they have been authenticated?
Any help would be apprecaited.
app