Sicher ins Intranet ohne VPN: Microsoft Direct Access im Test

Um Direct Access zu installieren, sind einige Voraussetzungen nötig. Serverseitig benötigt man eine PKI-Infrastruktur in Form der Active Directory Certificate Services. Dabei ist ein Auto-Enrollment zu empfehlen, das allen Clients automatisch Zertifikate verschafft, sobald sich das erste Mal ein Benutzer im Intranet an einer Domain anmeldet. Erforderlich ist darüberhinaus ein IIS-Webserver mit öffentlicher IPv4-Adresse im Internet. Er kann von überall erreicht werden und entscheidet, ob ein Rechner mit Zertifikat überhaupt über Teredo Zugang zu den IPv6-Adressen im Intranet bekommt. Außerdem veröffentlicht er die Certificate Revocation List (CRL), die erforderlich ist, wenn einem Mitarbeiter kurzfristig der Zugang entzogen werden muss.

Wenn man sich mit Active-Directory-Domänen, der Microsoft PKI und dem IIS ein wenig auskennt, dann ist ein Testszenario schnell aufgesetzt. Im ZDNet-Testlabor gelingt eine Installation ausgehend von nackter Hardware ohne Betriebssystem innerhalb vier Stunden. Der Release Candidate von Windows Server 2008 R2 wird dabei vom USB-Stick auf einen Rechner mit SSD installiert. Das spart leicht eine Stunde. Den Domain Controller setzt ZDNet auf dem physischen Rechner auf. Das Teredo-Gateway und der öffentliche Webserver werden auf einer einzigen Hyper-V-Maschine installiert. Microsoft empfiehlt allerdings beide Dienste auf zwei getrennten Servern zu installieren. Das erfordert eine weitere öffentliche IPv4-Adresse.

Der Domain Controller ist schnell eingerichtet. Die Certificate Services werden einfach nur installiert. Für ein Proof-of-Concept von Direct Access sind an den PKI-Diensten keine weiteren Einstellungen erforderlich. Der DNS-Server für die Active-Directory-Domäne muss aus dem Internet per IPv4 erreichbar sein. Empfehlenswert für den DNS-Server ist ferner, dass er über eine öffentliche IPv6-Adresse aufgerufen werden kann. Dazu entfernt ZDNet mit dem Befehl dnscmd /config /globalqueryblocklist wpad Teredo und Isatap aus der globalen DNS-Blockliste. Der Testclient und der Intranet-Testserver bekommen das nötige Zertifikat über das Certificate-MMC manuell. Das geht schneller als das Aufsetzen von Auto-Enrollment.

Die mindestens zwei aufeinander folgenden öffentlichen IPv4-Adressen lassen sich im ZDNet-Labor nicht kurzfristig beim Provider ordern und vom Administrator ins Labor-Netzwerk routen. Daher simuliert ZDNet das gesamte Internet mit einem Consumer-Ethernet-Switch. Um Direct Access zu testen, reicht es aus, wenn über diesen Switch Client und Teredo-Gateway mit dem scheinbar öffentlichen IPv4-Adressraum 130.107.0.0/16 kommunizieren können. Dieses Vorgehen empfiehlt Microsoft in einem Laborkonfigurationsvorschlag.

Themenseiten: Microsoft, Security-Praxis, Server, Servers, Storage, Storage & Server, VPN

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

Artikel empfehlen:

Neueste Kommentare 

1 Kommentar zu Sicher ins Intranet ohne VPN: Microsoft Direct Access im Test

Kommentar hinzufügen
  • Am 3. April 2011 um 15:31 von Daniel R.

    einschränkung
    Es sollte allerdings nicht unerwähnt bleiben das DA ausschließlich auf W7 Ultimate oder Enterprise eingesetzt werden kann.

Schreibe einen Kommentar

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