Bents Blog

In meinem letzten Artikel zum Problem bei der Migration eines Microsoft ISA Server 2006 auf das Microsoft Threat Management Gateway 2010 hatte ich bereits über die verwendete Celestix Appliance berichtet. Innerhalb eines Kundenprojektes bestand für mich die Aufgabe eine Celestix MSA 2000i auf eine Celestix MSA 1500i TMG zu migrieren, inklusive der zusätzlichen Zweifaktorauthentifizierungslösung (RADIUS One-Time-Password) von VASCO (nähere Informationen dazu in meinem Beitrag zur VASCO-Lösung). Dieses sehr sichere Authentifizierungsverfahren (basierend auf Hardware-Token und Benutzer-PIN) verwenden wir bei fast allen Installationen eines ISA Servers bzw. TMG 2010, um bspw. VPN-Verbindungen oder veröffentlichte Webseiten (Outlook Web Access) abzusichern.

Da sich die beiden Versionen grundsätzlich unterscheiden, möchte ich hier meine Erfahrungen dokumentieren und die Lösung präsentieren.

Vorbereitung und Analyse

Eines vorweg – eine direkte Migration auf der alten Appliance ist definitiv nicht möglich, da sich bereits das Betriebssystem des ISA Servers nicht auf die neue Version 2008 R2 upgraden läßt. Zwangsläufig muss der Weg einer parallelen Neuinstallation gewählt werden. Zu Beginn ein Vergleich der unterschiedlichen Produkte beider Lösungen:

Bestehende Lösung: Celestix MSA 2000i Appliance

• Betriebssystem Microsoft Windows Server 2003 R2 (32 Bit)
• Microsoft ISA Server 2006 Standard Edition
• VASCO VACMAN Middleware 3.0

Neues Zielsystem: Celestix MSA 1500i TMG Appliance

• Betriebssystem Microsoft Windows Server 2008 R2 (64 Bit)
• Microsoft Forefront Threat Management Gateway 2010 Standard Edition
• VASCO IDENTIKEY Server 3.2

Auf Seite der Hardware ähneln sich beide Versionen stark, beim neuen System kommen lediglich neuere Komponenten zum Einsatz. Die VASCO Lösung (VACMAN Middleware) wurde auf dem bestehenden System lokal auf der Celestix MSA 2000i installiert, auf Grund einer fehlenden Windows-Domäne werden dabei alle Daten in einer eigenen PostgreSQL Datenbank gespeichert. Auch das neue Zielsystem sollte autark – weiterhin ohne Integration in einer Windows-Domäne – funktionieren, da der Kunde überwiegend Linux-Systeme im Einsatz hat.

Plan der Migration

Nach meinen Vorstellungen sollte die Migration in relativ kurzer Zeit abgeschlossen werden, da ich mich im Vorfeld mit den Rahmenbedingungen und Anforderungen der Hersteller beschäftigt hatte. Die folgenden Schritte hatte ich geplant:

1. Export der Konfigurationsdaten des ISA Server 2006
2. Export der Benutzerdaten und Token aus der VASCO Middleware Lösung
3. Konfiguration der neuen Appliance (Betriebssystem und TMG 2010 vorinstalliert, als Recovery-Image integriert)
4. Import der ISA-Konfigurationsdaten im TMG 2010
5. Installation der neuen VASCO Lösung Identikey Server 3.2
6. Prüfung und Test
7. Austausch der Appliances

Leider wurde ich bereits beim vierten Schritt enttäuscht, ich berichtete darüber in meinem vorherigen Beitrag.

Installation der neuen Appliance

Wie beschrieben, war ich leider beim Import der Konfiguration der alten Appliance (ISA Server) auf dem TMG 2010 gezwungen, auf Automatismen zu verzichten und alle Definitionen im TMG 2010 manuell zu erstellen. Zu meinem Glück hielt sich dieser Aufwand in Grenzen, da die definierten Protokolle, Objekte und Regeln überschaubar waren.

Installation des VASCO IDENTIKEY Server 3.2

In größeren Umgebungen sollte die Software (die letztendlich als eigener RADIUS Server fungiert) immer auf einem anderen System und nicht auf der Firewall selbst installiert werden. In meinem Fall handelt es sich allerdings um eine relativ kleine Umgebung mit etwa 20 Benutzern. Außerdem wird die gesamte Firewall täglich über das im Betriebssystem integrierte Windows Image Backup (Windows Serversicherung) gesichert, um im Falle eines Bare-Metal-Recovery eine zügige Wiederherstellung zu ermöglichen.

Die Software von VASCO ist sowohl in einer 32 Bit als auch in der 64 Bit Version verfügbar. Auf Grund des Betriebssystems Windows Server 2008 R2 musste zwangsläufig die 64 Bit Variante installiert werden. Der VASCO Identikey Server besteht dabei aus folgenden Komponenten:

• IDENTIKEY Server 3.2
• Datenbank (PostgreSQL, Microsoft SQL Server via ODBC oder Active Directory)
• Java JRE
• Apache Tomcat 6.0 (Webserver für die Verwaltung)

Da der TMG 2010 bereits eine Microsoft SQL Server 2008 Express Edition (64 Bit) installiert, entschied ich mich, diese zu nutzen, um nicht noch eine weitere Datenbank installieren zu müssen (PostgreSQL ist nur in 32 Bit verfügbar, Active Directory ist nicht vorhanden). Dazu installierte ich zuerst das Microsoft SQL Server 2008 Management Studio Express auf dem neuen System, um eine neue Datenbank innerhalb der Instanz MSFW zu definieren (vorher Named Pipes aktiveren, um als lokaler Administrator via \\.\pipe\mssql$msfw\sql\query zugreifen zu können). Anschließend legte ich mit Hilfe der MMC Datenquellen (ODBC) eine neue User DSN „Identikey Server“ an.

Danach kann mit Hilfe des Tools dpdbadmin (im Ordner der Installationsdateien vorhanden) kann dann mit Hilfe des folgenden Befehls das vom IDENTIKEY Server benötigte Datenbankschema erzeugt werden:

dpdbadmin addschema -d „Identikey Server“ -u <Benutzer> -p <Passwort>

Anschließend konnte der VASCO IDENTIKEY Server erfolgreich installiert werden, die ODBC Verbindung zur Datenbank funktioniert ohne Probleme. Der Installations-Assistent sollte dann wie folgt aussehen:

Nach der Installation können mit Hilfe des Configuration Wizard die Kernkomponenten eingerichtet werden. Im Wesentlichen betrifft das die Konfiguration des RADIUS Servers (IP Adresse, Ports, Shared Secret, Administrator-Passwort). Dabei lassen sich die Webseiten für das Token-Management (Selfmanagement für die Benutzer) im IIS integrieren, welcher bereits durch die Celestix Web-Administration (Comet) installiert war.

Lediglich die Verwaltung der VASCO Lösung für Benutzer, Token, Richtlinien, RADIUS-Clients und Lizenzen muss über die Webseite des Apache Tomcat erfolgen:

Die Konfiguration des VASCO RADIUS Servers ist zwar ein durchaus komplex, stellt aber kein Hexenwerk dar. Allerdings sollte man sich vorher mit dem Thema RADIUS beschäftigen, da man sonst bei der Konfiguration von VASCO leicht den Überblick verlieren kann.

Konfiguration des TMG 2010 für die Verwendung des VASCO RADIUS Server

Im Anschluss kann nun die Firewall für die Verwendung des VASCO RADIUS Server konfiguriert werden. Exemplarisch möchte ich das hier für die VPN-Konfiguration zeigen, aber auch für veröffentlichte Webseiten kann ein Weblistener mit HMTL-Formularauthentifizierung den RADIUS-Server verwenden:

Für die Verwendung eines RADIUS-Servers bei der VPN Einwahl erfolgt die Konfiguration im TMG unter Remotezugriffsrichtlinie (VPN) unter VPN-Clients. Unter der Option RADIUS-Server auswählen kann nun die Einstellung für die IP-Adresse des RADIUS Servers, das Shared Secret und der Port für Authentifizierung (Standard 1812) und Kontoführung (Standard +1 = 1813) eingetragen werden:

Diese Konfiguration funktionierte bereits im ISA Server 2006 in Kombination mit der VACMAN Middleware immer ohne Probleme. Leider wurde ich bei meinen Tests arg auf dem neuen System mit TMG 2010 und IDENTIKEY Server arg enttäuscht.

Bei einem Test der VPN-Einwahlverbindung (PPTP) stellte ich mit Hilfe des VASCO Audit Viewers fest, dass kein RADIUS Request von der Firewall an den VASCO RADIUS Server gesendet wurde. Folglich prüfte ich diesen Fakt in der Protokollierung des TMG, auch hier wurde kein einziges RADIUS Paket versendet, geschweige denn empfangen. Nach einiger Suche fand ich einen entsprechenden Hinweis im Ereignisprotokoll der Maschine: Der Network Protection Server (NPS) meldete im Systemereignisprotokoll den folgenden Fehler mit der Event-ID 25:

Problem

Der NPS (Rolle des Betriebssystems) ist bei Celestix bereits vorinstalliert, obwohl Microsoft die Installation des NPS nicht auf der Firewall selbst empfiehlt. Das Problem ist, dass der TMG 2010 den NPS selbständig konfiguriert (Richtlinien und RADIUS Konfiguration). Dabei wird im obigen Beispiel, die IP-Adresse des VASCO RADIUS Servers in die Gruppe der remoten RADIUS Server aufgenommen. Im gleichen Moment erkennt der NPS aber, dass diese IP-Adresse zum lokalen System gehört und ignoriert diese. Aus diesem Grund werden keine RADIUS Pakete an den VASCO RADIUS versendet, die Authentifizierung – und damit auch die VPN-Einwahl – schlagen fehl.

Lösung

Da der NPS im Betriebssystem integriert ist, lässt sich dieser leider nicht überlisten. Ich hatte diverse Versuche unternommen, welche alle ohne Erfolg blieben. Auch die Deinstallation der Rolle des NPS führte zu keinem sinnvollen Ergebnis, denn der Fehler im Systemprotokoll (Event-ID 25) tauchte trotzdem auf, wenn auch mit etwas anderer Beschreibung – es wurden weiterhin keine RADIUS Pakete versendet.

Eine mögliche Lösung wäre die Deinstallation der VASCO Lösung von der Firewall und der Installation auf einem anderen Server. Da die Lösung auch als Linux-Paket verfügbar ist, wäre eine Installation auf einem der Linux Systeme des Endkunden denkbar. Allerdings hätte ich die Software neu lizenzieren (Lizenz ist abhängig von der IP) und alle Token und Benutzer neu importieren müssen. Da aber bereits alles – inklusive Datensicherung – fertig konfiguriert war, wollte ich einen relativ einfachen und kostenlosen Workaround finden.

Die Lösung ist so einfach wie clever. Sie heißt RADIUS-Proxy. Dabei werden alle ankommenden RADIUS Pakete einfach an einen anderen RADIUS Server weitergesendet – in meinem Fall also zurück an den VASCO RADIUS Server:

Auf einem zweiten System (im Test ein Debian Live System von CD) installiert man die Software FreeRADIUS. Dieser lässt sich sehr schnell zu einem sogenannten RADIUS Proxy konfigurieren. Zur Sicherheit hatte ich die RADIUS Ports des VASCO Servers auf 1814 und 1815 geändert. In der Konfiguration des TMG für die VPN Clients wurde als neuer RADIUS Server die IP-Adresse des Linux Systems eingegeben, die Ports wurden bei 1812 und 1812 belassen.

Im FreeRADIUS müssen anschließend folgende Einstellungen getroffen werden:

/etc/freeradius/client.conf

client IP-ADRESSE-DES-TMG {
secret = SHARED SECRET
shortname = TMG-NAME
}

/etc/freeradius/proxy.conf

realm DEFAULT {
authhost = IP-ADRESSE-DES-TMG:1814
accthost = IP-ADRESSE-DES-TMG:1815
secret = SHARED SECRET
}

Danach muss der FreeRADIUS neu gestartet werden. Und siehe da, bei einem erneuten Test der VPN-Einwahl durch einen Client erschienen im Audit Viewer des VASCO Servers folgende Meldungen:

Die Fehlermeldung User authentication failed ist in diesem Fall völlig korrekt, da der Tokencode für meinen Test nicht stimmen konnte, da ich diesen nicht zur Verfügung hatte. Mir ging es ja auch lediglich um die korrekte Übertragung der RADIUS Pakete, auch wenn in diesem Fall ein Access-Reject zurückgegeben wurde.

Fazit

Microsoft hat mit dem TMG 2010 in Verbindung mit dem Network Policy Server (NPS) einige Änderungen eingeführt. Wie schon erwähnt funktionierte die gleiche Konstellation der Komponenten mit dem ISA Server 2006 völlig problemlos. Der Workaround ist ganz sicher keine Lösung für größere Umgebungen – wie beschrieben, sollte hier der VASCO Server auf einem anderen System (bspw. in einer DMZ) installiert werden, als Datenspeicher empfehle ich die Verwendung des Active Directory (alle anderen Installationen habe ich so umgesetzt). Allerdings bin ich mit dieser speziellen Lösung sehr zufrieden, habe ich doch so die gesamte Konfiguration (Firewall und VASCO) auf einem System, die mit Hilfe der integrierten Sicherung einfach und schnell gesichert bzw. wiederhergestellt werden kann.

Bei Fragen zum Vorgehen oder auftauchenden Problemen nutzt bitte die Kommentar-Funktion. Wie bei allen meinen anderen Beiträgen gilt auch hier wieder: Für Tipps, Vorschläge sowie Fragen oder Kritiken bin ich stets offen.

Einen Blog am Leben zu erhalten kostet Zeit und Geld. Da ich auf meiner Seite weder Werbung einbinde, noch andersweitige Zuwendungen erhalte, freue ich mich über jede kleine Spende. Einfach und unkompliziert geht das über PayPalMe. Du unterstützt damit diesen Blog. Vielen Dank.