TMG/UAG 2010 und Exchange

Zukunft von TMG ?
Bei einem Vergleich "Maqic Quadrant for Secure Web Gateways" von Gartner fehlt TMG, weil Microsoft ein Ende angekündigt hat ?
http://blog.konab.com/2011/05/what-will-happen-with-tmg/

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.

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

Nach ca. vier Jahren wurde aus dem ISA 2006 nun der TMG 2010-Server. oder besser das Gespann auf TMG und UAG.

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 DirectAccess 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:

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.

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.

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

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.

UAG

Microsoft hat mit dem "Unified Access Gateway" 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 DirectAccess 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

Keywords:TMG UAG