Direct Access - Voraussetzungen
Ehe Sie nun einfach einen Windows Server in ihre Netzwerk einbinden, sollten Sie hier vorher die Voraussetzungen abprüfen. Alle Punkte sollten erfüllt sein, damit eine Implementierung Sinn macht:
Voraussetzung | Erfüllt |
---|---|
Clientsupport für DADa zwischen dem Client und dem LAN nur IPv6 genutzt wird, und dazu die Clients bei einer Anfrage nach einem Namen immer nur eine IPv6-Adresse vom Direct Access DNS-Proxy bekommen, muss die Clientsoftware mit IPv6 zurecht kommen. Ältere Software fragt gezielt nach IPv4 oder nutzt statische IPV4-Adressen und das funktioniert mit Direct Access nicht. Windows 2008R2 benötigt als DNS64/NAT64 Unterstützung zusätzlich das das Unified Access Gateway NAT64 und DNS64 könnten Sie auch über andere Systeme bereit stellen. Dazu ist aber intern dann zumindest teilweise ein ein IPv6 Deployment erforderlich. Im Notfall kann dies eine ISATAP-Lösung sein. |
|
Client Software muss DNS-Namen verwendenAus dem gleichen Grund ist es auch nicht möglich, direkt mit einer IPv4-Adresse eine Verbindung aufzubauen. Wer also z.B. eine ICA-Datei von seinem Citrix-Server bekommt, in dem eine IP-Adresse statt ein Name als Host enthalten ist, kann mit Direct Access nicht arbeiten. Auch ein "PING" auf eine IPv4-Adresse funktioniert aus Prinzip nicht. Windows 2008R2 benötigt als DNS64/NAT64 Unterstützung zusätzlich das das Unified Access Gateway. NAT64 und DNS64 könnten Sie auch über andere Systeme bereit stellen. Dazu ist aber intern dann zumindest teilweise ein ein IPv6 Deployment erforderlich. |
|
Windows Firewall MUSS aktiv seinDie ganze Tunnel-Technologie ist Bestandteil der Windows Firewall. Sie muss auf dem Server aber auch auf dem Client aktiv sein. Ich höre immer wieder, dass Firmen oder Anwender die Windows Firewall abschalten statt die erforderlichen Regeln zu addieren. Es gibt auch "Schutzprogramme (namentlich z.B. Symantec Endpoint Protection, SEP), die die Windows Firewall abschalten und ihre eigene Firewall stattdessen einsetzen. |
|
Passende Windows Client VersionSie benötigen Windows 7 Enterprise oder Ultimate oder Windows 2008R2+ oder neuer |
|
HardwareWindows ist
genügsam, wenn "nur" Direct Access installiert
ist. Auf einer VM hat
das System selten mehr
als 800 MB RAM
gebraucht.
Ausschlaggebend ist aber
weniger die Anzahl denn
der Durchsatz der
Benutzer. Einem
2xQuadcore werden bis zu
2300 User a 100kbit
(also 200 Megabit
Durchsatz) zu getraut.
Wer also "nur" ein paar User unterwegs
angebunden hat, wird mit
weniger zurecht kommen.
Letztlich nicht zu klein
anfangen und vernünftig
überwachen. |
|
NetzwerkanbindungDer Direct Access Server 2012 kann mit einer Netzwerkkarte oder zwei Karten (eine intern, eine in der DMZ mit NAT) oder eine Intern und eine extern betrieben werden. Windows 2008R2 benötigt zwingend zwei Netzwerkkarten, von denen die externe Karte ohne NAT auch zwei aufeinanderfolgende öffentliche IP-Adressen haben muss. |
|
Active Directory und Domain ControllerDie komplette Konfiguration der Direct Access Clients und Server erfolgt über Gruppenrichtlinien. Sowohl die Clients als auch die Server müssen Mitglied der Domäne sein. Beachten Sie die Mindestvoraussetzungen bezüglich Version der DCs und Forest Mode. Windows 2008R2 DA benötigt intern ein IPv6-Deployment, zum zumindest die DNS-Server per IPv6 anfragen zu können- |
|
PKIDa die Absicherung mit Zertifikaten erfolgt, müssen Sie eine Zertifikatsstelle betreiben, die Computerzertifikate auf die Clients verteilt. Beachten Sie, dass Sie beim der Verwendung interner Zertifikate auch die CRL extern bereitstellen müssen. Windows 7 Client müssen sich zwingend mit Computerzertifikaten anmelden. Erst mit Windows 8 Clients und höher kann auf Client-Zertifikate verzichtet werden. |
|
Network Location ServerDAzu wird intern ein IIS mit SSL-Zertifikat betrieben Achtung: Die aktuelle Einstellung findet sich in der folgenden URL HKLM\Software\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\CorporateConnectivity\DomainLocationDeterminationUrl. |
|
HochverfügbarkeitEs gibt mehrere Optionen, einen DA-Server "hochverfügbar" zu machen. Offiziell können Sie mit NLB arbeiten aber genauso gut können Sie natürlich einen einzelnen Server mit Hyper-V hochverfügbar machen. Bewerten Sie einfach ihre individuellen Anforderungen:
|
|
Remote Management per IPv6Wenn Dienste aus dem LAN eine Verbindung zum Client initiieren wollen, dann geht dies nur per IPv6. Wer also per SCOM o.ä., auf einen Client gehen möchte, muss IPv6 zumindest zwischen DA-Server und SCOM-Server aufbauen. Das gilt nicht, wenn auf dem Client schon ein Agent ist, der von sich aus der Verbindung zum Server herstellt. |
|
DA nicht auf AzureAnfangs konnten Sie den DA-Service sogar in Azure implementieren. Das ist mittlerweile aber nicht mehr möglich
|
|
Direct Access nutzt IPv6. das heißt eigentlich, dass sowohl Client als auch Service über IPv6 erreichbar sein müssen. Dabei sprechen wir nicht nur über die Netzwerke sondern auch die Clients. Nicht jeder Service ist über IP v6 erreichbar, auch wenn der Server selbst durchaus IPv6 anbietet. Dazu zählen z.B. Lync Frontendserver.
Und auch nicht jeder Client nutzt den vorhandenen IPv6-Stack sondern versucht weiter über IPv4 zu arbeiten. Entsprechend stellt sich die Matrix dar:
Client | Service | Direct Access 2008R2 | DA2008R2+UAG | DA2012 |
---|---|---|---|---|
IPv4 |
IPv4 |
|
|
|
IPv4 |
IPv6 |
|
|
|
IPv6 |
IPv4 |
|
|
|
IPv6 |
IPv6 |
|
|
|
Noch ist der Einsatzbereich von Direct Access alleine noch auf IP v6 beschränkt und auch mit dem kostenpflichtigen UAG wird es dem IPv6-Client zwar möglich, IPv4 Services zu erreichen aber nur, wenn der Client auch tatsächlich IPv6 als Quell-IP verwendet. Beim Zugriff auf IPv4-Server setzt DNS64/NAT64 die Pakete nämlich derart um, dass sich der IPv4-Server hinter einer übersetzten IPv6-Adresse verbirgt.
Ob ein Client auch IPv6 verwendet, können Sie einfach per NETMON ermitteln. Der entsprechende Prozess sollte auch IPv6-Pakete versenden.