none
Exchange 2010 "530.5.7.1. client was not authenticated" RRS feed

  • Frage

  • Hi Community,

    first of all, I am German, so please excuse any possible misunderstandings or non-native statements ;-)

    We are migrated to a new AD domain with a new Exchange Organization from Windows 2003/Exchange 2003 to Windows 2008/Exchange 2010.

    My Problem is, that we have external colleagues who needs to attach their different mail clients with POP3 to our working Exchange 2010 Server. The access of MAPI clients and OWA works perfect. Sending, receiving as well sending to internal as sending to external email addresses works excepting with POP3.

    I have configured the receive connector for clients with Exchange authentication. The certificate includes all fqdn etc.

    Trying to connect from external Outlook 2003 client with POP3 works as well. Receiving mails works, sending mails to internal mail addresses works as well, but seding to external mail addresses brings the error message during sending process of outlook: "530.5.7.1. client was not authenticated"

    Can you help me with this, or do you need any further information (what I suggest), then please contact me and I will try to inform you as far as I can do.

    Thanks in advance and best regards,

    Maiko

    Donnerstag, 11. Juli 2013 19:47

Antworten

  • Hallo Norbert...

    ich hab´s ich hab´s ich hab´s ........ *luftsprung*

    Es lag am smtp smarthost des Providers. Versende ich direkt über den MX - also direkt ins Internet - funktioniert der AutoReply...

    Ich habe im Sendconnector unter "Network" die Markierung auf "Use domain name system (DNS) "MX" records to route mail automatically" gesetzt. Gut, dass ich beim INternetprovider den PTR bereits gesetzt habe und auf unsere public IP verknüpft habe.

    Irgendwelche Bedenken, das so zu lassen? Dann müsste ich beim Mailprovider anklopfen und fragen, warum die unseren Exchange nicht über den Smarthost relayen lassen - ich meine, er authentifiziert sich doch über seinen Benutzernamen und Passwort, oder?

    Danke für einen letzten Tipp

    • Als Antwort markiert FCADMIN Dienstag, 16. Juli 2013 12:09
    Dienstag, 16. Juli 2013 11:10

Alle Antworten

  • Du schreibst hier in einem deutschsprachigen Forum. ;) wie wär's dann mit deiner Muttersprache? Mach mal einen Test: der Default clientconnector jedes Exchange 2010 ist per Default korrekt konfiguriert. Er lauscht auf dem Port 587. damit sollte eigentlich das interne und externe senden per smtp für deine User möglich sein. Bye Norbert
    Donnerstag, 11. Juli 2013 20:58
  • ergänzend zu Norbert: Wenn der von ihm erwähnte Connector nicht will oder der Client unbedingt Port 25 nehmen muss, dann wäre "Exchange Benutzer" die richtige Einstellung.


    Grüße aus Berlin schickt Robert
    MVP Exchange Server

    Freitag, 12. Juli 2013 05:55
  • OK - deutsches Forum - ich dachte, das wird allen zur Verfügung
    gestellte... sorry.Unser Exchangeserve empfängt und sendet Mails von und
    nach intern und extern. Die Anmeldung über OWA, MAPI, ActiveSync
    funktioniert.

    Die Anmeldung von einem entfernten Client (nicht im
    Netzwerk und/oder der Domäne), bei dem ich einen POP3 Zugriff
    eingerichtet habe funktioniert für den Empfang von allen Mails
    wunderbar. Der Versand nach intern funktioniert über Port 25 - also
    offensichtlich den Default Empfangsconnector - auch. Nur nach extern
    nicht.

    - Fehlermeldung: " 550 5.7.1 Unable to relay" in der Unzustellbarkeitsmail

    Konfiguriere ich am entfernten Client den Postausgangsserver mit Port 587 funktioniert beides nicht.

    - Fehlermeldung: "....Antwort des Servers: 530.5.7.1 Client was not authenticated"

    Ich
    habe in den Empfangsconnectoren bereits viele Kombinationen getestet -
    in erster Linie würde ich gerne über den Client, also Port: 587,
    verschicken. Ich weiß leider nicht, wo ich ggf. das Versenden für
    authentifizierte Windows User von externen Clients konfigurieren kann,
    wenn das möglich ist.

    Bin aktuell wieder auf den Standardeinstellungen der Empfangsconnectoren - es geht leider nicht.

    Ein Tipp war, den TLS komplett zu deaktivieren - brachte auch nichts.

    Nur Exchange User, oder nur Windows authentifizierte brachte auch nichts...

    Keine
    Ahnung, wo es noch hängt. Aufgrund der vielen Umkonfigurationsversuche
    der Empfangsconnectoren - kann man die Standardconnectoren vielleicht
    einfach noch mal generieren lassen und die "alten" Standards löschen -
    ggf. bringt das ja was...

    Beim Exchange 2007 hat das prima funktioniert.

    Danke für Eure Hilfe

    Freitag, 12. Juli 2013 11:08
  • Ichhabe in den Empfangsconnectoren bereits viele Kombinationen getestet -
    in erster Linie würde ich gerne über den Client, also Port: 587,
    verschicken. Ich weiß leider nicht, wo ich ggf. das Versenden für
    authentifizierte Windows User von externen Clients konfigurieren kann,
    wenn das möglich ist.

    Bin aktuell wieder auf den Standardeinstellungen der Empfangsconnectoren - es geht leider nicht.

    Die Standardeinstellungen bitte definitiv wieder herstellen.

    Ein Tipp war, den TLS komplett zu deaktivieren - brachte auch nichts.

    TLS komplett zu deaktivieren würde ich aus Sicherheitsgründen schon nicht tun. Es kann sein, dass du Standardauthentifizierung nur nach Starten von TLS mal deaktivieren mußt, damit der Client auch ohne TLS kommen kann. Würde ich nicht unbedingt empfehlen, aber damit funktioniert das immer. Bitte nicht einfach "rumkonfigurieren", sondern die Möglichkeiten der Reihe nach durchgehen. ;) Ob man die per "re-create" wieder erstellen kann, weiß ich nicht, aber nimm dir einfach einen "Standard Exchange Server" und vergleiche die Einstellungen. Bye Norbert
    Freitag, 12. Juli 2013 12:12
  • Hallo Norbert,

    danke für die Info. Es ist nun alles wieder auf Standard.

    Maiko

    Freitag, 12. Juli 2013 12:23
  • Hallo,die Einstellungen passen alle. Ich habe alles verglichen. Dabei ist mir noch etwas aufgefallen:

    Neben
    dem Versenden an externe Teilnehmer, indem man sich per POP3 am
    Exchange von einem externen Client aus anmeldet, funktioniert auch der
    Auto Reply an externe Adressen nicht - intern wie gehabt - alles schön.

    Bei
    den Remote Domains habe ich in den Einstellungen unter "Message Format"
    die beiden Haken gesetzt ("Allow automatic replies" und "Allow
    automatic forward")

    Zertifikate habe ich auch geprüft und die genutzten Namen sind alle im SAN hinterlegt.

    Kann mir denn keiner der geschätzten Exchange-Fachleute helfen?

    Montag, 15. Juli 2013 12:01
  • Nein, denn der Client Connector hat solche EInschränkungen nicht. Der ist per Default so konfiguriert, dass man per SMTP Mails an interne und externe Empfänger versenden kann. Wenn das bei dir nicht so ist, dann stimmt was anderes nicht. Und um genau zu sein ""530.5.7.1. client was not authenticated" bedeutet, dass sich dein Client eben nicht authentifiziert hat. Deswegen wird das nicht funktionieren. Wäre eher die Frage, warum man dann trotzdem an interne Empfänger senden kann. ;) Ich würde also erstmal an der eigentlichen Authentifizierung ansetzen. Ein praktisches Tool dafür ist bspw:

    http://www.skittel.de/software/smtpdiagpro/

    HTH

    Norbert

    Montag, 15. Juli 2013 12:05
  • Hallo,

    das Problem mit der externen Anmeldung am SMTP und das Versenden darüber an externe Adressen konnte gelöst werden.

    Das Problem, dass der AutoRply an externe Adressen nicht funktioniert (nur an interne), besteht weiterhin (ich dachte fälschlicherweise, die Ursache sei die gleiche.

    Lösung zum Versenden an externe Adressen über externe Verbindung zum Exchange:

    - Im Exchange Web Service (EWS) Virtual Directory war die public URL nicht hinterlegt.

      - in der Exchange Management Shell mit "Get-webservicesvirtualdirectory | fl identity,internalurl,externalurl" anzeigen lassen und falls eine der beiden URLs fehlt,

      - mit "Set-WebServicesVirtualDirectory -Identity "EWS (default web site)" -ExternalUrl https.//externeURL.com/EWS -BasicAuthentication $true -InternalUrl https://interneURL.local/EWS" die entsprechenden URLs einsetzen.

    Leider besteht das Problem "Autoreply an externe Adressen funktioniert nicht" nach wie vor... Hat vielleicht da jemand eine Idee?

    Gruß. Maiko.

    Montag, 15. Juli 2013 14:18
  • Was? Die externalURL des Webservice soll verhindern, dass man per SMTP Clientconnector Mails nach extern einliefern kann? Also das kann ich irgendwie nicht glauben. Kannst du das nachvollziehen, wenn du die URLs wieder zurückdrehst? Welches Autoreply meinst du überhaupt? Eventuell erklärst du das nochmal genauer. Der Thread ist hier nicht wirklich übersichtlich (sicher auch der tollen Forensoftware geschuldet. :()

    Bye

    Norbert

    Montag, 15. Juli 2013 14:42
  • Hallo Norbert.

    Ich bin auch sehr verwundert, dass es am EWS liegen soll, aber was soll ich sagen - kaum hatte ich die externe URL über die PS eingetragen, konnte ich über SMTPDiagPro (Danke nochmal für das Tool) Mails versenden, was vorher nicht funktionierte. Ich habe es auch noch mal an einem externen Client versucht, indem ich ein Pop Konto mit meinen Server URLs erstellt habe, was auch funktionierte (und vorher nicht). Ein Gegentest verifzierte es mir - ich konnte ohne die externe URL im EWS wieder nur intern versenden - auch über den Pop Account. Die Fehlermeldung (Authentifizierung fehlgeschlagen) erscheint mir hier also völliger Humbug...

    Auf die EWS-Geschichte kam ich aber aufgrund meines nun letzten Problems mit unserem neuen Exchange 2010: die AtuoReply Funktion ist nur für interne Empfänger vorhanden. Habe ich bei einem Benutzer die AutoReply Funktion für interne und externe aktiviert (ich habe bei den Remotedomains die Default entsprechend konfiguriert, das AutoReply und Forward erlaubt ist), werden automatisierte Antworten nur an interne Versender geschickt. Schreibe ich den Account (mit konfiguriertem Autoreply) von einer externen Adresse an, bekommt diese externe Adresse keine Abwesenheitsnotiz.

    Hast dazu eine Idee?

    Danke und Gruß,

    Maiko

    Dienstag, 16. Juli 2013 07:22
  • die AtuoReply Funktion ist nur für interne Empfänger vorhanden. Habe ich bei einem Benutzer die AutoReply Funktion für interne und externe aktiviert (ich habe bei den Remotedomains die Default entsprechend konfiguriert, das AutoReply und Forward erlaubt ist), werden automatisierte Antworten nur an interne Versender geschickt. Schreibe ich den Account (mit konfiguriertem Autoreply) von einer externen Adresse an, bekommt diese externe Adresse keine Abwesenheitsnotiz.

    Hast dazu eine Idee?

    Wie genau hast du die Remote-Domain konfiguriert. Schick mal Screenshot oder

    get-remotedomain * | fl allow*, auto*

    Bye

    Norbert

    Dienstag, 16. Juli 2013 08:07
  • Wie genau hast du die Remote-Domain konfiguriert. Schick mal Screenshot oder

    get-remotedomain * | fl allow*, auto*

    AllowedOOFType     : ExternalLegacy
    AutoReplyEnabled   : True
    AutoForwardEnabled : True
    Dienstag, 16. Juli 2013 08:15
  • Sieht erstmal korrekt aus. Steht vor deinem Exchange ggf. noch was, was den OOF rausfiltert? Welchen Patchstand hat eigentlich dein Exchange?

    Bye

    Norbert

    Dienstag, 16. Juli 2013 08:37
  • ...Steht vor deinem Exchange ggf. noch was, was den OOF rausfiltert? Welchen Patchstand hat eigentlich dein Exchange?...

    ExchangeVersion                    AdminDisplayVersion
    ---------------                         -------------------
    0.1 (8.0.535.0)                      Version 14.2 (Build 247.5)

    Vor dem Exchange steht lediglich eine Firewall, auf der die Ports 25, 587, 110, 443, 80 auf den Exchange geNATet sind.

    Kein Edge etc. Oder worauf wolltest Du genau hinaus?

    Ich bin immer noch der Meinung, dass es mit der Konfiguration der AutoDiscovery Pfade zusammenhängen könnte. Was meinst Ihr?

    Gibt es eine Standardeinstellung, mit der es in jedem Fall funktioniert - bzw. wie müssen die Pfade genau lauten (internerServer.domain.local/...? bzw. https:// externerServerZugriff.com/....?)

    • Bearbeitet FCADMIN Dienstag, 16. Juli 2013 10:08 update
    Dienstag, 16. Juli 2013 10:02
  • Also ist dein Exchange schonmal nicht aktuell, dann wäre es nämlich 14.3 irgendwas (SP3 Rollup 1).

    Ich wollte darauf hinaus, dass OOFs ohne Absender rausgehen und deswegen diverse Filter (auch Firewalls) sowas manchmal wegwerfen. Kannst du ja im Exchange eigentlich sehen, ob ein OOF generiert wird. Und es gibt keine "Standardeinstellung" mit der es immer überall funktioniert. Das hängt von deiner Umgebung ab, was da sinnvoll konfiguriert werden muß.

    Bye

    Norbert

    Dienstag, 16. Juli 2013 10:11
  • Hallo Norbert...

    ich hab´s ich hab´s ich hab´s ........ *luftsprung*

    Es lag am smtp smarthost des Providers. Versende ich direkt über den MX - also direkt ins Internet - funktioniert der AutoReply...

    Ich habe im Sendconnector unter "Network" die Markierung auf "Use domain name system (DNS) "MX" records to route mail automatically" gesetzt. Gut, dass ich beim INternetprovider den PTR bereits gesetzt habe und auf unsere public IP verknüpft habe.

    Irgendwelche Bedenken, das so zu lassen? Dann müsste ich beim Mailprovider anklopfen und fragen, warum die unseren Exchange nicht über den Smarthost relayen lassen - ich meine, er authentifiziert sich doch über seinen Benutzernamen und Passwort, oder?

    Danke für einen letzten Tipp

    • Als Antwort markiert FCADMIN Dienstag, 16. Juli 2013 12:09
    Dienstag, 16. Juli 2013 11:10
  • Es lag am smtp smarthost des Providers. Versende ich direkt über den MX - also direkt ins Internet - funktioniert der AutoReply...

    Ich frag mich manchmal, warum man Fragen wie " Steht vor deinem Exchange ggf. noch was, was den OOF rausfiltert?" dann im Falle eines Smarthosts mit "Da steht eigentlich nichts" beantworten kann. ;)
    Irgendwelche Bedenken, das so zu lassen?
    Um genau zu sein, ist das meine bevorzugte Konfiguration. Dann hab ich nämlich den kompletten Überblick über alle Logfiles. ;) Bye Norbert
    Dienstag, 16. Juli 2013 11:25
  • ...Ich wollte darauf hinaus, dass OOFs ohne Absender rausgehen und deswegen diverse Filter (auch Firewalls) sowas manchmal wegwerfen. Kannst du ja im Exchange eigentlich sehen, ob ein OOF generiert wird. ...


    Hi Norbert, das war ja auch mein eigentlicher Auslöser, endlich auf die reichtige Spur zu kommen. Ich hatte ja vorher geschrieben, dass ich nicht genau verstanden habe, was genau Du wissen musstest mit "...steht vor dem Exchange noch etwas...". Deine Antwort hat mich auf die richtige Fährte geschickt. Dafür danke noch mal.
    Dienstag, 16. Juli 2013 12:09