Direct Access 2012 und Windows 8

Auf der Seite Direct Access habe ich umfangreich die Grundlagen zu Direct Access beschrieben. Mit dem Release von Windows 2012 hat sich bei Direct Access einiges getan. Direct Access liegt nun in der Version 2.0 vor (1.5 war Win2008R2, 1.0 war Win2008) und räumt mit vielen Einschränkungen der vorherigen Versionen auf. Man muss aber auch dazu sagen, dass erst mit Windows 8 auf dem Client viele Dinge richtig elegant funktionieren.

TechEd Australia 2012: Windows 2012 Direct Access
http://channel9.msdn.com/Events/TechEd/Australia/2012/WSV333

Beachten Sie dazu auch Direct Access

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.

2883952 Recommended hotfixes and Updates für Windows Server 2012 Direct Access and Windows Server 2012 R2 Direct Access

Änderungen zu Windows 2008R2

Die wesentlichen Änderungen in Kürze:

  • Tunnel nur über IPHTTPS, Kein Teredo, 6to4 o.ä.
    Microsoft setzt als Tunnel einzig noch auch IP über HTTPS. Alle anderen Transition-Technologien über direkt IP, UDP, TCP-Connections sind entfallen. Anscheinend hat das mehr Probleme verursacht denn gelöst.
  • Single IP-Adresse
    Durch den Wegfall mehrere Tunneltechnologien ist es nicht mehr erforderlich, zwei aufeinanderfolgende öffentliche IP-Adressen bereit zu stellen
  • Keine PKI erforderlich
    Der Zwang für eine eigenen PKI mit Computerzertifikaten entfällt. Zum einen nutzt DA ein "Selbstsigniertes" Zertifikat, welches es über die Gruppenrichtlinie auf die Clients als "Trusted Root" bringt. für die Anmeldung kommt "Kerberos" zum Einsatz, wobei der DA-Server dabei als Kerberos-Proxy agiert , d.h. der externe Client kann über den den DA-Server mit dem KDC auf einem DC sprechen und so ein Ticket für die Verschlüsselung erhalten.
  • Kein Native IPv6 intern
    bei Windows 2008/2008R2 mussten Sie intern zumindest auf der ersten Teilstrecke ein IPv6-Netzwerk aufbauen. Das ist nicht schwer und vielleicht aus anderen Gründen interessant aber mit Windows 2012 DA nicht mehr erforderlich
  • DNS64/NAT64
    Brauchte man bei Windows 2008 DA noch zwingend das relativ teure UAG um auch interne IPv4-Ressourcen zu erreichen, so ist diese Funktion in Windows 2012 DA nun enthalten.
  • Windows 8 DA-Client
    Was in Windows 7 der "Direct Access Connectivity Assistant" war, ist in Windows 8 einfach vorhanden. Direct Access erscheint als Netzwerkverbindung und der Anwender sieht sofort den Status. Allerdings muss "Windows 8 Enterprise" eingesetzt werden
  • Entfernte Einrichtung
    Für die Einrichtung eines Clients unter Windows 2008 DA musste dieser quasi "intern" sein, damit er z.B. ein Computerzertifikat der PKI und die Einstellungen über die Gruppenrichtlinien bekommt. Mit dem Programm "DJOIN" ist es möglich, dass der Administrator eine ASCII-Codierte Binärdatei erstellt, die ein Anwender z.B. per Mail erhält und auf einem nagelneuen Windows 8 PC mit DJOIN aktiviert. Danach ist der Client in der Domäne und per Direct Access eingebunden

Es wurden also ganz viele Punkte verbessert, die bislang Direct Access als schwer umsetzbar behindert haben.

Installation

Wie bei Windows 2012 üblich aktivieren Sie Windows 2012 Direct Access als zusätzliches Feature. Per Default installiert Direct Access noch weitere Features, die für die Funktion erforderlich sind.

So gehört z.B. auch ein IIS in sehr abgespeckter Version dazu, damit die Clients später intern so prüfen können, ob sie intern sind.

Es wird auch automatisch ein 5 Jahre gültiges Selbstzertifikat installiert, was für Direct Access sogar ausreichend ist.

Die Installation der Rollen schaltet auch die entsprechenden Ports auf der Windows 2012 Firewall frei. Zugegeben ist Windows 2012 schon um einiges "sicherer", aber sie sollten dennoch die Konfiguration erst "intern" machen, d.h. da externe Netzwerk noch nicht aufstecken, bis Sie alles "gesichert" haben.

So können Sie auf der externen Karte die Datei/Druckfreigabe und dem Microsoft Client deaktivieren. Auch die Registrierung dieser externen IP-Adresse im DNS kann unterbleiben. Auch bei der Windows Firewall sollten Sie mal vorbei schauen, dass diese z.B. eine aktivierte "Remote Desktop Verwaltung" nicht aus dem Internet erlaubt, wenn Sie dies nicht wollen.

Initial Konfiguration

Nach der Installation der Features fordert Sie Windows schon alleine auf, die erforderlichen Einrichtungsschritte durch zu laufen. Das ist mit wenigen Fenstern auch getan. Zuerst bestimmen Sie den umfang.

Microsoft selbst schlägt die Nutzung beider Optionen vor. Sie können davon aber abweichen.

Bei der Auswahl der Topologie kann der Server selbst mit einem Bein im Internet und ein Beim im internen LAN stehen. Wenn Sie den Service hinter einer Firewall platzieren, dann muss sie eingehende Pakete auf Port 443 per Reverse-NAT zum DA-Server senden.

ACHTUNG:
Wenn Sie den Windows 2012 DA-Server mit einem Bein in das Internet stellen und keinen Filter davor haben, dann ist z.B. der IIS8 als auch eine aktivierter RDP-Zugang auch aus dem Internet erreichbar. passen Sie die Firewall-Einstellungen entsprechend an, wenn Sie diese Dienste nicht von außen erreichen wollen. Auch wenn das System vielleicht sicher ist, könnte per RDP jemand Kennwort ausprobieren und ihr Konto sperren.
Eine Überwachung des Servers und Vorgänge auf dem Server ist natürlich angeraten.

Sie müssen im Fenster dann einfach noch den Namen oder die IP-Adresse des Direct Access-Servers eintragen und im nächten Fenster könnten Sie schon "Fertig" sagen.

TuN SIE DAS BITTE NICHT.
Schauen Sie sich über den kleinen "here"-Link die Einstellungen an. Sie werden diese sicher anpassen wollen!

Der Assistent legt nämlich zwei Gruppenrichtlinien an und bindet die Client Richtlinie an die Gruppe "DomänenComputer".

Vielleicht sollten Sie hier erst mal eine Testgruppe mit Pilotclients vorsehen, ehe alle Clients umgehend für Direct Access konfiguriert werden. Sie können auch die Direct Access-"Prüfpunkte" anpassen, über die der Client ermittelt, ob er im internen Netzwerk ist.

Hinweis: Direct Access legt einen DNS-Eintrag "DirectAcccess-WebProbehost.<domain>" an, den er auch im DNS registriert und per GPO verteilt. Insofern funktioniert DA auch ohne diese Einträge, wenn eine automatische DNS-registrierung möglich ist. 

Da macht der Client weiterhin über einen Testzugriff auf einen Webserver. Ist dieser erreichbar, geht der Client davon aus, dass er "intern" ist. Ansonsten aktiviert er Direct Access zur Firma über IPHTTPS.

Wenn Sie ihre Konfiguration wie gewünscht angepasst haben, dann können Sie mit einem Apply die Einstellungen speicher.

Bedenken Sie, dass gerade Gruppenrichtlinien erst auf die DCs repliziert und von den Clients heruntergeladen und angewendet werden müssen. Wenn Sie mit Mitgliedschaften in Sicherheitsgruppen zur Steuerung der GPO arbeiten, dann greifen neue Mitgliedschaften erst nach einer Neuanmeldung des Benutzers bzw. Neustart des Computers.

DNS Einträge

Gerne vergessen werden zwei DNS-Einträge die aber Microsoft in den Dokumentationen beschreibt

  • Direct Access-webprobehost'
    Should resolve to the internal IPv4 address of the Direct Access server, or to the IPv6 address in an IPv6-only environment.
  • Direct Access-corpconnectivityhost
    Should resolve to the local host (loopback) address. The following host (A) and (AAAA) resource records should be created: a host (A) resource record with value 127.0.0.1, and a host (AAAA) resource record with value constructed out of NAT64 prefix with the last 32 bits as 127.0.0.1

Auch sonst sollten die immer mal einen Blick auf die aktuelle Dokumentation werfen, denn ein Assistent kann nicht alle Fälle berücksichtigen.

Nachkonfiguration

Über die Tools im Servermanager erhalten Sie Zugriff auf die beiden Konfigurationsprogramme:

Der Assistent richtet auch RRAS ein. Mittlerweile kann PPTP als Protokoll als "unsicher" gelten. Dennoch ist es bei Windows 2012 nicht nur dabei, sondern per Default auch aktiv. Hier sollten Sie vielleicht auf PPTP verzichten.

Überwachen

Windows 2008 DA hat darunter gelitten, dass es nicht einen Status für Direkt Access Clients gegeben hat. Erst UAG hat einige Funktionen in Form einer Webseite mitgebracht, die einen Überblick erlauben. Mit Windows 2012 ist der RRAS-Status und Direct Access-Status zusammengewachsen in eine Applikation. Sie erlaubt den Zugriff auf die Konfiguration aber zeigt auch den Status der einzelnen Komponenten an:

Achtung: Dieses Fenster zeigt nicht, an, wenn der Windows Firewall Dienst auf dem externen Interface deaktiviert ist und daher Direct Access nicht funktioniert.

Auch das Fenster "Remote Client Status" ist hilfreich, um die aktuell verbundenen Client auf einen Blick anzuzeigen.

Auswerten

Windows 2012 DA erlaubt auch ein "Reporting". Allerdings ist diese Reporting auch per Default nicht angeschaltet. Sie haben die Wahl, ob die Daten an einen RADIUS-Accounting-Server gesendet oder in der lokalen Windows Datenbank hinterlegt werden. In der Remote Acccess Management Console gibt es dazu links den Punkt Reporting zur Konfiguration und zum Start von Auswertungen:

Hier ist natürlich noch nicht viel los gewesen. Die Installation war ja auch sehr jung.

Windows 8 Client

Auf die beschränkten Konfigurationseinstellungen und DiagnoseMöglichkeiten von Windows 7 möchte ich hier nicht weiter eingehen. Interessanter ist natürlich Windows 8 und wie dort Direct Access "sichtbar" wird. Auf dem Client kann eigentlich nichts selbst konfiguriert werden. Alle Einstellungen bezüglich Direct Access kommen über Gruppenrichtlinien und der Client agiert ohne zutun des Benutzers, indem er bei jeder Änderung des Netzwerkstatus versucht, die konfigurierten "Network Location Server" zu erreichen. Nur wenn der NLS-Service nicht erreicht werden kann, wird eine Direct Access-Verbindung automatisch gestartet. Wie der Client verbunden ist, kann der Anwender auf Windows 8 mittlerweile auch im Netzwerkstatus sehen, wo die Direct Access-Verbindung nun wie eine RAS-Verbindung erscheint

Intern im LAN unterwegs per WiFi am Android Telefon

Und auch die Eigenschaften können nun angezeigt werden

Auf der Kommandozeilen zeigt ein IPConfig, dass der Adapter "IPHTTPSinterface" verbunden ist.

Damit dies funktioniert, muss aber der Dienst "Network Connectivity Assistant (NCASvc)" auf dem Windows 8 Client aktiviert sein. Dieser wird normalerweise automatisch gestartet, wenn der PC in einer Domäne ist.

C:\> sc.exe qtriggerinfo NcaSvc [SC] QueryServiceConfig2 SUCCESS
 
SERVICE_NAME: NcaSvc
 
        START SERVICE
          GROuP POLICY                 : 659fcae6-5bdb-4da9-b1ff-ca2a178d46e0 [MACHINE POLICY PRESENT]
        START SERVICE
          DOMAIN JOINED STATUS         : 1ce20aba-9851-4421-9430-1ddeb766e809 [DOMAIN JOINED]
        STOP SERVICE
          DOMAIN JOINED STATUS         : ddaf516e-58c2-4866-9574-c3b615d42ea1 [NOT DOMAIN JOINED]

Die Beschreibung "Provides Direct Access status notification für uI components" würde nur auf eine Anzeige hinweisen aber wenn er nicht läuft scheint auch Direct Access nicht zu funktionieren.

Interessant kann aber auch die PowerShell auf dem Client sein. Es gibt nämlich einige Einstellungen, die per PowerShell einfach ermittelt werden können:

Get-DAConnectionStatus meldet ihnen auch, wenn der für die Funktion erforderliche "Network Connectivity Assistant service" nicht gestartet sein sollte.

DA Client und VPN

Auch wenn Sie Direct Access konfiguriert haben können Sie weiterhin auch klassische VPN-Verbindungen aufbauen. Immer, wenn Sie eine klassische VPN-Verbindung starten oder sich direkt per LAN verbinden, wird Direct Access beendet. Bei Windows 8.1 sieht das so aus:

Sobald Sie dann die VPN-Verbindung wieder beenden, baut sich Direct Access sofort wieder auf.

Weitere Links