UAG - Forefront unified Access Gateway (UAG)

Achtung:
Important Changes to the Forefront Product Line http://blogs.technet.com/b/server-cloud/archive/2013/12/17/important-changes-to-the-forefront-product-line.aspx
Ab 1. Jul 2014 wird UAG nicht mehr verkauft. Mainstream Support gibt es bis 14. Apr 2015

Microsoft verweist als Ersatz auf den Windows 2012R2 Web Application Proxy (Siehe http://www.msxfaq.de/internet/wap.htm) und die Windows 2012 Direct Access Funktion

Wenn der Zugriff auf IPv6 Ressourcen per Direct Access nicht ausreichend ist, oder die Veröffentlichung von Outlook Webzugriff über einen einfachen ReverseProxy a la TMG nicht ausreicht, dann ist UAG eine interessante Lösung auf der Microsoft Plattform.

Installation

Wer UAG auf einer VM installiert, muss zumindest das 4GB Limit für RAM können, welches UAG beim Setup prüft.

Am besten laden Sie sich die aktuelle Version von UAG aus ihrem Microsoft Lizenzportal herunter, da dann oft das aktuellste ServicePack und sogar Rollup-Updates schon integriert oder automatisch nachinstalliert werden. Die Installation ist durch einen Assistenten geführt und fragt im wesentlichen nur den Zielpfad der Installation ab. Danach legt das Setup schon los und installiert UAG (mit darunter liegendem TMG) und mit der passenden CD auch gleich das SP1 Rollup1. Dazu sind eventuell mehrere Neustarts erforderlich.

Ich beschränke mich hier auf einen "Single Server", den man aber dank Virtualisierung sehr einfach auch "besser verfügbar" machen kann. Es sei aber nicht verschwiegen, dass Sie auch mit zu 8 UAG-Server in einem Array mit NLB installieren können.

Nach einigen Neustarts sollten Sie dann UAG auf dem Server haben und dank dem darunter liegenden TMG ist das System auch ziemlich "dich". Das geht also soweit, dass der Server weder per PING noch per RDP mehr erreichbar ist, selbst wenn er das vorher erreichbar war.

Hinweis
Ihr UAG steht mit einem Bein sehr nahe am Internet. Ratsam ist immer eine Filterung der Pakete "davor" aber selbst dann sollten Sie in eigenem Interesse regelmäßig Updates installieren. Wundern Sie sich nicht, wenn auch TMG oder SQL mal ein Update benötigt.

Erstkonfiguration

Mit dem ersten Start der UAG-Konsole aus dem Menü wird der Admin schon dazu gezwungen die ersten drei Schritte durchzuführen

Und jeder der Schritte ist in weniger als einer Minute eigentlich vollzogen.

  1. Schritt 1 ist die Konfiguration der NetzwerkUmgebung

    Hier sollten Sie auch alle internen Subnetze angeben und später müssen diese natürlich auch per Leitwege bekannt gegeben werden. Das Default Gateway des UAG-Servers ist später das Internet.
  2. Schritt 2 definiert den Server
    Die meisten Firmen werden vielleicht nicht gleich mit einem Array starten, sondern mit einem einzelnen Server arbeiten, der aber per Virtualisierung natürlich auch etwas "besser" verfügbar gemacht werden kann
  3. Im Schritt 3 wird dann nur noch Windows Update und Feedback an Microsoft konfiguriert-

Mit dem Abschluss der erstmaligen Konfiguration werden die Einstellungen angewendet. Die Konfiguration wird dabei in einer Datei zusätzlich gesichert.

Die Angabe eines Kennworts ist erforderlich-.

Bedenken Sie bitte, dass alle KonfigurationsÄnderungen in einer darunter liegenden SQL-Datenbank abgespeichert werden und die UAG-Dienste sich diese Einstellungen regelmäßig "ziehen". Änderungen werden also nicht immer sofort aktiv.

Basiseinrichtung

Ich habe ja schon geschrieben, dass TMG mit installiert wird und da TMG durchaus als Firewall bezeichnet werden kann, schützt es den Server auch gegen eingehende Verbindungen, die noch nicht freigeschaltet sind. Sehr viele Einstellungen von TMG werden direkt durch UAG kontrolliert, aber einige Einstellungen sind in UAG nicht möglich. Wenn Sie aber den IE9 installiert haben, dann können Sie TMG gar nicht erst konfigurieren, das der IE9 einen Fehler meldet.

Die Lösung besteht darin, entweder IE9 wieder zu deinstallieren oder die fragliche Zeile im Skript zurecht zu rücken.

Editieren Sie folgende Datei

C:\Program Files\Microsoft Forefront Threat Management Gateway\UI_HTMLs\TabsHandler\TabsHandler.htc

Und kommentieren Sie die Zeilen aus, die den String "paddingTop" enthalten, z.B. durch ein "//" am Anfang der Zeile. Es müssten genau drei Zeilen sein (UAG 2010 SP1 Rollup 1)

Danach können Sie dann auch die TMG-Konfiguration anpassen. Zwei weitere "Default-Einstellungen" sind zwar sicher aber lassen den ein oder anderen Admin vielleicht verzweifeln. In kleineren Umgebungen möchten Administratoren zumindest von Intern auch per RDP auf ihre Server und ein PING möge bitte zur Fehlersuche auch beantwortet werden. TMG hat dazu zwei eingebaute Regeln in den System Policies, die man aber entsprechend anpassen muss, denn die hinterlegten Gruppen sind erst einmal leer.

Wer es nicht ganz so sicher braucht, addiert hier einfach das Netzwerk "Internal", damit von intern eine Verbindung per RDP und ein test per ICMP möglich ist.

Direct Access

UAG wird natürlich gerne eingesetzt, um das in Windows 2008 R2 Direct Access um die IPv4 Erreichbarkeit der internen Systeme zu erweitern. Wer UAG auf einem bislang als DA-Server genutzten System installiert, wird darauf hingewiesen, dass die GPOs von DA und UAG in Konflikt stehen und ersetzt werden.

UAG entfernt also die DA Richtlinien, weil es selbst deutlich mehr Möglichkeiten der Konfiguration bietet.

Achtung:
Die bisherige Direct Access-Verwaltung sollten Sie nicht mehr starten, da Sie mit UAG und den erweiterten Richtlinien und Filterfunktionen von TMG nicht umgehen kann und sogar Fehlaussagen trifft:

Der Assistent erfragt dann wie bei Windows 2008R2 selbst die Server, anhand der ein Client erkennen kann, ob er intern oder extern ist.

Nutzen Sie immer HTTPS oder ein Dateizugriff. Es gibt nämlich Provider wie z.B. die Telekom mit einer "Navigationshilfe". Wenn ein Servernamen von "zuhause" nicht erreichbar ist, dann sendet der Telekom-DNS-Server dennoch eine IP-Adresse. Der Anwender wird bei einem Zugriff mit dem Browser auf die Telekom Suchseite umgelenkt. Dieses Verhalten kann der Anschlussinhaber Sie aber im Telekom Kundencenter abschalten.

Download der Visio Dateien
https://skydrive.live.com/?cid=dae8dcb8662ac00d&sc=documents&id=DAE8DCB8662AC00D!226

NAT 64 und UAG

Einer der wesentlichen Gründe für UAG ist der Einsatz von NAT64 und DNS64. Der Client fragt nach einem internen Rechner und die Anfrage landet nicht beim internen DNS-Server sondern beim UAG-DNS64-Server.

Dieser fragt dann den internen DNS-Server um die IP-Adresse zu erhalten. Liefert der interne DNS-Server nun nur eine IPv4-Adresse zurück, dann ersetzt der DNS64-Server die IPv4-Adresse durch eine IPv6-Adresse. Das kann man hier beim Zugriff auf "Intranet" von Net at Work gut sehen.

    intranet.netatwork.de
    ----------------------------------------
    Eintragsname . . . . . : intranet.netatwork.de
    Eintragstyp  . . . . . : 28
    Gltigkeitsdauer . . . : 2388
    Datenlänge . . . . . . : 16
    Abschnitt. . . . . . . : Antwort
    AAAA-Eintrag  . . . . : fd49:5251:304:5554:4:4:c0a8:6427

Dies ist eine "besondere IP-Adresse". Das Subnetz wird in der UAG-Konfiguration hinterlegt:

Und wenn Sie etwas Hexadezimal und Dezimalzahlen umrechnen, dann schauen Sie sich mal die letzten beiden Words "c0a8:6427" an. Daraus kann man problemlos 192.168.100.39 herleiten. Mein Client spricht dann also gefühlt diese IPv6-Adresse an, welche aber direkt beim UAG wieder landet, welcher dann per NAT dieses Paket nach intern umsetzt.

So kann dann auch ein IPv4-System allein über IPv6 erreicht werden. Allerdings erscheint bei dem angesprochenen Server natürlich als anfragende IP-Adresse die IPv4-Adresse des UAG-Gateways. Eine unterscheidung nach IP-Adressen von Clients kann der angesprochene Service daher nicht vornehmen.

UAG und Authentifizierung

Ein einfacher "Reverse Proxy" ist auch mit UAG möglich. Interessant wird aber die Funktion erst, wenn der UAG die Zugriffe von außen selbst authentifiziert, d.h. dem externen Client eine Anmeldung abverlangt. Das ist relativ einfach möglich. Wenn UAG die Identität des Benutzer kennt, kann er abhängig von der Mitgliedschaft in Windows Gruppen verschiedene Anwendungen auf dem Portal zulassen.

Aber auch ohne das Portal können Anwendungen mit einer vorherigen Authentifizierung geschützt werden. Der Zugriff auf den eigentlichen Server erfolgt nur, wenn der Anwender dem UAG bekannt ist. Das funktioniert sogar für Clients, die gar keine "Portalanmeldung" per se unterstützen wie z.B. Outlook Anywhere (RPC over HTTP) oder ActiveSync (Exchange ActiveSync Server). Der UAG "erkennt" anhand des UserAgent im HTTP-Request, ob es sich um einen Browser handelt, über den ein Anwender auch ein Formular ausfüllen kann, oder ein "Rich-Client", welcher dann per NTLM oder Basic-Auth sich anmelden muss. Auf die anonyme Anfrage liefert der Webservice die beiden Verfahren "Negotiate" und "NTLM". Kerberos kann aus dem Internet natürlich nicht gehen. Auch andere Firewalls bieten sowas an. Beim UAG kann man das auf dem Trunk unter "URL Inspection" abschalten

Man kann natürlich auch immer im lokalen Credential Manager (Tresor) einfach die Anmeldedaten hinterlegen, dann versucht Windows gar kein Negotiate mehr. Das würde ich aber nicht anraten, da nach einem geänderten Kennwort dann wieder der Dialog kommt oder schlimmstenfalls das AD-Konto gesperrt werden kann.

Damit UAG aber dann im Auftrag des Benutzers wieder die nachfolgenden Server erreichen kann, sollte UAG zum einen Mitglied der Domäne sein und Sie natürlich Kereros Constraint Delegation einsetzen.

UAG als Web Publishing und Web Portal

UAG kann natürlich nicht nur Direct Access anbieten, sondern auch Webseiten veröffentlichen und optional sogar "Portalzugänge" erlauben. Das ist aber ein komplett eigenes Kapitel und hier verweise ich auf viele andere schöne Webseiten und Whitepapers.

UAG und Exchange

UAG kann genau wie TMG natürlich auch Exchange OWA, aber auch ActiveSync, EWS, OAB etc. veröffentlichen. Seit UAG 2010 SP1 ist ein Weg, der vorher möglich war aber nicht supportet wurde, nun auch offiziell nicht mehr nutzbar. Wer eine Anmeldung des Benutzers an UAG abverlangt und intern auf Exchange auch noch "Formbased" arbeitet, muss innen auf HTTP umstellen oder zusätzliche virtuelle Webseiten unterstützen.

  • UAG einmal mit Portal (Client erforderlich)
  • UAG einmal preAuth (Client möglich)
  • UAG transparent (nur URL-Screening)
    Dies ist die sicher schwächste Absicherung aber mit TMG vergleichbar, wenn keine Preauthentication stattfindet. Sowohl auf dem UAG Trunk als auch auf der Application wird eine Anmeldung abgestellt so dass UAG quasi nur noch ReverseProxy und URL-Filter und Inspection macht. Wer mit UAG wirklich "nur" Exchange publizieren will, kann dies dennoch tun und die Anmeldemaske von Exchange nutzen

Hier noch ein paar weiterführende Links

SSL Bindungen

Ein "Problemfeld" hat mich immer wieder mit UAG eingeholt. Der Server hat ja per Default erst mal 2 IP-Adressen und auf dem Server wird für die Portallösung auch ein IIS installiert. Auch wenn die zweite IP-Adresse eigentlich für IPHTTP vorgesehen ist, so scheint UAG das mit den Bindungen nicht immer hin zu bekommen. "Normalerweise" binden sich die Protokolle explizit an die einzelnen IP-Adressen und Ports und eine "Default Bindung" ist auf 0.0.0.0:443 gebunden. Diese ist dann allerdings IPHTTP. Ich habe bislang keinen Weg gefunden, um IPHTTP explizit ein Zertifikat zu binden.

netsh http show sslcert

Leider installiert UAG auch ein "Default Webserver Zertifikat" mit einer sehr langen Gültigkeit mit und bindet diese auf alle Ports, wenn nicht abweichend etwas konfiguriert ist

Prüfen Sie daher einfach mit einem HTTPS oder ein anderes Tool (z.B. http://www.digicert.com/help/) von extern das angebotene Zertifikat. Wenn das Zertifikat nicht passt, dann sollten Sie es per NETSH löschen und per GUI wieder neu zuweisen. Leider scheint auch hier die GUI von UAG sich anders zu verhalten als von DA. Daher hier die kompletten Kommandozeilen. Der Hashwert können Sie aus dem Zertifikat (Fingerprint) ablesen.

REM Zuerst delete der default bindung
netsh http delete sslcert 0.0.0.0:443 

REM Addieren einer Bindung (Zeilenumbruch entferen
REM Per PowerShell koennen sie mit "([guid]).guid" schnell eine GUID erzeugen.
REM Zur Lesbarkeit wurden Zeilenumbrueche addiert
netsh http add sslcert 
    ipport=0.0.0.0:443 
    certhash=‎5d52fe388590d25fbd4f7d902f298e97a4404440 
    appid={9c5923e9-de52-33ea-88de-7ebc8633b9cc} 
    clientcertnegotiation=enable 
    ds=en

‎C:\>netsh http show sslcert

SSL Certificate bindings:
-------------------------

    IP:port                 : 0.0.0.0:443
    Certificate Hash        : 5d52fe388590d25fbd4f7d902f298e97a4404440
    Application ID          : {9c5923e9-de52-33ea-88de-7ebc8633b9cc}
    Certificate Store Name  : (null)
    Verify Client Certificate Revocation    : Enabled
    Verify Revocation using Cached Client Certificate Only    : Disabled usage Check    : Enabled
    Revocation Freshness Time : 0 URL Retrieval Timeout   : 0
    Ctl Identifier          : (null)
    Ctl Store Name          : (null)
    DS Mapper usage    : Enabled
    Negotiate Client Certificate    : Enabled

Wenn Sie UAG mit DA automatisch installieren, dann wird auch der Parameter "Negotiate Client Certificate" auf "Enabled" gesetzt. Haben Sie aber DA vorab eingerichtet und installieren dann UAG hinterher, dann ist diese Option nicht eingeschaltet.

Status und Überwachung

Auch die Überwachung von Direct Access und den anderen neuen Funktionen von UAG wurde nun auf eine Webseite ausgelagert. So können Sie, entsprechende Berechtigungen und Firewall-Regeln vorausgesetzt, von überall den Status des UAG-Servers einsehen.

http://uagservername:50002/

Hier exemplarisch die beiden Ansichten bezüglich Direct Access. Zuerst der Statusübersicht der verschiedenen Dienste und Rollen

Und hier sieht man meinen PC, der über IPHTTPS gerade eine aktive Verbindung hat

Natürlich kann UAG auch SNMP-traps und SYSLOG-Meldungen senden und sich damit auch in andere Umgebungen einbinden.

Weitere Links