Exchange Management Console not setting Permissions for Receive Connectors, fixing 5.7.1 Client was not authenticated issues with inbound e-mails

,

I was recently helping out on a migration from Exchange 2003 to Exchange 2010. The organisation was moving from two servers, a front end and back end server to four with two Mailbox servers running in a DAG (Database Availability Group) configuration and two Client Access Servers in an array and along with Hub Transport roles on the two CAS Servers.  They had been running their Exchange 2003 server for a while with routing connectors setup so the 2003 machine was handling all of the external mail and it had finally come time to decommission the old server and tell the firewall to push e-mail to the two new Hub Transport servers.

By default, Exchange 2010 sets up two connectors, one Client SERVERNAME and Default SERVERNAME with the default connector handling your external e-mail. For external servers to connect to the connector we need to enable anonymous authentication for the connector. So we went ahead, opened up the connector and ensured the Anonymous was ticked, clicked apply for good measure and then Ok. After using telnet to remotely connect to the e-mail server (via 3G) we received a Client not authenticated message after giving it the mail from command. So it was clear to me that the EMC (Exchange Management Console) wasn’t saving the authentication settings. So we resorted to PowerShell to configure the connector. I opened up the Exchange Management Shell and issued the following command

Get-ReceiveConnector -identity "Default SERVERNAME" | list

The list contained everything that was ticked bar the Anonymous that we had just enabled. So we decided to run a Set command to update the permissions list for the Default connector. I issued the following command with SERVERNAME being the name of the Exchange Server hosting the connector

Set-ReceiveConnector "Default SERVERNAME" -PermissionGroups:"ExchangeUsers, ExchangeServers, ExchangeLegacyServers, AnonymousUsers"

We then ran the Get command again and the Anonymous entry was listed. So after a few minutes we used 3G and telnet to connect back into the e-mail server and after getting passed the mail from command we were relieved that the issued was resolved and that the servers could now accept incoming external e-mail. Microsoft have a good article up on Tech Net regarding Exchange 2010 and the Receive connectors (as well as the defaults Exchange setup creates) at the following article Understanding Receive Connectors.

Note that you won’t receive this issue if your transport server is an Edge transport server as Exchange setup automatically configures the connectors for external connections.


Leave a Reply

More Posts

Adopt Unifi Access Point over Internet or VPN using SSH

If you’ve shipped some Ubiquiti Unifi Wireless access points to a remote site before adopting them or happen to have your controller on another network, you can log into them via SSH and point them to your Unifi controller. It performs discovery via basic L2 broadcast and DNS resolution of hostname unifi, if either of […]

Microsoft 365 Admin Notifications to your user mailbox with Plus addressing

Licensing your Entra Administrator accounts for email is a common practice to ensure you are across service health updates, user, security and billing alerts but by doing this it introduces security risks and additional costs for mailbox licensing. As a best practice, privileged accounts should remain isolated from unnecessary communication channels to minimise vulnerabilities or […]