Icon Makefg

Wenn Sie NoSpamProxy Large Files hinter Microsoft TMG einsetzen, kommt es zu Fehlermeldungen, wenn Sie Dateien mit Umlauten über NoSpamProxy verschicken. Die Fehlermeldung ist sehr kryptisch und sagt lediglich aus, dass es sich um einen internen Serverfehler handelt. Als Statuscode wird ein 500 er Fehler angezeigt. Grund für diese Meldung ist die Verwendung von sogenannten High Bit-Zeichen, die standardmäßig in Microsoft TMG im Rahmen des HTTP-Sicherheitsfilters verboten sind.
Aktiviert man in TMG die Protokollierung, sieht man eine Verweigerte Verbindung:

LargeFiles over TMG Bild1

Um das Problem zu lösen, muss in der HTTP-Richtlinie in der Regel das High Bit-Zeichen erlaubt werden.

LargeFiles over TMG Bild2

Einstellung in Microsoft TMG

Icon Makefg

Aus Sicherheitsgründen wird die API bei GlobalSign auf bestimmte Anfrage-IP-Adressen limitiert. Damit Sie Ihre Anfragen erfolgreich durchführen können, müssen Sie die öffentlichen IP-Adressen Ihrer Gateway Rollen bei GlobalSign hinterlegen.

GlobalSign IP Configuration

Icon Makefg

Dieser Artikel beschreibt, wie Sie mit den Debugging Tools Logfiles für die Analyse von hohen Prozessorauslastungen erstellen können, die dann vom NoSpamProxy Support ausgewertet werden.

Installieren Sie auf dem Server mit der hohen Prozessorlast zunächst die Debugging Tools von Windows. Diese können Sie sich zum Beispiel hier herunterladen https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/
Anschließend geben Sie folgenden Befehl in der Kommandozeile ein:
cdb.exe -pv -pn NetatWorkMailGatewayGatewayRole.exe -c ".load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll;!EEStack -ee;qd" > NoSpamProxyStack_%date:~-4,4%%date:~-7,2%%date:~-10,2%_%time:~0,2%%time:~3,2%%time:~6,2%.log
Ersetzen Sie vorher ggfs. den Prozess NetatWorkMailGatewayGatewayRole.exe durch den Prozess, der die hohe Prozessorlast verursacht. Führen Sie den Befehl mehrfach aus und schicken Sie die entstandenen Log-Dateien anschließend in gezippter Form an den NoSpamProxy Support.

Icon Makefg

Dieser Artikel beschreibt, wie Sie den LoopbackCheck des Windows Servers abschalten können. Dies ist immer dann notwendig, wenn das Web Portal und die Gateway Rolle bzw. Intranet Rolle auf demselben Server installiert sind und die Verbindung von der Gateway Rolle zum Web Portal über den FQDN hergestellt werden soll.

Gehen Sie dazu wie folgt vor:

  1. Klicken Sie auf Start und auf Ausführen, geben Sie regedit ein, und klicken Sie auf OK.
  2. Klicken Sie auf den folgenden Registrierungsunterschlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
  3. Klicken Sie mit der rechten Maustaste auf Lsa, zeigen Sie auf Neu, und klicken Sie auf den DWORD-Wert.
  4. Geben Sie DisableLoopbackCheck ein, und drücken Sie anschließend die [EINGABETASTE].
  5. Klicken Sie mit der rechten Maustaste auf DisableLoopbackCheck. Klicken Sie dann auf Ändern.
  6. Geben Sie im Feld Wert den Wert 1 ein, und klicken Sie auf OK.
  7. Beenden Sie den Registrierungs-Editor.
  8. Starten Sie den Computer neu, damit die Änderung wirksam wird.

Alternativ können Sie auch einzelne Hostheader freigeben. Die entsprechende Anleitung finden Sie hier: http://www.techtask.com/sharepoint2010/loopback-check-in-sharepoint-2010-ausschalten-disableloopbackcheck/

Icon Makefg

Fehler:

Obwohl unter “Kryptografische Schlüsselanbieter” die Konfiguration für SwissSign korrekt erfolgt ist und alle Gateway Rollen via TCP 443 (https) auf ra.swisssign.net Zugriff haben, erscheint beim Abrufen von Zertifikaten folgende Fehlermeldung im Eventlog:
ID: 026f7e58-9be2-4434-b562-11016c181bfd
Created: 12.06.2015 12:15:56
Mail address: Test.Benutzer@nospamproxy.de
Request type: CertificateRequest
Request status: Failed
Failure status: TrustCenterError
Error text: Unexpected error: Message:
An error occurred while sending the request.
Error type:
System.Net.Http.HttpRequestException

Error code: 2148734208
Program location:
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at Netatwork.NoSpamProxy.Cryptography.SwissSignCertificateProvider.<EnrollAsync>d__e.MoveNext()

The request was aborted: Could not create SSL/TLS secure channel.

Message:
The request was aborted: Could not create SSL/TLS secure channel.
Error type:
System.Net.WebException

Error code: 2148734217
Program location:
at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context)
at System.Net.Http.HttpClientHandler.GetRequestStreamCallback(IAsyncResult ar)

Subject name:E=test.benutzer@nospamproxy.de, CN=Secure Mail: Gateway Certificate

Ursache:

Sowohl im Zertifikatsspeicher des Computerkontos einer oder aller Gateway Rollen sowie im Zertifikatsspeicher des NoSpamProxy Encryption Gateways befindet sich das Pseudo-AutoRAO-Dienstzertifikat zur Authentifizierung beim Dienstanbieter SwissSign.

Lösung:

Unter “Kryptografische Schlüsselanbieter” öffnen Sie die Konfiguration für den Anbieter SwissSign. Hier finden Sie das hinterlegte Pseudo-AutoRAO-Zertifikat. Mit einem Klick auf dieses werden die Zertifikatsdetails angezeigt, die beim Identifizieren des korrekten Zertifikats im Zertifikatsspeicher des Computerkontos hilfreich sind:

SwissSign Provider Configuration

Öffnen Sie nun als Administrator “mmc.exe” auf der Gateway Rolle.

Zertifikatsverwaltung öffnen

Klicken Sie auf “Datei” und “Snap-In hinzufügen/entfernen” (1). Wählen Sie anschließend “Zertifikate” (2) und klicken Sie auf “Hinzufügen” (3). Es erscheint ein neues Fenster, in dem Sie das “Computerkonto” (4) auswählen und mit “Weiter” (5) bestätigen. Wählen Sie den “Lokalen Computer” (6) und klicken Sie auf “Fertigstellen” (7). Sie kehren Zurück zur Snap-In-Auswahl und bestätigen diese mit “OK” (8).

SwissSign Certificate at MS Store

Navigieren Sie nun zu den “Eigene Zertifikate” (1) und finden Sie das Pseudo-AutoRAO-Dienstzertifikat. Wählen Sie dieses aus (2) und löschen Sie es (3). Anschließend starten Sie bitte das betroffene Windows System der Gateway Rolle neu, damit die Änderungen wirksam werden.

Wiederholen Sie diese Schritte ggf. für alle weiteren Gateway Rollen.

Icon Makefg

Verhalten:

In der Ereignisanzeige sehen Sie immer wieder diese Meldung:
---------------
Gateway Role 1088:
Could not secure an inbound connection with the host 192.168.0.100:53627.
Die angegebenen Daten konnten nicht entschlüsselt werden
Error type:
System.ComponentModel.Win32Exception
Error number:2147500037
Program location:
---------------

In der Folge finden Sie auch zum gleichen Zeitpunkt einen SChannel-Fehler im Windows-Anwendungs-Eventlog wie diesen:
---------------
SChannel 36887:
Es wurde eine schwerwiegende Warnung vom Remoteendpunkt empfangen. Die schwerwiegende Warnung hat folgenden für das TLS-Protokoll definierten Code: 51.
---------------

Beachten Sie bitte, dass die ID und der Code sich geringfügig unterscheiden können.

Erklärung:

Windows 2008 R2 und neuer unterstützt von Haus aus bzw. nach einem Windows-Update ältere, schwache Ciphersuites, die als gebrochen gelten, nicht mehr. Daher kommt keine TLS-Verbindung zustande, wenn der einliefernde Server nur diese beherrscht. Als Folge dessen werden die oben genannten Warnungen bzw. Fehler geloggt. Der einliefernde Server muss dann einen Fallback auf Klartext durchführen. Hierzu ist es notwendig, dass der einliefernde Server eine neue Verbindung aufbaut, da die alte Verbindung, bei der keine TLS-Verbindung hergestellt werden konnte, geschlossen werden muss.

Die Unterstützung lediglich veralteter Ciphersuits ist definitiv ein Problem des absendenden Servers, wenn dieser kein Fallback auf Klartext macht, sobald keine TLS-Verbindung erfolgreich zustande kommt. Die Warnungen im Log weisen entsprechend nur darauf hin, dass die Verbindungen nicht zustande kamen, weil der TLS-Handshake nicht funktionierte; sprich sich auf keine Ciphersuite geeinigt werden konnte, da keine gemeinsame gefunden wurde. Manche Server verwenden dann einfach stumpf eine Ciphersuite ihrer Wahl, was dann zu weiteren Meldungen führen kann.

Sollte aufgrund dieses Verhaltens Ihre Kommunikation gestört sein, wenden Sie sich bitte an den Betreiber des einliefernden Servers und weisen ihn auf den hier geschilderten Umstand hin. Es obliegt dann dem Betreiber TLS zu deaktivieren oder seine Lösung dem aktuellen Stand der technischen Entwicklung anzupassen.

Icon Makefg

Fehler:

Bei manchen Benutzern kann der Antwortlink des NoSpamProxy Large Files nicht in die Mail eingefügt werden.

Lösung:

Prüfen Sie bitte, ob per GPO die folgende Sicherheitseinstellung greift:

GPO Einstellung für Antwortlink

Falls ja, setzen Sie bitte die aktivierte Sicherheitseinstellung auf “Disabled”.

Icon Makefg

Fehler:

Wenn Smartcard-Lesegeräte zum Einsatz kommen, die über einen Netzwerk-USB-Anschluss angesteuert werden, wird entweder die Smartcard oder das Token auf der Smartcard selber nicht angezeigt.

Status:

Dieser Fehler taucht immer dann auf, wenn die Verbindung in einer RDP Sitzung hergestellt wird.

Lösung:

Die Smartcard-Anbindung über eine netzwerkbasierte USB-Verbindung sollte über den Hyper-V Manager oder den VMWare Manager in einer direkten Verbindung zur VM hergestellt werden.