none
Warnung Event ID 1035 RRS feed

  • Frage

  • HI Community,

    ich beobachte seit einiger zeit eine Warnung in unserem Exchange 2010:

    Protokollname: Application Quelle: MSExchangeTransport Datum: 27.04.2014 10:28:48 Ereignis-ID: 1035 Aufgabenkategorie:SmtpReceive Ebene: Warnung Schlüsselwörter:Klassisch Benutzer: Nicht zutreffend Computer: UNIVERSE.DOMAIN.local Beschreibung: Fehler LogonDenied bei der eingehenden Authentifizierung für den Empfangsconnector Default UNIVERSE (E-Mail empfang von Internet). Der Authentifizierungsmechanismus ist Login. Die Quell-IP-Adresse des Clients, der die Authentifizierung bei Microsoft Exchange versucht hat, ist [72.252.13.175].

    Eingestellt ist Standardauthentifizierung für diesen Empfangskonnektor aber ich komme jetzt schon mal gar nicht hinter den Sinn dieser Warnung. Warum sollte sich ein Mailserver der E-Mails zu uns schickt authentifizieren müssen und wenn das so wäre warum bekomme ich dann überhaupt E-Mails? Ich kann keine Einschränkung in der Funktionalität feststellen. Ich habe bereits ein paar Postings bzgl. dieser Warnung gelesen aber die hatten eigentlich immer eine interne IP als Quell-IP-Adresse, hier sind es aber ausschließlich externe IP-Adressen.

    Kann mir mal jemand kurz erläutern was hier schief läuft? Dann könnten wir ggf nach einer Lösung suchen.

    Thx & Bye Tom



    Dienstag, 29. April 2014 08:07

Antworten

  • Moin,

    alle Authentifizierungsmethoden, die Du eingestellt hast, sind Optionen (nur TLS bei Kennwort wäre zwingend, aber darum geht es erstmal nicht).

    Wenn Du "Exchange Benutzer" und "Anonym" eingestellt hast, KANN man beim Einliefern einen User nehmen, muss es aber nicht. Wenn Du nun z. B. nur Anonym eingestellt hat und es irgendein Gerät trotzdem mit Benutzernamen probiert, bekommt man den oben genannten Fehler. Gleiches, wenn z. B. eine falsche Methode, ungültige Verschlüsselung o.ä. verwendet wird.

    In den meisten Fällen wird hier einfach probiert, Passworte zu raten und den Connector anschließend als Relay zu missbrauchen.

    Der Zertifikatsfehler kommt doch bei einem ausgehenden Connector, oder? Dein Fehler eingangs ist aber eingehend.

    Natürlich solltest Du den Zertifikatsfehler beheben, der hat aber direkt nichts mit dem Fehler zu tun. Höchstens indirekt, wenn es sich allgemein um ein Problem mit dem Zertifikat handelt.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Mittwoch, 30. April 2014 07:13

Alle Antworten

  • Moin,

    Gegenfrage: Hast Du da überhaupt ein Problem? Wie viele von den Meldungen bekommst Du so? Sind das immer die gleichen IP-Adressen/IP-Bereiche oder komplett verschiedene?

    Irgendein Gerät im Internet versucht Mails mit einer falschen Authentifizierungsmethode einzuliefern. Und nu? Who cares. Wenn das wichtig ist, bekommt der Absender einen NDR und wird sich darum kümmern.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Dienstag, 29. April 2014 09:53
  • Servus,

    > Gegenfrage: Hast Du da überhaupt ein Problem? Wie viele von den Meldungen bekommst Du so?

    Einige am Tag, so ein Dutzend ungefähr.

    > Sind das immer die gleichen IP-Adressen/IP-Bereiche oder komplett verschiedene?

    Es sind immer verschiedene

    > Irgendein Gerät im Internet versucht Mails mit einer falschen Authentifizierungsmethode einzuliefern. Und nu? Who cares. Wenn das wichtig ist, bekommt der Absender einen NDR und wird sich darum kümmern.

    Mich interessiert es schon, zumindest so lange ich nicht weiß was das Problem eigentlich genau ist. Das bringt mich auch gleich zu einer anderen Fehlermeldung die ich noch habe:

    Protokollname: Application
    Quelle:        MSExchangeTransport
    Datum:         30.04.2014 08:34:48
    Ereignis-ID:   12014
    Aufgabenkategorie:TransportService
    Ebene:         Fehler
    Schlüsselwörter:Klassisch
    Benutzer:      Nicht zutreffend
    Computer:      UNIVERSE.DOMAIN.local
    Beschreibung:
    Microsoft Exchange konnte ein Zertifikat nicht finden, das den Domänennamen "mx.domain.de" im persönlichen Informationsspeicher auf dem lokalen Computer enthält. Daher kann die STARTTLS-SMTP-Aktionsart für den Connector "E-Mail ausgehend" mit einem FQDN-Parameter von "mx.domain.de" nicht unterstützt werden. Überprüfen Sie die Connectorkonfiguration sowie die installierten Zertifikate, damit sichergestellt wird, dass ein Zertifikat mit einem Domänennamen für jeden Connector-FQDN vorhanden ist. Wenn das Zertifikat vorhanden ist, führen Sie "Enable-ExchangeCertificate -Services SMTP" aus, damit sichergestellt ist, dass der Microsoft Exchange-Transportdienst auf den Zertifikatschlüssel zugreifen kann.
    

    Könnte da ein Zusammenhang bestehen?

    Thx & Bye Tom

    Mittwoch, 30. April 2014 06:46
  • Moin,

    alle Authentifizierungsmethoden, die Du eingestellt hast, sind Optionen (nur TLS bei Kennwort wäre zwingend, aber darum geht es erstmal nicht).

    Wenn Du "Exchange Benutzer" und "Anonym" eingestellt hast, KANN man beim Einliefern einen User nehmen, muss es aber nicht. Wenn Du nun z. B. nur Anonym eingestellt hat und es irgendein Gerät trotzdem mit Benutzernamen probiert, bekommt man den oben genannten Fehler. Gleiches, wenn z. B. eine falsche Methode, ungültige Verschlüsselung o.ä. verwendet wird.

    In den meisten Fällen wird hier einfach probiert, Passworte zu raten und den Connector anschließend als Relay zu missbrauchen.

    Der Zertifikatsfehler kommt doch bei einem ausgehenden Connector, oder? Dein Fehler eingangs ist aber eingehend.

    Natürlich solltest Du den Zertifikatsfehler beheben, der hat aber direkt nichts mit dem Fehler zu tun. Höchstens indirekt, wenn es sich allgemein um ein Problem mit dem Zertifikat handelt.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Mittwoch, 30. April 2014 07:13
  • Servus,

    > Wenn Du "Exchange Benutzer" und "Anonym" eingestellt hast, KANN man beim Einliefern einen User nehmen, muss es aber nicht. Wenn Du nun z. B. nur Anonym eingestellt hat und es irgendein Gerät trotzdem mit Benutzernamen probiert, bekommt man den oben genannten Fehler. Gleiches, wenn z. B. eine falsche Methode, ungültige Verschlüsselung o.ä. verwendet wird.

    Die Einstellungen schauen derzeit so aus, oder steht da noch was auf einer anderen Registerkarte?:

    > In den meisten Fällen wird hier einfach probiert, Passworte zu raten und den Connector anschließend als Relay zu missbrauchen.

    So rum wird ein Schuh daraus, mit dem ich was anfangen kann. Ich habe im Sicherheits-Tab in der Ereignisanzeige einen passenden Eintrag zur selben Zeit gefunden.

    Die ausgelöste Warnung dazu:

    Protokollname: Application
    Quelle:        MSExchangeTransport
    Datum:         30.04.2014 07:23:09
    Ereignis-ID:   1035
    Aufgabenkategorie:SmtpReceive
    Ebene:         Warnung
    Schlüsselwörter:Klassisch
    Benutzer:      Nicht zutreffend
    Computer:      UNIVERSE.DOMAIN.local
    Beschreibung:
    Fehler LogonDenied bei der eingehenden Authentifizierung für den Empfangsconnector Default UNIVERSE (E-Mail empfang von Internet). Der Authentifizierungsmechanismus ist Login. Die Quell-IP-Adresse des Clients, der die Authentifizierung bei Microsoft Exchange versucht hat, ist [72.252.13.175].

    dazu wir parallel folgender gescheiterte Anmeldeversuch geloggt:

    Protokollname: Security
    Quelle:        Microsoft-Windows-Security-Auditing
    Datum:         30.04.2014 07:23:09
    Ereignis-ID:   4625
    Aufgabenkategorie:Anmelden
    Ebene:         Informationen
    Schlüsselwörter:Überwachung gescheitert
    Benutzer:      Nicht zutreffend
    Computer:      UNIVERSE.DOMAIN.local
    Beschreibung:
    Fehler beim Anmelden eines Kontos.
    
    Antragsteller:
    	Sicherheits-ID:		NETZWERKDIENST
    	Kontoname:		UNIVERSE$
    	Kontodomäne:		DOMAIN
    	Anmelde-ID:		0x3e4
    
    Anmeldetyp:			8
    
    Konto, für das die Anmeldung fehlgeschlagen ist:
    	Sicherheits-ID:		NULL SID
    	Kontoname:		ec2c8a23106@domain.de
    	Kontodomäne:		
    
    Fehlerinformationen:
    	Fehlerursache:		Unbekannter Benutzername oder ungültiges Kennwort.
    	Status:			0xc000006d
    	Unterstatus::		0xc0000064
    
    Prozessinformationen:
    	Aufrufprozess-ID:	0x4cf4
    	Aufrufprozessname:	C:\Program Files\Microsoft\Exchange Server\V14\Bin\EdgeTransport.exe
    
    Netzwerkinformationen:
    	Arbeitsstationsname:	UNIVERSE
    	Quellnetzwerkadresse:	-
    	Quellport:		-
    
    Detaillierte Authentifizierungsinformationen:
    	Anmeldeprozess:		Advapi  
    	Authentifizierungspaket:	Negotiate
    	Übertragene Dienste:	-
    	Paketname (nur NTLM):	-
    	Schlüssellänge:		0
    
    Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde.
    
    Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe".
    
    Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk).
    
    Die Felder für die Prozessinformationen geben den Prozess und das Konto an, für die die Anmeldung angefordert wurde.
    
    Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an.  Der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben.
    
    Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung.
    	- Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren.
    	- Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an.
    	- Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0.

    Ich denke damit liegst du genau richtig.

    > Der Zertifikatsfehler kommt doch bei einem ausgehenden Connector, oder? Dein Fehler eingangs ist aber eingehend.

    Ja das ist der Connector 'E-Mail ausgehend'

    > Natürlich solltest Du den Zertifikatsfehler beheben, der hat aber direkt nichts mit dem Fehler zu tun. Höchstens indirekt, wenn es sich allgemein um ein Problem mit dem Zertifikat handelt.

    Jupp, ich hätte da eh noch ein paar lästige Probleme mit Zertifikaten zu lösen. Da wäre mal das autodiscover-Problem, was wir jetzt zwar mit einem Redirect im DNS gelöst haben aber schön ist das auch nicht und intern wird von den nicht Domänenmitgliedern das vom Exchange selbst ausgestellte Zertifikat des internen FQDNs mit einer Zertifikats-Warnung versehen. Aber das wird schon...

    Thx & Bye Tom


    Mittwoch, 30. April 2014 07:37
  • Moin,

    auf dem Reiter "Authentifizierung" steht nur, wie die Authentifizierung zu erfolgen hat, WENN eine notwendig ist. Wenn Du z.B. auf dem Reiter "Berechtigungsgruppen" nur Anonym hast, wird gar keine Authentifizierung verlangt und die Einstellungen spielen bei gewolltem SMTP gar keine Rolle.

    Zum Verständnis ein beliebter Fall (nicht für Dich): Wenn man will, dass Exchange Server untereinander Mails einliefern können, muss bei Berechtigungsgruppen "Exchange Server" eingestellt sein. Es muss aber dann auch bei Authentifizierung "Exchange Server Authentifizierung" ausgewählt sein, weil Exchange Server keine Standardauthentifizierung können.

    Das mit dem Zertifikat ist natürlich grundsätzlich eine wichtige Sache und versteigt diesen Thread hier vermutlich.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Mittwoch, 30. April 2014 08:09