TMG 2010 und Exchange

TMG wird nicht mehr weiter entwickelt. TMG2010 ist die letzte Version.
01. Dez 2012 letzter Verkaufstag
14. Apr 2015 Ende MainstreamSupport
14. Apr 2020 Ende Extended Support
Siehe auch: http://blogs.technet.com/b/server-cloud/archive/2012/09/12/important-changes-to-forefront-product-roadmaps.aspx

Die Firma SecureGuard liefert und unterstützt als Microsoft OEM Partner noch TMG in Form einer Appliance
http://www.secureguard.de/Company/Contact

TMG 2010 SP2 verfügbar (Build 9193)
Download: http://www.microsoft.com/download/en/details.aspx?id=27603
2555840 Microsoft Forefront Threat Management Gateway 2010 Service Pack 2
Kerberos kann nun mit NLB genutzt werden.

und das aktuelle Rollup wäre noch anzuraten
2870877 Rollup 4 für Forefront Threat Management Gateway 2010 Service Pack 2

Forefront Threat Management Gateway (TMG) Client
http://www.microsoft.com/download/en/details.aspx?id=10504

Publishing Exchange Server 2013 using TMG
http://blogs.technet.com/b/exchange/archive/2012/11/21/publishing-exchange-server-2013-using-tmg.aspx

Celestix announces continued availability of their MSA appliance range running TMG 2010 until 2023
http://www.celestix.com/celestix_announces_tmg_availability.html

TMG Nachfolger

Nach ca. vier Jahren wurde aus dem ISA 2006 nun der TMG 2010-Server. oder besser das Gespann auf TMG und uAG, bzw. mittlerweile gibt es die nicht mehr. Microsoft hat beide Produkte ohne klare Nachfolger eingestellt. Die ein oder andere Funktion des TMG kann durch die Windows Funktionen WAP - Web Application Proxy oder IIS ARR Application Request Routung bedient werden, aber dieser Markt wird den Drittherstellern überlassen. Es gibt sogar die Firma SecureGuard, die den TMG-Code weiter pflegt und noch einige Jahre TMG-Appliances verkauft.

Auch wenn TMG also von Microsoft nicht mehr selbst vertrieben wird, muss man nun nicht panisch nach Alternativen suchen.

TMG vs. UAG

Neben dem TMG gab es auch noch den uAG. Hier die wesentlichen uterschiede: 

  • TMG = Thread Management Gateway
    primäre als Proxy Server angedacht, welcher Zugriff von innen nach außen erlaubt und dabei mittlerweile sogar SSL-Verbindungen aufmachen und reinschauen kann. Trotzdem kann er auch wie der ISA-Server als einfaches Gateway zu Veröffentlichung von Exchange OWA, ActiveSync und Outlook Anywhere dienen
  • UAG = unified Access Gateway
    Das ist eigentlich das Produkt zur Veröffentlichung von internen Seiten mit umfangreichen Zusatzfunktionen, z.B. Prüfung des Clients auf Konformität und Direct Access Zugriff.

Beide Produkte können Exchange veröffentlichen, aber haben für sich individuelle Zusatzfunktionen oder Einschränkungen. Die folgende Tabelle kann ihnen einen ersten Überblick geben:

Für Exchange relevante Funktionen

Forefront TMG

Forefront uAG

Outlook Web App (OWA) und Exchange Control Panel (ECP) mit formularbasierter Anmeldung veröffentlichen

Ja Ja

Outlook Anywhere über BasicAuth oder NTLM bereitstellen

Ja Ja

Microsoft Exchange ActiveSync mit BasicAuth bereitstellen

Ja Ja

Unterstützung einer Zwei-Faktor-Anmeldung (z.B. Tokens) für OWA und ActiveSync

Ja Ja

Lastverteilung für HTTP-Protokolle auf mehrere interne CAS-Server

Ja Ja

Unterstützung der zertifikatsbasierten Anmeldung für OWA, ECP und ActiveSync

Ja Nein

Support für die Installation der Exchange Edge-Rolle mit Microsoft Forefront Protection 2010 als Virenschutz und Spamschutz

Ja Nein

Schutz von internen Benutzern beim Zugriff auf das Internet (Proxy-Funktion) gegen Schadcode und andere Angriffe

Ja Nein

Besser Skalierung von großen Outlook Anywhere Umgebungen durch Nutzung mehrere Quell-IP-Adressen

Nein Ja

Funktion zur Überprüfung des Clients auf aktuelle update, aktuellen Virenscanner etc., ehe der Zugriff auf OWA zugelassen wird (Network Access Protection).

Nein Ja

Zentral steuerbares Löschen lokaler Daten am Ende einer Outlook Web App Verbindung auf dem Client.

Nein Ja

Sie sehen also, dass beide Produkte eine stabile und sichere Veröffentlichung von Outlook Web App erlauben aber es auch unterschiede gibt. UAG kann zusätzlich auch den Client besser kontrollieren und unterstützt die hier nicht aufgeführten Zugriffe per Direct Access etc. während TMG auch als ausgehender Proxy agieren kann. Eine schnelle Antwort zum richtigen Produkt kann ich ihnen nicht geben.

TMG und Exchange

Natürlich ist auch TMG weiter eine sehr gute Wahl für den Einsatz vor einem Exchange CAS-Server oder CAS-Array. Wie sie aber auf der Seite  NLB gelesen haben sollten, sollte ein CAS-Array nicht über eine NLB-Adresse veröffentlicht werden, zumindest nicht wenn die Anfrage beim CASArray mit der IP-Adresse des TMG-Servers gestellt wird.

Achtung TMG SP1 + SU1 für Exchange und Forefront erforderlich
http://blogs.technet.com/b/isablog/archive/2010/09/01/problems-when-installing-exchange-2010-service-pack-1-on-a-tmg-configured-for-mail-protection.aspx
http://technet.microsoft.com/de-de/library/ff966399%28en-us%29.aspx

Whitepaper: Publishing Outlook Anywhere using NTLM Authentication With Forefront TMG or Forefront uAG
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=040b31a0-9a69-4278-9808-e52f08ffaee3

Publishing Exchange Server 2010 with Forefront unified Access Gateway 2010 and Forefront Threat Management Gateway 2010
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=894bab3e-c910-4c97-ab22-59e91421e022&displaylang=en

TMG2010 SP1 Installation ist auch per RDP möglich, zumindest vom internen LAN aus konnte ich dies nutzen.

Listener und Authentifizierung

In Firmennetzwerken wird gerne die "integrierte Anmeldung" genutzt, da damit die Anwender nicht erneut zur Eingabe von Anmeldedaten aufgefordert werden und die Kennworte bei NTLM und Kerberos auch ohne SSL recht gut gesichert sind. Bei der Anwendung von "Basic" sollten Sie die Transportwege per SSL verschlüsseln, da die Daten nur BASE64 codiert aber nicht verschlüsselt sind. Leider muss man bei "Basic" die Anmeldedaten immer wieder eingeben, da kein Browser den Benutzernamen und das Kennwort erhalten; mal abgesehen von irgendwelchen Password-Helfern, die Formulare auf Webseiten oder Anmeldedialoge automatisch ausfüllen. Wenn sie nun aber nur genau einen Listener bereit stellen und die "Vorauthentifizierung per Formular" des ISA/TMG-Servers einsetzen möchten, dann müssen Sie folgendes wissen:

  • TMG/ISA Fallback ist "Basic"
    Per Default wird auf dem Listener die Authentifizierung eingestellt. Das bedeutet, dass alle Regeln, die auf diesem Listener aufsetzen dieser Einstellung unterworfen werden.
  • Outlook Anywhere RPCProxy kann nur Basic oder NTLM
    Während andere virtuelle Verzeichnisse von Exchange (EWS, OAB etc.) durchaus verschiedene Authentifizierungsverfahren parallel unterstützen, kann der Outlook Anywhere nur entweder oder eingestellt werden. Da ISA/TMG beim Fallback nur Basic kann, müssen Sie also diesen Zugang auf Basic stehen lassen (Basic ist Default)
  • Basic = unverschlüsselt = SSL
    Sie sollten alle Verbindungen per SSL absichern, damit die Zugangsdaten (Benutzer und Kennwort) auf der Leitung nie unverschlüsselt übertragen werden.
  • Outlook 2010 Kennwort Speicher
    In Outlook 2010 ist es erstmals möglich, auch bei der Nutzung von RPC/HTTP die Zugangsdaten permanent zu speichern

All diese Einschränkungen können Sie nur dann umgehen, wenn Sie für den Zugang für RPC/HTTP etc. Und OWA zwei unterschiedliche Listener verwenden. 

Die TMG nutzt wie auch der vorherige ISA so genannte "Listener" um zu steuern, welche externen Port das System "abhört" um Verbindungen anzunehmen und gegebenenfalls nach intern weiter zu geben. Dies ist aber nur für "Webseiten" (also HTTP/HTTP) relevant.. Ein Listener kann zwar mehrere IP-Adressen mit mehreren Namen bedienen, aber es kann nur ein Zertifikat pro Listener gebunden werden. Dies ist also die Domäne von SAN-Zertifikaten, d.h. ein Zertifikat mit mehreren Namen kann auf einen Listener gebunden werden und in den Regeln kann dann über den "Public Name" gesteuert werden, welche Regel zutreffend ist.

Der Listener steuert aber auch die Anmeldung und die ist dann für alle Regeln, die diesen Listener benutzen, auch gleich. Ich kann also nicht über einen Listener ein virtuelles Verzeichnis mit "Form based" freigeben und ein anderes Verzeichnis z.B. Anonym oder mit HTTP-Authentifizierung. Und ich kann auch keine zwei Listener auf die gleiche IP-Adresse:Port-Kombination binden.

So eine Konfiguration ist natürlich sehr ungeschickt, wenn man z.B. Outlook WebApp per ""Formular-Anmeldung" im TMG/ISA schützen möchte, aber die URL für Pushmail (/Microsoft-Server-ActiveSync) auf dem gleichen Webserver betrieben werden soll. Aber auch hier hat TMG und ISA eine Lösung. Die Einstellung "Formularbasierte Anmeldung" greift nämlich nur, wenn der TMG auch einen "Browser" als Client erkennt. Denn nur dann geht er davon aus, dass der Client das Formular auch wirklich "ausfüllen" kann. Das gleiche Problem gäbe es auch mit RPC over HTTP (URL /RPC), EWS und Autodiscover da hier der Client kein Browser ist. TMG erkennt solche Clients aber, weil er eine Liste der "Browser" mit dem useragent überprüft den nicht erkannten Systemen eine "Standard-Anmeldung" angeboten wird. Sie sehen das immer dann, wenn Sie auf dem Client z.B. den useragent anpassen (z.B.: mit Fiddler oder Proxomitron)

Wer also auf dieser Basis dann weitere Regeln anlegt um eben ActiveSync, EWS etc. durchzulassen muss dort dann einstellen, dass die Berechtigung weiter durchgereicht werden kann und eine Anmeldung auch erforderlich ist.

Allerdings ist es nicht möglich, z.B. OWA auf dem TMG per Formular zu veröffentlichen und RPC over HTTP dann mit NTLM. Die Authentifizierung von "nicht Browsern" fällt auf "Basic" zurück, d.h. Übermittlung von Benutzername und Kennwort als BASE64-codierte Strings, die natürlich per SSL verschlüsselt sein sollten. Wenn Sie NTLM/Integriert für RPC/HTTP nutzen wollen und OWA per Formular auf dem TMG sichern, dann benötigen Sie getrennte Listener, also auch getrennte IP-Adressen, wenn beide auf Port 443 lauschen sollen.

Best Practices für Veröffentlichung mit einer IP-Adresse

Die Konfiguration einer Firewall ist eine gewissenhafte Aufgabe, denn Fehler öffnen sonst sehr einfach Türen für unerwünschte Pakete oder Zugänge. Daher kann ich hier nur eine einfache Empfehlung geben, die meine Überlegungen für die Veröffentlichung von OWA und anderen Exchange Diensten verdeutlicht. Interessant sind hier erst mal nur die CAS-Server, die auch aus dem Internet erreichbar sind und daher einen "ExternalURL"-Eintrag erhalten sollen  (Siehe auch CASURLs und CAS Intern/Extern. Nun handelt es sich bei einem CAS-Server, wenn man von POIP3/IMAP4/SMTP mal absieht, um einen Webserver mit verschiedenen virtuellen Verzeichnissen. Technisch könnten Sie nun einfach mit einem Listener einfach alle Dienste auf einen Schlag veröffentlichen. Es gibt aber mehrere Gründe dies in unterschiedliche Regeln aufzuteilen.

  • Benutzersteuerung und Zeitsteuerung
    Wenn der TMG die Anmeldung der Benutzer annimmt, dann können Sie natürlich über den TMG auch steuern, welche Anwender diesen Weg verwenden dürfen.

    Sie könnten über eine Sicherheitsgruppe z.B. bestimmen, dass ein Anwender über den TMG von extern kein OWA oder Pushmail machen darf, aber intern im LAN per Browser sehr wohl auf OWA zugreifen kann. Sie könnten den Zugriff auch nach der Tageszeit steuern.
  • Protokollierung und Diagnose
    Sehr hilfreich sind unterschiedliche Regeln, wenn Sie einem Problem nachspüren wollen. TMG kann bei der Protokollierung auf Regeln filtern.

    So lässt sich schon eine Vorauswahl treffen, wenn Sie z.B. Problemen mit ActiveSync nachspüren wollen
  • Authentifizierung
    Zuletzt ist es natürlich innerhalb der Regel auch möglich, die Authentifizierung und die Weitergabe der Anmeldedaten an nachgeordnete Webserver zu konfigurieren. Wer in einer Regel z.B. "All users" zulässt, kann noch so viel in den Authentifizierungsstellungen fordern aber TMG wird gar nicht erst Nachfragen.

Entsprechend sehen die meisten Publizierungsregeln etwas wie folgt aus:

Regel Name Aktion Public Name Pfade Linktranslation Authentifizierung Benutzer
1 HTTP Redirect Deny owa.firma.tld / Aus keine All users
2 Autodiscover Allow autodiscover.firma.tld /AutoDiscover/* Aktiv Basic All Auth users
3 ActiveSync Allow owa.firma.tld /Microsoft-Server-ActiveSync/* Aktiv Basic All Auth users
4 RPCHTTP Allow owa.firma.tld /rpc/*
/UnifiedMessaging/*
/ews/*
/oab/*
Aktiv Basic All Auth users
5 OWA Allow owa.firma.tld /owa/*
/exchange/*
/ExchWeb/*
/Public/*
Aktiv TMG Formular gegen Windows
NTLM
All Auth users
6 Default Deny          

Allen Regeln ist gemeinsam, dass sie den gleiche Listener verwenden, auf dem natürlich das Zertifikat für "owa.firma.de" und "autodiscover.maildomain.de" gebunden ist und die Anmeldung per Formular aktiviert ist. Besonderheiten zu den Regeln

  1. HTTP Redirect
    Diese Regel verbietet den Zugriff per HTTP und lenkt die Zugriffe auf https um. Man kann geteilter Meinung sein, ob dies der Sicherheit zuträglich oder sogar abträglich ist. Einige Administratoren vertreten den Standpunkt, dass Benutzer schon selbst gefälligst "https" eingeben sollten.
  2. Fallback to Basic
    Greift, da die Regel 5 per Formbased aufgrund des user-Agent nicht angewendet wird.
  3. Fallback to Basic
    Greift, da die Regel 5 per Formbased aufgrund des user-Agent nicht angewendet wird.
  4. Fallback to Basic
    Greift, da die Regel 5 per Formbased aufgrund des user-Agent nicht angewendet wird.
  5. Nur /OWA
    Exchange 2010 benötigt keinen Zugriff mehr auf /ExchWeb, /Public/ oder /Exchange/
  6. Default
    In allen anderen Fällen werden die Pakete verworfen.

Sonderfall RPC mit Outlook 2003 auf XP und "FW_Connection_killed"

Wenn Outlook mit dem Exchange Server per RPC/HTTP spricht und der TMG in diese Pakete dank SSL-Offloading reinschauen kann, dann kann es passieren, dass TMG einige Pakete verwirft. Das scheint insbesondere in Verbindung mit Loadbalancern zu passieren, die die Rückpakete eventuell umbauen.

Auch wenn beide KB-Artikel nicht direkt einen Zusammenhang mit Outlook aufführen, so ist MAPI/HTTP auch mit Outlook betroffen. Anscheinend aber nur Outlook 2003 auf XP-Clients, bei denen der TMG nach ein paar Paketen dann einen "FW_Connection_killed" liefert.

Bedeutung des UPN

Ein Anwender kann im Outlook Assistenten eigentlich nur seinen Namen, die Mailadresse und das Kennwort eingeben. Per Default versucht nun Outlook mit dieser Mailadresse sich anzumelden. Das geht aber so einfach erst mal nicht, da ISA/TMG nur drei Anmeldeformen akzeptiert

  • NT4Stype Domain\Username
  • UPN
  • DistinguishedName

Wer also der UPN mit der Mail-Adresse übereinstimmt, dann haben die Anwender und Sie als Betreiber die besten Ergebnisse.

Constraint Delegation mit Web Farm

Ein besonderer Fall ist die Funktion, die CAS Server per "Contraint Delegation" erreichbar zu machen. Dies ist weder mit Exchange 2007 noch Exchange 2010 RTM möglich, sondern wurde erst mit einem update bereit gestellt, so dass die Beschreibung dort maßgeblich ist.

TMG und Kennwort

Mit TMG ist es möglich, auf der Formularseite einen Hinweise zu platzieren, wenn das Kennwort des Anwenders demnächst abläuft. Es ist sogar möglich das Kennwort direkt über TMG zu ändern.

Allerdings nutzt TMG dazu "LDAPS", d.h. auf dem Domain Controller muss dann ein Zertifikat installiert sein, damit eine SSL-Verbindung aufgebaut werden kann.

  • 321051 How to enable LDAP over SSL with a third-party certification authority
  • IISADMPWD

TMG Fehler und IE9 = “member not found”, “refresh failed”

Wenn Sie auf dem TMG-Server den IE9 installieren, dann können Sie den TMG nicht mehr verwalten.

Es betrifft nicht alle IE9 Sprachversionen aber mit dem IE8 passiert es nicht. Die Lösung für einen IE9 besteht darin, eine Datei des TMG zu ändern.

  • öffnen der Datei "TabsHandler.htc"
    Diese liegt normal hier:
"C:\Program Files\Microsoft Forefront Threat Management Gateway\UI_HTMLs\TabsHandler\TabsHandler.htc"
  • Editieren
    Es gibt drei Zeilen mit dem Text "paddingTop". Diese sind mit einem führenden "//" auszukommentieren.

Dann reicht ein "Reload" der MMC und Sie können wie gewohnt arbeiten.

TMG Konfiguration

Einen Fehler, den Administratoren sehr gerne machen, ist keine Geduld zu haben. TMG kann sowohl als einzelne Instanz als "StandardServer" installiert werden als auch als Gruppe in einer Enterprise Farm. In beiden Fällen wird die Konfiguration aber nicht "sofort" angewendet, sondern erst nach einigen Sekunden aktiv, denn die MMC schreibt die Konfiguration in die SQL-Datenbank, aber die TMG-Engine bezieht ihre Informationen nicht direkt aus dieser SQL-Datenbank.

Ein Replikationsprozess sorgt daher dafür, dass die Konfiguration aus der Datenbank in den lokalen Store übertragen wird. Diese Replikation kann aber einige Minuten dauern.

Daher sollten Sie nach KonfigurationsÄnderungen immer zusätzlich auch den Status der Konfiguration betrachten, ehe Sie Funktionstests durchführen.

UAG

Microsoft hat mit dem "Unified Access Gateway (UAG)" ein zweites Produkt im Rennen, um interne Dienste zu veröffentlichen. Wer uAG schon mal installiert hat, wird sogar TMG "darunter" erkennen. UAG erweitert also die Funktion von TMG um eine Portalseite, Clientüberprüfungen und auch beim Thema Direct Access sattelt uAG die Funktionen DNS64 und NAT64 drauf, die für den Zugriff auf IPv4-Ressourcen erforderlich ist.

Die neuen Möglichkeiten von uAG finden Sie mitterlweile umfangreich beschrieben.

White Paper – Publishing Exchange Server 2010 with Forefront”
http://go.microsoft.com/fwlink/?LinkId=197136

Weitere Links