Managing Receive Connectors (Part 4)

If you missed the previous articles in this series please read:

In the last article we saw how to manage permissions using the Exchange Management Shell and AdsiEdit.msc. In this article we are going to personalize receive connector permissions in a different way without using the default Permissions groups.

Exchange Server 2007 has a set of predefined Permissions Groups which makes it easier to administer using a single checkbox to define the required permissions. When we have more than one server it might be painful since some organizations need a more restrictive receive connector which can be reached using the procedure outlined in this article. If you do not really need such feature it is strongly recommended to stick with the default Permissions Groups available through the Exchange Management Console or Exchange Management Shell.

Let’s say that we just want an AD Group called Grp_Relay to be allowed to relay in Exchange Server 2007. In order to do that we have to go further than the Receive Connector permission configurations to assign different users than the default list.

If you use more than one HUB Transport in an NLB scenario for this receive connector, all changes must be made in all NLB nodes to provide the same mode of authentication and permissions.

First of all, we should remove all known groups of the Receive Connector Permissions tab in the Exchange Management Console. To do that we can get the properties of the Internal Relay connector and make sure that there is no group checked on the Permissions tab.

Now, let’s go back to AdsiEdit.msc and right-click on our Internal Relay connector and click on Properties. Click on the Security tab, and add the Grp_Relay group from Active Directory. Make sure that the group has at least the following permissions (Figure 01):

  • Submit Messages to Server

  • Submit Messages to any Recipient

  • Bypass Anti-Spam

  • Accept routing Headers

Figure 01

Now, only users that belong to the Grp_Relay group will be able to send messages using the Internal Relay Receive Connector. If any user outside of that group tries to send a message, they will be asked for credential several times; you can validate the error in the Receive Connectors log file. The error will contain the following information:

Inbound authentication failed because the client DOMAIN\username doesn’t have submit permission.

If you have a situation where some servers must relay on Exchange Server without using authentication, you can use the same procedure above to grant permission to Anonymous entry on the Receive Connector Security tab.

It is not best practice to allow anonymous permission to relay in an Exchange Server box. Make sure that only a set of servers can use this connector using the RemoteIPRanges configuration of the receive connector.

Configuring TLS on a Receive Connector

Okay, now that we have seen how to properly configure the authentication methods and groups in a Receive Connector, we are going to enable TLS in our Receive Connector. First of all, let’s go to the properties of the Internal Relay Receive Connector and then click on the Authentication tab and check the option TLS, as shown in Figure 02.

Figure 02

Now let’s try to connect to this receive connector which has the FQDN defined as relay.apatricio.local (Apatricio.local is my AD FQDN name). Let’s just use the first SMTP verb, EHLO  and we can see that the STARTTLS is not being presented which means that even with TLS enabled on the Receive Connector we are not able to use it right now. (Figure 03)

Figure 03

After that connection we can go to the Event Viewer of our Exchange Server and the EventID 12014 (Figure 04) will be there, and the error message gives us a clue about what is happening with our current environment. The simple answer is that there is not a Certificate with the name configured in the FQDN of that Receive Connector.

Figure 04

So, let’s fix it. I will assume that we are using an internal PKI and in order to request a new SMTP certificate using the Exchange Management Shell use the following cmdlet:

New-ExchangeCertificate –GenerateRequest –Path c:\cert.req –SubjectName “cn=relay.apatricio.local” –FriendlyName “Internal Relay Certificate” –PrivateKeyExportable:$True

Now, let’s request the certificate created using the Certification Authority webpage:

  1. Logged on Exchange Server open the http://<CA Server>/certsrv, where <CA Server> is your server which hosts the Certification Authority.

  2. Click on Request a Certificate link.

  3. Click on advanced certificate request.

  4. Click on the second link which is Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.

  5. Open the file C:\cert.req which was created by New-ExchangeCertificate cmdlet and copy the content.

  6. Paste the content of that file into the Base-64-encoded certificate request field in the webpage.

  7. On the same page, select Web Server in the Certificate Template field and then click the Submit button.

  8. On the new page, click on the Download Certificate link and save it in the C:\ root of the Exchange Server.

Let’s import the new certificate, to do that use this cmdlet:

Import-ExchangeCertificate –Path:C:\certnew.cer

The file name and path is just an example, you have to use the file name and path that you have used in the previous step.

Time to enable the new imported certificate to be used by the SMTP service using the Exchange Management Shell. To enable it we just need to copy the Thumbprint that was shown when we imported the request in the previous step and use this cmdlet:

Enable-ExchangeCertificate –Thumbprint <Thumbprint> -Services SMTP

You will be prompted to change the default SMTP certificate, just type in N and hit enter.

Let’s test our changes, we will be connecting again in the Internal Relay Receive Connector and we are going to type in the first SMTP verb, ehlo Did you notice any change? You should, now we have the STARTTLS being offered by Exchange Server. We can also go back to the Exchange Server Event Viewer and we will not see any Transport error like we saw before.

Figure 05

Let’s go back to our Outlook Express to confirm the solution. In the Outlook Express account properties, we have to use an FQDN name in the Outgoing mail (SMTP) field, and this name must be resolved by the client and it also must be same used by the certificate deployed recently (Figure 06).

Figure 06

The second step that must be done is on the Advanced tab where the option This server requires a secure connection (SSL) must be checked, as shown in Figure 07.

Figure 07

Now, let’s send a message using our Outlook Express. We do not need to receive on the Outlook Express client because we did not set up the proper POP3 server, only the SMTP. If the message disappears from the Outbox folder it is a good sign, but let’s validate the log files and we will see that the last message was sent using TLS, as shown in Figure 08.

Figure 08


In this article we have seen how to avoid Event ID 12014 when we configure a new FQDN in a Receive Connector, how to configure a specific group to relay in a specific Receive Connector, and how to configure a certificate and validate the log files to make sure that the configuration is working properly.

If you missed the previous articles in this series please read:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top