Microsoft hat ein, zumindest für Benutzer, super Feature in Windows 7 eingebaut: DirectAccess. Etwas das, speziell für jeden der viel von unterwegs arbeitet, sehr interessant ist. Die passende Werbeaussage hierzu “Sie sitzen im Flughafen und öffnen Ihr Notebook und sind schon drin” ist natürlich sehr verführerisch. Wo drin? Im Firmennetzwerk und das ohne Benutzeraktion, kein VPN aufbauen, kein Proxy ändern, garnichts. Interessant? Fanden wir auch. Vorweg es gibt zwei Wege wie man DirctAccess implementieren kann:
1. Der einfache Weg (mit UAG und hohen Kosten)
2. Der steinige Weg (mit Windows 2008 R2 Bordmitteln und überschaubaren Kosten)
Wir wählten aus zwei Gründen Variante 2:
Erstens schließt sich im SMB Umfeld „der einfache Weg“ aus Kostengründen aus (das UAG kostet alleine schon über 6000 €) und zweites ist das ein Projekt für die ITHer0s. Also machte sich Jan Kappen daran einen Weg zu erarbeiten, wie man DirectAccess in einer relativ “normalen” IT Umgebung (nämlich unserer) ans Laufen bringen kann.
Das daraus schließlich mehr als 1 Mannwoche werden sollte hatte im Vorfeld keiner gedacht. Trotzdem hat sich das Ergebnis gelohnt. Wir können nun unterwegs unsere Notebooks aufklappen und losarbeiten. Etwas das man, wenn man es erst mal benutzt hat, nicht mehr missen möchte. Aber lesen Sie selbst die Anleitung von Jan, in der er aufzeigt, wie man DirectAccess in einer normalen Umgebung ohne UAG implementiert.
Die Grundvoraussetzungen
Da wir soeben erfolgreich Direct Access bei uns implementiert habe, möchten wir das ganze natürlich hier auch dokumentieren bzw. für andere zur Verfügung stellen, die sich ebenfalls mit dem Thema beschäftigen. Die komplette Einrichtung hat sich mehrere Tage hingezogen, inkl. Testumgebung, Fehlersuche und Nachstellen in der Testumgebung.
Hilfreich waren uns bei der Einrichtung die folgenden Dokumente:
Test Lab Guide: Demonstrate DirectAccess
DirectAccess Design, Deployment, and Troubleshooting Guides
Der oben verlinkte Test Lab Guide hat bei uns sofort nach der Einführung anstandslos funktioniert, allerdings gab es während der Installation in unserer Umgebung das eine oder andere Problem bzw. diverse Voraussetzungen, die zwar erfüllt sein müssen, in dem Test Lab Guide aber nicht erwähnt wurden. Die komplette Installation ist ein ziemlich großes Projekt, was nicht mal eben an einem Nachmittag durchgeführt werden kann und bei dem einige Überlegungen vor Beginn der Installation anstehen. Aus diesem Grund haben wir uns dazu entschieden, die komplette Dokumentation in mehrere Teile zu gliedern. In diesem ersten Teil geht es um die Grundvoraussetzungen, die für eine erfolgreiche Implementierung erforderlich sind.
Die einzelnen Funktionen und die Anzahl der Server
Wer sich das oben erwähnte Test Lab Guide angeschaut hat (und das empfehlen wir ausdrücklich!) wird feststellen, das Microsoft sechs Systeme benötigt, vier Windows Server 2008 R2 und zwei Windows 7 Enterprise. Ein Windows 7 fällt in einer “normalen” Umgebung weg, da hier ausschließlich ein Router simuliert wird, und solch ein Gerät in der Regel an nahezu jedem Internet-Anschluss für den Aufbau der Internetverbindung verantwortlich ist. Das zweite Windows 7 ist der Direct Access Client, hier ist nur wichtig, das es sich um eine Enterprise- oder Ultimate-Version handelt. Ob 32 Bit oder 64 Bit ist egal.
Bei den Servern wird ein Domänencontroller benötigt, der gleichzeitig DNS-Server (für die Domäne) und DHCP-Server ist, zusätzlich wird er für eine PKI benötigt und hat die Rolle “Active Directory-Zertifikatdienste” aktiviert. Als zweites System wird der Direct Access-Server benötigt, ebenfalls zwingend ein Windows Server 2008 R2. Der dritte Server im Test Lab fungiert als Dateiserver und als Network Location Server. Server Nummer Vier wird genutzt, um einen externen DNS-Server zu simulieren. Diese Aufgabe wird in den meisten Fällen vom Internet-Provider übernommen, daher ist diese Maschine nur in der Demo-Umgebung nötig und fällt in einem Live-Szenario raus (nur der Server als Hardware/Lizenz, nicht die Funktionalität).
Nun die entscheidende Frage: Wie viele Server brauche ich für mein Projekt?
Wir haben für mein Projekt zwei neue Systeme benötigt, wären zur Not aber auch mit einem ausgekommen. Hier die Auflistung der Server inkl. Rollenverteilung:
Server1:
Windows Server 2008 R2, Domänencontroller, DNS-Server, DHCP-Server, Zertifikatdienste
Server2:
Windows Server 2008 R2, Direct Access-Feature
Server3:
Windows Server 2008 R2, Network Location Server, PKI Sperrlisten-Verteilungspunkt
Server4:
Debian Linux, externer DNS-Server
Server5:
Windows Server 2008 R2, File-Server
Server2 und Server3 haben wir im Zuge des Projekts neu installiert, die restlichen Server waren schon vorhanden und wurden nur angepasst.
Wichtige Dinge, die man vor Beginn der Installation wissen sollte
- Die interne Domäne und die externe Domain müssen unterschiedlich sein. Es ist nicht möglich Direct Access erfolgreich einzurichten, wenn sowohl Domäne als auch Domain gleich sind. Was allerdings funktioniert ist, wenn die Domain contoso.com ist und die Domäne corp.contoso.com. Contoso.com als Domain und Domäne hingegen funktioniert nicht.
- Es werden zwei aufeinanderfolgende, öffentliche IPs benötigt. Adressen, die genatet werden, funktionieren nicht!
- Bevor man automatisch Computer-Zertifikate ausrollt oder sonstige Zertifikate erstellt sollte man sicher gehen, das die PKI so funktioniert wie sie soll und das nichts mehr verändert werden muss. Falls etwas geändert werden muss (In meinem Fall die URL des Sperrlisten-Verteilungspunktes), müssen die Zertifikate teilweise oder komplett neu erstellt werden, da die Änderungen nicht in den vorher ausgestellten Zertifikaten enthalten sind und es somit zu Fehlern kommen kann.
- Ob ein Gerät sich per Direct Access mit dem Firmennetz verbindet oder nicht wird durch eine Gruppe in der Active Directory festgelegt. Wir empfehlen in diese Gruppe zuerst ein Gerät zu stellen, was nicht gerade dem Geschäftsführer oder einer anderen wichtigen Person gehört. Wir hatten durch eine Fehlkonfiguration das Problem, das mein Notebook (als einziges Mitglied der Gruppe) die Direct Access-GPO gezogen hatte, und danach keine Kommunikation mehr zum Domänencontroller aufbauen konnte, und somit auch keine Änderungen mehr mitbekommen hat. Das Problem ließ sich nur lösen, indem ich mein Notebook aus der Domäne entfernt habe und neu hinzugefügt habe.
- Es ist nur möglich eine Verbindung zu Maschinen im Firmennetzwerk aufzubauen, die per IPv6 kommunizieren können. Bei Windows Server 2003 kann man IPv6 nachinstallieren, Windows 2000 ist zu alt. Man kann Programme von Drittherstellern installieren die diese Funktion nachrüsten, aber möchte man wirklich sein mittlerweile zehn Jahre alten Server per Direct Access seinem Windows 7 verfügbar machen?
- Der “Forest Functional Level” muss nicht zwingend “Windows Server 2008 R2” sein wie in dem Guide beschrieben, das schließt Domänencontroller mit Systemen älter als Windows Server 2008 R2 nicht aus, Bedingung ist nur mindestens einen Windows Server 2008 R2 als Domänencontroller und als DNS-Server
- Es wird kein SSL-Zertifikat benötigt, was z.B. von GoDaddy oder VeriSign gegengezeichnet wurde. Es reichen die Zertifikate aus, die von der eigenen PKI erstellt werden.
Der Domänencontroller
Nachdem wir nun in Teil 1 besprochen haben welche Anforderungen an die Umgebung und die Systeme bestehen, fangen wir nun mit der Installation bzw. Einrichtung des Domänencontrollers an.
Das System muss ein Windows Server 2008 R2 sein, und es müssen die folgenden Rollen aktiviert werden:
- Active Directory-Domänendienste
- Active Directory-Zertifikatdienste
- DHCP-Server
- DNS-Server
Wie man in dem Screenshot sehen kann ist auf unserem System noch die Rolle “Webserver (IIS)” aktiviert, dies ist zur Anforderung von Zertifikaten per Web-Browser.
Active Directory-Domänendienste
Diese Rolle wird automatisch installiert, wenn man “dcpromo” ausführt, um den Server zum Domänen-Controller hochzustufen. Wenn man die Domäne neu aufsetzt, kann man während des Wizards ruhig “Windows Server 2008 R2” als “Forest Functional Level” nehmen, bei einer vorhandenen Active Directory muss der Level nicht auf “Windows Server 2008 R2” erhöht werden. Wie schon in Teil 1 erwähnt, darf der Name der Domäne nicht gleich dem Namen der Internet-Domain sein. Wenn Domain und Domäne gleich sind, funktioniert Direct Access nicht. Rachfahl.de und rachfahl.loc hingegen sind kein Problem, ebenso (wie in dem Step by Step-Guide beschrieben) contoso.com und corp.contoso.com.
Sonst ist weiter bei der Installation nichts zu beachten, alle wichtigen Änderungen bzw. Erweiterungen werden im Laufe der Implementierung durchgeführt und dann dokumentiert.
Active Directory-Zertifikatdienste
Diese Rolle muss installiert werden, damit die benötigten Zertifikate ausgestellt werden können. Während der Installation werden die folgenden Dinge angefragt (Screenshots von Maschine aus dem Step by Step-Guide):
DHCP-Server
Bei der Installation des DHCP-Servers ist eigentlich nichts weiter zu beachten, außer das man bei der Nachfrage zur “Konfiguration des statusfreien DHCPv6-Modus” die Option “Statusfreien DHCPv6-Modus für diesen Server deaktivieren” auswählt.
DNS-Server
Schon während der Hochstufung des Servers zum Domänencontroller wurde angeboten, die DNS-Rolle mit zu installieren. Dies sollte gemacht werden, da man sonst nach der Hochstufung erneut Hand anlegt und die DNS-Server-Rolle installiert. Wenn es der erste Domänencontroller ist, muss man die DNS-Server-Rolle eh installieren. Weiter müssen keine Einstellungen gemacht werden, es müssen lediglich Einträge erstellt werden. Hierzu allerdings später mehr.
Anlegen einer Sicherheitsgruppe in der Active Directory
Wir legen nun in der Active Directory eine neue Sicherheitsgruppe an, in die später die PC-Konten kommen, die eine Verbindung per Direct Access aufbauen sollen. Ich habe die Gruppe “DirectAccess_Clients” genannt, das ist aber jedem selber überlassen. Wichtig ist, das die folgenden Einstellungen verwendet werden:
Erstellen einer eigenen Zertifikats-Vorlage
Als nächstes erstellen wir eine neue Zertifikats-Vorlage, die wir später benutzen, um Zertifikate für z.B. den “Network Location Server” anzufordern. Hierzu öffnen wir uns den Server-Manager, erweitern den Punkt “Active Directory-Zertifikatdienste” und gehen zum Punkt “Zertifikatvorlagen”. Dort werden alle vorhandenen Vorlagen gelistet, ziemlich weit unten finden wir die Vorlage “Webserver”.
Ein Rechtsklick auf “Webserver” und “Doppelte Vorlage” erzeugt eine Kopie des Zertifikats. Hier in Screenshots die Einstellungen der neu erzeugten Zertifikatvorlage:
Wichtig ist hier die Einstellung “Exportieren von privatem Schlüssel zulassen”!
Unter “Sicherheit” muss in den Berechtigungen der “Authentifizierten Benutzer” das Recht “Registrieren” hinzugefügt werden, weiterhin muss die Gruppe “Domänencomputer” hinzugefügt werden, die ebenfalls die Rechte “Lesen” und “Registrieren” erhält.
Nach Erstellung der Vorlage muss man diese noch in die Vorlagen der Zertifizierungsstelle hinzufügen, dies macht man wie folgt:
In dem darauf erscheinenden Fenster wählt man die soeben erstellte Vorlage aus (In meinem Fall “Web Server 2008 (DirectAccess)”), und schon ist die Vorlage verfügbar.
Erstellen einer Firewall-Regel um ICMPv6 zu erlauben
Direct Access kann nur funktionieren, wenn sich bestimmte Systeme untereinander über IPv6 anpingen können. Aus diesem Grund erstellen wir nun eine Firewall-Regel, die per Gruppenrichtlinie ausgerollt wird und auf allen Systemen die nötigen Einstellungen setzt. Auf dem Domänencontroller öffnen wir die Gruppenrichtlinienverwaltung, und erstellen ein neues Gruppenrichtlinienobjekt (Ich habe es “ICMPv6-Firewall-Policy” genannt, wie man es nennt ist egal). Wir navigieren zu
Computerkonfiguration / Richtlinien / Windows-Einstellungen / Sicherheitseinstellungen / Windows-Firewall mit erweiterter Sicherheit / Windows-Firewall mit erweiterter Sicherheit
Unter “Eingehende Regeln” legen wir eine Regel “Inbound ICMPv6 Echo Requests” an. Die Einstellungen sind wie hier gezeigt:
Unter ausgehende Regeln legen wir ebenfalls eine Regel anhand der oben gezeigten Einstellungen an, der einzige Unterschied ist der, das wir die Regel nicht “Inbound ICMPv6 Echo Requests” nennen, sondern “Outbound ICMPv6 Echo Requests”.
Nach der Erstellung der GPO darf man natürlich nicht vergessen, diese auch mit der Domäne zu verknüpfen!
Entfernen von ISATAP aus der DNS global block list
Als nächstes muss man den ISATAP-Eintrag aus der “DNS global block list” entfernen. Hierzu ruft man sich eine Kommandozeile als Administrator auf (Im weiteren Verlauf “administratives cmd-Fenster”)
In der Kommandozeile rufen wir den folgenden Befehl aus
dnscmd /config /globalqueryblocklist wpad
Dieser Befehl bewirkt, das in der Registry unter
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DNS\Parameters
in dem REG_MULTI_SZ-Wert “GlobalQueryBlockList” nur noch der Wert “wpad” steht, und nicht mehr “wpad” und “isatap”.
Der Direct Access-Server
Grundeinrichtung:
Nachdem wir nun unseren Domänencontroller weitestgehend eingerichtet bzw. angepasst haben, kommen wir nun zur Einrichtung des Direct Access-Servers. Geplant ist, das auf dem Direct Access-Server zusätzlich noch der IIS-Server installiert wird, um dort die Sperrlisten der CA abzulegen bzw. abzurufen.
Nach der Grundinstallation des Windows Server 2008 R2 müssen auf dem einen Netzwerk-Interface eine interne Adresse vergeben werden, und auf dem zweiten Interface müssen die beiden öffentlichen Adressen eingerichtet werden, die für den Betrieb von Direct Access benötigt werden. An dieser Stelle empfiehlt es sich, die beiden Interface umzubenennen in “intern” und “extern”, da man die Netzwerkkarten später in der Konfiguration auswählen muss und nur den Namen sieht.
Wichtig ist, das man bei der internen Netzwerkkarte in den erweiterten TCP/IPv4-Einstellungen unter DNS bei “DNS-Suffix für diese Verbindung” den internen Domänen-Namen einträgt, da sonst später das Direct Access-Setup diesen Punkt anmäkelt.
Nach dem einstellen der Netzwerkadressen muss der Server in die Domäne aufgenommen werden, und nach einem Reboot kann im “Server-Manager” unter “Rollen” der “Webserver (IIS)” installiert werden.
Einrichten eines webbasierten Sperrlistenverteilungspunktes
Im Internetinformationsdienste-Manager navigieren wir nun unter “Sites” zur “Default Web Site”, klicken mit rechts darauf und wählen “Virtuelles Verzeichnis hinzufügen…”
Im darauf erscheinenden Fenster wählen wir unter “Alias” den Alias-Namen aus, in unserem Fall “CRLD”. Bei “Physikalischer Pfad:” muss der Pfad auf der Festplatte eingetragen werden, in dem die Dateien gespeichert werden. Dies ist auch der Pfad, der gleich freigegeben wird, damit der CA-Server dort seine Dateien speichern kann (Mehr dazu unter “Konfiguration der CA”).
In den Eigenschaften des Verzeichnises “CRLD” im IIS-Manager wählen wir “Verzeichnis durchsuchen” und aktivieren die Funktion rechts in der Aktions-Leiste.
Im Konfigurations-Editor unter “system.webServer/security/requestFiltering” setzen wir die Option “allowDoubleEscaping” auf “True”
Erstellen der Windows-Freigabe
Als nächsten Schritt müssen wir nun den soeben angelegten Ordner freigeben. Hierzu gehen wir zu dem Ordner, wählen “Eigenschaften”, “Freigabe” und dann “Erweiterte Freigabe”:
Konfiguration der CA
Vorbemerkung zur Sperrlistenverteilungspunkt-Konfiguration
Wir kommen nun zu einem sehr wichtigen Punkt. Wir richten nun einen Sperrlistenverteilungspunkt ein. Unsere CA pflegt eine Sperrliste, in der alle Zertifikate aufgeführt werden, die gesperrt sind. Diese Datei wird von dem Server, auf dem die CA läuft, in eine UNC-Freigabe kopiert, und kann dann per http abgerufen werden. Wenn man an der Konfiguration der CA (wie in diesem Fall) etwas ändert, kann es sein das zuvor ausgestellte Zertifikate (bzw. die Kommunikation mit Hilfe dieser Zertifikate) nicht mehr funktionieren. In unserem Fall mussten wir die Zertifikate für unsere RDS-Farm neu erstellen, da die “alten” Zertifikate noch nicht den Sperrlistenverteilungspunkt eingetragen hatten, und dadurch ein Verbindungsaufbau nicht erfolgreich war.
Da das mehrfache Erstellen von Zertifikaten ziemlich zeitaufwendig ist, sollte man sich vor der Einrichtung einer CA bzw. dem Sperrlistenverteilungspunkt genaue Überlegungen machen, welche Einstellungen man tätigt, um eventuelle Mehrarbeit zu vermeiden.
DNS-Einträge erstellen
Als ersten Schritt muss man einen DNS-Eintrag für den Webserver eintragen (lassen), auf dem die Sperrlisten-Dateien liegen (in unserem Fall der Direct Access-Server). Dieser Eintrag wird in der Regel bei dem zuständigen Provider gemacht, oder wenn man die Möglichkeit hat, kann man ihn auch selbst eintragen. Da wir für unsere DNS-Auflösung selbst zuständig sind, kann ich die Eintragung selbst durchführen. Dazu muss ein Name gewählt werden, wir halten uns da an den Step by Step-Guide und verwenden “crl” als Hostname.
Neben dem Eintrag “crl” benötigen wir ebenfalls noch einen Hostnamen, mit dem die Verbindung zum Direct Access-Server aufgebaut wird. Diesen haben wir direkt mit eingetragen, in unserem Fall war es “vdirectaccess”. Diesen Namen merken, wir benötigen ihn später noch.
Wichtig: Als IP-Adresse für den Hostname muss die erste der beiden öffentlichen Adressen eingetragen werden, nicht die zweite und nicht beide!!!
Sperrlistenverteilungspunkt einrichten
Auf dem Server, auf dem die Zertifizierungsstelle (CA) installiert ist, öffnen wir nun die Konsole “Zertifizierungsstelle” unter “Start” => “Verwaltung”.
Im Reiter “Erweiterungen” im Punkt “Sperrlisten-Verteilungspunkt” fügen wir nun zwei Einträge hinzu, und zwar einmal die Verbindung per http (extern) und einmal per UNC-Freigabe (intern).
Externe Verbindung:
Nach einem Klick auf “Hinzufügen…” tragen wir unter “Ort” die Adresse des Webservers ein, ein unserem Fall
http://crl.contoso.com/crld/
.crl
Wichtig: Man darf hinter den Variablen nicht das “.crl” vergessen, sonst werden Dateien ohne Endung angelegt!
Nach einem Klick auf “OK” wählen wir die folgenden Optionen
Interne Verbindung:
Wir klicken erneut auf “Hinzufügen…” und tragen nun die Adresse der Freigabe ein, die wir im vorherigen Schritt erstellt haben:
\\servername\crldist$\
.crl
Nach dem Klick auf “OK” wählen wir die folgenden Optionen
Wichtig hier ist, das wir nicht die Optionen
“In Sperrlisten einbeziehen. Wird z. Suche von Deltasperrlisten benötigt”
und
“In CDP-Erweiterung des ausgestellten Zertifikats einbeziehen”
wählen, da die Freigabe sonst auch von dem Client abgefragt wird, was wir nicht wollen!
Nach einem Klick auf “OK” möchte der Dienst der CA neustarten, wir bejahen die Anfrage und warten bis der Dienst neugestartet wurde.
Überprüfung der Veröffentlichung
Wenn wir nun auf dem Server, auf dem die CA installiert ist, die Freigabe öffnen, dürften wir noch keine Dateien sehen. Wenn man nun in der Zertifizierungsstelle-Konsole unterhalb der CA einen Rechtsklick auf “Gesperrte Zertifikate” macht und den Punkt “Veröffentlichen” im Menüpunkt “Alle Aufgaben” wählt, veröffentlicht die CA ihre Sperrliste und ihre Deltasperrliste an dem soeben angegeben Ordner. Dort liegen nun zwei Dateien, eine heißt so wie die CA, und die andere hat noch ein “+” im Namen.
Konfiguration des Auto-Enrollment der Computer-Zertifikate
Für den nächsten Punkt müssen wir auf einen Domänen-Controller. Dort gehen wir in die “Gruppenrichtlinienverwaltung” und erstellen ein neues Gruppenrichtlinienobjekt, in meinem Fall heißt es “Autoenrollment”.
Unter
“Computerkonfiguration / Richtlinien / Windows-Einstellungen / Sicherheitseinstellungen / Richtlinien für öffentliche Schlüssel”
stellen wir in dem Objekt “Zertifikatsdienstclient – Automatische Registrierung” die folgenden Einstellungen ein:
Als zweiten Punkt müssen wir unter “Einstellungen der automatischen Zertifikatsanforderung” noch die “Computer-Zertifikats-Vorlage” hinzufügen:
Wichtig: Auch hier bitte nicht vergessen, die soeben erzeugte GPO mit der Domäne zu verknüpfen!
Anfordern eines weiteren Zertifikates für den Direct Access-Server
Auf dem Direct Access-Server öffnen wir eine mmc, fügen “Zertifikate” als Snap-In hinzu (Zertifikate für “Computerkonto”) und navigieren zu “Eigene Zertifikate” => “Zertifikate”.
Dort wählen wir im Kontextmenü unter “Alle Aufgaben” => “Neues Zertifikat anfordern…”. Unter “Zertifikate anfordern” in dem Wizard wählen wir die Vorlage aus, die wir im Teil “Der Domänencontroller” erstellt haben, in meinem Fall “Web Server 2008 (DirectAccess)”.
Wie in der Warnung schon ersichtlich, werden zusätzliche Informationen benötigt. Mit einem Klick auf die blaue Schrift gelangt man in das folgende Fenster:
Die Einstellungen bei “Typ” müssen “Allgemeiner Name” und “DNS” sein, als Wert muss hier jeweils der Name des Direct Access-Servers eingetragen werden (Den Namen haben wir weiter oben in unserem DNS-Server eingetragen!). Außer diesen beiden Eintragungen muss hier nichts weiter gemacht werden, nach einem Klick auf “OK” kann man den Wizard weiter durchklicken, und am Ende hat man ein neues Zertifikat, ausgestellt auf den Namen, der aus dem Internet erreichbar ist.
Tipp: Nachdem das Zertifikat erstellt wurde, sollte man in den Eigenschaften des Zertifikats unter “Anzeigename” etwas eintragen, Vorschlag von Microsoft ist “IP-HTTPS Certificate”. Dies dient zur besseren Orientierung, während der Konfiguration des IIS auf dem NLP-Servers wird man sehen, wozu dieser Eintrag hilfreich ist :)
Der Network Location Server
Als nächsten Schritt richten wir einen “Network Location Server” (NLS) ein. Dieser Server spielt bei der Überprüfung des Clients eine Rolle, da diese ihren Standort (intern oder extern) danach bestimmen, ob sie den NLS-Server erreichen können oder nicht. Aus diesem Grunde ist es wichtig, das der Server per HTTPS nur von intern erreichbar ist.
Für die Funktionalität muss kein eigener Server aufgesetzt werden, es wird lediglich ein System benötigt, welches Mitglied der Domäne ist, und auf dem die IIS-Rolle entweder schon aktiv ist, oder auf dem sie aktiviert werden kann.
Auf dem Server öffnen wir uns in einer mmc das Snap-In “Zertifikate” und erstellen unter “Eigene Zertifikate” wie schon auf dem Direct Access-Server ein eigenes Zertifikat. Als Vorlage benutzen wir ebenfalls “Web Server 2008 (DirectAccess)”.
Auch hier müssen wir weitere Informationen hinterlegen, die wir durch einen Klick auf die blaue Schrift eintragen können. Die Einstellungen hier sehen wie folgt aus:
Wichtig: Die hier hinterlegte Adresse muss der interne Domänenname sein, NICHT ein externer Name. In dem Step-by-Step Guide ist “corp.contoso.com” die Domäne, “contoso.com” die Internet-Domain!
Als nächstes wechseln wir in den IIS-Manager und wählen unter “Default Web Site” (Oder da, wo die https-Bindung hinzugefügt werden soll) “Bindungen hinzufügen”.
Im nächsten Menü wählen wir “Hinzufügen…”, wählen “https” aus und unten das vorhin erzeugte Zertifikat.
Später in der Konfiguration des Direct Access werden wir nach der Adresse des NLS-Servers gefragt. Wenn man diese Seite aufruft muss der Code, den der Server zurückgibt, der Statuscode 200 sein. Es darf keine Abfrage von Benutzerdaten oder ähnlichem kommen, d.h man kann hier nicht die interne Adresse des “Outlook Web Access” oder ähnlichen Seiten nehmen…
Falls man keinen Fileserver hat oder diesen während der Einrichtung noch nicht verändern möchte, kann man auf diesem Server noch eine Datei-Freigabe erstellen, um später den Zugriff von einem Client aus auf diese Freigabe zu testen. Hierzu legt man einfach einen Ordner an (im Guide wird der Ordner “Files” genannt). Dann legt man eine beliebige Textdatei in diesem Ordner an und gibt den Ordner anschließend frei. Zum Test kann “Jeder” Lesezugriff haben, man kann die Freigabe-Rechte aber auch einschränken, so das nur die Admin-Gruppe Zugriff hat oder nur der Benutzer, mit dem das Direct Access später getestet wird.
Die Einrichtung des Direct Access
Nach all den Vorbereitungen sind wir nun an dem Punkt angelangt, an dem wir mit der Konfiguration bzw. der Einrichtung des Direct Access beginnen können. Als erstes müssen wir im Server-Manager unter “Features” das Feature “DirectAccess-Verwaltungskonsole” aktivieren.
Zusätzlich wird noch automatisch das Feature “Gruppenrichtlinienverwaltung” installiert. Weiter braucht man nichts zu bestätigen oder einzutragen, man kann den Wizard einfach durchklicken. Ein Neustart wird nicht benötigt, nach der Installation kann man direkt mit der Einrichtung starten.
Nach dem Aufruf der Konsole sollte einen das folgende Bild erwarten:
Falls dies nicht der Fall ist, wird einem der Grund für den Fehler angezeigt. Die Fehler die wir bisher hatten waren:
- In den Netzwerkeinstellungen war unter “Erweitert” => “DNS” kein DNS-Suffix eingetragen
- Die GPO mit der Firewallregel war noch nicht aktiv und der Wizard hat erkannt, das ICMPv6 noch nicht in den Ausnahmen war
- Die externe Netzwerkkarte hatte keine DNS-Server eingetragen (Diesen Fehler hatte ich nur in einer frühen Phase unserer Umgebung, das die externe Karte keine DNS-Server hat ist an sich in Ordnung, wenn die Auflösung über das interne Interface gemacht wird)
Schritt 1:
Nach einem Klick auf “Bearbeiten” wählen wir die Gruppe mit den Computerkonten aus, die wir im Teil “Der Domänencontroller” angelegt haben:
Schritt 2:
In Schritt 2 werden die Schnittstellen des Systems eingetragen und die benötigten Zertifikate hinterlegt.
An dieser Stelle erweist sich die erwähnte Benamung der Netzwerkschnittstellen (“extern” und “intern”) als Vorteil, da man hier nur den Namen der Schnittstelle in der Auswahlliste sieht, nicht die dazugehörigen Adressen. Wenn alle Einstellungen für den Wizard korrekt sind, erscheint unten nur ein Info-Feld, keine Warn- oder Fehlermeldung. Nach einem Klick auf weiter muss man die Zertifikate auswählen, die benötigt werden.
Das obere Zertifikat ist das der CA, das untere ist das Zertifikat, welches wir im Teil “Konfiguration der CA” angefordert haben (vdirectaccess.contoso.com war der Beispiel-Name). Nach einem Klick auf “Fertig stellen” endet der Wizard für Teil 2.
Schritt 3:
Hier wird als erstes die Adresse des Network Location Server angegeben
Durch einen Klick auf “Überprüfen” stellt man die Funktionalität sicher. Zur Info: Dies ist die Adresse, die wir im Teil „Der Network Location Server“ definiert haben.
Nach einem Klick auf “Weiter” wird automatisch der Namenssuffix der Domain sowie der Name des NLS-Servers (ohne IP eines DNS-Servers) eingetragen. All die Namen, die hier eingetragen werden ohne IPv6-Adresse eines DNS-Servers, werden grundsätzlich nicht über die Direct Access-Verbindung aufgerufen. Da durch den NLS-Server überprüft wird ob man sich intern oder extern befindet, steht dieser hier mit in der Liste ohne IPv6-Adresse eines DNS-Servers um sicherzustellen, das der Name nur aufgelöst werden kann, wenn man sich im Firmennetzwerk befindet.
Weiter unten in dem Fenster kann man die Optionen für die Namensauflösung eingeben, die mittlere Option sollte in den meisten Fällen die richtige sein.
Nach einem Klick auf “Weiter” kann man die IP-Adressen der Systeme eingeben, die aus dem Firmennetzwerk heraus eine Verbindung zu den Direct Access-Clients aufbauen dürfen. Typischer Anwendungsfall wäre z.B. die Verteilung von Updates über einen WSUS-Server.
Nach einem Klick auf “Fertig stellen” ist Schritt 3 auch schon beendet.
Schritt 4:
Im letzten Schritt kann man eine zusätzliche End-to-End-Authentifizierung einstellen.
Dies wird in unserem Fall allerdings nicht benötigt, und nach einem Klick auf “Fertig stellen” sind wir eigentlich schon komplett durch mit der Konfiguration des Direct Access.
Wenn man nun in der Konsole unten rechts auf “Fertig” klickt, bekommt man eine Zusammenfassung der Einstellungen, und nach einem Klick auf “Übernehmen” werden die GPOs erstellt.
Wenn man sich auf einem Domänencontroller die Gruppenrichtlinienverwaltung anschaut, sieht man zwei neue GPOs, die mit der Domäne verknüpft worden sind.
Der Client und ein bisschen Troubleshooting
Wenn die Verbindung per Direct Access sich nicht aufbauen lässt oder wenn es anderen Probleme gibt, hier der Link zu dem offiziellen Troubleshooting-Guide von Microsoft:
DirectAccess Design, Deployment, and Troubleshooting Guides
Nachdem wir nun alle benötigten Einstellungen getätigt haben, ist es Zeit sich um den Client zu kümmern. Als ersten Schritt müssen wir das Computerkonto des Gerätes zu der Sicherheitsgruppe “DirectAccess_Clients” hinzufügen.
Nun machen wir auf dem Client in einem administrativem cmd-Fenster ein “gpupdate /force”. Nach einer Ab- und erneuten Anmeldung überprüfen wir die Einstellungen, ebenfalls in einem administrativen cmd-Fenster, mit “gpresult /R”:
Wie man in dem Screenshot sieht, ist mein Computer Mitglied der Gruppe “Direct Access” und auf ihn wird eine der beiden Direct Access-GPOs angewendet. Das nur eine angewendet wird ist korrekt, die andere ist exclusiv für den Direct Access-Server.
Der Verbindungsaufbau
Wenn man sein Notebook nun zuhause oder wo auch immer an einen DSL-Anschluss hängt, sollten die Netzwerkeinstellungen wie folgt aussehen:
Wir sehen hier, das das Interface “Teredo Tunneling Pseudo-Interface” eine IPv6-Adresse hat, die mit 2001 anfängt. Man kann sich die Einstellungen auf dem Client auch mit den folgenden Befehlen anschauen:
netsh name show pol
netsh name show eff
Ein Ping auf unterschiedliche Systeme sieht wie folgt aus:
Man erkennt hier sehr gut die Direct Access-Verbindung, da die ping-Werte selbst bei Zugriff auf einen eigentlich im gleichen Netzwerk stehenden Server (Storage2) bei 74ms liegen, was einer normalen ping-Zeit zu einem System im Internet beträgt.
Ein Zugriff auf den Storage2 per Explorer sieht wie folgt aus:
Das DNS-Suffix
Bei uns läuft das Direct Access nun schon etwa eine Woche, und ich war während dieser Zeit schon bei ein paar Kunden, und hatte dort auch die Gelegenheit, Direct Access zu testen.
Als erstes muss ich sagen: Coole Sache! :) Notebook aufklappen, anmelden, evtl. noch Desktop Authority laden lassen, und man ist intern. Ich kann mit meinem Outlook arbeiten wie intern, ich habe meine Netzlaufwerke, ich komme auf nahezu alle Systeme drauf (da bei uns intern der älteste Server ein Windows Server 2003 ist für die Telefonanlage) und kann mich viel ungestörter und zwangloser bewegen wie in einem VPN, das evtl. mal abbricht, sich nicht richtig verbindet, teilweise den gesamten Traffic durch den Tunnel schickt wenn man nicht seine Einstellungen anpasst usw…
Was mir allerdings aufgefallen ist:
Wenn man in einer Umgebung ist, in dem ein Domänencontroller DHCP-Adressen herausgibt, stellt der Client keine IPv6-Adresse (2001:……) ein und Direct Access funktioniert nicht. Wenn ich in der gleichen Umgebung mir eine feste Adresse zuweise, funktioniert es. Andere Möglichkeit ist, das man sich auf dem Client in den erweiterten IPv4-Einstellungen unter “DNS” ein DNS-Suffix einträgt, welches entweder nur ein Name der internen Domäne (ohne Endung) oder der eigene Name (Ich habe z.B. “Jan” genommen) ist. Mit dieser kleinen Änderung funktioniert Direct Access auch bei DHCP-Adressen in einer Domänen-Umgebung.
Ich hoffe wir können mit dieser Anleitung einigen Leuten ihre Arbeit erleichtern, den notwendigen Tipp bei einem Problem geben oder einfach nur generell Licht ins Dunkel bringen :)
Wenn Ihnen diese Dokumentation gefällt, Sie Kritik, Anregungen oder Lob haben wäre ich froh von Ihnen zu hören.
Die komplette Dokumentation gibt es auch noch als PDF-Datei für einen einfacheren Ausdruck bzw. um sie zu speichern und offline zu verwenden:
Keine Kommentare:
Kommentar veröffentlichen