Windows Direct Access

Achtung:
Ein Windows 2008 DNS Server hat eine Globale DNS Query Block List, die eine Abfrage auf ISATAP eventuell verhindert.
DNS Server Global Query Block List
http://download.microsoft.com/download/5/3/c/53cdc0bf-6609-4841-a7b9-cae98cc2e4a3/dns_server_global_%20query_block%20list.doc

Siehe auch Direct Access 2012

Für den Einsatz von DA ist ein grundlegendes Verständnis von IPV6 erforderlich.
Lesen Sie daher bitte vorher die Seiten IPV6 und insbesondere IPv6 im LAN.

IT Free Training: Windows 7 DirectAccess
http://itfreetraining.com/70-680/windows-7-directaccess/

Es wurde schon viel über den neuen Ansatz geschrieben, wie mobile Clients ganz einfach "always on" mit dem Firmennetzwerk verbunden sein können. Und das ganz ohne den Aufbau und Abbau von VPN Verbindungen. Stark vereinfacht werden hierbei einfach zwei Kommunikationspartner per IPV6 verbunden und die IPV6-Möglichkeiten der Authentifizierung und Verschlüsselung (vgl. IPSEC) genutzt. Wenn Sie nun sagen, dass das ja nicht geht, da viele Internetverbindungen und auch ihre Internetanbindung als auch das interne LAN doch nur mit IPV4 arbeitet, so vergessen sie, dass es sehr wohl funktionierende Methoden gibt um IPV6 über IPV4 zu transportieren und umgekehrt. Und genau das ist auch der Trick von Direct Access.

Direct Access ist einfach ...
... wenn die Randbedingungen stimmen. Und genau da liegt oft das Problem. Ohne "richtige" Zertifizierungsstelle, die auch von extern ihre CRL erreichbar macht, ohne korrekte DNS Einträge und Gruppenrichtlinien und ohne die passenden Windows 7 Lizenzen (Enterprise oder Ultimate) können Sie viel Zeit in der Fehlersuche verbringen.

Unterstützung durch Net at Work:
Nutzen Sie doch einfach unter Know-how bei Windows Zertifizierungsstellen (Siehe Firmen CA und Private CA) und Direct Access.
Wir können Sie aktiv unterstützen. Rufen Sie einfach unter 0800-NETATWORK (0800-638 28 96) an.

Für den Anwender erfolgt dies alles transparent. Er ist faktisch "immer" mit der Firma verbunden, wen er eine geeignete Internet-Verbindung nutzen kann. Im Gegensatz zum klassischen VPN nutzt Direct Access aber eine "Split-Tunnel" Konfiguration, d.h. trotz Verbindung zum Intranet der Firma kann ich auch noch im Internet arbeiten und lokale Ressourcen verwenden. Umgekehrt ist der Client natürlich auch aus dem Firmennetzwerk heraus immer zu "erreichen", wenn er eingeschaltet ist. Das macht es natürlich für die Software und Patchverteilung einfacher, da nicht erst darauf gewartet werden muss, dass der Anwender ein VPN aufbaut.

Zur Sicherheit kommen hier Zertifikate zum Einsatz, d.h. ehe die ersten Nutzdaten übertragen werden, haben sich die Systeme gegenseitig authentifiziert. Wenn also diese Überprüfung der Zertifikate keine Schwachstellen enthält, dann ist es sehr unwahrscheinlich, dass die Sicherheit gefährdet ist. Wie immer dürfte der PC und der Anwender davor selbst das größere Problem darstellen. Ein Angreifer kann vermutlich nur versuchen, die Bandbreite durch Pakete zu belasten.

Voraussetzungen

Ehe Sie nun einfach einen Windows 2008 R2 Server in ihre Netzwerk einbinden, sollten Sie hier schon mal die Voraussetzungen abprüfen:

Voraussetzung Erfüllt
  • Hardware
    Windows 2008R2 ist genügsam, wenn "nur" DirectAcces 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 MBit 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.
    Und wenn Sie doch mal UAG installieren wollen, dann sind 4GB Mindestvoraussetzung.
  
  • Client: Windows 7 Enterprise oder Ultimate oder Windows 2008 R2 auf dem Client
    Für ältere Versionen scheint Microsoft Direct Access nicht nachrüsten zu wollen. Nun da aber Windows XP schon sehr alt ist und Vista in vielen Firmen nicht so weit verbreitet ist, dürfte der Wechsel nach Windows 7 wohl im Zeitraum 2010-2012 bei den meisten Firmen anstehen und damit die Basis für Direct Access gelegt sein. Windows 7 Professional oder kleiner reichen aber nicht aus
  
  • Gateway: Windows 2008 R2 als Direct Access Gateway mit zwei Netzwerkkarten
    Das Gateway muss zwingend zwei Netzwerkkarten besitzen, von denen eine zum Internet geht und die andere zum internen LAN verbunden ist.
  
  • Zwei aufeinanderfolgende öffentliche IP-Adressen
    Der Direct Access Server benötigt zwei aufeinanderfolgende öffentliche IP-V4 Adressen zur exklusiven Verwendung.
  
  • Domain Controller
    Windows 2008 SP2 oder R2 als Domain Controller mit IPV6
    Mindestens ein Windows 2008 R2 DC ist erforderlich. Zudem können Direct Access Clients nur auf Windows 2008 oder 2008 R2 DCs zugreifen. Windows 2003 DCs und älter sind nicht erreichbar.
  
  • Active Directory Windows 2003 Native Forest
    Die Betriebsart des Active Directory muss mindestens Windows 2003 Native sein, d.h. es darf keine Windows 2000 DC oder gar NT4 BDCs mehr geben.
  
  • PKI
    Da 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.
  
  • "Network location Server", interner IIS mit SSL-Zertifikat
    Der Client versucht per HTTPS einen bestimmten Webserver zu erreichen. Ist dies möglich, dann geht er von einer "internen Verbindung" aus. Ist der Server nicht erreichbar, dann geht der Client davon aus, dass er extern unterwegs ist. Dieser Server "sollte" sehr gut verfügbar sein, da ansonsten die Client auch intern davon ausgehen, dass sie extern wären.

Achtung:
Ein Client prüft beim "Network Change". Ist dieser Server nicht erreichbar, dann geht auch ein interner Client davon aus, dass er "extern" ist und versucht zu tunneln, was aber nicht geht. Leider kann man nur einen NLS-Server angeben. Die Abhängigkeit muss bekannt sein. Sie können den DA-Server daher zum NLS-Server machen oder z.B. per Loadbalancer ein hochverfügbares Exchange 2010 CAS-Array dazu missbrauchen.

  
  • Interne Server mit IPV6
    Direct Access baut auf IPV6 auf und erlaubt ohne weitere Hilfsmittel nur den Zugriff auf Systeme, die auch eine IPV6-Adresse haben. Das bedeutet nicht, dass auch alle internen Router nun IPV6 unterstützen müssen. IPV6-Systeme können sich durchaus über IPV4-Strecken auch intern verbinden. Dazu muss dann aber ISATAP konfiguriert sein.
    Auch in einer reinen IPv6-Umgebung müssen Sie Leitwege korrekt konfigurieren. So kommen die DA-Clients mit einem eigenen Subnetz an, zu dem alle Server einen "Rückweg" wissen müssen.
  
  • NAT64 für IPV4-Only-Systeme
    Sollten Direct Access Client auch auf reine IPV4-Systeme zugreifen müssen, dann müssen sie über entsprechende Gateways eine entsprechende Umsetzung auf IPV4 einrichten. Das kann ein Microsoft UAG oder andere Produkte sein. Das Windows 2008 R2 Direct Access Gateway alleine bietet diese Funktion aber nicht an.
  
  • Gruppenrichtlinien
    Letztlich werden alle Funktionen und Einstellungen über Gruppenrichtlinien gesteuert und konfiguriert.
  

Hochverfügbarkeit

Es 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

  

Wer mit wem

Direct Access nutzt IPv6. das heißt eigentlich, dass sowohl Client als auch Service über IPv6 erreichbar sein müssen. Daber 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 DA+UAG
IPv4 IPv4 Nein Nein
IPv4 IPv6 Nein Nein
IPv6 IPv4 Nein JA
IPv6 IPv6 JA JA

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.

Tunnelkomponenten

IPV6 und IPV4 können nebeneinander koexistieren aber es gibt immer Teilstücke, die z.B. kein IPV6 unterstützen, so dass "getunnelt" werden muss. Es gibt aber auch Server die kein IPV6 bedienen und nur über IPV4 erreichbar sind. Auch hier müssen Systeme die reinen IPV6-Clients den Zugriff z.B. per NAT64 erlauben. Hier eine Sammlung der verschiedenen Optionen:

Funktionsübersicht

Sie haben schon gelesen, dass bei Direct Access nichts ohne IPV6 geht. Das basiert darauf, dass Microsoft mit Direct Access zuerst einmal davon ausgeht, dass die beiden Kommunikationspartner per IPV6 miteinander kommunizieren können und Gruppenrichtlinien entsprechend die Verbindungen konfiguriert werden (IPSec). Nun ist es aber leider nicht so, dass heute schon alle Clients per IPV6 miteinander kommunizieren können. Direct Access stellt durch die passenden Komponenten auf dem Windows 7 Enterprise/Ultimate-Client und den Direct Access-Server die Hilfsmittel bereit, auch IPV4-Strecken über das Internet für IPV6 durchgängig zu machen und hierbei auch NAT-Router und andere Hindernisse zu überwinden. IPV6 wird also auf dem Client in ein IPV4-Paket getunnelt zum Direct Access Server übertragen, welcher dann das Packet wieder intern auf die Leitung setzt. Da spielen natürlich viele Komponenten zusammen, damit Direct Access funktioniert. Auch wenn die Direct Access-Rolle an sich sehr schnell installiert ist und der Assistent Sie durch die Konfiguration führt, so ist dies "nur" Direct Access aber nicht die Umgebungen. Hier mal ein schematisches Bild der Komponenten.

Dieses Bild nutze ich gerne bei Vorträgen und Planungsworkshops mit Kunden. Dort "entsteht" das Bild aber auf einer weißen Tafel. Links sieht man die vier verschiedenen Möglichkeiten einer Clientverbindung

Der Client kann zuhause, an einem öffentlichen Accesspoint o.ä. angeschlossen sein und schafft es für Verbindungen zu den internen Servern die Daten zu übertragen. Über Zertifikate auf dem Server und die Clients wird der Datenverkehr abgesichert. Als Tunneloptionen bietet DirektAccess dabei 6to4, Teredo, ISATAP oder HTTPS-Tunnel an.

Aber auch hier ist zu sehen, dass der Zugriff auf eine IPV4-Ressource im LAN nur über ein NAT64-Gateway wie den UAG oder andere Systeme erfolgen kann. Das Problem wird natürlich kleiner je mehr Dienste intern per IPV6 zu erreichen sind. Mindestens ein Domain Controller muss ja schon per IPV6 erreichbar sein, damit die Funktion gegeben ist. Wer intern dann jedoch mehrere Subnetze betreibt, wird irgendwann auch hier intern IPV6-taugliche Router einsetzen müssen, damit auch diese Erreichbarkeit durchgängig möglich ist.

Welchen Weg der Client aus dem Internet zum Direct Access-Server nutzt, bestimmt er anhand der lokalen IP-Adresse, die er in seinem Subnetz bekommen hat:

IP-Adresse des Clients Bevorzugter Verbindungsweg FirewallPorts Verbindung
Globale eindeutige IPV6-Adresse IPV6 zum Direct Access-Server ICMPv6
IP Protokoll 58
IPsec Encapsulating Security Payload (ESP) traffic (IPv6 protocol 50)		 Direkt IPV6
Öffentliche IPV4 Adresse 6to4: IPV6-Pakete über IPV4-Pakete geroutet übermitteln Getunnelter IPv6 Traffic über
IPv4 Protocol 41		 Direkt IPV4
Private IP-Adresse Teredo: Tunnelt IPV6-Pakete in IPV4-Pakete, die auch durch NAT-Systeme durchgehen können UDP Port 3544 NAT über IPV4
Keine Verbindung per 6to4 oder Teredo Fallback auf IP over HTTPS TCP Port 443 HTTPS auch über Proxies

Damit ist natürlich klar, dass das ganze nur sinnvoll funktioniert, wenn das Client-Subnetz sich auch danach richtet. Eine Firma, die intern einen "offiziellen" Bereich verwendet, der ihr aber nicht zugewiesen ist, sondern als "Altlast" einfach da ist, wird den Client genauso stören wir eine offizielle "falsche" IP-V6-Adresse.

Weiterhin spielen ihnen Internet Provider, Router und GSM-Provider Streiche, indem Sie bestimmte Ports aus "Kostengründen" oder "Sicherheitsbedenken" sperren

Der APN für Vodafone ist: "volume2.d2gprs.de" statt "web.vodafone.de"
Hinweis. Ein 1und1 Vertrag der die Vodafone Struktur nutzt, kann diesen APN scheinbar nicht nutzen.

Der APN für T-Mobile ist: "internet.t-mobile.de"
Hinweis. Ein 1und1 Vertrag der die Vodafone Struktur nutzt, kann diesen APN scheinbar nicht nutzen.

Sie sollten also immer die verwendeten Protokolle kennen und mit NETMON auch hinter die Kulissen schauen können.

6to4

Mit einer offiziellen IPv4 Adresse versucht der Client sich also per 6to4-Tunnel mit dem Server zu verbinden. Der Assistent zu Direct Access macht die erforderlichen Einstellungen per Gruppenrichtlinie, wie Sie an dem Bild erkennen können:

In der Mitte ist die IPv4-Adresse des Server angegeben. Eine Kontrolle mit RegEdit auf dem Client zeigt ihnen den entsprechenden Schlüssel: 

Die Einträge für Teredo sind auch an der gleichen Stelle zu finden. Auch NETSH zeigt ihnen die Daten mit "netsh interface 6to4 show relay":

Eigentlich sollte 6to4 über offizielle Adressen in allen Netzwerken funktionieren. Dummerweise gibt es Provider, die trotz offizieller Adresse dies diese ICMP-Pakete verändern und der Direct Access Client die Verbindung nicht herstellen kann. Es kann daher sogar besser sein, auf 6to4 zu verzichten und gleich zu Teredo zu gehen.

Ob die Verbindung per 6to4 möglich ist, können Sie einfach mit dem NETMON überprüfen, bei dem Sie folgenden Filter verwenden

IPv4.NextProtocol == 0x29

An einem einfachen unverschlüsselten PING eines Clients ist gut zu sehen, wie IPv6 in IPv4 eingepackt wird

Andere "Nutzdaten" werden anhand der Richtlinien natürlich verschlüsselt.

I would definitely set Teredo to Enterpriseclient status. I recommend that you do this permanently for all of your Direct Access computers via a GPO (and disable 6to4 on all of your Direct Access clients computers using the same GPO). 6to4 is only ever used if your client computer gets a real public IP address (like from a cell phone card), 6to4 will never connect when the user is sitting behind a NAT like a home router. And in the rare cases that 6to4 does actually connect, half the time the ISP blocks IP Protocol 41 which kills your DA connection. Better to disable the 6to4 adapter and let Teredo do the job in its place.
Quelle: Jordan Krause MVP http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/thread/8475dc32-eb4e-4255-9153-76db62b0b582

Das können Sie auf dem Client zum Test einfach mit NetSH ein und ausschalten.

netsh interface 6to4 set state disabled

Für den Firmeneinsatz sollte das natürlich dann in der Direct Access Gruppenrichtlinie unter "Computer Configuration\Policies\Administrative Templates\Network\TCPIP Settings\IPv6 Transition Technologies " erfolgen.

Sollten Sie die entsprechende Einstellung nicht in der GUI sehen, dann haben Sie noch nicht die Windows 2008 R2 - ADMX-Vorlagen eingespielt.

Teredo

Aber auch für das "Tunneln" durch Teredo tragen die Gruppenrichtlinien entsprechende Einträge lokal ein, die auf den Direct Access Server verweisen. Über "netsh interface teredo show state" können Sie den Status des Teredo-Interface einsehen

Die IP-Adresse des Servers, der per Gruppenrichtlinie übertragen wurde, habe ich hier unkenntlich gemacht. Sie können Teredo natürlich auch manuell per NETSH konfigurieren

netsh interface teredo set state enterpriseclient
sc control iphlpsvc paramchange

Über NETSH können Sie auf dem Direct Access Server auch die Serverseite anschauen

C:\>netsh int ipv6 show teredo server
Teredo Parameters
---------------------------------------------
Type                    : server
Virtual Server Ip       : 80.22.60.221
Client Refresh Interval : 30 seconds
State                   : online
 
Server Packets Received : 33612
Success                 : 33583 (Bubble 31210, Echo 2273, RS1 86 RS2 14)
Failure                 : 29 (Hdr 0, Src 29, Dest 0, Auth 0)
 
Relay Packets Received  : 21724
Success                 : 245421 (Bubble 544, Data 244877)
Failure                 : 446 (Hdr 0, Src 0, Dest 446)
 
Relay Packets Sent      : 53555
Success                 : 556279 (Bubble 1210, Data 555069)
Failure                 : 8 (Hdr 0, Src 8, Dest 0)
 
Packets Received in the last 30 seconds:
Bubble 0, Echo 0, RS1 0, RS2 0
6to4 source address 0, native IPv6 source address 0
6to4 destination address 0, native IPv6 destination address 0

Ich ziehe aber die Konfiguration per Gruppenrichtlinien über den Assistenten vor. Damit Teredo funktioniert muss mindestens eine Firewallregel auf dem Client eingerichtet werden.

To allow Teredo-based connectivity, you must configure and deploy the following additional Windows Firewall with Advanced Security rules for all of the domain member computers in your organization:

Inbound ICMPv6 Echo Request messages (required)
Outbound ICMPv6 Echo Request messages (recommended)

Nicht alle Router unterstützen übrigens Teredo. Dazu zählt insbesondere die Fritz-Box 7170 und 7270 (Version 1). Ab Version 2 kann IPV6 intern genutzt werden.

IPHTTPS

Zuletzt gibt es den Tunnel durch HTTPS. Der Client packt alle Pakete in HTTPS-Request ein, die er über die gewohnten Wege versendet. Hier kann aber immer noch ein HTTPS-Proxy die Verbindung blockieren. Allerdings gibt es da keine kleine Falle. Während die Gateway-IP für 6tp4 und Teredo als "nummer" gespeichert wird, wird der Zugang für HTTPS als Name gespeichert. Die Einstellungen finden sich auf dem Client auf einem Unterschlüssel:

Und das ist genau die zweite IP-Adresse, die für Direct Access erforderlich ist. Wenn Sie nämlich bei der Konfiguration "genau" hinschauen, dann zeigt der Assistent nicht die erste sondern die zweite IP-Adresse an

Und diese Adresse ist mit dem Namen im DNS zu veröffentlichen.

Hinweis
Wenn Sie Split-DNS" nutzen, dann müssen sie auch diesen Host später in der NRPT ausnehmen.

Wenn Sie dies nicht tun, dann wird der HTTPSTunnel nicht funktionieren, weil Windows den Namen über die IPv6-DNS-Server erreichen will, der Tunnel aber noch nicht stehen kann. (Henne-Ei-Problem). Wenn das aber funktioniert, dann sieht es wie folgt aus:

Aber auch die Serverseite von IPHTTPS kann per NETSH überprüft werden

C:\>netsh interface httpstunnel show interface 

Interface IPHTTPSInterface Parameters
------------------------------------------------------------
Role                       : server
URL                        : https://da.netatwork.de:443/IPHTTPS
Client authentication mode : certificates
Last Error Code            : 0x0
Interface Status           : IPHTTPS interface active


C:\>netsh interface httpstunnel show st
 
Interface IPHTTPSInterface Parameters
------------------------------------------------------------
Total bytes received       : 21331
Total bytes sent           : 42139
 
Most Recent Client Address                 Total Bytes In    Total Bytes Out
------------------------------------------ ----------------- -----------------

Bei einer fehlerfreien Verbindung können Sie mit IPCONFIG den Tunneladapter samt der aus dem Direct Access-Pool zugewiesenen IPv6-Adresse sehen.

Beachten Sie, dass der HTTPTunnel nur funktioniert, wenn der Client zum DA-Server per HTTPS reden kann. Dabei kann auch ein Proxy dazwischen sein, solange dieser keine Authentifizierung verlangt.

IPHTTPS und Proxy
IP-HTTPS does not support proxy servers that require authentication with each connection, which might cause problems with IP-HTTPS connections. To determine if you are behind this type of proxy, open your Internet browser and browse a public website. You might be prompted for authentication. Open a second Internet browser window or tab and browse a different public website. If you can get to the second website without having to specify authentication credentials, IP-HTTPS should work across the proxy. If you need to enter credentials each time you access a different website, IP-HTTPS might be blocked.
Quelle: http://technet.microsoft.com/en-us/library/ee844126(WS.10).aspx

Es ist aber kein Problem, wenn z.B. an einem Hotspot sind und sich dort per Browser anmelden, aber dann keine weitere HTTP-Anmeldung erforderlich ist, was fast überall der "Standard" ist. Faktisch dürfte der HTTPS-Tunnel daher fast nur dann nicht funktionieren, wenn Sie ihren Notebook bei einer fremden Firma angestöpselt haben, deren HTTP-Proxy eine integrierte Anmeldung erfordert.

Sollten alle anderen Optionen (6to4, Teredo) nicht gehen und auch der HTTPS-Tunnel nicht aufgebaut werden, dann sehen Sie beim Schnittstellenstatus mit "netsh interface httptunnel show interface" einen Fehlercode:

Häufiger Fehler ist z.B. das Zertifikat auf dem Client. Wer auf der internen Enterprise-CA ein eigenes Template für die Ausstellung von Computer-Zertifikaten einsetzt, sollte darauf achten, dass der DNS-Name zumindest im SAN-Feld enthalten ist und der Antragsteller (Subject) nicht leert ist. Hier die wichtige Seite.

Aber auch auf dem Server spielen Zertifikate eine wichtige Rolle. Der IPHTTP-Listener kann anscheinend nicht explizit an eine IP-Adresse gebunden werden, sondern nutzt als Teil des Betriebssystems einfach alle IP-Adressen auf Port 443: Entsprechend sieht man mit NETSH einen globalen Listener.

C:\>netsh http show sslcert

SSL Certificate bindings:
-------------------------
 
    IP:port                 : 0.0.0.0:443
    Certificate Hash        : ae5f91d465eeac2a0c3ada91606f7fbd7da4f2c7
    Application ID          : {5d8e2743-ef20-4d38-8751-7e400f200e65}
    Certificate Store Name  : MY
    Verify Client Certificate Revocation    : Enabled
    Verify Revocation Using Cached Client Certificate Only    : Disabled
    Usage Check    : Enabled
    Revocation Freshness Time : 0
    URL Retrieval Timeout   : 0
    Ctl Identifier          :
    Ctl Store Name          :
    DS Mapper Usage    : Enabled
    Negotiate Client Certificate    : Disabled

Dabei bedeutet dies nicht, dass ein IIS oder eine andere Applikation nicht einen "enger" gefassten Listener konfigurieren kann. Es ist mir aber besonders mit UAG aber mehrfach passiert, dass die Assistenten nicht das richtige Zertifikat an diesen Listener gebunden haben. Leider kann man das nicht "ändern", sondern muss den Listener löschen und neu anlegen. Zudem ist die Einstellung "Negotiate Client Certificate" bei DA per Default auf "disabled" und bei UAG ein "enabled". Insofern ist Direct Access hier etwas toleranter als UAG, so dass Fehler auf dem Clientzertifikat vielleicht nicht sofort auffallen.

Dafür kann UAG an anderer Stelle sich einmischen, wie folgender Forenbeitrag ausführt:

BTW: UAG has a setup bug in the way its bind the default website (internal site) to 0.0.0.0:443. When using DA this site gets accessible from the outside (without UAG URL Filters active) because the DA Wizards will create a TCP443 Paketfilter to allow this traffic. So the 404 message you get is most likely a responce from your Default Website (aka. internal site). To see if this is the case for you try using the following URL:  https://da1.koncar-inem.hr/internalsite/languages/en-us.xml If you can access this file (your Portal Trunk would deny it for a good reason), then you still have the default binding in place...
Quelle: http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/thread/2ed199cf-c1ad-47fe-aff1-12fb22449ed6

Wenn Sie daher die Bindungen der Zertifikate überarbeiten wollen, dann sind folgende Zeilen eine gute Vorlage. den Hash des Zertifikats müssen Sie manuell ermitteln und die GUID bei der AppID ist eine zufällige GUID, die sie in Powershell mit dem Befehl "[guid]::NewGuid()" ganz schnell erzeugen können. Zur Lesbarkeit wurden die Zeilen umgebrochen.

netsh http add sslcert 
   ipport=0.0.0.0:443 
   certhash=28aa1c1bc1bc69b071ecd0d5a0a3fd17f0a4788c 
   appid={9c5923e9-de52-33ea-88de-7ebc8633b9cc} 
   certstorename=MY dsmapperusage=en clientcertnegotiation=dis

netsh http add sslcert 
   ipport=0.0.0.0:443 
    certhash=28aa1c1bc1bc69b071ecd0d5a0a3fd17f0a4788c 
    appid={9c5923e9-de52-33ea-88de-7ebc8633b9cc} 
    certstorename=MY dsmapperusage=en clientcertnegotiation=en

Leider kann man eine Bindung nicht "ändern", sondern muss diese immer "überschreiben" und dabei alle gewünschten Parameter mitgeben

Welcher Tunnelweg ist gerade aktiv ?

Nun wissen Sie, dass sie insgesamt vier mögliche Tunnelszenarien vorfinden können, von denen der Client hoffentlich über einen Zugang arbeiten kann. Einen schnellen Überblick über die aktuelle Verbindung erhalten Sie zwar auch mit IPCONFIG, aber die Liste ist meistens sehr lang und nicht übersichtlich. Besser ist der Aufruf von "netsh interface ipv6 show interface" oder

In diesem Beispiel können Sie sehen, das abgesehen vom Loopback Interface ich per WiFi mit einem LAN verbunden bin und weiterhin das iphttpsinterface aktiv ist. Teredo ist nicht aktiv und 6to4 gar nicht aufgeführt.

Namensauflösung: NRPT - Name Resolution Policy Table

Da bei Direct Access der Clients quasi sowohl "intern" als auch im Internet ist, muss natürlich die Namensauflösung diesen Umstand berücksichtigen. Es ist also nicht hilfreich, wenn der PC weiter nur die "Internet"-DNS-Server befragt. Fragt er aber nur die internen DNS-Server der Firma, dann müssen diese natürlich auch eine externe Auflösung zulassen. Es gibt aber auch den Bedarf eines "geteilten" Namensraums, bei dem der Client z.B. nur interne Namen gegen die internen DNS-Server auflöst aber für alle übrigen Anfragen weiter das Internet nutzt. Windows löst dies mit der Name Resolution Policy Table, welche ebenfalls über eine Gruppenrichtlinie aufgebaut wird.

Unabhängig vom Assistent sollten Sie zusätzliche Einträge addieren, wenn Sie Verkehr zu diesen Seiten "nicht" intern durch leiten wollen.

Split DNS
Die meisten dieser Hinweise sind nur relevant, wenn Sie eine Split-DNS-Konfiguration, .d.h. wenn der DNS-Namensraum im Internet und im Intranet identisch sind. Wenn ihr interner DNS-Namensraum z.B. firma.intern ist, dann benötigen Sie eigentlich gar keine Ausschlüsse.

Hosts Beschreibung
CRL-Verteilpunkte Viele Firmen habe mittlerweile eine private Zertifizierungsstelle (Siehe Firmen CA) und wenn diese Zertifikate auch extern genutzt werden, sollte die URL für die Rückrufliste (Siehe CRL) natürlich auch publiziert werden. Gerade bei "Split-DNS" Umgebungen ist der Pfad extern als auch intern der gleiche. Wenn nun Direct Access eben Zertifikate dieser CA verwendet, dann möchte der Client die Gültigkeit prüfen. Die per Gruppenrichtlinie verteilte NRTP in Direct Access weist den Client aber per Default an, interne Namen intern aufzulösen.
Die CRL kann normalweise auch ohne Direct Access erreicht werden und sollte daher in den Ausnahmen erscheinen
IPHTTPS-Server Wenn der Direct Access Zugang per HTTPS erreichbar machen und der Name dieses Zugangs den gleichen DNS-Suffix wie ihre interne Domäne hat, dann müssen Sie diesen Namen ebenfalls "ausschließen".
Lync Server (Speziell AV-Edge)

Ein besonderer Fall ist der Lync Edge Server. Wenn Sie z.B. die Audio-Daten nicht durch den Direct Access-Tunnel senden wollen, weil die ja auch eine TCP-Verbindung oder sogar ein HTTPS-Tunnel sein kann, dann sollten Sie die Namen der Edge-Server ebenfalls aus dem Tunnel ausschließen, so dass Lync diese Namen über den externen DNS auflöst und er dann auch normal wie ein externer Client mit dem Edge kommuniziert. Dies ist nicht unsicherer aber führt zu einer besseren Audioqualität. Audio/Video muss nicht durch einen per TCP gesicherte Verbindung mit "Retransmits" getunnelt werden. Aber auch andere Dienste von Lync (z.B. Webservices, SIP, WebConf) können eventuell besser am Tunnel vorbei geführt werden, z.B. weil die Server intern nicht über IPv6 erreichbar sind (Routing) und IPv4 er mit UAG möglich ist.

Vergessen Sie auch nicht z.B. "_sipinternaltls._tcp.<sipdomain>, da ansonsten der Client auch von extern den internen Server auflöst, aber solange Lync kein IPv6 unterstützt, ist das nicht hilfreich.

Auch "meet/join/LyncWeb" und andere Dienste, die per IPv6 nicht erreichbar sind.
Veröffentlichte Webseiten Überlegen sie was ein Anwender erwartet, wenn er extern unterwegs ist und eine URL eingibt, die er "normalweise" aus dem Internet auch als extern erreichen möchte. Dies kann auch Webseiten betreffen, die durch Direct Access gar nicht erreichbar sind, weil diese in einer DMZ stehen oder noch kein IPV4 unterstützen. Solche Namen sollten Sie auch in der Ausschlussliste aufführen, damit der Zugriff von Extern weiter möglich ist. Dies trifft natürlich nicht zu, wenn die gerade dem Anwender auch von Unterwegs so arbeiten lassen wollen, als wäre er intern.
OWA, ADFS, RDP-Gateway Auch ohne Direct Access gibt es sichere Zugänge zu bestimmten Diensten. Wenn diese nicht ausgeschlossen werden, dann werden diese auch von "intern" angesprochen. Speziell wenn Direct Access vielleicht nicht geht, weil ein Provider dies blockt, lasse ich diese Dienste auch "außen herum" laufen.
VPN-Server Wenn Clients sich außer per Direct Access auch per Dialup-VPN verbinden können, dann sollten Sie den Namen diese Zugangssystems auch auf die Ausschlussliste setzen
Autodiscover Wer Exchange einsetzt aber OWA und RPC/HTTP an Direct Access vorbei leitet, sollte auch an Autodiscover denken. Autodiscover kommt mit Outlook sowieso nur zum Einsatz, wenn keine Verbindung zum DC möglich ist aber andere Dienste könnten dadurch ebenfalls gestört werden, vor allem wenn Autodiscover nicht per IPv6 erreichbar und kein NAT64 aktiv ist.
UAG Portale Wenn sie UAG einrichten, dann kann damit nicht nur Direct Access "optimiert" und NAT64/DNS64 angeboten werden, sondern sie können damit auch eine Portallösung für Webseiten und interne Dienste bereit stellen. Schade, wenn Sie diese Funktion unterwegs nutzen möchten aber Sie dank "Direct Access" wieder intern sind.

Maximal können hier 1000 Einträge gepflegt werden. Aber diese Grenze sollte bei einem guten Design nicht erreicht werden. Die aktuelle Einstellung bzw. wirksame Einstellung kann per "netsh namespace show policy" oder "netsh namespace show policy" ermittelt werden:

Auch der Befehl "netsh dns show state" liefert Informationen:

Wer etwas tiefer nachschaut findet auch die Einstellungen direkt im Policy-Zeit der Registrierung.

Für Administratoren (die hier etwas ändern dürfen) ist es für die Fehlersuche auch möglich, hier etwas zu ändern. Sie erkennen aber in beiden Fällen, dass die "Infrastrukturserver", die für die interne DNS-Auflösung zuständig sind, hier hinterlegt sind. Es muss also eine DNS-Auflösung über IPV6 möglich sein.

Änderungen werden erst übernommen, wenn die den Dienst "DNS Client (dnscache)" neu starten.

Manchmal kommt anscheinend aber auch DA durcheinander. Hier sieht man eine DNS-Bindung auf meiner Gigabit-Karte, die an der Stelle "falsch" ist. Ich bin zu dem Zeitpunkt extern aber mit Direct Access über einen UAG verbunden.

Hier ist aber zu erkennen, dass auch die internen DNS-Server eingetragen wurden. Auf den ersten Blick scheint das ja gut zu sein, vor allem weil es ja auch erst mal funktioniert. Aber leider umgeht mein Clients damit die NRPT-Tabelle bezüglich internen IPv4-Servern. Hier soll er nicht die DNS-Server direkt fragen, sondern per NRPT die DNS64-Server der UAG, damit dieser intern die IPv4-Adresse suchen und in eine IPv6-Adresse für mich übersetzen kann. Mit dieser falschen Einstellung bekomme ich hingegen die IPv4-Adresse per DNS aufgelöst aber kann diese nicht erreichen.

ISATAP (Intrasite Automatic Tunnel Addressing Protocol)

Dieses Verfahren ist für Direct Access ebenfalls wichtig, zumindest wenn sie in ihrem Intranet noch kein IPV6 durchgängig konfiguriert haben. Ohne Hilfe von NAT64, z.B. in Form eines UAG, kann ein Client nach dem Tunnel durch Direct Access nur IPV6-Systeme ansprechen. ISATAP ist ein Weg, quasi ein durchgängiges IPV6-Netzwerk über IPV4-Verbindungen aufzubauen. Findet Direct Access bei der Installation keine interne IPV6-Infrastruktur, dann konfiguriert DA sich automatisch als ISATAP-Router um zwischen dem IPV6-Netzwerk von Client und DA-Server und dem IPV6-Server intern und DA-Server zu routen. IPV6 fährt dann also Huckepack auf IPV4-Paketen.

Achtung:
Ein Windows 2008 DNS Server hat eine Globale DNS Query Block List, die eine Abfrage auf ISATAP eventuell verhindert.
DNS Server Global Query Block List
hhttp://download.microsoft.com/download/5/3/c/53cdc0bf-6609-4841-a7b9-cae98cc2e4a3/dns_server_global_%20query_block%20list.doc

Meiner Erfahrung nach sollte ISATAP in Firmen nicht eingesetzt werden. Sorgen Sie besser für eine saubere IPv6 Infrastruktur oder setzen Sie Pakete zwischen den Welten gezielt um. Aber überspannen Sie nicht ihre sauber geplanten IPv4-Subnetze durch ein großes ISATAP-IPv6-Netz

Auch wenn DA bzw. UAG sich zum ISATAP-Router aufschwingen, sollten Sie genau überlegen, ob sie dies wollen.

Ich persönlich würde ISATAP in Firmen eher nicht einsetzen wollen. Es mag sein, das ein Internetprovider ihnen so vielleicht schon IPv6 anbietet, obwohl die Zugangsstruktur noch IPv4 ist, aber in Firmen sollten Sie sich eher mit dem korrekten Aufbau einer IPv6 Routingumgebung beschäftigen.

Das erlaubt eine Koexistenz auch wenn das interne Netzwerk noch kein IPV6 durchgängig kann. Allerdings ist ISATAP kein Hilfsmittel, um IPV4-Systeme intern zu erreichen. Der Endpunkt muss immer IPV6 sein. Und da ISATAP von einem gerouteten IPV4-Subnetz ausgeht, ist es nicht für die externe Verbindung mit Clients geeignet.

Wenn Sie ISATAP auf Firewalls blocken wollen, dann können Sie auf der Firewall einfach IP-Protocol 41 blockieren. Damit stoppen Sie aber nicht nur ISATAP sondern auch 6to4 als Tunneltechnologie.br> Wer keine Protokollfilter nutzen kann, kann natürlich den angeblichen ISATAP-Server per IPv4-Routing unerreichbar machen.

Routing

Wer bislang Windows Routing und RAS-Server kannte, der hat sehr oft sich das Leben einfach gemacht und dem Client einfach IP-Adressen aus dem LAN zugewiesen, an dem auch der RRAS-Server angeschlossen war. Der VPN-Zugang war dann eher eine "Bridge". DirectAcces hingegen ist ein echter IPv6-Router und die Clients werden in ein bei der Einrichtung anzugebenen IP-Subnetz angebunden. Jeder Client bekommt in dem folgenden Bild also eine Adresse aus dem FD49:5251:0304:5555::/64 Netzwerk.

Nun muss natürlich ein Server in dem internen Netzwerk FD49:5251:0304:0001::/64 einen Leitweg zu diesem neuen Subnetz finden. In der klassischen IPv4-Welt müssten Sie nun wieder mit "ROUTE ADD" entsprechende Leitwege in ihre Router oder gar Server eintragen. Bei IPv6 können Sie dies auch, aber sie müssen es nicht. Über das "Neighbourhood discovery protocol" (NDP) kann jeder Router seine "Routes" im angeschlossenen Subnetz verkünden. Und das macht auch Direct Access wie ein ""netsh interface ipv6 show route" anzeigt./p>

Die Spalte "Publish" zeigt in der 9ten Zeile, dass das Direct Access-Subnetz über diesen Server "erreichbar" ist.

Fernwartung - von innen nach remote

Einer der großen Vorteile von Direct Access ist die automatische und sofortige Verbindung durch den PC selbst, wenn eine Internetverbindung besteht. Zwar muss in Hotels und anderen öffentlichen Orte durch den Anwender oft erst eine Freischaltung erfolgen aber die Anwender, die mit dem Firmennotebook zuhause am DSL-Anschluss verbunden sind, sind auch "online" mit der Firma verbunden, wenn gar kein Anwender angemeldet ist.

Dennoch kann nach entsprechender Konfiguration ein Zugriff von der Firma auf das entfernte Gerät erfolgen, z.B. um Software zu verteilen, Fehler einzusammeln, Daten zu übertragen, Fernwartung/Unterstützung ausführen etc.) Der Remote Client hat nämlich eine IPv6 Adresse aus dem eigenen Firmennetzwerk und registriert sich im Firmen-DNS. Aber er hat keine IPv4-Adresse, d.h. die Systeme. die sich mit den entfernten Clients verbinden wollen müssen selbst mit IPv6-Adressen versehen sein, um die Clients zu erreichen.

Installation und How-To

Es gibt eine ganze Menge von Anleitungen und Beschreibungen von Microsoft und im Internet, so dass ich hier keine "Schritt für Schritt"-Anleitung mehr publizieren möchte. Hierzu verweise ich auf ein Microsoft Dokument, mit dem es jedem interessierten Admin möglich sein sollte, Direct Access in einem Labor einzurichten.

Test Lab Guide: Demonstrate Direct Access
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=24144

Wer aber einfach nur Direct Access von Windows 2008 R2 installiert und über den Assistent die passenden Gruppenrichtlinien einrichtet, wird vielleicht übersehen, dass er für die Clients noch zusätzliche Firewall-Freischaltungen konfigurieren muss. Für die Windows Firewall geht das natürlich über Gruppenrichtlinien.

Hinweis
Viele Firmen werden vielleicht dem Direct Access-Server einfach zwei offizielle IP-Adressen vergeben und ein Bein in das Internet stellen. Auch wenn Windows 2008R2 eine recht "sichere" Firewall an Bord hat, so sind dennoch auch im "Public-Profil" sehr viele Dienste von extern erreichbar, z.B. auch RDP, DFS, RPC für Remote Management. Hier sollten Sie unbedingt Hand anlegen, wenn Sie keine vorgeschaltete Firewall haben und diese Regel auf "Domain" setzen

Microsoft Direct Access Connectivity Assistant

Lange Zeit war es schwer bis unmöglich für einen Anwender zu erkennen, ob Direct Access funktioniert oder nicht. Er merkte es eigentlich immer nur, wenn etwas nicht funktioniert hat und dann war es für den Helpdesk der Firma auch nicht gerade einfach, die Ursache zu finden. Wenn alle das Problem hatten, dann war es wohl am Server zu suchen aber ansonsten war guter Rat teuer. Dem hat Microsoft mit dem "Microsoft Direct Access Connectivity Assistant" abgeholfen.

Microsoft Direct Access Connectivity Assistant
http://technet.microsoft.com/en-us/library/ff384241.aspx

Diese Programm kann auf dem Client gestartet werden und in der Taskleiste einen Status anzeigen.

Achtung:
Das Programm benötigt zusätzliche Angaben, um, die Funktion von Direct Access auch zu prüfen. Ansonsten sehen Sie die folgende Meldung

Bitte lesen Sie das Deployment Guide und konfigurieren Sie per Gruppenrichtlinien die IP-Adressen und Systeme, die das Tool auch "testen" kann.

Durch die Installation in das Standardverzeichnis "C:\Program Files\Direct Access Connectivity Assistant" wird nicht nur ein Taskicon installiert, sondern auch der Dienst "DCASVC", der dann automatisch gestartet ist:

Die Einstellungen zur Überwachung landen als Gruppenrichtlinie wieder im gewohnten Zweig der Registrierung

Im Unterschlüssel "Probes" sind dann die verschiedenen konfigurierten Prüfungen zu sehen.

Hinweis:
Durch den Einsatz von UAG wird auch diese Konfiguration in der UAG-Direct Access Configuration vorgenommen.

So richtig zufrieden bin ich mit dem Werkzeug nicht, da es zu viele Details nicht anzeigt, z.B. fehlt mir der aktuelle Verbindungstyp, der per NETSH recht einfach ermittelt werden kann. Ich kann einem Benutzer eigentlich nicht zumuten IPCONFIG und NETSH auszuführen und die Ergebnisse einzusammeln.
Zudem würde ich die Tests gerne auch mit externen Patterns erweitern (z.B.: PING auf Default Gateway, NSLOOKUP auf Provider DNS) und die einzelnen Ergebnisse auch anzeigen.

Fehlerquellen und Ursachen

Die Tatsache, dass bei Direct Access viele Komponenten zusammen spielen und in den meisten Fällen irgendwas nicht geht, nutzen wir wieder unser Bild vom Anfang um exemplarisch ein paar Fehlerquellen aufzuzeigen und indirekt damit die Funktionsweise erneut in Erinnerung zu rufen:

Hier folgt die Beschreibung zu den Fehlern:

Fehler Beschreibung
1

Wenn 6to4 und Teredo nicht funktioniert, dann kommt HTTPSTUNNEL zum Einsatz. Und da kann einiges schief gehen:

  • DNS-Auflösung
    Zuerst muss der Client natürlich den konfigurierten DA-Zugriffspunkt auflösen können. Beachten Sie, dass die zweite IP-Adresse des DA-Servers hierfür genutzt wird. Testen Sie die Erreichbarkeit einfach per Browser oder Telnet auf Port 443 des Servers
  • NRPT-Ausschluss
    Normalerweise schließt der Assistent alleine diesen Namen in der NRPT-Tabelle aus. Gerade bei Split-DNS-Umgebungen sollten Sie dies aber auf jeden Fall noch mal prüfen.
  • Zertifikatname
    Das auf dem DA-Server installierte Zertifikat muss natürlich auf den Namen ausgestellt sein. Auch das können Sie von extern mit einem Browser prüfen
  • CRL-Erreichbarkeit
    Und natürlich möchte der Client die passende CRL prüfen. Gerade wenn sie kein öffentliches Zertifikat sondern ein privates Zertifikat verwenden, muss die interne CA korrekt konfiguriert und veröffentlicht sein.
  • HTTP-Proxy
    Der Zugriff vom DA-Client über HTTPS funktioniert auch über Proxies aber nur, wenn diese keine Authentifizierung erfordern. Zugänge wie Hotspots, bei denen Sie per Browser sich anmelden und danach keine weitere Anmeldung kommt, sind erst dann auch nutzbar.
  • Client Zertifikat
    Zuletzt fordert zumindest die Installation von UAG dem Client auch ein Zertifikat ab. Wer eine interne CA mit eigenen Templates verwendet, muss hier auf die oben bei IPHTTTPTUNNEL genannten Punkte aufpassen
2 Der Einsatz von Teredo erfordert eine Erreichbarkeit über UDP-Port 3544. Es gibt nicht wenige Provider und auch DSL-Router (Hier besonders AVM Fritzbox), die diesen Zugriff aus "Sicherheitsgründen" blockieren.
3 Bei einer direkten IPv4 Verbindung, wie sie z.B. mit einer UMTS-Karte im Notebook vorhanden sein kann, kommt 6to4 zum Einsatz. Auch hier blocken diverse Provider gerne die erforderlichen ICMP-Ports. Insbesondere der Rückweg vom DA-Server zum Client wird hier oft verhindert. Sie können das mit NETMON auf dem Server und dem Client schön sehen.
4

Der Direct Access Server muss natürlich aus dem Internet ansprechbar sein. Insbesondere wenn eine Firewall "davor" steht, passiert es immer wieder, dass nicht alle Ports geöffnet sind. Gerade Teredo, welches auch die zweite IP anspricht, wird gerne übersehen. Prüfen Sie die Firewall-Logs auf blockierte Pakete.

  • 6to4
    ICMPv6 Echo in beide Richtungen.
  • Teredo
    Nutzt UDP 3544 auf beide IP-Adresse
  • IPHTTPSTunnel
    Nutzt 443 auf die zweite IP-Adresse
5 Über die Erreichbarkeit des NLS-Servers findet der Client heraus, ob er intern ist oder nicht. Der NLS-Server darf also unter gar keinen Umständen von extern erreichbar sein und muss von intern erreichbar sein. Fällt er aus, haben auch interne Clients Probleme. Ist der externe Client an einem Provider oder Firmen-Lan angeschlossen, die jeden Namen erfolgreich auflösen und auf eine Suchseite umlenken (z.B. Telekom Navigationshilfe oder WLAN-Provider), dann wird Direct Access hoffentlich das fehlerhafte oder fehlende Zertifikat bemerken.
6 Schon bei Fehler 1 habe ich auf die Wichtigkeit der CRL hingewiesen, insbesondere beim Einsatz einer internen CA. DA ist sicher und erfordert daher die CRL-Prüfung. Sie sollten diese Funktion daher eventuell redundant auslegen.
7 Beim Einsatz einer internen CA werden oft eigene Templates angelegt, die z.B. länger als 1 Jahr gültig sind. Stellen Sie sicher, dass die ausgestellten Computerzertifikate auch für DA tauglich sind. Alle Computerzertifikate sollten von der gleichen CA ausgestellt werden.
8 Die komplette Konfiguration von DA erfolgt über Gruppenrichtlinien. Sowohl die Clients als auch die Server erhalten so ihre Einstellungen. Verzögerungen oder Fehler bei der AD-Replikation und dem Abgleich von "SYSLOG" über den Windows FRS können die Umsetzung verzögern. Natürlich muss ein Computer nach der Aufnahme in die Gruppe einmal gestartet werden, um seine neue Mitgliedschaft zu erkennen und die GPO anzuwenden.
9 DA erlaubt nur den Zugriff auf IPv6 Dienste und Server bzw. Server, die über Tunnel (ISATAP) erreichbar sind. Aber auch dann muss IPv6 erst mal sauber funktionieren. Die DAClients sind nämlich im Gegensatz zu RRAS in einem eigenen Subnetz. IPv6 Router Advertising (RA) muss funktionieren oder Sie pflegen statisch Leitwege.
10 Und natürlich darf nicht vergessen werden, dass die DNS-Server, die vom Client für die "interne Domain" verwendet werden, per IPv6 erreichbar sein müssen.
11

Das Zertifikat auf dem Client ist natürlich mit eine der Schlüsselkomponenten einer DA-Konfiguration. Es muss von einer internen CA ausgestellt sein, die richtigen Namen im Subject bzw. SAN haben, damit der DA-Server im Active Directory das Computerobjekt finden kann. Normalerweise laufen Computer-Zertifikate auch nach einem Jahr mit einem 6 Wochen Renew-Windows ab. Das kann durchaus eine Herausforderung für Client sein, die länger unterwegs sind. Ein angepasstes Template kann hier ratsam sein.

Und weil die 11 der einzige Fehler am Client ist sei hier auch noch mal erwähnt, dass Direct Access nur mit Windows 7 Enterprise/Ultimate funktioniert.

Zudem sollte der Dienst "IKE- und AuthIP IPsec-Schlüsselerstellungsmodule" automatisch gestartet werden:

 
12 Sobald Sie weitere interne Subnetze einsetzen und auch dort mit IPv6 arbeiten, muss natürlich der DA-Server die Leitwege in diese Subnetze kennen und auch der Rückweg definiert sein. Hier kommen dann Router Announcements, Default Gateways, DHCPv6 etc zum tragen.

Es gibt noch eine ganze Reihe weiterer Fehler und Problemfälle, die ich aber nicht alle aufführen kann. Mit NETMON, PING, Traceroute und etwas Erfahrung im Troubleshooting mit Eventlog und anderen Werkzeugen sollten sie auch ihre Direct Access-Umgebung zum Laufen bekommen.

Fehlersuche von Hand

Wenn Sie verstanden haben, wie Direct Access "Tickt", dann ist die Fehlersuche relativ schnell möglich. Ich gehe mal von der aus meiner Sicht häufigsten Konfiguration aus:

Auf dem Direct Acces Server gibt es auch die "Monitoring"-Seite, die schnell anzeigt, welche Dienste gerade in Benutzung sind. Sind wie hier alle Dienste "Gelb", dann sind diese bereit aber gerade nicht aktiv. Sobald sich ein Client verbindet, wird die Anzeige grün. Dann lohnt es sich auch über "Details" letztlich den Windows Performance Monitor zu starten, um eine numerische Anzeige zum ausgewählten Protokoll zu erhalten.

Diese Anzeige ist nicht mehr verfügbar, wenn Sie parallel auch UAG installiert haben. Dann müssen Sie die Status-Webseite von UAG nutzen, die dann aber auch anzeigt, welche Benutzer wie angemeldet sind.

DA und IPv4

Microsoft hat Direct Access von Anfang an auf IPv6 ausgelegt. Das bedeutet auch, dass intern natürlich zumindest ein Stück weit IPv6 konfiguriert sein muss (und wenn es nur ein ISATAP-Wölkchen) ist. Auch die DNS-Server müssen per IPv6 erreichbar sein. Es gibt ohne Hilfe einer anderen Komponente keine Erreichbarkeit für für IPv4 Systeme. Das gilt es immer zu bedenken.

Anscheinend greift der DirectAcces-Client hier auch in die Namensauflösung auf dem Client ein. Ich kann zwar per NSLOOKUP selbst gezielt nach Namen suchen und bekommt auch IPv4-Adressen geliefert.

Wenn ich dann aber per PING den gleichen Namen auflöse, dann behauptet der Client, das der Name nicht auflösbar ist.

Ich kann mir das nur so erklären, dass die NRPT erkennt, dass der Name durch den Tunnel aufgelöst werden muss und daher die Anfrage nur nach "AAAA"-Records schaut.

Wer also IPv4 nutzen möchte, muss mit NAT64 arbeiten, d.h. über UAG oder andere Produkte jedem IPv4-Systeme zumindest virtuell eine IPv6-Adresse geben. Der Client spricht dann mit der IPv6-Adresse aber das NAT64-System setzt die Anfragen dann wieder auf IPv4-Adressen um.

In den ersten Jahren wird dies vielleicht noch für das ein oder andere Produkt erforderlich sein die noch kein IPv6 unterstützen, (z.B. auch Exchange UM ohne Lync Edge). Aber mittelfristig wird wohl auch Direct Access alleine ausreichen. Es sei denn Sie benötigen z.B. ab Beispiel UAG auch noch dessen zusätzliche Funktionen zur Veröffentlichung von Websites etc.

DA und Anmeldeskripte

Erinnern sich sie bitte daran, das die "Verbindung zur Firma" bereits mit dem Hochfahren des Computers besteht. Das ist ja grade der immense Vorteil von Direct Access weil z.B. Gruppenrichtlinien und Anmeldeskripte ebenfalls funktionieren. Bei klassischen VPN-Lösungen meldet sich der Anwender ja in der Regel erst am Windows Client (ohne Anbindung an das Firmennetzwerk) an und baut dann erst die VPN-Verbindung auf.

Mit DirectAccess kann ich mich auch an einem PC anmelden, an dem ich vorher noch nie angemeldet war und somit noch keine gecachten Credentials habe. Genau das ist aber auch das Problem, wenn Firmen in Anmeldeskripten umfangreiche Aktionen (z.B.: Kopieren von Vorlagen etc.) machen. Die werden nun nämlich auch ausgeführt, selbst wenn der Client zuhause oder unterwegs ist und die Bandbreite wirklich nicht grenzenlos ist. Aber auch die "Internetleitung" des der Firma muss mit diesem Verkehr umgehen.

Tipp: Optimieren Sie ihre Anmeldeskripte derart, das Sie auf langsame Verbindungen Rücksicht nehmen. Für DirektAccess können Sie die Funktion recht einfach umsetzen, indem Sie den gleichen Test wie DA machen. Prüfen sie den Zugriff auf die DirectAccess- NLS-Webseite. Nur wenn Sie diese erreichen können, sind sie im internen Netzwerk.

Ansonsten könnte es passieren, dass sich ihre Anwender bei der Anmeldung unterwegs über sehr lange Wartezeiten beschweren.

Weitere Links

Keywords:Direct Access VPN IPV6