DirectAccess mit Windows Server 2008 R2 und Windows 7

image

Mit Windows Server 2008 R2 und Windows 7 Enterprise Clients gibt es viele neue Features und Möglichkeiten, eine davon ist DirectAccess, dass ich hier mal genauer durchleuchten möchte.

image Mit DirectAccess ist es möglich, immer mit dem firmeneigenem Intranet und dessen Ressourcen verbunden zu sein, ohne dass der Anwender interaktiv mitwirken muss. Soll heißen: Sobald sich der Anwender mit seinem Notebook irgendwo auf der Welt ins Internet einwählt, ist er automatisch direkt mit dem Intranet seiner Firma verbunden.

Jetzt ist das ganze nicht wirklich eine Neu-Erfindung, denn das geht ja schon seit Jahren mit VPN Access. Warum man sich jetzt mit DirectAccess beschäftigen sollte oder ob man doch besser beim gewöhnlichen VPN Zugang bleibt, möchte ich im Folgenden erörtern.

Die IDC hat Ergebnisse veröffentlicht, die besagen dass im 3. Quartal 2008 erstmals mehr Notebooks und Laptops verkauft wurden, als herkömmliche Desktop-PC’s. Und die Anzahl der mobilen Geräte wird weiter steigen. Der “mobile Mitarbeiter” wird immer flexibler, sei es durch UMTS oder öffentliche W-LAN Hotspots, aber auch zu Hause hat sich ein Breitbandanschluss voll durchgesetzt. Wenn wir mögen, können wir also immer online sein, und durch VPN uns in die Firma verbinden.

Warum also DirectAccess, beziehungsweise was ist so schlecht an VPN?

  • Eine VPN Verbindung aufzubauen, benötigt eine aktive Handlung des Users, die sich teilweise auch durch mehrere Schritte arbeiten müssen.
  • Ist es durch NetworkAccessProtection (NAP) erforderlich, erst den Rechner auf seine Gesundheit (alle Updates und Security-Patches) zu prüfen, dauert es sehr lange bis die eigentliche Verbindung tatsächlich aufgebaut ist.
  • Verliert ein Benutzer die Internet-Verbindung, muss er sich erneut einwählen
  • Manche Umgebungen (W-LAN Hotspots etc.) erlauben keinen VPN-Traffic über Ihre Firewalls

 

Nutzt man dann auch noch das “Microsoft-VPN” Protokoll PPTP ist man auch nicht wirklich “sicher” unterwegs, alle Firewalls der Welt setzten inzwischen auf das um einiges sicherere IP-SEC Protokoll, welches Microsoft zwar inzwischen implementiert hat, jedoch eher mit dem Anschein, damit sich keiner mehr beschwert, denn eine “schöne” oder “einfache” Implantation ist etwas anderes.

DirectAccess ist nun endlich soweit! Es setzt auf das IP-SEC Protokoll mit Triple Data Encryption Standard (3DES), Advanced Encryption Standard (AES) und Encapsulating Security Payload (ESP). Jeder der sich hier bisschen auskennt sieht sofort: Hier wurde nicht gepfuscht, 3DES und AES gelten als absolut sicher und sind aktuell der Standard, auch wenn es bei vielen noch so aussieht das das reine DES Standard ist.

Aber damit nicht genug, das ganze wird noch mit dem sicherem IPv6 verbunden. Zusätzlich muss auf dem Client ein Computerzertifikat installiert sein, damit der Rechner schon vor der Anmeldung des Users die ersten Schritte der Authentifizierung vornehmen kann, aber dazu später mehr.

image

Der DirectAccess Client verbindet sich mit dem DirectAccess Server und baut zwei IPSec Tunnel auf, durch die über IPv6 kommuniziert wird. Das ganze funktioniert über das IPv4-basierte Internet. Das ganze funktioniert mit dem IPv6-over-IPv4 Protokoll.

Tunnel 1 authentifiziert sich durch das Computer-Zertifikat, und gibt dadurch Zugriff auf die internen DNS und DC frei, sowie die Möglichkeit auf GroupPolicy Objekte zuzugreifen.

Tunnel 2 authentifiziert sich durch das Computer-Zertifikat in Verbindung mit den User-Credentials. Dadurch können durch diesen Tunnel Zugriffe auf die direkten Dienste wie Exchange, SharePoint Services etc. gewährt werden.

Zudem hat der Administrator die Möglichkeit festzulegen, welche Applikationen über DirectAccess benutzt werden dürfen und welche nicht. Auch über SmartCards ist eine Authentifizierung möglich.

 

Es gibt zwei Szenarien um DirectAccess zu designen, End-to-End und End-to-Edge. Dabei wird End-to-End als “die sicherste Variante” von Microsoft behandelt.

END-TO-END

image

Mit dem End-to-End Szenario verbinden sich DirectAccess Clients direkt mit den im Intranet befindlichen Diensten und Applikationen. Dabei muss das Intranet komplett IPv6 sprechen, und die Server IPSec unterstützen. Also am Besten muss jeder Server ein Windows Server 2008 System sein.

 

END-TO-EDGE

image Bei End-to-Edge wird das IPv6 und IPSec nur bis zum DirectAcces Server hergestellt, und dieser leitet die Anfragen über das “unsichere” IPv4 Protokoll an die Server im Intranet weiter. Für dieses Szenario kann auch eine ältere Infrastruktur eingesetzt werden, da keine Veränderungen notwendig sind. End-to-Edge ähnelt damit voll dem normalem VPN Szenario.

 

Der Verbindungsprozess von DirectAccess

  1. Der DirectAccess Client auf einem Windows 7 Enterprise Client erkennt dass er Verbindung zu einem Netzwerk hat.
  2. DirectAccess versucht sich auf eine vorher vom Administrator konfigurierte Intranetseite zu verbinden. Gelingt dies, weiß DirectAccess dass sich der Client schon im Intranet befindet und stoppt den Prozess. Gelingt der Versuch nicht, geht der Verbindungsprozess weiter.
  3. DirectAccess verbindet sich zum DirectAccess Server über IPv6 und IPSec. Ist natives IPv6 nicht verfügbar (und das wird es nie sein beim bisher herkömmlichen IPv4 Internet), nutzt es 6to4 oder das Teredo Protokoll.
  4. Klappt dies auch nicht, da die Firewall oder der Proxy die Verbindung verweigert, wird die Verbindung über HTTPS (SSL) aufgebaut.
  5. Der Computer authentifiziert sich durch sein Computer-Zertifikat am Server.
  6. Der Server überprüft anhand des Active Directory, ob der Computer Zugriff über DirectAccess erhalten darf.
  7. Ist NAP aktiviert, so werden alle aktivierten NAP-Features überprüft, das können Anforderungen sein wie die letzten Security Updates oder Virenscanner-Definitionen. Akzeptiert der Server die Verbindung, so ist dadurch sichergestellt das der Client den
    Sicherheitsanforderungen des Unternehmens entspricht.
  8. Der DirectAccess Server beginnt den Traffic durch den Tunnel ins Intranet weiterzuleiten.

 

All das passiert schon bevor sich der Benutzer am eigenem Rechner anmeldet, vorausgesetzt der Rechner erkennt ein ihm bekanntes W-LAN Netzwerk. Durch die Anmeldung des Benutzers wird lediglich nur noch der Zugriff auf die Dienste wie Exchange etc. validiert.

 

Ein paar Fakten noch:

  • Auch bei DirectAccess kann der Administrator festlegen, ob auch der Internet-Traffic über die IPSec Tunnel geschickt wird, oder ob dieser separat direkt erfolgt.
  • Die SmartCard Authentifizierung kann rein mit User-Authentifizierung erfolgen, unabhängig vom Computer, oder MIT Computer-Zertifikat, so dass es NUR mit einem Computer klappt, oder über die Gateway Authentifizierung, d.h. DirectAccess kann sich ohne SmartCard am Server authentifizieren, aber der User kann ohne SmartCard nicht auf die Dienste im Intranet zugreifen.
  • DirectAccess benötigt IPv6. Ist IPv6 noch nicht im Einsatz, so kommt das 6to4 Protokoll zum Einsatz.
  • NAP und DirectAccess arbeiten Hand in Hand. Unterstützt ein Computer die Anforderungen des Unternehmens nicht, baut sich keine Verbindung auf.

 

Die Mindestanforderungen für DirectAccess:

  • Einer oder merhere DirectAccess Server auf Windows Server 2008 R2 mit zwei Netzwerkkarten: eine die direkt mit dem Internet verbunden ist und die zweite mit dem Zugriff auf das Intranet.
  • Mindestens zwei aufeinanderfolgende öffentliche und feste IP-Adressen die auf die öffentliche Netzwerkkarte des DirectAccess Servers gebunden sind.
  • Windows 7 auf den Clients
  • Mindestens einen DNS Server auf Windows Server 2008. Bei SmartCard Authentifizierung muss zudem die Active Directory Domain Services (AD DS) Rolle installiert sein.
  • Eine Public Key Infrastruktur (PKI) um Computerzertifikate, SmartCard Zertifikate und für NAP Health Zertifikate zu verteilen.
  • IPSec Policys um den sicheren Traffic zu gewährleisten.
  • IPv6 fähige Geräte oder 6to4

 

Mit DirectAccess hat man also nahtlose Verbindung, Administratoren haben immer direkt Zugriff auf die Clients und können diese aktualisieren, auch wenn diese über DirectAccess verbunden sind. Durch IPSec und IPv6 erreicht man höchstmögliche Sicherheit.

 

Nun aber nochmal zu meiner Anfangsintention: Lieber DirectAccess oder herkömmliches VPN?

Schön ist die DirectAccess Lösung von Microsoft allemal, aber aus meinen Augen mit einem dermaßen administrativen Aufwand verbunden den herkömmliches VPN noch nicht aufwiegen kann. Zwei feste und aufeinanderfolgende IP Adressen? Die Anforderung ist fast schon unglaublich. IPv4 kann zwar weitergenutzt werden, optimiert ist DirectAccess jedoch für natives IPv6 auch im Intranet.

 

Linksammlung:

Direct Access Technical Overview

Microsoft.com – What is DirectAccess?

DirectAccess visualized Demo (Silverlight)

Ähnliche Beiträge:

  1. MSTSC /Console oder /Admin ?
  2. Windows Web Server 2008 inkl. WordPress und PHP
  3. Windows Server 2008 R2 Dokumentation & Forefront Namen
  4. Windows 7 ab morgen über MSDN und MSDNAA verfügbar
  5. Windows 2000 stirbt am 13.07.2010
Dieser Beitrag wurde unter Bunte IT-Welt, Hösl, News abgelegt und mit , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

0 Antworten auf DirectAccess mit Windows Server 2008 R2 und Windows 7

  1. revres sagt:

    Vielen Dank für die ausführliche Umschreibung =)

  2. Was heisst da Umschreibung?? Frechheit.

  3. Utopas sagt:

    Hallo Patrick

    funktioniert Direct Access schon vor dem Login oder erst nachher ?
    Beispiel: Wenn User über UMTS etc. ins Firmennetzwerk möchten, gibt es da einen Lösung, dass z.B. UMTS Internet Verbindung vor dem Login aufgebaut wird und der User dann einloggt und das Roaming Profile kriegt ?

    Gruss
    U 2 Pas

  4. Ja, das ganze passiert bereits vor dem Login, bei UMTS wird das allerdings leider nicht möglich sein.
    Ob sich danach das RP noch aufbaut ist mehr als fraglich, aber ich gehe dem nach.

    Gruß
    Patrick

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*

*


Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>