Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort zu diesem Buch
Inhalt des Buchs
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was überhaupt ist .NET?
6 Installation
7 Core-Installationsoption
8 Active Directory-Domänendienste
9 Netzwerkdienste im AD-Umfeld
10 Active Directory Lightweight Directory Services (AD LDS)
11 Active Directory-Verbunddienste (Federation Services)
12 Active Directory-Zertifikatdienste
13 Active Directory-Rechteverwaltungsdienste (AD RMS)
14 »Innere Sicherheit«
15 Dateisystem und Dateidienste
16 Drucken
17 Webserver (IIS)
18 SharePoint (Windows SharePoint Services, WSS)
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
24 Windows 7 und Windows Server 2008 R2
Stichwort

Download:
- ZIP, ca. 104 MB
Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Windows Server 2008 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2008 R2

Windows Server 2008 R2
geb., 1.410 S., 59,90 Euro
Galileo Computing
ISBN 978-3-8362-1528-2
Pfeil 24 Windows 7 und Windows Server 2008 R2
Pfeil 24.1 Überblick DirectAccess
Pfeil 24.1.1 Funktionsweise
Pfeil 24.1.2 Einige Technologiegrundlagen
Pfeil 24.1.3 Vorbereiten und Einrichten
Pfeil 24.1.4 Aus der Client-Perspektive
Pfeil 24.1.5 Die Sicherheit
Pfeil 24.2 Überblick BranchCache
Pfeil 24.2.1 Voraussetzungen
Pfeil 24.2.2 Funktionsweise
Pfeil 24.2.3 Installation und Konfiguration
Pfeil 24.2.4 Clients konfigurieren
Pfeil 24.2.5 Hosted Cache

Denn das seht ihr alle, daß mein Geschenk mir entgehet.
Ihm antwortete drauf der mutige Renner Achilleus:
Atreus Sohn, ruhmvoller, du habbegierigster aller,
Welches Geschenk verlangst du vom edlen Volk der Achaier?
Nirgends wissen wir doch des gemeinsamen vieles verwahret.

24 Windows 7 und Windows Server 2008 R2

Bekanntlich ist die Verwandtschaft zwischen dem aktuellen Server- und Client-Betriebssystem relativ eng. Diese »Pärchen« sind aktuell:

  • Windows Server 2008 und Vista
  • Windows Server 2008 R2 und Windows 7

Das bedeutet nun keinesfalls, dass andere »Kombinationen« nicht grundsätzlich auch gut funktionieren würden – selbst Windows 95- oder Windows NT 4-Clients können auf einen Windows Server 2008 (R2) zugreifen (gegebenenfalls sind für so alte Clients einige Einstellungen notwendig).

In diesem Kapitel geht es weniger darum, aus Sicht des Servers auf die Clients zu schauen, sondern zu erläutern, welche Features eines Windows 7-Clients einen Windows Server 2008 R2-Server voraussetzen. Dies sind übrigens genau die Features, die Windows 7 im Unternehmen wirklich spannend werden lassen. Wenn Sie Windows 7 nachhaltig und ganzheitlich einführen, kommen Sie vermutlich um den einen oder anderen R2-Server kaum herum.

Folgende Features des Windows-Clients benötigen die »Mithilfe« eines Servers:

  • DirectAccess: Das »VPN der nächsten Generation« benötigt zur Annahme der Verbindungen einen Windows Server 2008 R2.
  • IKEv2-VPN und VPN Reconnect: Wo wir gerade bei VPNs sind – zwischen Windows 7 und Windows Server 2008 R2 können VPN-Verbindung via IPSec mit IKEv2-Authentifizierung aufgebaut werden. Interessant dabei ist, dass bei solchen Verbindungen ein Feature namens VPN Reconnect verfügbar wird. VPN Reconnect sorgt dafür, dass aus Sicht der auf dem Client laufenden Applikationen bei einem Verbindungsabbruch der VPN-Tunnel nicht verloren geht – selbst wenn er einige Minuten oder gar Stunden nicht zur Verfügung steht. Sobald wieder eine Verbindung möglich ist, kann die Applikation weiterarbeiten, ohne dass eine Aktivität des Anwenders notwendig wäre. Das klappt übrigens auch, wenn das Übertragungsmedium wechselt (zum Beispiel WLAN zu UMTS).
  • BranchCache: Windows 7-Clients in Außenstellen können den WAN-Verkehr reduzieren, indem große Dateien nur einmal über die Weitverkehrsverbindung transportiert werden. Das funktioniert allerdings nur, wenn der Server, auf den zugegriffen wird, mit dem Windows Server 2008 R2-Betriebssystem läuft.
  • Windows Bereitstellungsdienste (WDS, Windows Deployment Services): Wenn Sie Windows 7 wirklich elegant installieren wollen, führt vermutlich kein Weg an den Windows Bereitstellungsdiensten vorbei. Die in Windows Server 2008 R2 enthaltenen Bereitstellungsdienste unterstützen selbstverständlich alle Deployment-Features des Windows 7-Clients. Anzumerken wäre, dass die Serverbetriebssysteme ebenfalls über die Bereitstellungsdienste installiert werden können, allerdings nutzen die meisten Unternehmen die Dienste »nur« für die Clientinstallation.
  • BitLocker: Grundsätzlich funktioniert die seit Windows Vista verfügbare Laufwerksverschlüsselung BitLocker auch ohne Mithilfe eines Servers. Für die Verwaltung ist es allerdings sehr praktisch, wenn Wiederherstellungscodes im Active Directory gespeichert werden.
  • Remotedesktopdienste: Wenn Sie Windows 7 in einer virtuellen Desktopinfrastruktur (VDI) einsetzen möchten, können Sie den Host für Remotedesktopvirtualisierung, eine Rolle der Remotedesktopdienste in Windows Server 2008 R2, nutzen.

Client-Themen

Da es sich bei diesen Themen ganz eindeutig um Client-Themen handelt (auch wenn Servertechnologie benötigt wird), möchte ich sie in diesem Serverbuch nur kurz ansprechen. Für weitergehende Informationen verweise ich auf mein bei Galileo Press erschienenes Windows 7-Buch, das sich ausführlich mit Aspekten wie DirectAccess, Deplyoment mit den Bereitstellungsdiensten oder BitLocker auseinandersetzt (ISBN 978-3-8362-1501-5).

Ich möchte noch darauf hinweisen, dass ein Windows Server 2008 (R2)-Server dieselben Client-Features zur Verfügung stellen kann, wie der Windows 7-Client. Sie können also beispielsweise BitLocker oder ihn als DirectAccess-Client nutzen. Da dies in der Praxis nicht (oder kaum) geschieht, gehe ich darauf nicht weiter ein – es funktioniert letztendlich genauso wie beim Windows7-Client.



Galileo Computing - Zum Seitenanfang

24.1 Überblick DirectAccess Zur nächsten ÜberschriftZur vorigen Überschrift

Eines der spannendsten Beispiele für neue Mobilitäts-Features, die Windows 7 in Verbindung mit Windows Server 2008 R2 bereitstellt, ist sicherlich DirectAccess. Im Zusammenhang mit dieser Technologie findet man Aussagen wie »das VPN der nächsten Generation«. Obwohl man mit solch euphorischen Statements sicherlich vorsichtig sein sollte, hat DirectAccess das Potenzial, in Unternehmen mit mobilen Mitarbeitern eine wertvolle Erweiterung zu werden. Etwas salopp gesagt, wird der mobile Client mit DirectAccess »nahtlos« in das Unternehmens-LAN integriert. Sobald der Client eine IP-Verbindung aufbaut, wird geprüft, ob er sich im Unternehmensnetz befindet. Ist dies nicht der Fall, baut er direkt und ohne weiteres Zutun des Benutzers eine Verbindung dorthin auf. Er ist also sozusagen »always on« im LAN, was zahlreiche Vorteile hat:

  • Der Benutzer kann einfach auf lokale Ressourcen zugreifen, und zwar ohne dass er erst mehr oder weniger umständlich VPN-Verbindungen aufbauen muss.
  • Das Management von Clients, die sich selten im Unternehmens-LAN befinden, verbessert sich. So kann jeder beliebige Prozess auf Server im LAN zugreifen – beispielsweise für Windows Updates (WSUS), für Softwareverteilungs- und Inventarisierungszwecke und dergleichen mehr.
  • Weiterhin ist es möglich, aus dem LAN auf den Client zuzugreifen, was ebenfalls für Management-Werkzeuge interessant sein könnte.

Etliche meiner Kunden interessieren sich sehr für die Möglichkeiten von DirectAccess und haben es bereits sehr früh eingesetzt – die Technologie hat also durchaus eine hohe Praxisrelevanz.


Voraussetzungen

Bevor Sie sich mit Begeisterung auf DirectAccess stürzen, möchte ich auf einige wesentliche Voraussetzungen hinweisen. DirectAccess ist nämlich nicht »mal eben so« implementiert. Die wichtigsten Voraussetzungen sind:

  • DirectAccess-Client-Funktionalität ist nur in der Enterprise und der Ultimate Edition von Windows 7 enthalten.
  • Es wird ein Windows Server 2008 R2 als DirectAccess-Server benötigt.
  • Der DirectAccess-Server benötigt zwei aufeinander folgende öffentliche IP-Adressen. Hierbei muss es sich um geroutete Adressen handeln, NAT ist nicht möglich.
  • Mindestens ein DNS-Server muss auf einem Windows Server 2008-Domänencontroller laufen. Dieser DC muss auf Windows Server 2008 SP2 oder Windows Server 2008 R2 basieren.
  • Da diverse Zertifikate benötigt werden, ist eine eigene PKI unumgänglich. Die zugehörige Zertifikatssperrliste muss aus dem öffentlichen Internet abrufbar sein.
DirectAccess basiert auf IPv6. Die Server, auf die DirectAccess-Clients zugreifen sollen, müssen über ein aktiviertes IPv6 verfügen. Alternativ kann NAT-PT zur Umsetzung zwischen IPv4- und IPv6-Adressen verwendet werden. Eine solche Funktionalität müsste allerdings von einem Dritthersteller bezogen werden, da Windows Server 2008 keine NAT-PT-Funktionalität enthält.

Aus diesen Voraussetzungen ergibt sich, dass DirectAccess keine Technologie für ein kleines Unternehmen ist, dessen Geschäftsführer einen komfortablen mobilen Zugriff auf Unternehmensdaten wünscht.

Wenn Sie ohnehin Windows 7 Enterprise oder Ultimate Edition-Clients einsetzen, sind die zusätzlichen Kosten für die Implementation vergleichsweise gering.



Galileo Computing - Zum Seitenanfang

24.1.1 Funktionsweise Zur nächsten ÜberschriftZur vorigen Überschrift

Auf Abbildung 24.1 ist die Funktionsweise von DirectAccess vereinfacht dargestellt:

  • Befindet sich der Client im Internet, greift er auf Ressourcen, die nicht im Unternehmens-LAN liegen, beispielsweise öffentliche Webserver, direkt zu. Bei »normalen« VPNs ist das Verhalten bekanntlich anders, dort wird bei einer aktiven VPN-Verbindung sämtlicher Verkehr über das VPN geleitet, das heißt, auch die Webzugriffe der Benutzer laufen darüber. Auf den ersten Blick sieht sich das vielleicht gar nicht schlecht aus, da die Webzugriffe sich so kontrollieren und filtern lassen. Wenn allerdings die Zugriffe von vielen weltweit verteilten Benutzern immer über die Zentrale erfolgen müssen, resultiert das in einem signifikanten Bandbreitenbedarf – bei einigermaßen begrenztem Nutzen. Also: Datenverkehr, der nicht Ressourcen im Unternehmens-LAN betrifft, erfolgt direkt.

Empfehlung

Sofern bei den mobilen Clients ein Proxy eingetragen ist, wird dieser Verkehr über diesen geführt und somit dann doch durch das Unternehmen transportiert. Es empfiehlt sich also, die Clients so zu konfigurieren, dass unterwegs kein Proxy verwendet wird.


  • Greift der Client auf eine Ressource im Unternehmens-LAN zu, wird der Verkehr verschlüsselt über das Internet zum DirectAccess-Server geleitet. Von dort werden die Datenpakete dann zum jeweiligen Server im Unternehmens-LAN transportiert.

Abbildung 24.1 Das Funktionsprinzip von DirectAccess


Galileo Computing - Zum Seitenanfang

24.1.2 Einige Technologiegrundlagen Zur nächsten ÜberschriftZur vorigen Überschrift

In diesem Abschnitt möchte ich einige Technologiegrundlagen vorstellen, die von DirectAccess genutzt werden. Das Wissen um diese Grundlagen ist einerseits interessant, um DirectAccess zu verstehen, andererseits lässt sich auch abschätzen, ob es in Ihrer Umgebung noch größere Stolpersteine gibt, die eine Einführung (vorerst) verhindern könnten.

Ich gehe an dieser Stelle auf die Grundlagen zur Server- und Infrastruktur ein.

IPv6 und Tunnelmechanismen

DirectAccess basiert auf IPv6. Ich möchte etwas deutlicher werden: DirectAccess ist ohne IPv6 nicht funktionsfähig. Da die meisten Unternehmen und Organisationen in Europa ihre Infrastruktur (noch) nicht auf IPv6 umgestellt haben, überlegen Sie sich vielleicht, das Buch direkt zuzuklappen und die Hoffnung auf DirectAccess zu begraben. Das ist aber vermutlich nicht notwendig, da letztendlich »nur« die Kommunikation zwischen DirectAccess-Server und dem vom Client angesprochenen Server über IPv6 laufen muss. Es ist nicht notwendig, dass außerhalb des Rechenzentrums das neue IP-Protokoll verwendet wird, was ein komplexeres IPv6-Konzept bedingen würde.

Weiterhin ist anzumerken, dass kaum ein Provider in der Lage ist, IPv6-Zugang zum Internet anzubieten. Der Datenverkehr über das Internet muss also über IPv4 laufen. Abbildung 24.2 zeigt das anhand einer kleinen Skizze:

  • Der DirectAccess-Client spricht die Ressourcen im internen LAN über deren IPv6-Adressen an.
  • Die IPv6-Pakete werden über das Internet mit einem Tunnelmechanismus transportiert. Die Nutzung des IPv4-Internets ist also kein Problem. Sofern Ihnen dieses Buch in einigen Jahren wieder in die Hand fällt, wenn IPv6 flächendeckend zur Realität geworden ist: Die Übertragung durch das Internet kann auch über IPv6 erfolgen.
  • Vom DirectAccess-Server zu den Servern im internen LAN erfolgt die Datenübertragung über IPv6.

IPv6

Aus der Skizze folgt übrigens eine wirklich wichtige Erkenntnis: Die Server im internen Netz, auf die per DirectAccess zugegriffen werden soll, müssen (!) IPv6 sprechen. Mit Windows Server 2003 und Windows Server 2008 ist das kein Problem, ältere Maschinen scheiden aus.

Sofern Sie unbedingt per DirectAccess auf einen NT-Server oder Windows 2000-Server zugreifen müssen, gibt es einen Workaround in Form von NAT-PT. NAT-PT dient vereinfacht gesagt als Brücke zwischen IPv6 und IPv4. Diese Funktionalität ist aber in Windows Server 2008 R2 nicht vorhanden, müsste also von einem Dritthersteller gekauft werden. Cisco verfügt beispielsweise über Geräte mit dieser Funktion.

Ich habe weiter vorn in diesem Buch (Kapitel 4, »Protokolle«) ziemlich deutlich die Meinung geäußert, dass für die meisten Unternehmen und Organisationen eine mit Vehemenz durchgeführte Komplettumstellung auf IPv6 keinen signifikanten Mehrwert hat.

Dass Sie momentan nicht aktiv eine nachhaltige und möglichst ganzheitliche IPv6-Nutzung vorantreiben, soll und darf aber nicht dazu führen, dass IPv6 generell per Registry-Schlüssel ausgeschaltet wird. Ich kenne Unternehmen, in denen genau das einer der ersten Handgriffe nach der Installation eines Windows Server 2008-Servers ist.

Diese Vorgehensweise rächt sich irgendwann – beispielsweise dann, wenn DirectAccess oder andere Technologien eingesetzt werden sollen, die auf IPv6 basieren.


Abbildung 24.2 Die IPv6-Pakete werden über das IPv4-Internet mit einem geeigneten Tunnelmechanismus übertragen.

Folgende Tunnelmechanismen können zum Einsatz kommen:

  • ISATAP: Diese Technologie wird eingesetzt, um IPv6-Datenpakete durch ein IPv4-Intranet zu tunneln.
  • 6to4 wird eingesetzt, um IPv6-Datenpakete durch das IPv4-Internet zu transportieren. Das Problem an 6to4 ist, dass keine NATs zwischen DirectAccess-Client und -Server liegen dürfen.
  • Teredo wird eingesetzt, um IPv6-Datenpakete durch das IPv4-Internet zu tunneln, wenn zwischen DirectAccess-Client und -Server NATs existieren.

Kurz zur Erklärung des NAT-Szenarios: NAT bedeutet Network Address Translation und ist eine Technologie, die dann angewendet wird, wenn ein Client mit einer privaten IP-Adresse mit einem System im Internet kommunizieren möchte. Ein im DirectAccess-Umfeld typischer Fall ist auf Abbildung 24.3 skizziert:

  • Der Client befindet sich im (privaten) Homeoffice-LAN eines Mitarbeiters. Vermutlich hat dieser einen einfachen DSL-Router und die interne IP-Adresse des Clients in die öffentliche IP-Adresse des Routers umsetzt.
  • Die Komponenten des Homeoffice-LANs müssen übrigens von IPv6 nichts wissen, da die Tunnelung bereits auf dem DirectAccess-Client erfolgt.

In diesem Szenario muss Teredo verwendet werden, 6to4 ist nicht NAT-fähig. Durch Nutzung von Teredo kann es aber problemlos eingesetzt werden.

Abbildung 24.3 DirectAccess verträgt NAT-Komponenten auf dem Übertragungsweg zwischen DirectAccess-Client und -Server.

Der DirectAccess-Client ermittelt den zu verwendenden Tunnelmechanismus automatisch. Sofern 6to4 und Teredo nicht funktionieren, wird IP-HTTPS verwendet, was allerdings unter Performancegesichtspunkten ungünstiger ist.

Beim IPv6-Tunneling muss der Client natürlich wissen, wohin, also zu welchem IPv4-System, die Pakete getunnelt werden sollen. Dies wird in der Konfiguration der jeweiligen Tunnelmethode festgelegt; auf Abbildung 24.4 ist zu erkennen, dass das »Ziel« des Tunnels die eine öffentliche IP des DirectAccess-Servers ist. Die Konfiguration erfolgt über eine Gruppenrichtlinie, welche die DirectAccess-Konfigurationsanwendung automatisch erzeugt.

Abbildung 24.4 Das Relay für die IPv6-Tunnelmechanismen wird mit einer Gruppenrichtlinie konfiguriert.

IPSec

Die Datenübertragung durch das Internet erfolgt geschützt über IPSec (Internet Protocol Security). Es ist ein Sicherheitsprotokoll für die Kommunikation über IP-Netze und gewährleistet Vertraulichkeit, Authentizität und Integrität. IPSec arbeitet auf der Vermittlungsschicht des TCP/IP-Protokoll-Stacks.

Für die IPSec-Authentifizierung werden bei der Verwendung mit DirectAccess Zertifikate eingesetzt, weshalb eine eigene PKI (Public Key Infrastructure) zwingend erforderlich ist.

Man könnte über IPSec viele Hundert Seiten schreiben – möchte ich hier aber nicht tun, da die notwendigen Richtlinien durch den DirectAccess-Installationsassistenten erzeugt werden.

Namensauflösung und NRPT

Namen von internen (also im LAN stehenden) Servern müssen notwendigerweise von einem internen DNS-Server aufgelöst werden. Für den Zugriff auf externe Ressourcen kann prinzipiell jeder beliebige im Internet stehende DNS-Server verwendet werden. Das bedeutet, dass je nach angefragtem Namen unterschiedliche DNS-Server verwendet werden müssen. Vor Windows 7 wäre diese Herausforderung nicht zu bewältigen gewesen – das neue Betriebssystem löst dies über NRPT (Name Resolution Policy Table). NRPT ist, wie der Name ja auch schon vermuten lässt, eine Tabelle, die definiert, für welche Namensräume welcher DNS-Server befragt werden soll. Das Ergebnis sieht dann wie auf Abbildung 24.5 gezeigt aus:

  • Wird eine externe Ressource angefordert, wird der DNS-Server verwendet, der vom jeweiligen Internetprovider bzw. Mobilfunkanbieter vorgegeben wird.
  • Wenn eine interne Ressource benötigt wird, wird die DNS-Anfrage über IPSec und den DirectAccess-Server an einen DNS-Server im Unternehmens-LAN geleitet.

Abbildung 24.5 Namensauflösung mit NRPT

Abbildung 24.6 zeigt, wie das Ganze auf einem Client aussieht. Mithilfe des Befehls netsh name show pol kann die NRPT ausgegeben werden. In diesem Fall ist konfiguriert, dass für Hosts im Namensraum ubinf.intra der DNS-Server 2002:a21e:… verwendet werden soll.

Abbildung 24.6 Die Anzeige der Name Resolution Policy Table


Konfiguration

Die Konfiguration gilt nur, wenn der Client sich außerhalb des Unternehmensnetzes befindet. Innerhalb des LANs wird die Namensauflösung »ganz normal« durchgeführt. Es macht bei DirectAccess also einen Unterschied, ob sich der Client im LAN oder außerhalb befindet.


Network Location Server

Eine wirklich wichtige Fähigkeit eines DirectAccess-Clients ist, zu erkennen, ob er sich im Unternehmens-LAN oder außerhalb desselben befindet. Dazu wird ein Network Location Server verwendet. Das hört sich deutlich komplizierter an, als es in Wirklichkeit ist. Als Network Location Server kann ein beliebiger im LAN stehender Webserver verwendet werden.

Ein DirectAccess-Client probiert beim Initialisieren der Netzwerkverbindung, ob der Network Location Server direkt (also ohne über den DirectAccess-Server zu gehen) erreicht werden kann. Ist dies der Fall, befindet er sich also im Innenbereich des Netzes. Kann er den Network Location Server nicht direkt erreichen, versucht er es über den DirectAccess-Weg.


Network Location Server

Der Network Location Server sollte auf einem hochverfügbaren Webserver installiert werden. Ist dieser Server nämlich nicht erreichbar, erkennen die DirectAccess-Clients nicht, dass sie sich im Innenbereich befinden und versuchen einen Verbindungsaufbau über den DirectAccess-Server.

Der Network Location Server muss auf einen nicht authentifizierten Zugriff ohne Fehlermeldung antworten. Webapplikationen, die eine Benutzerauthentifizierung fordern (wie beispielsweise SharePoint oder Outlook Web Access), scheiden also aus. Nichtsdestotrotz könnte man natürlich auf einem hochverfügbaren SharePoint-NLB-Cluster eine weitere IIS-Website einrichten, die auf einen anonymen Zugriff mit »OK« antwortet.

Die Network Location Server-Website muss mit einem SSL-Zertifikat geschützt sein. Die Sperrliste der Zertifizierungsstelle muss für den im Internet befindlichen Client erreichbar sein, das heißt sich auf einem öffentlich zugänglichen Webserver befinden. Das ist nicht allzu kompliziert zu realisieren – aber ein weiterer Schritt, der erledigt werden muss.


Zertifikate

Die IPSec-Kommunikation beruht, zumindest bei DirectAccess, darauf, dass die Clients über Zertifikate authentifiziert werden. Sie benötigen dazu eine eigene ins Active Directory integrierte PKI (Public Key Infrastructure).

Wie bereits zuvor erwähnt, muss die Zertifikatssperrliste öffentlich erreichbar sein – das dürfte bei den meisten Unternehmens-PKIs derzeit nicht der Fall sein.


PKI

Den Aufbau einer eigenen PKI und das Thema Sperrlisten habe ich in einem separaten Abschnitt (12.10) recht ausführlich erläutert.



Galileo Computing - Zum Seitenanfang

24.1.3 Vorbereiten und Einrichten Zur nächsten ÜberschriftZur vorigen Überschrift

Auf den ersten Blick sieht alles ganz einfach aus:

  • Das Feature DirectAccess-Verwaltungskonsole wird auf dem vorgesehenen Server hinzugefügt (Abbildung 24.7).
  • Die DirectAccess-Verwaltungskonsole zeigt die durchzuführenden Schritte an (Abbildung 24.8).

In der Tat brauchen Sie wirklich nur die vier Schritte abzuarbeiten. Aber (und dieses Wort müsste man eigentlich ganz groß drucken) die vorbereitenden Arbeiten sind nicht zu unterschätzen:

  • Netzwerkstandorte »sauber« konfigurieren
  • DNS-Server vorbereiten (Registrieren von ISATAP-Adressen zulassen)
  • PKI einrichten, insbesondere ist darauf zu achten, dass die Zertifikatssperrliste extern erreichbar ist.
  • Zertifikate an alle beteiligten Computer ausrollen
  • IP-Konfiguration der Server aktualisieren, um die ISATAP-Adresse hinzuzufügen
  • Sicherheitsgruppe für die Clients (Computer), die über DirectAccess zugreifen dürfen
  • Network Location Server vorbereiten
  • Firewall-Konfiguration anpassen, so dass die zwei gerouteten öffentlichen IP-Adressen beim DirectAccess-Server »ankommen«

Einrichtung

Wie bereits angemerkt, enthält mein Windows 7-Buch eine detaillierte Schritt-für-Schritt-Anleitung zur Einrichtung der genannten Voraussetzungen.


Abbildung 24.7 Erster Schritt ist das Hinzufügen der DirectAccess-Verwaltungskonsole. Weiterhin wird die Gruppenrichtlinienverwaltung benötigt.

Abbildung 24.8 Die DirectAccess-Konfiguration erfolgt mit diesem Werkzeug.

In der Praxis hat sich gezeigt, dass das »Hauptproblem« bei DirectAccess-Implementationen das Zertifikatwesen ist. Hier gibt es verschiedene »Standardprobleme« (oder sagen wir besser häufige Probleme):

  • Die Zertifikate sind nicht gültig, das heißt, der Name passt nicht, das Zertifikat ist zeitlich nicht gültig oder nicht vertrauenswürdig.
  • Die Sperrliste ist nicht erreichbar: Der DirectAccess-Client muss die Zertifikatssperrliste erreichen können – und zwar sowohl aus dem LAN als auch aus dem Internet heraus. Viele Zertifizierungsstellen in Unternehmen erfüllen diese Forderung derzeit nicht (insbesondere die Verfügbarkeit bei externem Zugriff), schlicht und ergreifend, weil das bis dato trotzdem alles funktionierte.

Abbildung 24.9 Die DirectAccess-Clients werden über Gruppenrichtlinien konfiguriert.

Vielleicht haben Sie sich nun gefragt, was mit der Konfiguration des Clients ist, schließlich war bisher nur vom Server die Rede. Auch wenn Sie einen Windows 7-Client intensiv untersuchen, werden Sie dort nirgends eine Windows 7-Konfigurationsapplikation finden. Der Grund für die Erfolglosigkeit der Suche ist auch schnell erklärt: Der Client verfügt nicht über eine solche Konfigurationsapplikation. Die Einrichtung der Clients (und übrigens auch der anderen beteiligten Systeme) erfolgt ausschließlich über Gruppenrichtlinien: Auf Abbildung 24.9 sehen Sie beispielsweise die Richtlinien für die Konfiguration von Verbindungssicherheitsrichtlinien. Sie brauchen sich allerdings keine Sorgen zu machen, dass Sie diese Gruppenrichtlinieneinstellungen manuell vornehmen müssten – das erledigt freundlicherweise die DirectAccess-Verwaltungskonsole.


Einschränkung

Da die Clients per Gruppenrichtlinien konfiguriert werden, ergibt sich eine wichtige Einschränkung: Ein Computer muss mindestens einmal mit der Domäne verbunden sein, bevor er mit DirectAccess zugreifen kann. Außer dem Einlesen der Gruppenrichtlinien muss der Client mit Zertifikat und Stammzertifikat versorgt werden.

Diese »Erkenntnisse« liegen zwar auf der Hand, es kann aber nicht schaden, die konkreten Auswirkungen in dem angestrebten Verwendungsszenario zu durchdenken.



Galileo Computing - Zum Seitenanfang

24.1.4 Aus der Client-Perspektive Zur nächsten ÜberschriftZur vorigen Überschrift

Für die Benutzer ist DirectAccess eine wunderbare Angelegenheit: Das komplette interne Netz (jedenfalls der Teil mit ISATAP-Adressen, der vom Administrator zugelassen ist) steht zur Verfügung, und man braucht nichts weiter zu tun. Also ist kein »Herumfummeln« mit einem VPN-Client nötig – alles läuft, und zwar sofort.

IP-Konfiguration

Abbildung 24.10 zeigt die IP-Konfiguration eines per DirectAccess verbundenen Clients:

  • Der Client hat eine öffentliche IP-Adresse, könnte also beispielsweise mit einer UMTS-Karte ausgestattet sein.
  • Der Client verfügt über eine ISATAP-Adresse (2002:….).

Abbildung 24.10 Die IP-Konfiguration des über das Internet verbundenen DirectAccess-Clients

Name Resolution Policy Table (NRPT)

Eine wesentliche Voraussetzung für die Nutzung von DirectAccess ist die NRPT. Mit dem Befehl netsh name show pol wird das gesamte (per Gruppenrichtlinie konfiguierte) Regelwerk, mit netsh name show eff werden die momentan aktiven DNS-Auflösungsregeln angezeigt: Auf Abbildung 24.11 ist ein Client zu sehen, der momentan mit dem Internet verbunden ist. Namensauflösungen für den Namensraum ubinf.intra werden von einem internen Server aufgelöst, der über eine ISATAP-Adresse erreichbar ist.

Abbildung 24.11 Die NRPT-Konfiguration, wenn der DirectAccess-Client über das Internet verbunden ist

Wie das Ganze aussieht, wenn der Client sich im Unternehmensnetz befindet, ist auf Abbildung 24.12 gezeigt:

  • Das in der NRPT enthaltene Regelwerk (netsh name show pol) bleibt unverändert.
  • Da der PC sich im Innenbereich befindet, werden Suchanfragen nach internen PCs nicht über DirectAccess geleitet, sondern direkt einem »normalen« Nameserver zugewiesen. Dies wird dadurch erreicht, dass von DirectAccess in die NRPT eingegriffen wird.

Abbildung 24.12 Dieses Bild ergibt sich, wenn der Client im Unternehmens-LAN ist.

Registrierung im DNS

Ein Client, der im internen Netz startet, registriert Namen und IP-Adressen im DNS – das ist nun nicht neu. Da ein DirectAccess-Client in letzter Konsequenz ebenfalls eine interne Maschine ist, registriert dieser brav Namen und IP-Adressen. Ein Blick ins DNS (Abbildung 24.13, markierter Eintrag) zeigt, dass der Client nur eine IPv6-Adresse hat. Das ist auch korrekt, denn über eine IPv4-Adresse ist er in der Tat auch nicht zu erreichen, wenn er über DirectAccess mit dem Unternehmensnetz verbunden ist.

Abbildung 24.13 Ist der Client über das Internet verbunden, ist für ihn nur eine IPv6-Adresse konfiguriert.

Wenn der Client zu einem späteren Zeitpunkt im Unternehmensnetz eingeschaltet wird, wird er sowohl die IPv4- als auch die IPv6-Adresse registrieren – dann ist er ja auch über beide Varianten erreichbar.

Zugriff auf das Unternehmens-LAN

Nun zu dem vermutlich spannendsten Test, nämlich dem Zugriff auf interne Server des Unternehmensnetzes. Da muss ich Sie enttäuschen, denn es gibt da nicht viel zu zeigen – es klappt einfach.

Abbildung 24.14 Die Namen von IPv6-Servern mit ISATAP-Adresse können aufgelöst werden. Dies ist mit »Nur-IPv4-Clients« nicht möglich. Diese werden einfach nicht gefunden.

Abbildung 24.15 Sehen Sie einen Unterschied? Der Zugriff auf diesen Dateiserver erfolgt über DirectAccess.

Abbildung 24.14 zeigt zunächst einen Ping-Test zu einem Server, der über eine ISATAP-Adresse verfügt: Der Name wird aufgelöst, und der Server antwortet auf die Pings.

Als Zweites habe ich den Namen eines Servers angegeben (ubinfex2), der nur über eine IPv4-Adresse verfügt. Er wird nicht gefunden. Der Server ist zwar im Netz vorhanden, da er aber keine IPv6-Adresse hat, steht er für den DirectAccess-Client nicht zur Verfügung.


DirectAccess auf älteren Servern

Falls Sie mit DirectAccess auf einen älteren Server (Windows 2000 oder älter) zugreifen möchten, müssen Sie NAT-PT einsetzen. Diese Technologie ist aber nur von Drittherstellern (zum Beispiel Cisco) erhältlich.


Abbildung 24.15 zeigt den Zugriff über DirectAccess auf einen Dateiserver mit Freigaben – es ist kein Unterschied zu erkennen, der Benutzer kann so arbeiten, als wäre er im LAN.

Zugriff auf den DirectAccess-Client

Der Zugriff funktioniert nicht nur von im Internet befindlichen Clients in Richtung der internen Server, sondern auch umgekehrt. Auf Abbildung 24.16 habe ich von einem als Verwaltungsserver definierten System einen Ping-Befehl auf den über DirectAccess verbundenen Client abgesetzt. Siehe da, es klappt.

Da der DirectAccess-Client seine IP-Adresse beim Verbindungsaufbau mit dem Unternehmensnetz am internen DNS-Server registriert, kann er einfach mit seinem Namen aufgerufen werden.

Abbildung 24.16 Der über das Internet angebundene DirectAccess-Client kann von den als Verwaltungsserver konfigurierten Systemen aus angesprochen werden.


Zwei wichtige Anmerkungen
  • Der Zugriff auf die DirectAccess-Clients ist nur von den als Verwaltungsserver eingetragenen Maschinen möglich.
  • Der Zugriff ist auch möglich, wenn kein Benutzer angemeldet ist. Sie könnten beispielsweise auf einen eingeschalteten PC per Remotedesktop zugreifen und sich anmelden.


Galileo Computing - Zum Seitenanfang

24.1.5 Die Sicherheit topZur vorigen Überschrift

Der Schwachpunkt in puncto Sicherheit bei DirectAccess ist wohl nicht, dass ein potenzieller Datendieb die IPSec-Verschlüsselung bricht. Die Bedrohung ist viel naheliegender: Wenn ein Notebook mit DirectAccess-Zugriff gestohlen wird, und dieses fragt beim Einschalten nicht nach einem Benutzerkennwort, dann ist der Datendieb »drin« (im Unternehmensnetz). Für DirectAccess-Notebooks sollten also folgende Richtlinien durchgesetzt werden:

  • Aktivierte BitLocker-Verschlüsselung
  • Nach einigen Minuten ohne Benutzeraktivität sollte sich das Notebook sperren.
  • Weiterhin sollte das Gerät beim Aufwachen aus dem Ruhezustand und generell beim Systemstart ein Kennwort anfordern.


Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






<< zurück
  Zum Katalog
Zum Katalog: Windows Server 2008 R2

Windows Server 2008 R2
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Windows 7 für Administratoren






 Windows 7 für
 Administratoren


Zum Katalog: Konzepte und Lösungen für Microsoft-Netzwerke






 Konzepte und
 Lösungen für
 Microsoft-Netzwerke


Zum Katalog: Office SharePoint Server 2007 und Windows SharePoint Services 3.0






 Office SharePoint
 Server 2007 und
 Windows SharePoint
 Services 3.0


Zum Katalog: Exchange Server 2007 und Office Communications Server 2007






 Exchange Server 2007
 und Office
 Communications
 Server 2007


Zum Katalog: Citrix XenApp 5






 Citrix XenApp 5


Zum Katalog: PC-Netzwerke






 PC-Netzwerke


Zum Katalog: VMware vSphere 4






 VMware vSphere 4


Zum Katalog: VMware vSphere 4 - Videotraining






 VMware vSphere 4
 - Videotraining


Zum Katalog: VirtualBox






 VirtualBox


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2010
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de