Exchange Error: 454 4.7.5 certificate validation failure über IONOS-smarthost

Seit gestern erreichen mich Fehlermeldungen auf Exchange-Servern, die über einen Smarthost von 1&1 (jetzt IONOS) versenden.

Das SMTP-Logfile des Sendeconnectors sieht wie folgt aus:

2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,17,192.168.0.20:8319,212.227.15.167:25,,,Remote certificate 2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,18,192.168.0.20:8319,212.227.15.167:25,,"CN=smtp.1und1.de, L=Montabaur, S=Rheinland-Pfalz, O=1&1 Telecommunication SE, C=DE",Certificate subject
2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,19,192.168.0.20:8319,212.227.15.167:25,,"CN=TeleSec ServerPass Class 2 CA, STREET=Untere Industriestr. 20, L=Netphen, PostalCode=57250, S=Nordrhein Westfalen, OU=T-Systems Trust Center, O=T-Systems International GmbH, C=DE",Certificate issuer name 2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,20,192.168.0.20:8319,212.227.15.167:25,,289B2D8A7DE5FEEEB5E117131748CC27,Certificate serial number
2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,21,192.168.0.20:8319,212.227.15.167:25,,ECAE7BFD0F1CF5F33853D6D81E9A37A90B6D9674,Certificate thumbprint 2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,22,192.168.0.20:8319,212.227.15.167:25,,smtp.1und1.de,Certificate alternate names
2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,23,192.168.0.20:8319,212.227.15.167:25,,,"TLS protocol SP_PROT_TLS1_0_CLIENT negotiation succeeded using bulk encryption algorithm CALG_AES_256 with strength 256 bits, MAC hash algorithm CALG_SHA1 with strength 160 bits and key exchange algorithm CALG_ECDHE with strength 256 bits" 2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,24,192.168.0.20:8319,212.227.15.167:25,,,Received certificate
2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,25,192.168.0.20:8319,212.227.15.167:25,,ECAE7BFD0F1CF5F33853D6D81E9A37A90B6D9674,Certificate thumbprint 2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,26,192.168.0.20:8319,212.227.15.167:25,,UntrustedRoot,Chain validation status
2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,27,192.168.0.20:8319,212.227.15.167:25,>,QUIT,
2019-01-18T09:37:11.573Z,1und1,08D67C27692E0958,28,192.168.0.20:8319,212.227.15.167:25,<,221 kundenserver.de Service closing transmission channel,
2019-01-18T09:37:11.573Z,1und1,08D67C27692E0958,29,192.168.0.20:8319,212.227.15.167:25,-,,Local

Was ist passiert?

Mit einem der letzten Updates von Microsoft ist das Stammzertifikat der TeleSec-Zertifizierungsstelle aus dem Pool der vertrauenswürdigen Stammzertifizierungsstellen entfernt worden.
Unter dem nachfolgenden Link kann das Stammzertifikat heruntergeladen werden, damit es danach erneut manuell importiert werden kann:

https://www.telesec.de/de/public-key-infrastruktur/support/root-zertifikate/category/59-t-telesec-globalroot-class-2

Auf dem Exchange-Server muss das MMC-Snapin für das lokale Computerkonto geöffnet werden. Unter dem Punkt „Vertrauenswürdige Stammzertifizierungsstellen“ kann das Zertifikat importiert werden (siehe Screenshot).

MMC-Snapin

Anschließend muss der „MSExchangeTransport“-Dienst neu gestartet werden, damit das neue Zertifikat geladen wird.

DHCP-Server-Migration

DHCP-Datenbank exportieren

Dafür öffnen wir eine Administratorshell auf dem Quellserver und tippen folgenden Befehl ein:

netsh dhcp server export C:\dhcp.txt all

Die Datenbank wird nun nach C:\dhcp.txt exportiert und kann auf das Zielsystem kopiert werden.

DHCP-Datenbank importieren

Auch dies ist mit dem netsh-Befehl möglich:

netsh dhcp server import c:\dhcp.txt

Zitat Microsoft:
„Wenn Sie kein Mitglied der Gruppe „Sicherungsoperatoren“ sind, kann während dieses Vorgangs die Meldung „Zugriff verweigert“ angezeigt werden. Wenn die Fehlermeldung „DHCP-Serverversion wurde für den Server nicht erkannt“ angezeigt wird, vergewissern Sie sich, dass der DHCP-Serverdienst auf dem Server ausgeführt wird und dass der angemeldete Benutzer Mitglied der lokalen Administratorengruppe ist.“

Trend Micro WFBS Client Passwort für Deinstallation vergessen

Mit den folgenden Schritten kann man ein Worry Free Business Security Agent (Client) deinstallieren, wenn das Passwort für die Deinstallation verloren gegangen ist.

Getestet habe ich das Vorgehen an einem Worry Free Business Security Agent Version 9.5.

Zunächst brauchen wir eine Admin-CMD und navigieren darin zu

C:\Program Files (x86)\Trend Micro\Security Agent

Darin angekommen wird mittels folgenden Befehls die Deinstallation ohne Passwortabfrage gestartet:

NTRmv.exe -980223

Watchguard: Multi-WAN

Bei einer Watchguard habe ich immer wieder Probleme mit dem Betrieb mehrer externer Interfaces erlebt. Daher hier ein kurzer „Walkthrough“, wie es stabil laufen kann.

Zunächst gilt in der allgemeinen Multi-WAN-Konfiguration zu beachten, dass ich hier absichtlich keinen Failover verwende, sondern den Routing-Table-Mode (siehe Punkt 1). Der generelle Failover hat in diversen Konfigurationen im Zusammenspiel mit BOVPN zu seltsamen Beeinträchtigungen geführt.

Als Ping- sowie TCP-Monitor müssen unterschiedliche Ziele pro Interface definiert werden, so dass auf den einzelnen Interfaces nicht die gleichen IP’s oder URL’s abgefragt werden (siehe Punkt 2 und 3). Es kommt sonst vermehrt zum Interface-Ping-Pong, sprich Inteface 1 ist up / Interface 2 ist down und umgekehrt. Warum dies geschieht, wissen die Götter. Es scheint ein Bug in der Fireware zu sein.

Ich verwende für den Ping-Monitor hier Loadbalancer der Telekom. Das funktioniert natürlich nur bei Telekom-Leitungen. Weitere gute Ping-Ziele sind öffentliche DNS-Server-IPs.

Hier noch kurz ein Screenshot, wie ich an die IP’s der Loadbalancer gelangt bin. Aus dem Netz der Telekom reagieren diese auf HTTP-Proxy-Anfragen sowie DNS-Anfragen:

So sieht es fertig konfiguriert aus:

In den Firewall-Regeln, die für ausgehenden Datenverkehr zuständig sind, definiere ich dann, …

  1. welches Interface für die Internetnutzung in Anspruch genommen werden soll.
  2. das Failover sowie die Priorisierung der Interfaces.

Dieser Vorgang muss dann für alle Regeln, die Datenverkehr nach extern regulieren, wiederholt werden.

Exchange-Postfach Ordner in falscher Sprache

Wird ein Exchange-Postfach angelegt durch einen Admin, ist noch nicht festgelegt, in welcher Sprache die Standardordner wie Posteingang etc. dargestellt werden. Diese Entscheidung wird beim ersten Anmelden des Benutzers getroffen. Hierbei spielt die Spracheinstellung des verwendeten Clients die entscheidende Rolle.

Wird ein englisches Outlook verwendet, dann heißt der Posteingang plötzlich „Inbox“. Im OWA wird bei erster Anmeldung sofort nach den Regions- und Spracheinstellungen gefragt. Diese werden dann auf die Ordner angewendetet.

Um dies wieder rückgängig zu machen, kann folgender Parameter an die Outlook.exe übergeben werden, der die Standardordner auf die Spracheinstellung des übergebenden Outlooks zurücksetzt:

outlook.exe /resetfoldernames

Zuverlässige öffentliche DNS-Server

DNS-Server werden vom Internetprovider zur Verfügung gestellt. Aber was macht man, wenn man zwei Leitungen von unterschiedlichen Providern an einer Firewall betreiben möchte?

Die Firma Level 3 Communications betreibt auf folgenden IP-Adressen DNS-Cluster. Diese sind aus allen Netzen verfügbar:

4.2.2.1
4.2.2.2
4.2.2.3
4.2.2.4
4.2.2.5
4.2.2.6

Alternativ können die Google-DNS-Server verwendet werden. Diese sind allerdings in der letzten Zeit hin und wieder durch schlechte Reaktionszeiten negativ aufgefallen – wahrscheinlich aufgrund von DoS-Attacken.

8.8.8.8
8.8.4.4

Weitere Server können im Wiki der Firewall-Distribution IPFire nachgeschlagen werden:
https://wiki.ipfire.org/dns/public-servers

Update April 2018:

Das Unternehmen Cloudflare stellt seit diesem Monat zwei Anycast-DNS-Services unter folgenden IP-Adressen zur Verfügung:

1.1.1.1
1.0.0.1

Des Weiteren bin ich auf den DNS-Dienst von Quad 9 gestoßen, der sowohl Zuverlässigkeit als auch Datenschutz verspricht:

9.9.9.9

Update Dezember 2019

Die Resolver der Firma Level 3 haben in der letzten Zeit oftmals Anfragen mit Timeouts quttiert. Ich rate daher von Ihrer Nutzung ab.
Die Server von Quad 9 sowie Cloudflare scheinen zuverlässiger zu sein.

VMware vSphere-Client Download nicht möglich

Firma VMware setzt nun auf den Webclient für vSphere. Ältere Downloadlinks, zum Beispiel von der Webseite eines ESXi 5.5 – Hosts, sind wahrscheinlich deshalb nicht mehr gültig:

VMware war so nett und hat einen KB-Artikel veröffentlicht, in dem die Links zu allen Versionen nochmals aufgelistet werden:

https://kb.vmware.com/s/article/2089791?language=en_US&sliceId=1&dialogID=889034206&docTypeID=DT_KB_1_1&stateId=0+0+889036554

DD-WRT und KRACK-Attack

Wer DD-WRT nutzt, sollte schnellstens patchen, da Linux eines der Betriebssysteme ist, welches besonders angreifbar für KRACK ist.

Momentan gibt es erst ein Beta-Release einer Firmware, die diese Lücke schließen soll. Das entsprechende Release-Build lautet r33555 und kann hier bezogen werden:

ftp://ftp.dd-wrt.com/betas/2017/10-20-2017-r33555/

Das Update kann einfach über das Webinterface der Routerfirmware eingespielt werden.

DD-WRT Firmware Update

Update:

Das neuste (Beta-) Release kann stets unter ftp://ftp.dd-wrt.com/betas/ bezogen werden. Die Releases sind auf dem FTP-Server nach Release-Date sortiert abgelegt.

WSUS-Installation auf Server 2012: „Post install error HTTP-Status 503“

Nachdem ich auf einem Windows Server 2012 R2 die WSUS-Rolle hinzugefügt hatte, konnte ich den Setup-Wizard über die WSUS-Konsole nicht öffnen, um die Konfiguration des WSUS abzuschließen.

Die Konsole erzeugte folgenden Fehler:

Log file is located at C:\Users\administrator.DOMAIN\Appdata\Local\Temp\tmpF7EC.tmp
Post install is starting
Fatal Error: Failed to start and configure the WSUS service

Das in der Fehlermeldung angegebene Logfile beinhaltete folgende Informationen:

Scheinbar ein Problem, den IIS zu konfigurieren, denn es wurde ein HTTP-Error 503 zurückgegeben.

Nachdem ich den virtuellen Host im IIS für die WSUS-Verwaltung gelöscht hatte, war ein Durchführen der Post-Installationsroutine und ein Ausführen des Konfigurationswizards wieder möglich.