Managing Receive Connectors (Part 3)

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

If you would like to be notified when Anderson Patricio releases the next article in this series please sign up to the MSExchange.org Real Time Article Update Newsletter.

Configuring Receive Connector Logging Settings

We can configure logging per receive connector. In order to enable log filing in a receive connector we should make sure where the log files will be generated. To configure where the log files will be kept before enabling the logging feature at the connector level:

  1. Open the Exchange Management Console.
  2. Expand Server Configuration.
  3. Click on Hub Transport.
  4. Select an available hub transport on the right hand side, and click on Properties.
  5. Click on the Log Settings tab. In the Protocol Log section we can change the path where either Receive Connectors or Send Connectors will be stored by clicking on Browse button. (Figure 01)<


Figure 01

Now, that we already know where the log files are stored, we can get the properties of any Receive Connector and we have an option called Protocol logging level which by default is defined as None and we are going to change to Verbose (Figure 02). Use Verbose mode only during a troubleshooting scenario, otherwise keep it configured as None.


Figure 02

Now, we can send a test message using the SMTP verbs that we saw previously in this series and we will be able to track all communication in the log file, as shown in Figure 03.


Figure 03

Configuring Authentication and Permission…

What we have been working on so far is on how to create the receive connector, how to manage some security features and also how to change the listening IPs to make each connector unique. Now we will go over the Authentication methods and Permissions available that can be associated with a Receive Connector.

Receive Connectors use 7 (seven) different types of authentication, which are: No authentication, TLS, Integrated, Basic Authentication, Basic Authentication over TLS, Exchange Server Authentication (Gssapi and Mutual Gssapi) and External Authoritative. These authentication methods are offered to the clients during the SMTP session and after authentication is made the permissions are applied. In order to configure the authentication method that a specific Receive Connector will use, follow these steps:

  1. Open the Exchange Management Console.
  2. Expand Server Configuration.
  3. Click on Hub Transport.
  4. Click on a Receive Connector and click on Properties.
  5. Click the Authentication tab (Figure 04).


Figure 04

We are able to see the authentication method used by a receive connector through a simple telnet session. All available authentication methods are shown after the SMTP verb ehlo. The following table shows the difference on the SMTP answer for each authentication method:

Authentication Method

Response of EHLO

Transport Layer Security (TLS)

250-STARTTLS

Basic Authentication

250-Auth Login

Integrated Windows Authentication

250-Auth NTLM

Externally Secured

250-Auth
250 XEXCH50

Okay, we have just seen how to configure the authentication methods that can be applied in a Receive Connector, now we are going to configure an internal relay server, it might be useful where some users/printers/servers must send message using an internal relay server. We are going to create an internal relay connector from scratch and then we will be changing some configurations to demonstrate how we can play with receive connector authentication and permissions to fit your needs.

Let’s create an Internal Receive Connector. This connector will accept a connection on port 25, however the connections will be made only from a set of machines (172.16.171.1 to 172.16.171.20 in this example). We are also going to specify a different FQND; for this internal receive connector we will be using relay.apatricio.local, the following cmdlet can be used to create the connector:

New-ReceiveConnector –Usage:Client –Bindings:0.0.0.0:25 –RemoteIPRanges:172.16.171.1-172.16.171.20 –FQDN:relay.apatricio.local –Server srv-ex01 –ProtocolLoggingLevel:Verbose –Name:”Internal Relay”

Now, that we have just created the Receive Connector, we can go to any machine that belongs to the defined remote IP range and we will receive a prompt of our new receive connector. We can verify the FQND information displayed in the first line (Figure 05).


Figure 05

Okay, now let’s open the Event Viewer in our Exchange Server, and we will see an error number 12014 and MSExchangeTransport Source. This error occurred because we do not have a certificate for the relay.apatricio.local FQDN, yet. We can avoid that message error for now by configuring the internal Receive connector to use Basic Authentication and Integrated Windows Authentication, as shown in Figure 06. We are going to play with TLS and certificates for this connection in the next article.


Figure 06

In the Permission Groups tab, we have 5 different permissions groups which we can associate to a receive connector. These predefined permissions groups are a set of objects that might include users, computers and security groups and they define permissions to well-know SID (Security Identifier), for example (Exchange Users group permission is the Authenticated Users Group in the AD). Using these permissions groups is the recommended solution for the majority of the companies, however we cannot change these permission groups using the Exchange Management Console.

In the Permissions Groups tab, we are going to validate who is allowed to connect to our Receive Connector. In a Client Connector only “Exchange Users” are allowed by default. (Figure 07)


Figure 07

Since we have the proper Authentication method and a permission associated with Exchange Users we are able to test it. To test we can use Outlook Express to create a dummy account using a fake POP3 Server account just to test the SMTP protocol. Make sure that the reply address used in the Outlook Express account belongs to the current list of Accepted Domains in your Exchange organization and also that you are using the proper username and password, and finally configure the account to use authentication using the option “My Server requires authentication”.


Figure 08

Now you can send a message to any e-mail address and the message will be sent. How do we make sure that authentication is working? Easy! During the receive connector creation we configured the logging level to Verbose. Now you understood why I said easy, right? Just look at the log files generated and we will see the authentication process, as shown in Figure 09.


Figure 09

The default configuration works in most scenarios, however sometimes a special set of permissions is required in order to configure a Receive Connector to fit in with company requirements. We are able to configure Receive Connector permissions in two different ways: using the Exchange Management Shell or AdsiEdit.msc.

The first method is using the Exchange Management Shell. To view the current permission of a Receive Connector run this cmdlet:

Get-ReceiveConnector <connector-Name> | Get-ADPermission

To manage the permissions use Add-ADPermission to add entries in that list and Remove-ADPermissions to remove entries as well.

The second method to set Receive Connector permissions is by using AdsiEdit.msc (by default it comes with Windows Support Tools, the process to install it can be found at Adsiedit Overview).

Using ADSIEdit.msc we can play around with Receive Connector permission:

  1. Open AdsiEdit.msc.
  2. Expand Configuration.
  3. Expand CN=Services.
  4. Expand CN=Microsoft Exchange.
  5. Expand CN=<Organization name>.
  6. Expand CN=Exchange Administrative Group (FYDIBOHF23SPDLT).
  7. Expand CN=<Server Name>.
  8. Expand CN=Protocols.
  9. Expand CN=SMTP Receive Connectors.
  10. On the right hand side, we will see all the Receive Connector of that specific Server (Figure 10).


Figure 10

  1. Right click on a Receive Connector and click on Properties.

  2. Click on the Security tab, and in the list we will see all the Security Identifiers of each permission Group that was associated with the receive connector and all permissions granted as well.

Now we are able to manage the permissions easily using Adsiedit.msc instead of the Exchange Management Shell that requires a little more effort.

Conclusion

In this article we saw how to configure the log settings in a Receive Connector and also how to configure permissions using AdsiEdit and the Exchange Management Shell.

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

If you would like to be notified when Anderson Patricio releases the next article in this series please sign up to the MSExchange.org Real Time Article Update Newsletter.

Leave a Comment

Your email address will not be published.

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

Scroll to Top