Sicher ins Intranet ohne VPN: Microsoft Direct Access im Test

Microsoft Direct Access ist kein Dienst wie die Routing and Remote Access Services, die unter anderem für die VPN-Einwahl zuständig sind. Direct Access besteht nur aus einer MMC-Steuerkonsole, die vorhandene Dienste wie das Teredo-Gateway, die Certificate Services, IPv6-Routing, Internet Information Server, Network Location Services und Network Access Protection miteinander kombiniert. Diese Dienste gibt es allesamt auch schon in Windows Servern vor 2008 R2. Um sie für Direct Access nutzen zu können, müssen jedoch ihre aktuellen Varianten verwendet werden.

Die Direct-Access-Steuerkonsole, siehe Bild 1, wird im Server-Manager des Teredo-Gateways als Feature hinzugefügt. Sie leitet Schritt für Schritt durch das Setup. Nicht erfüllte Voraussetzungen, etwa zwei öffentliche IPv4-Adressen auf dem Gateway oder mindestens zwei Netzwerkkarten, findet der Wizard umgehend, siehe Bild 3. Die Tatsache, dass die Firewall in der Standard-Konfiguration keinen Teredo-Traffic durchlässt, beanstandet das Setup mit einer Warnung. Die Installation kann trotzdem fortgesetzt werden. Das Problem lässt sich später durch Öffnung von UDP-Port 3544 beseitigen.

In einem ersten Schritt bestimmt man eine Active-Directory-Security-Gruppe, die die Computer enthält, welche grundsätzlich Direct Access benutzen dürfen, siehe Bild 2. Im zweiten Schritt, siehe Bild 4, bestimmt man, welche Adapter des Teredo-Gateways ins Intranet und ins Internet zeigen. Anschließend gibt man mindestens je einen DNS-Server und einen Anmeldeserver für das Active-Directory an, siehe Bild 5, die aus dem Internet erreichbar sind.

Der DNS-Server muss eine öffentliche IPv4-Adresse besitzen. Der Anmeldeserver bekommt eine erreichbare IPv6-Adresse. Eine öffentliche IPv4-Adresse hätte es auch getan. Das wäre dann allerdings die vierte, die man in einer von Microsoft empfohlenen Konfiguration exklusiv für Direct Access bereitstellen muss. Die IPv6-Adresse des Anmeldeservers kann öffentlich oder privat, aber nicht linklokal sein. Der Anmeldeserver ist über das Computerzertifikat geschützt. Ihn können nur Rechner benutzen, die über ein Firmenzertifikat verfügen. Nach der Anmeldung können auch Benutzerzertifikate zur Authentifizierung eingesetzt werden. Das konfiguriert man im vierten Schritt, siehe Bild 6. So ist sichergestellt, dass nur berechtigte Benutzer von berechtigten Computern Zugriff auf erlaubte Server erhalten.

Der Wizard erleichtert die Einrichtung deutlich. Unter anderem erstellt er die Group Policy, die erforderlich ist, dass die Teredo-Interfaces der Clients richtig konfiguriert werden und sich am richtigen DNS-Server die Adressen für Teredo-Gateway und Anmeldeserver abholen. Ein bisschen Arbeit bleibt jedoch. Die grundsätzliche Teredo-Funktionalität am Client schaltet man mit dem Befehl netsh interface teredo set state enterpriseclient frei. Bis die Group Policy am Client angekommen ist, dauert es eine Weile. Wer nicht warten will, nutzt den Befehl gpupdate /force. Manchmal mag der mittlerweile völlig unzutreffend bezeichnete „TCP/IP-NetBIOS-Hilfsdienst“ Änderungen in der IP-Konfiguration nicht sofort erkennen. In diesem Fall hilft mit man dem Befehl sc control iphlpsvc paramchange nach.

Einen Server im Intranet erreicht man nur, wenn er über IPv6-Konnektivität und ein gültiges Zertifikat verfügt. Seine IPv4-Adresse macht ihn über Direct Access nicht erreichbar. So soll es im Endeffekt auch sein. Direct Access ist konsequent auf das Internetprotokoll der Zukunft ausgelegt. Kompatibilitätsballast aus der heutigen IPv4-Zeit kann bei Bedarf einfach abgeworfen werden. Mit Serverdiensten von Microsoft wird es unter IPv6 sicherlich nicht zu Problemen kommen, wenn der IPv6-Ping funktioniert. Interessant ist es vor allem, zu testen, wie sich Third-Party-Applikationen auf der Client- und Serverseite mit IPv6 verhalten.

Gleiches gilt für das Zusammenspiel von Routern, Netzwerkmanagementsystemen, Security-Appliances und anderen Komponenten mit Clients, die mobil nur über IPv6 erreichbar sind. Die ein oder andere Überraschung wird dabei nicht ausbleiben.

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 *