Exchange 2010 Receive Connector configuration

Question

I am having a very hard time getting clear about receive connectors in Exchange 2010, which I have unhappily inherited.

I have read a lot of articles and books, but nothing presents the information I need in a clear way, and some of the articles are conflicting, which is expected but doesn't make this any easier.

The reason for asking these questions together is that some of them impact others, and if asked separately they would probably not make clear what I need to accomplish.

My Exchange server is Hub role internet-facing. There is no edge or filter between it and the outside.

I recently implemented split DNS, and I want to know if the "Server" and "Fqdn" attributes should be changed to the public DNS name for my mail server, as in "mail.domain.com".

The "Name" attribute is only a label for the connector which shows in the Exchange Management Console.

The "Identity" attribute is related to the GUID. Again, it currently shows as \<"Name" attribute>. The question is whether I can change that to the public DNS name for my mail server, "mail.domain.com".

I need to know if the DistinguishedName attribute can or should also be changed.

Some of my existing connectors have a value for the "DistinguishedName" attribute which reads "CN=,CN=SMTP Receive Connectors,CN=Protocols,CN=,CN=Servers,CN=Exchange Administrative Group,(...),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=,DC=". I know that at one point a migration was done from Exchange 2003, and that it was not cleaned up, so to speak. I need to know if I can simply remove connectors with that value, or whether they need to be replaced with other ones.

The "Default" connector, as I understand it, receives email from the internet on port 25 from any IP (0.0.0.0-255.255.255.255).

I need to understand how AuthMechanism, RequireTLS and PermissionGroups relate to each other, and where RequireTLS is appropriate, as in I don't want to lose email by forcing TLS.

I want to configure TLS. I need to understand where "opportunistic" vs "mutual" applies, as in do I use it for both internet and internal, or only internet.

I want to understand which values should be set for the "AuthMechanism" attribute, and why, given that I want to configure TLS.

I have internal applications which I think need separate connectors, from what I have read. I need to know if that is true, and how to configure that.

I have multifunction printers which send scans via email, which I think also need separate connectors, and I need to know how to configure that.

I have a third party who needs to send email using my DNS name and IP, which I think is called "relay". I need to know if that is correct, and how to configure it.

Links to articles which don't present specific instructions on how to accomplish what I listed above are not helpful.

Explanations of how these connectors are used for my specific needs are very helpful, and I appreciate the help.

Answer 1

I recently implemented split DNS, and I want to know if the "Server" and "Fqdn" attributes should be changed to the public DNS name for my mail server, as in "mail.domain.com".

What you'll most likely want to do is start with several connectors. Classify your clients like the following, for example:

• Internal MAPI Clients ( Outlook )
• External SMTP Clients ( Other MTAs/Mail Servers )
• Internal Devices ( printers? that may/may not use authentication )

Which should give you 3 receive connectors. Outlook clients should be limited to port(s) 585 and 587. You can use the (All Available IPv4) option to filter them, assuming you do not expose your client submission port to the public internet. You can also limit it to the internal IP address of your Exchange server if you wish.

Some of my existing connectors have a value for the "DistinguishedName" attribute which reads "CN=,CN=SMTP Receive Connectors,CN=Protocols,CN=,CN=Servers,CN=Exchange Administrative Group,(...),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=,DC=". I know that at one point a migration was done from Exchange 2003, and that it was not cleaned up, so to speak. I need to know if I can simply remove connectors with that value, or whether they need to be replaced with other ones.

The "Default" connector, as I understand it, receives email from the internet on port 25 from any IP (0.0.0.0-255.255.255.255).

Correct. You can leave that range "as-is."

I need to understand how AuthMechanism, RequireTLS and PermissionGroups relate to each other, and where RequireTLS is appropriate, as in I don't want to lose email by forcing TLS.

AuthMechanism configures the methods available for authentication. Exchange Server authentication is between two Exchange Servers. Basic Authentication is more or less standard, but for an External source, you'll want to ONLY Offer Basic Authentication after starting TLS. Otherwise, you're sending your usernames and passwords over the internet using plaintext if you have clients using SMTP to send email from outside your network.

Integrated Windows Authentication uses built-in ( surprise! ) Windows Authentication - for example, are you logged into the Active Directory domain on a workstation? Then Integrated Windows Authentication will use those credentials without having to include a password in your Outlook setup. Best used for Internal Clients, not including devices.

I want to configure TLS. I need to understand where "opportunistic" vs "mutual" applies, as in do I use it for both internet and internal, or only internet.

Opportunistic means that you'll use TLS if it's available or if it's requested. Mutual means that you need to have a trusted ( issued by a trusted root CA ) certificate installed on both servers. Probably not what you want. A lot of email servers use self-signed certificates and simply request TLS but do not request Client certificates.

I want to understand which values should be set for the "AuthMechanism" attribute, and why, given that I want to configure TLS.

• Internal Connector for Outlook clients: TLS Opportunistic, Basic Auth, Only Offer Basic Auth with TLS, Integrated Windows Authentication ( use Integrated Windows Authentication only if you're in a Windows environment ), Permission Groups ( Exchange Users - require authentication to send )

• Internal Connector for devices: I typically allow SMTP ( bind to port 25 ) ( internal IP address ), limit "remote servers" to internal subnets, offer basic authentication ( no TLS ), offer TLS in opportunistic, Permission Groups ( anonymous ) to allow devices to send without an account.

  I have internal applications which I think need separate connectors, from what I have read. I need to know if that is true, and how to configure that.

Well, it depends on how you're going to separate them out. If you need a specific connector for an application, you need to be able to identify it by IP address, authentication type, and encryption requirement.

I have a third party who needs to send email using my DNS name and IP, which I think is called "relay". I need to know if that is correct, and how to configure it.

Controlling relay security is an entirely different question... Get the above working as you want first, then follow up on that. If you want to understand what this stuff means, you're going to need to read a book on Exchange, rather than just a simple tutorial. You're going to have to read some RFCs as well.

Answer 2

Okay, try this on for size and see if this helps.

2) Don't mess with the identity. That's an active directory attribute and is pretty much internal to Exchange. Leave it alone, it doesn't affect operation of the server. The name is based on the name the server knows itself as and a GUID.

3) Leave the DistinguishedName alone. The DN is an LDAP attribute and identifies an object uniquely in the directory ( Active Directory in this case ).

4) Okay, I would try disabling connectors one at a time, or checking to see if their status is "Enabled," and if they're disabled, then delete them. The names are not nearly as significant as the settings. If you're worried that something might be overlooked, you can enable protocol logging on that connector and the check the logs to see if the connector is active.

5) Okay, AuthMechanism is a list of acceptable ways to authenticate. Can you only log in using Windows? Not so great in an Environment with Macs or Linux included. Can you log in using Basic Authentication? ( Plain text ) Preferably not by itself, even internally. Only as a last resort.

I would suggest making two mostly-identical external connectors and setting Require TLS on one and leaving it turned off for the other. The enable protocol logging on the connector WITHOUT TLS and monitor that to see what mail is coming through. My suspicion is that there are VERY few mailservers in production that do not support TLS now. If so, you're potentially letting third parties read your email in order to prevent missing email from legacy systems. On my mail server, I require TLS ( opportunistic ) ALWAYS. The only time I see an error is when someone tries to brute force passwords so I block the servers that try to use plaintext authentication at the firewall and I haven't missed any emails. Proceed cautiously and you should be okay to require this.

The "Transport Layer Security (TLS)" section of the properties dialog under the Authentication tab corresponds to opportunistic TLS. The Mutual Auth checkbox indented underneath that is mutual auth TLS.

Permission Groups are related to authentication by specifying WHO is allowed to log in using the specified authentication mechanism.

• Partners means other mail servers
• Exchange Users means accounts that have a mailbox on your Exchange server
• Exchange Servers is for other Exchange Servers - typically inside of your environment that use a server as an Edge Transport
• Anonymous Users means no one has to authenticate
• Legacy Exchange Servers is for OLD, OLD versions of Exchange

6) You're close. TLS is Transport Layer Security. Think of it this way. TLS is a like a scrambled phone line from the movies. You can call headquarters on a scrambled line and no one can listen in, but headquarters still won't talk to you without the password of the day ( authentication ). You'll want your internal clients to use opportunistic TLS if at all possible. Always use TLS, is the bottom line. Not using mutual auth will let someone pretend to be someone else, but I'm assuming you have some sort of SPAM filter in place anyway.

7) Take a look at the picture at the beginning of the post and see if that helps you sort this out.

8) You can use connectors for your applications that are specific to the server that is sending mail ( where the application lives ) by filtering using the network tab. Then you can configure authentication and permission groups based on the capabilities of the application. You can filter for a single group, set opportunistic TLS, and enable anonymous users and your server will accept all mail without a username and password from that server. I recommend configuring an active directory user that is denied logon locally permissions and creating a mailbox that rejects all mail to allow using the Exchange Users Permission Group so that you're authenticating the application using a username and password if possible. Always use TLS. If it's opportunistic, it should request rather than require anyway.

9) Take a look at the picture up at the beginning

10) Yes, that's called relaying. I recommend doing the same thing for the third party as for the apps. Create a receive connector for their server, then give them a username and password to send mail from. That's assuming that they're sending email from your domain. If you're truly relaying mail for other domains, make sure that you're requiring a username and password before doing so.