Direct Access - Voraussetzungen

Clientsupport für DA
Client Software muss DNS-Namen verwenden
Windows Firewall MUSS aktiv sein
Passende Windows Client Version
Hardware
Netzwerkanbindung
Active Directory und Domain Controller
PKI
Network Location Server
Hochverfügbarkeit
Remote Management per IPv6
DA nicht auf Azure

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 DA Da 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 verwenden Aus 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 sein Die 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 Version Sie benötigen Windows 7 Enterprise oder Ultimate oder Windows 2008R2+ oder neuer Direct Access kann nicht mit älteren Clients (Windows Vista, XP, 2003) genutzt werden. Aber auch die neueren Clients müssen die richtige "Edition" haben. Windows 7 Professional oder Home reicht definitiv nicht.
Hardware Windows 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. und wenn Sie doch mal UAG installieren wollen, dann sind 4GB Mindestvoraussetzung.
Netzwerkanbindung Der 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 Controller Die 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-
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. 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 Server DAzu wird intern ein IIS mit SSL-Zertifikat betrieben Die Clients versucht per HTTPS einen konfigurierten Webserver zu erreichen und das Zertifikat zu prüfen.. 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. Diese Funktion kann in kleinen Firmen der DA-Server übernehmen. 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. Oder Sie verpassen z.B. ihrem CoreSwitch im LAN einen HTTPS-Zugang, der von den Clients gefragt werden kann. Wichtig ist, dass diese Adresse hoch verfügbar ist, da ansonsten die internen Clients irrtümlich davon ausgehen, dass sie extern sind. Die aktuelle Einstellung findet sich in der folgenden URL HKLM\Software\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\CorporateConnectivity\DomainLocationDeterminationUrl.
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: Planning Redundancy für a Direct Access Server http://technet.microsoft.com/en-us/library/ee382281(WS.10).aspx
Remote Management per IPv6 Wenn 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 Azure Anfangs konnten Sie den DA-Service sogar in Azure implementieren. Das ist mittlerweile aber nicht mehr möglich DirectAccess No Longer Supported in Microsoft Azure https://support.microsoft.com/en-us/help/2721672/microsoft-server-software-support-for-microsoft-azure-virtual-machines DirectAccess ist nicht mehr gelistet Microsoft server software support for Microsoft Azure virtual machines https://directaccess.richardhicks.com/2016/11/07/directaccess-no-longer-supported-in-microsoft-azure

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	Nein	Nein	Nein
IPv4	IPv6	Nein	Nein	Nein
IPv6	IPv4	Nein	Ja	Ja
IPv6	IPv6	Ja	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.