Direct Access - Sonderfälle

Neben der Direct Access Standard Installation gibt es ein paar Sonderfälle, auf die ich auch gesondert eingehen will:

Direct Access und Internetzugriff

Passend zum Routing ergibt sich auch die Frage, wie denn Clients über Direct Access ins Internet kommen. Bei der Konfiguration können Sie einen "Force Tunnel"-Mode aktivieren.

Der ist aber Default nicht aktiv. Normalerweise greifen Anwender nicht durch den Tunnel auf das Internet zu, sondern über ihren lokalen Zugang. Hier im Bild als Verbindung 1 dargestellt:

Wenn Sie aber den "Force Tunnel"-Mode aktiv machen, dann werden alle Pakete des Clients zum Direct Access-Server gesendet. Der hat aber als "Default Gateway" natürlich seine externe Netzwerkkarte zum Internet und wird dann versuchen, das Paket des Clients über diesen Weg loszuwerden. Die meisten größeren Umgebungen werden aber genau dies nicht zulassen, dass Clients mit der IP-Adresse eines VPN-Servers "Surfen". In der Hinsicht unterscheidet Direct Access von einem klassischen Tunnel-VPN. Entsprechend gibt es nur zwei real nutzbare Szenarien:

  1. Kein Tunnel Mode mit lokalem Zugriff
    Dies ist für kleine Firmen vermutlich die einfachste Lösung und entlastet zudem die Leitung der Firma von "Surf-Traffic". Der wird ja dank YouTube, Webcasts und auch bei der Nutzung von Office 365 eher mehr und muss daher nicht über das Firmen-Jan gehen
  2. Tunnelmode mit HTTP-Proxy
    Wenn Sie aber aus Sicherheitsgründen den Tunnelmode vorschreiben, dann ist auch ein HTTP-Proxy mit erweiterten Schutzfunktionen ratsam, damit die Sicherheit wirklich auch höher ist. Wenn ein Client nur über den DirectAcces-Server surfen darf, haben sie nicht viel gewonnen.

Die Sicherheitsbetrachtung muss natürlich jeder für sich selbst ausmachen. Ein paar Links gibt es aber schon dazu:

Direct Access und Proxy

Auch für die Konfiguration des Proxy-Servers hat Direct Access bzw. NRPT eine Lösung. Allerdings sind diese Einstellungen nicht in der Direct Access Verwaltungskonsole vorhanden sondern können nur per Powershell oder Gruppenrichtlinien Editor gesetzt werden.

Von der direkten Veränderung der Direct Access und NRPT-Einträge über die MMC für Gruppenrichtlinien kann ich nur dringend abraten. Der Direct Access Assistent ist sehr empfindlich, wenn er in den Richtlinien etwas findet, was er nicht interpretieren kann und verweigert einfach die Arbeit. Wohl dem, der dann einfach ein Backup der Gruppenrichtlinie restaurieren kann.

Daher zeige ich hier nur die Stelle, an der ein Proxy in der Gruppenrichtlinie bei NRPT definiert werden kann:

Mit mehreren Einträgen können Sie je nach Domäne oder sogar pro Host andere Proxy-Server hinterlegen.

Achtung:
Diese Eintragung helfen nur für Client, die die Microsoft WinHTTP-API nutzen. Das ist natürlich der Internet Explorer und Chrome. Meines Wissens nutzt Firefox z.B. eine eigene Logik und wird dies nicht erkennen.
Bug 1083569 - Firefix doesn't handle NRPT entries with proxy servers set
https://bugzilla.mozilla.org/show_bug.cgi?id=1083569 

Fernwartung - von innen nach remote

Einer der großen Vorteile von Direct Access ist die automatische und sofortige Verbindung durch den PC selbst, wenn eine Internetverbindung besteht. Zwar muss in Hotels und anderen öffentlichen Orte durch den Anwender oft erst eine Freischaltung erfolgen aber die Anwender, die mit dem Firmennotebook zuhause am DSL-Anschluss verbunden sind, sind auch "online" mit der Firma verbunden, wenn gar kein Anwender angemeldet ist.

Dennoch kann nach entsprechender Konfiguration ein Zugriff von der Firma auf das entfernte Gerät erfolgen, z.B. Um Software zu verteilen, Fehler einzusammeln, Daten zu übertragen, Fernwartung/Unterstützung ausführen etc.) Der Remote Client hat nämlich eine IPv6 Adresse aus dem eigenen Firmennetzwerk und registriert sich im Firmen-DNS. Aber er hat keine IPv4-Adresse, d.h. die Systeme. die sich mit den entfernten Clients verbinden wollen müssen selbst mit IPv6-Adressen versehen sein, um die Clients zu erreichen.

Installation und How-To

Es gibt eine ganze Menge von Anleitungen und Beschreibungen von Microsoft und im Internet, so dass ich hier keine "Schritt für Schritt"-Anleitung mehr publizieren möchte. Hierzu verweise ich auf ein Microsoft Dokument, mit dem es jedem interessierten Admin möglich sein sollte, Direct Access in einem Labor einzurichten.

Test Lab Guide: Demonstrate Direct Access
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=24144

Wer aber einfach nur Direct Access von Windows 2008 R2 installiert und über den Assistent die passenden Gruppenrichtlinien einrichtet, wird vielleicht übersehen, dass er für die Clients noch zusätzliche Firewall-Freischaltungen konfigurieren muss. für die Windows Firewall geht das natürlich über Gruppenrichtlinien.

Hinweis
Viele Firmen werden vielleicht dem Direct Access-Server einfach zwei offizielle IP-Adressen vergeben und ein Bein in das Internet stellen. Auch wenn Windows 2008R2 eine recht "sichere" Firewall an Bord hat, so sind dennoch auch im "Public-Profil" sehr viele Dienste von extern erreichbar, z.B. auch RDP, DFS, RPC für Remote Management. Hier sollten Sie unbedingt Hand anlegen, wenn Sie keine vorgeschaltete Firewall haben und diese Regel auf "Domain" setzen

Microsoft Direct Access Connectivity Assistant

Lange Zeit war es schwer bis unmöglich für einen Anwender zu erkennen, ob Direct Access funktioniert oder nicht. Er merkte es eigentlich immer nur, wenn etwas nicht funktioniert hat und dann war es für den Helpdesk der Firma auch nicht gerade einfach, die Ursache zu finden. Wenn alle das Problem hatten, dann war es wohl am Server zu suchen aber ansonsten war guter Rat teuer. Dem hat Microsoft mit dem "Microsoft Direct Access Connectivity Assistant" abgeholfen.

Microsoft Direct Access Connectivity Assistant
http://technet.microsoft.com/en-us/library/ff384241.aspx

Diese Programm kann auf dem Client gestartet werden und in der Taskleiste einen Status anzeigen.

Achtung:
Das Programm benötigt zusätzliche Angaben, um, die Funktion von Direct Access auch zu prüfen. Ansonsten sehen Sie die folgende Meldung

Bitte lesen Sie das Deployment Guide und konfigurieren Sie per Gruppenrichtlinien die IP-Adressen und Systeme, die das Tool auch "testen" kann.

Durch die Installation in das Standardverzeichnis "C:\Program Files\Direct Access Connectivity Assistant" wird nicht nur ein Task-Icon installiert, sondern auch der Dienst "DCASVC", der dann automatisch gestartet ist:

Die Einstellungen zur Überwachung landen als Gruppenrichtlinie wieder im gewohnten Zweig der Registrierung

Im Unterschlüssel "Probes" sind dann die verschiedenen konfigurierten Prüfungen zu sehen.

Hinweis:
Durch den Einsatz von UAG wird auch diese Konfiguration in der UAG-Direct Access Configuration vorgenommen.

So richtig zufrieden bin ich mit dem Werkzeug nicht, da es zu viele Details nicht anzeigt, z.B. fehlt mir der aktuelle Verbindungstyp, der per NETSH recht einfach ermittelt werden kann. Ich kann einem Benutzer eigentlich nicht zumuten IPCONFIG und NETSH auszuführen und die Ergebnisse einzusammeln.
Zudem würde ich die Tests gerne auch mit externen Patterns erweitern (z.B.: PING auf Default Gateway, NSLOOKUP auf Provider DNS) und die einzelnen Ergebnisse auch anzeigen.

DA und Anmeldeskripte

Erinnern sich sie bitte daran, das die "Verbindung zur Firma" bereits mit dem Hochfahren des Computers besteht. Das ist ja grade der immense Vorteil von Direct Access weil z.B. Gruppenrichtlinien und Anmeldeskripte ebenfalls funktionieren. Bei klassischen VPN-Lösungen meldet sich der Anwender ja in der Regel erst am Windows Client (ohne Anbindung an das Firmennetzwerk) an und baut dann erst die VPN-Verbindung auf.

Mit Direct Access kann ich mich auch an einem PC anmelden, an dem ich vorher noch nie angemeldet war und somit noch keine gecachten Credentials habe. Genau das ist aber auch das Problem, wenn Firmen in Anmeldeskripten umfangreiche Aktionen (z.B.: Kopieren von Vorlagen etc.) machen. Die werden nun nämlich auch ausgeführt, selbst wenn der Client zuhause oder unterwegs ist und die Bandbreite wirklich nicht grenzenlos ist. Aber auch die "Internetleitung" des der Firma muss mit diesem Verkehr umgehen.

Tipp: Optimieren Sie ihre Anmeldeskripte derart, das Sie auf langsame Verbindungen Rücksicht nehmen. für DirektAccess können Sie die Funktion recht einfach umsetzen, indem Sie den gleichen Test wie DA machen. Prüfen sie den Zugriff auf die Direct ccess- NLS-Webseite. Nur wenn Sie diese erreichen können, sind sie im internen Netzwerk.

Ansonsten könnte es passieren, dass sich ihre Anwender bei der Anmeldung unterwegs über sehr lange Wartezeiten beschweren.