Primary target IP address responded with: “451 5.7.3 Cannot achieve Exchange Server authentication.”

In my previous post I was banging my head over an Exchange 2013 issue. I was able to finally resolve it. And it took some steps to do so…

451 4.4.0 Primary target IP address responded with: “451 5.7.3 Cannot achieve Exchange Server authentication.”

After an Exchange 2013 Install I found myself having issues with sending emails between two Exchange Servers; 2010 and 2013. The messages on both server seem to be stuck in the mail Queue.

Full message reads: 451 4.4.0 Primary target IP address responded with: “451 5.7.3 Cannot achieve Exchange Server authentication.” Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts.

This issue existed because the Exchange servers could not authenticate with one another. This type of authentication is required for Exchange to route email internally. The respective servers use the X-EXPS command to authenticate. This error will happen when servers don’t have this method of authentication enabled.

In my case this wasn’t true, however there was another issue preventing the X-EXPS command from being passed and that was our Cisco security appliance/router. In fact the Extended SMTP verbs X-ANONYMOUSTLS, X-EXPS, and GSSAPI must be able to pass. I will get to this a bit later…

In my adventure to troubleshoot this issue the following was done (thank you Microsoft for providing details. While useful did not directly solve the overall issue. These steps are below

 

Step 1 – Enable Exchange Authentication on Receive Connectors

For Microsoft Exchange Server 2013 remote servers:

1. Go to the following website to access the Exchange Administration Center (EAC):

https://<CAS>/ECP

1. Sign in to the ECA by using the administrator account.
2. Click mail flow.
3. Click receive connectors.
4. In the Select server box, select the remote Exchange server that the email message should be sent to.Note To determine the correct Exchange server, review the send protocol logs from the server that the email message is stuck in.
5. Select the receive connector and then click Edit.Note Typically, the receive connector is the Default server_name receive connector for the remote Exchange server
6. Click security, under Authentication, make sure that Exchange Server Authentication check box is selected.

For Microsoft Exchange Server 2007 or 2010 remote servers:

1. Start Exchange Management Console.
2. Expand Server Configuration and then click Hub Transport.
3. Click the Receive Connectors tab.
4. Locate the remote Exchange server receive connector that the e-mail message is trying to be sent to.
5. Right-click the receive connector and then click Properties.
6. On the Authentication tab, make sure that the Exchange Server authentication check box is selected.

For Microsoft Exchange Server 2003 remotes servers:

1. Start Exchange System Management.
2. Expand the Servers container.
3. Under the problematic remote Exchange server, locate to the Protocols container.
4. Expand the Protocols container, right-click SMTP.
5. Right-click Default SMTP Virtual Server and then click Properties.
6. Click the Access tab and then click Authentication.
7. Make sure that the Integrated Windows Authentication check box is selected.

As I mentioned above this did not resolve my issue as this was already enabled, so I went onto the next step in troubleshooting the problem.

 

Step 2 – Event ID 12014 (MSExchangeTransport)

I had (for some time) many errors in my Application Event Log referencing the ID of 12014, where the TLS Certificate for SMTP was no longer valid. Event message below.

Log Name:      Application
Source:        MSExchangeTransport
Date:          7/3/2013 4:30:06 PM
Event ID:      12014
Task Category: TransportService
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      exchange.jermsmit.com

Description:

Microsoft Exchange could not find a certificate that contains the domain name mail.jermsmit.com in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector To Internet with a FQDN parameter of mail.jermsmit.com. If the connector’s FQDN is not specified, the computer’s FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.

To correct this issue I needed to log open the Exchange Power Shell on my Exchange 2010 server and enter the following: “New-ExchangeCertificate -DomainName mail.jermsmit.com -services SMTP” followed by a restart of the Transport Services (I did this on both).

I tested out my change and now the event error message is gone however I am still unable to send email between the Exchange Servers.

 

Step 3 – Back to the basics

I later logged into each Exchange Host (2010/2013) and used telnet to connect to the respective hosts SMTP address. I got a response: 220**************************************************** but this was not the proper response for an Exchange SMTP.

Then it was apparent that a firewall was blocking the communication between one Exchange host and the other. In my case it was a Cisco ASA which has a mailguard feature turned by.  The Auth and Auth login commands (Extended Simple Mail Transfer Protocol [ESMTP] commands) are stripped by the firewall

So the logical thing was to turn it off. This was done by entering the following command:
no fixup protocol smtp 25

Once this command was issued I restarted the transport services on each host and to use an old coined phrase “You Got Mail” I was back in business.

 

Info Resources:

http://support.microsoft.com/kb/979175

http://technet.microsoft.com/en-us/library/bb123786(v=exchg.65).aspx

http://support.microsoft.com/kb/320027