Authenticode

Es war bei einem Kunden, der den Zugang zum Internet nicht offen gestaltet hat. Man musste nur die Adresse des Proxy Servers können und konnte ohne weitere Anmeldung surfen. Allerdings hat selbst diese Umgebung das Exchange 2007 Rollup5 Fix dafür gesorgt, dass nach der Installation die Exchange Dienste nicht mehr gestartet sind.

Empfohlene Lösung für Exchange 2007
944752 Exchange 2007 managed code services do not start after you install an Update rollup für Exchange 2007

Was war passiert ?

Das Symptom

Programme können schon seit längerem mit einer digitalen unterschrift (Codesigning) versehen werden. Anscheinend wurden durch das Rollupfix 5 für Exchange 2007 einige Dateien nun digital signiert, so dass das .NET Framework die Gültigkeit dieser Signatur überprüfen möchte.

Kann der PC nun nicht die ausstellende Zertifizierungsstelle erreichen, um die Gültigkeit des Zertifikats zu prüfen, dann passiert, es, dass der Windows Dienstmanager lapidar meldet, dass der Dienst nicht rechtzeitig auf eine Anforderung reagiert hat und der Dienst wird einfach nicht gestartet.

Fatal dabei ist, dass de Exchangecode selbst noch gar nicht ausgeführt wurde und Sie daher im Eventlog natürlich auch lange nach Fehlern seitens Exchange suchen können. Sie werden keine finden. Letztlich können die Exchange Dienste nicht mehr starten. Auch ein wiederholter Versuch schläft fehl.

Exchange Rollup-Installationen dauern dann seht lange. Im Exchange 2010 SP1 Rollup1 habe ich dazu sogar das erste Mal eine Warnung gesehen

Es ist natürlich Schade, dass es vom Jan 2008 (2007RU5) bis Okt 2010 (2010SP1RU1) gedauert hat, um die Administratoren darauf aufmerksam zu machen. Auf der anderen Seite muss sich eine Firma natürlich auch fragen lassen, warum sie dem Thema CRL bislang so wenig Aufmerksamkeit geschenkt hat.

PCs, Internet Explorer und Internet Zugriff mit WinHTTP

Im Hintergrund versucht der PC selbst nämlich die Webseite hhttp://crl.microsoft.com zu erreichen, um die Gültigkeit zu prüfen. Wer nu glaubt, er könne doch mit seinem PC im Internet surfen und trägt im Internet Explorer die korrekten Proxy Einstellungen ein, der irrt. Windows ist ein MultiUser System und nur weil Sie als Administrator auf der Konsole "surfen" können  (ob das gut ist, muss jeder selbst für sich klären), können noch lange nicht alle Programme und Dienste auf das Internet zugreifen. Besonders der Computer selbst und Dienste, die als "LocalSystem" arbeiten, können nicht von den Proxy Einstellungen und Authentifizierungstokens des angemeldeten Benutzers profitieren.

Aber auch für "LocalComputer" gibt es Proxyeinstellungen, die aber nicht per GUI durchgeführt werden können. Anstatt aber nun in der Registrierung unter "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\" Einträge direkt vorzunehmen, sollten Sie statt dessen das Hilfsprogramm "PROXYCFG.EXE" verwenden. Starten Sie ProxyCFG einfach in einer CMD-Box. Ein einfacher Aufruf zeigt die aktuellen Einstellungen an : (Beispiel mit "direkter Zugriff")

ProxyCFG

Mit dem Aufruf "Proxycfg -u" übernimmt man die aktuellen Proxy-Einstellungen des angemeldeten Benutzers für das System: (Hier am Beispiel von NetatWork):

ProxyCFG mit Proxy

Man sieht dass hier z.B. einige URLs nicht über den Proxy geleitet werden. Ein einfacher Aufruf von "Proxycfg" zeigt die aktuellen Einstellungen an. "Proxycfg -d" stellt wieder den direkten Zugang ein. Man muss allerdings lokaler Administrator sein, um die Einstellungen durchführen zu können.

Proxy mit Windows 2008

Das Programm ProxyCFG gibt es nicht mehr auf Windows 2008. Die Registrierungsschlüssel sind natürlich die gleichen. Aber hier hilft dann NETSH:

REM Setzen
netsh winhttp set proxy 192.168.100.21:8080 bypass-list=lokaler_Domänenname

REM Anzeigen
netsh winhttp show proxy

Unabhängig von den Einstellungen per Kommandozeile, der immer wieder vergessen wird, gefällt mir als Administrator natürlich der Weg besser, diese Einstellungen entweder per Gruppenrichtlinie oder WPad durchzuführen. Einige Applikationen ignorieren aber sogar diese Einstellung. Speziell für .NET Programme gibt es eventuell abweichende Einstellungen in der jeweiligen Application.config/Web.config

Hintergründe

Wenn man einige KB-Artikel und die MSDN liest, dann ist Authenticode im Prinzip natürlich etwas Gutes. Schon sehr lange werden z.B. ActiveX-Controls, die von Webseiten geladen werden, digital signiert. Damit können Sie als Anwender prüfen, dass der Code unterändert ist und der Hersteller bekannt ist. Die Installation von nicht signierten Controls oder Controls unbekannter Hersteller sollten Sie nicht akzeptieren. Wer heute professionell Software entwickelt und verteilt, sollte diese auch digital signieren können. Leider sind offizielle Codesigning-Zertifikate nicht gerade "günstig".

Kaum ein Entwickler eines Trojaners, Virus oder sonst wie schädlichen Programms wird seinen Code signieren, da er dann ja nicht mehr anonym ist. Weiterhin verhindert der Einsatz von digitalen Signaturen in Verbindung mit Programmcode, dass dieser nachträglich auf der Festplatte des Computers verändert wird. Es verhindert natürlich auch, das jemand den Code in seinem Sinne verändert (z.B.: Textbausteine austauscht etc.)

Achtung
Wenn der Administrator die Überprüfung von Codesignaturen abschaltet, ist der Schutz nicht mehr gegeben, d.h. Code kann unbemerkt verändert werden.

Windows prüft nun nicht nur die Signatur des Codes, sondern möchte auch wissen, ob das Zertifikat vielleicht zurückgezogen wurde. Daher verbindet es sich mit der "Certificate Revocation List" (CRL). Das passiert in zwei Fällen:

  • CryptoAPI-Aufrufe
    Als Entwickler kann ich mich der CryptoAPI bedienen, um Signaturen zu prüfen. In diesem Fall wird eine Verbindung zum Internet aufgebaut.
  • .NET 2.0 lädt managed Assemblies
    Lädt das Framework ein digital signiertes Codeteil zur Ausführung, dann prüft es ebenfalls die CRL und sucht dazu im Internet den Kontakt zur CRL

Sicher gibt es noch weitere Fälle, aber diese beiden Beispiele sind für Exchange 2007 relevant.

Verhalten je nach Verbindung

Kann der Aufruf an http://crl.microsoft.com nicht erfolgen, dann hängt es auch davon ab, wie die Netzwerkverbindung auf die versuchte Anfrage reagiert.

  • Timeout bei Namensauflösung
    Wird kein Proxy eingesetzt, dann versucht der Server eine DNS Auflösung. Der DNS-Server kann nun auf drei Arten reagieren:
    • "Name nicht gefunden"
      Diese schnelle Antwort bringt den Server dazu, die Abfrage abzubrechen und, je nach Einstellung, ohne Prüfung weiterzufahren.
    • Timeout bei Namensauflösung
      Des kann einige Sekunden dauern und führt zu dem Problem, dass die Anfrage länger dauert als der Service Controls Manager auf den Dienst wartet. Der Dienst startet nicht
    • IP-Adresse wird zurück übergeben
      In diesem Fall versucht der Server dann eine direkte HTTP-Verbindung
  • Timeout bei Connection
    Auch bei der Verbindung gibt es mehrere Optionen
    • TCP-Verbindung wird aktiv blockiert (RSET)
      Der Server weiß also, dass er das Ziel nicht erreichen kann und bricht ab.
    • TCP-Verbindung wird gedroppt (Paket ohne Quittung verworfen)
      Für den Server sieht es nun so aus, als ob die Verbindung einfach nur "sehr langsam" ist. Er versucht mehrfach eine TCP-Verbindung zu etablieren, was relativ lange dauert und ebenfalls den Start des Dienstes verhindert

Es ist also zu erkennen, dass das Problem um so offensichtlicher wird, umso schlechter das eigene Netzwerk konfiguriert ist. hat man früher in Firewall sehr gerne Verbindungen einfach "versickern" lassen, so sollte man heute zumindest Verbindungsversuche von intern nach extern aktiv blockieren und den Client auch darüber informieren, dass es nicht weiter geht. Die Zeiten, als man als Administrator sogar ICMP (PING) aus Sicherheitsaspekten geblockt hat, sind schon länger vorbei.

Lösung

Mit dem Wissen um die Hintergründe und das Verhalten ist auch die Beschreibung der verschiedenen LösungsMöglichkeiten einfach:

  • http://crl.microsoft.com erreichbar machen
    Machen Sie die Microsoft CRL erreichbar für ihre Server. Über eine passende Proxy-Konfiguration auf dem Server und geeignete Firewallregeln sollte der Server problemlos die CRL erreichen können. Das ist sicher der schnellste und einfachste Weg, zumindest wenn die Server überhaupt ins Internet kommen. Beim Einsatz eines Proxy-Server sollten Sie darauf achten, dass die Proxyeinstellungen mit "PROXYCFG" auch für LocalMachine gelten.
  • .NET Authenticode Timeouts verändern
    Auch die Zeit, die das .NET Framework und CryptoAPI wartet, kann reduziert werden. Dies ist aber nur mit Vorsicht durchzuführen, da bei langsamen Internetverbindungen natürlich die Prüfung eventuell nicht gelingt und Prozesse, die eine Gültigkeitsprüfung fordern, dann nicht funktionieren. Die Werte können auch über eine Gruppenrichtlinie gesteuert werden.
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\ EncodingType 0\CertDllCreateCertificateChainEngine\Config]
"ChainURLRetrievalTimeoutMilliseconds"=dword:00015000
"ChainRevAccumulativeURLRetrievalTimeoutMilliseconds"=dword:00020000
  • Timeout für Dienststart erhöhen
    Ein anderer Weg besteht darin, den Service Control Manager (SCM) so einzustellen, dass er länger auf den Start des Dienstes wartet. Damit hat das NET-Framework mehr Zeit um die Timeouts der CRLAbfrage zu überstehen und den Dienst doch noch zu starten. Allerdings "verzögert" das unter dem Strich natürlich schon den Start eines jeden Dienstes. Der Wert ist in der Registrierung in Millisekunden anzugeben und wird erst nach dem Neustart des Servers übernommen.
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control]
"ServicesPipeTimeout"=dword:00015000
  • Lokale "crl"
    Denkbar ist natürlich auch, dass man die CRL der Microsoft CA einfach lokal im Netzwerk bereit stellt und den internen DNS-Server oder den Proxy so konfiguriert, dass die CRL eben vom internen Server bezogen wird. Allerdings müssen Sie selbst dann natürlich von Zeit zu Zeit dafür sorgen, dass die aktuellen CRLs des Microsoft Servers auf ihren Server kopiert werden.
  • application.config
    Zu jeder .NET 2.0 Anwendung kann man im gleichen Verzeichnis eine .CONFIG-Datei anlegen. (also zum Programm "Dienst.exe" gibt es dann eine "Dienst.exe.config"). Aus dieser Datei bezieht das NET-Framework weitergehende Konfigurationseinstellungen für die Anwendung. Angeblich soll man durch folgende Zeilen in dieser Datei ebenfalls die Prüfung abschalten können. Allerding müssen sie dann für jedes Programm eben selbst die vorhandenen Datei anpassen oder neu erstellen. Und die Einstellung funktioniert nur, wenn Sie einen Hotfix, der in "936707 FIX: A .NET Framework 2.0 managed application that has an Authenticode signature takes longer than usual to start " beschrieben ist, installiert haben.
    Exchange Server 2007 rollups nightmares - automate the .config file modification  http://blogs.technet.com/b/gbordier/archive/2008/07/11/exchange-server-2007-rollups-nighmares.aspx
    <generatePublisherEvidence>-Element
    http://msdn.microsoft.com/de-de/library/bb629393.aspx
<configuration>
	<runtime>
		<generatePublisherEvidence enabled="false"/> 
	</runtime>
</configuration>
  • Authenticode bei der Installation
    Wenn sie bei der Installation schon "lange" auf den Abschluss einer Komponente warten müssen, dann können Sie im Internet Explorer die im Bild markierte Option deaktivieren
    IE SSl Sicherheit
    Damit wird auch hier die Prüfung auf zurückgezogene Zertifikate abgeschaltet. Machen Sie dies bitte nicht auf Systemen, mit denen Sie regelmäßig im Internet surfen.

Mein Favorit ist natürlich eine Konfiguration bei der die Programme im Netzwerk sicher und zuverlässig Zertifikate überprüfen können. In diesem Fall also die Konfiguration eines Proxy-Servers auf jedem Server (z.B.: per Gruppenrichtlinie) und die Erreichbarkeit bestimmter Webseiten ohne weitere Authentifizierung oder für die gruppe "Domänen Computer".

Server und Internetzugriff?

Natürlich lässt es sich wunderbar streiten, ob Server Verbindungen zum Internet (und insbesondere Microsoft) aufbauen dürfen, oder ob Server überhaupt solche Verbindungen benötigen. Andererseits gibt es heute sehr leistungsfähige Filter und Proxy-Server, die einen gesicherten Zugriff auf bestimmte URLs erlauben können. Das ist natürlich nicht mit einem Router und NAT zu vergleichen.

Der Zugriff per HTTP ist für Server auch noch aus anderen Aspekten ganz hilfreich, z.B.

  • Updates von EXBPA und anderen Assistenten
    An vielen
  • Fernwartung durch Dienstleister (MSXFAQ.DE - Fernwartung)
    Viele Produkte nutzen heute HTTP um durch Firewalls hindurch eine Fernwartung für Dienstleister zu erlauben
  • Aktuelle OnlineHilfe
    An vielen Stellen der Exchange Offline Hilfe gibt es Links zu eventuell aktuelleren Online Seiten. Sogar Links zu Supportforen, Downloads oder weiteren Informationen können direkt vom Server aus erreicht werden.
  • Microsoft Error Reporting und Eventlog
    Bei Fehlern im Eventlog gibt es Links zu Internetseiten mit weiterführenden Informationen. Auch der Ausfall eines Dienstes (Dr. Watson) kann an Microsoft gemeldet werden. Oft gibt es sogar direkte Hinweise auf Updates und Korrekturen.
  • Und einige mehr

Aus meiner Sicht ist es leichtsinnig, einen Server "einfach so" per HTTP in das Internet zu lassen. Aber mit der passenden Konfiguration des Internet Explorers und einem Proxy, der für Server nur bestimmte URLs zulässt (die natürlich zu pflegen sind), ist eine Verbindung aus meiner Sicht problemlos und eher ein Vorteil. Normale Anwender können ja weiterhin über einen Proxy und eine Anmeldung auf andere Ziele zugreifen.

Wenn Sie aber ein Problem mit ihrem Server haben und Sie für eine schnelle Recherche im Internet oder beim Hersteller immer erst Fehlermeldungen abschreiben müssen, dann geht kostbare Zeit verloren.

Fusion Log Viewer

Wenn ihr Exchange dann immer noch "träge" startet, könnten es auch andere Probleme beim Laden, Kompilieren und Binden von DLLs sein. Dann hilft eventuell folgendes:

Hier die erforderliche REG-Datei, um das Logging zu aktivieren.

Windows Registry Editor 5.0

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion]
"LogPath" = "C:\fusionlogs"
"LogFailures" = 1
"ForceLog" = 1
"LogResourceBinds" = 1

Dieses Werkzeug protokolliert die relevanten Vorgänge im .NET Framework.

Code Access Security Policy Tool (Caspol.exe)

Auch beim Einbindung von anderen Codeteilen wird über einen Vertrauenslevel gesteuert. Das ist zum einem über die Signatur der Datei aber auch über den Pfad bestimmt. Lokale Dateien sind eher vertrauenswürdig als Dateien über einen Netzwerkshare oder gar aus dem Internet.

Sie sehen schon, wie .NET und auch Windows by Default versucht immer "sicherer" zu werden, indem man nicht erst Programme auf ihre Verhalten oder Schadhaftigkeit überprüft (wie es Virenscanner machen), sondern von vorneherein über einen Vertrauenslevel die Ausführung von "unbekannten" und damit unsicheren Programmteilen unterbindet. Und das kann manchmal auch gewollte Prozesse stoppen.

Weitere Links