454 4.7.0 Temporary authentication failure

  • Article

Diese Fehlermeldung ist mir nun schon bei zwei Umstellungen von Exchange 2003 auf Exchange 2007 unterlaufen. Grund genug sie zu veröffentlich, da die Lösung, zumindest bei den beschriebenen Umgebungen, zwar trivial aber nicht leicht zu finden ist. Sie zeigt sich in der Warteschlangenanzeige eines Exchange 2007 Servers mit der Hub-Tranport Rolle und lautet im kompletten Text.

451 4.4.0 Primary target IP address responded with: "454 4.7.0 Temporary authentication failure." Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts

Wie kommt es nun dazu. Im ersten Fall trat der Fehler bei der Kommunikation zwischen Exchange 2007 und Exchange 2003 auf, als ich sämtliche Replikate der Öffentlichen Ordner übernehmen wollte. Im zweiten Fall bei der Kommunikation zwischen zwei Exchange 2007 Servern, doch dazu später.

Die Fehlermeldung deutet auf einen Authentifizierungsfehler hin. Prinzipiell kommunizieren Exchange Server untereinander über das SMTP Protokoll. Diese Kommunikation erfolgt jedoch immer authentifiziert. Wobei als Authentifizierungsmethode zwischen zwei Exchange 2007 Server Kerberos und bei Exchange 2003 GSSAPI-NTLM verwendet wird. Ausführlichere Informationen dazu finden sich unter:

Bei meinem ersten Problem mit dem Exchange 2003 Server war der Internet Mail Flow am Exchange 2003 Server schlecht konfiguriert, es gab keinen dedizierten Connector und es wurde direkt der SMTP Dienst konfiguriert. Hier wurde die Integrierte Windows Authentifizierung deaktiviert. Dadurch konnte sich der Exchange 2007 Server nicht authentifizieren und verweigerte die Zustellung der Nachrichten. Ein Fehler der recht einfach zu beheben war.

Das zweite Problem gestaltete sich etwas komplizierter. Das Konfiguration bestand aus zwei Exchange 2007 Servern mit der Hub-Transport Rolle. Server 1 sollte direkt Mails aus dem Internet empfangen und senden können. Es war also kein Server mit der Edge Server Rolle vorgesehen. Entsprechend der Dokumentation unter How to Configure Internet Mail Flow Directly Through a Hub Transport Server wurde beim Default Receive Connector die Berechtigung für Anonyme Benutzer gegeben. Weiters wurde am Default Connector ein Full Qulified Domain Name angegeben. Ein FQDN sollte bei jedem SMTP Dienst im Internet konfiguriert sein, entsprechende RFCs (RFC821, RFC2821) schreiben einen gültigen Host Namen im Ablauf der SMTP-Kommunikation vor. Ab diesem Zeitpunkt konnte Server 2 keine Nachrichten mehr an Server 1 zustellen. Mit der oben angeführten Fehlermeldung ging in diesem Fall auch ein Event Log Eintrag einher:

Quelle: MsExchangeTransport
Event ID: 2017
Fehler TargetUnknown bei der ausgehenden Authentifizierung für den Sendeconnector "Organisationsinterner SMTP-Sendeconnector". Der Authentifizierungsmechanismus ist ExchangeAuth. Das Ziel ist SMTPSVC/mail.contoso.com

Details zu diesem Eventlog Eintrag finden sich hier.

Wobei mail.contoso.com der am Server 1 eingetragene FQDN ist. Eine intensive Studie der Exchange Dokumentation, speziell des Artikels Receive Connectors, lieferte zu dem Problem noch die Notiz, daß man auf dem Default Empfangsconnector (welcher automatisch angelegt wird) keinen FQDN setzen sollte da sonst, bei mehreren Hub Transport Servern, der interne Mail Flow nicht mehr funktioniert.

So weit so gut, es gibt nun mehrere Möglichkeiten dieses Problem zu umgehen:

  1. Einen Edge Transport installieren: Die absolut empfohlene Methode!
  2. Den FQDN löschen: Nicht zu empfehlen, da ja niemand gegen die RFC verstoßen will.
  3. Die Security aufweichen und die Exchange Server zu zwingen, gegenseitig keine Authentifizierung zu benötigen: Lehne ich persönlich strikt ab. Security ist nicht immer angenehm aber wird immer notwendiger.
  4. Einen weiteren Empfangsconnector für den Internet Mail Flow konfigurieren und den Default Connector entsprechend durch IP Adressen einschränken: Sicherlich ein gangbarer Weg, den ich aber selbst nicht probiert habe.
  5. Den Authentifizierungsfehler beseitigen: Für diesen Weg habe ich mich entschieden und eine Lösung gefunden.

Auf der Suche nach dem Authentifizierungsfehlers blieb ich immer an der Formulierung des Eventlog Eintrags hängen, hier vor allem an der Bezeichnung: SMTPSVC/mail.contoso.com. Nachdem natürlich die DNS Einträge dahingehend überprüft wurden, daß die beiden Hub Transport Server sich prinzipiell finden, war klar, dass sich der Zielserver für diesen Name als nicht zuständig bewertete. Da ich schon des öfteren Probleme mit der Kerberos Authentifizierung hatte, besonders bei Sharepoint Seiten die ebenfalls unter einem FQDN gehostet wurden welcher nicht dem Servernamen entsprach, hatte ich die Vermutung, es könnte an einem fehlenden Service Principal Name (SPN) liegen. Der Service Principal Name wird bei Kerberos dafür verwendet, das genaue Service des Zielservers zu identifizieren für den ein Client ein Kerberos-Ticket beantragt. Eine gute Unterstützung zur Fehler such findet sich unter Troubleshooting Kerberos Errors. Und dies ist auch im vorliegenden Fall die Lösung des Problems, es ist nur nötig, den eingetragenen FQDN zusätzlich als SPN für das Smtp Service (SMTPSVC) zu registrieren. Am einfachsten läßt sich dies mit dem setspn Utility aus den Windows Support Tools erreichen. Der korrekte Aufrauf lautetet in dem beschrieben Fall:

setspn -A SMTPSVC/mail.constoso.com server1

Wobei server1 den Netbiosnamen oder den Domainnamen des Servers bezeichnet. Ein Anleitung zum setzen des SPN findet sich unter Registrieren von Kerberos-Dienstprinzipalnamen (wenn auch hier im Zusammenhang mit HTTP und SQL Server 2005). Eventuell ist nach setzen des SPN ein Serverneustart erforderlich.

Beitrag von Heinrich Pommer