Howto: Einrichtung von DirectAccess

Vorlage 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.

Direct-Access-Howto-Tutorial-Part-2-01-AD-Controller

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):

Direct-Access-Howto-Tutorial-Part-2-02-AD-Controller

Direct-Access-Howto-Tutorial-Part-2-03-AD-Controller

Direct-Access-Howto-Tutorial-Part-2-04-AD-Controller

Direct-Access-Howto-Tutorial-Part-2-05-AD-Controller

Direct-Access-Howto-Tutorial-Part-2-06-AD-ControllerDirect-Access-Howto-Tutorial-Part-2-07-AD-Controller

Direct-Access-Howto-Tutorial-Part-2-08-AD-ControllerDirect-Access-Howto-Tutorial-Part-2-09-AD-Controller

Direct-Access-Howto-Tutorial-Part-2-10-AD-Controller

Direct-Access-Howto-Tutorial-Part-2-11-AD-Controller

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.

Direct-Access-Howto-Tutorial-Part-2-12-AD-Controller

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:

Direct-Access-Howto-Tutorial-Part-2-13-AD-Controller

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”.

Direct-Access-Howto-Tutorial-Part-2-14-AD-ControllerEin Rechtsklick auf “Webserver” und “Doppelte Vorlage” erzeugt eine Kopie des Zertifikats. Hier in Screenshots die Einstellungen der neu erzeugten Zertifikatvorlage:

Direct-Access-Howto-Tutorial-Part-2-15-AD-Controller

Direct-Access-Howto-Tutorial-Part-2-16-AD-Controller

Direct-Access-Howto-Tutorial-Part-2-17-AD-Controller

Wichtig ist hier die Einstellung “Exportieren von privatem Schlüssel zulassen”!

Direct-Access-Howto-Tutorial-Part-2-18-AD-Controller

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:

Direct-Access-Howto-Tutorial-Part-2-19-AD-Controller

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:

Direct-Access-Howto-Tutorial-Part-2-20-AD-Controller

Direct-Access-Howto-Tutorial-Part-2-21-AD-ControllerDirect-Access-Howto-Tutorial-Part-2-23-AD-Controller

Direct-Access-Howto-Tutorial-Part-2-24-AD-ControllerDirect-Access-Howto-Tutorial-Part-2-25-AD-Controller

Direct-Access-Howto-Tutorial-Part-2-26-AD-Controller

Direct-Access-Howto-Tutorial-Part-2-27-AD-Controller

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”)

Direct-Access-Howto-Tutorial-Part-2-28-AD-Controller

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”.

 

Direct-Access-Howto-Tutorial-Part-2-29-AD-Controller

Damit die Änderungen greifen ist der “IP-Helper Dienst” neu zustarten. Das kann man durch die Befehle:

net stop iphlpsvc
net start iphlpsvc

erreichen.

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.

Direct-Access-Howto-Tutorial-Part-3-01-DirectAccess-Server

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.

Direct-Access-Howto-Tutorial-Part-3-02-DirectAccess-Server

Nach dem einstellen der Netzwerkadressen muss der Server in die Domäne aufgenommen werden.

Wichtig: Es ist notwendig, dass die interne IP-Adresse des DirectAccess Servers über den Namen “isatap” aufgelöst werden kann. Hierzu müssen wir in die DNS Konfiguration Ihres DNS Servers wechseln, dort die interne Domaine auswählen (in unserem Beispiel “corp.contoso.com”) und dann einen A-Record mit dem Namen “isaptap” und der IPv4-Adresse der internen Netzwerkschnittstelle des DirectAccess-Servers ergänzen.

Einrichten eines webbasierten Sperrlistenverteilungspunktes

Zuerst installieren wir die Rolle “Webserver (IIS)” über den “Server-Manager” nach. Im Internetinformationsdienste-Manager navigieren wir nun unter “Sites” zur “Default Web Site”, klicken mit rechts darauf und wählen “Virtuelles Verzeichnis hinzufügen…”

Direct-Access-Howto-Tutorial-Part-3-03-DirectAccess-Server

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

Direct-Access-Howto-Tutorial-Part-3-04-DirectAccess-Server

Direct-Access-Howto-Tutorial-Part-3-05-DirectAccess-Server
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”:

Direct-Access-Howto-Tutorial-Part-3-06-DirectAccess-Server

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.

Direct-Access-Howto-Tutorial-Part-2-30-AD-Controller

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.

Direct-Access-Howto-Tutorial-Part-4-01-Konfiguration-der-CA

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”.

Direct-Access-Howto-Tutorial-Part-4-02-Konfiguration-der-CA

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/<CaName><CRLNameSuffix><DeltaCRLAllowed>.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

Direct-Access-Howto-Tutorial-Part-4-04-Konfiguration-der-CA

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$\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

Nach dem Klick auf “OK” wählen wir die folgenden Optionen

Direct-Access-Howto-Tutorial-Part-4-03-Konfiguration-der-CA
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:

Direct-Access-Howto-Tutorial-Part-4-05-Konfiguration-der-CA
Als zweiten Punkt müssen wir unter “Einstellungen der automatischen Zertifikatsanforderung” noch die “Computer-Zertifikats-Vorlage” hinzufügen:

Direct-Access-Howto-Tutorial-Part-4-06-Konfiguration-der-CA

Direct-Access-Howto-Tutorial-Part-4-07-Konfiguration-der-CA

Direct-Access-Howto-Tutorial-Part-4-08-Konfiguration-der-CA

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)”.

Direct-Access-Howto-Tutorial-Part-4-09-Konfiguration-der-CA
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:

Direct-Access-Howto-Tutorial-Part-4-10-Konfiguration-der-CA

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)”.

Direct-Access-Howto-Tutorial-Part-4-09-Konfiguration-der-CA

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:

Direct-Access-Howto-Tutorial-Part-5-01-Der-Network-Location-Server

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”.

Direct-Access-Howto-Tutorial-Part-5-02-Der-Network-Location-Server

Im nächsten Menü wählen wir “Hinzufügen…”, wählen “https” aus und unten das vorhin erzeugte Zertifikat.

Direct-Access-Howto-Tutorial-Part-5-03-Der-Network-Location-Server

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.

Direct-Access-Howto-Tutorial-Part-6-01-Einrichtung-des-Direct-Access

Nach dem Aufruf der Konsole sollte einen das folgende Bild erwarten:

Direct-Access-Howto-Tutorial-Part-6-02-Einrichtung-des-Direct-Access

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:

Direct-Access-Howto-Tutorial-Part-6-03-Einrichtung-des-Direct-Access

Schritt 2:

In Schritt 2 werden die Schnittstellen des Systems eingetragen und die benötigten Zertifikate hinterlegt.

Direct-Access-Howto-Tutorial-Part-6-04-Einrichtung-des-Direct-Access
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.

Direct-Access-Howto-Tutorial-Part-6-05-Einrichtung-des-Direct-Access

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, zur Verdeutlichung haben wir es “IP-HTTPS” genannt). 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

Direct-Access-Howto-Tutorial-Part-6-06-Einrichtung-des-Direct-Access
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.

Direct-Access-Howto-Tutorial-Part-6-07-Einrichtung-des-Direct-Access

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.

Direct-Access-Howto-Tutorial-Part-6-08-Einrichtung-des-Direct-Access
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.

Direct-Access-Howto-Tutorial-Part-6-09-Einrichtung-des-Direct-Access

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.

Direct-Access-Howto-Tutorial-Part-6-10-Einrichtung-des-Direct-Access

Wenn man sich auf einem Domänencontroller die Gruppenrichtlinienverwaltung anschaut, sieht man zwei neue GPOs, die mit der Domäne verknüpft worden sind.

Direct-Access-Howto-Tutorial-Part-6-11-Einrichtung-des-Direct-Access

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”:

Direct-Access-Howto-Tutorial-Part-7-01-Der-Client-und-ein-bisschen-Troubleshooting

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:

Direct-Access-Howto-Tutorial-Part-7-02-Der-Client-und-ein-bisschen-Troubleshooting
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

Direct-Access-Howto-Tutorial-Part-7-03-Der-Client-und-ein-bisschen-Troubleshooting

netsh name show eff

Direct-Access-Howto-Tutorial-Part-7-04-Der-Client-und-ein-bisschen-Troubleshooting
Ein Ping auf unterschiedliche Systeme sieht wie folgt aus:

Direct-Access-Howto-Tutorial-Part-7-05-Der-Client-und-ein-bisschen-Troubleshooting

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:

Direct-Access-Howto-Tutorial-Part-7-06-Der-Client-und-ein-bisschen-Troubleshooting

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.

Direct-Access-Howto-Tutorial-Part-3-02-DirectAccess-Server

 


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:

Download – Howto: Einrichtung von Direct Access

Wenn Sie Hilfe bei der Einrichtung benötigen, einen externen Blick auf ihre Umgebung bei einem Problem oder wenn wir für Sie Direct Access bereitstellen sollen, stehen wir Ihnen gerne zur Verfügung.

Unsere Kontaktdaten:

Tel.: 02984-9292 0

Fax: 02984-9292 50

Mail: technik [at] rachfahl . de | j.kappen [at] rachfahl . de | c.rachfahl [at] rachfahl  de

Internet: technikblog.rachfahl.de | www.rachfahl.de

Juli 2010 | Jan Kappen | Rachfahl IT-Solutions GmbH & Co. KG

Teilen:

IT-Her0es

Die "IT-Her0es" sind ein gemeinsames Projekt von Carsten Rachfahl und Jan Kappen. Einige der hier beschriebenen Lösungen, HowTos und Erklärungen wurden von beiden zusammen erarbeitet oder recherchiert. Um dieser Arbeit ein klein wenig Respekt zu zollen, wurde das Projekt "IT-Her0es" geschaffen.

31 Kommentare:

  1. Mensch Jungs, was ein super HowTo!!!

    Vielen Dank!!!
    Auch wenn ich ein bisschen abgeschreckt von der vielen Arbeit bin freue ich mihc sehr, das bald mal selbst in Angriff zu nehmen!!!

    Nochmals vielen Dank und ein dickes ++++++
    Gruß
    JustusFowl

  2. Hi,

    ich bin zwar von der Technik selbst nicht so richtig überzeugt (eine direkte Verbindung aus dem Internet ins CN ohne Proxy in einer richtigen DMZ ist m. E. ein no-go). Der Artikel selbst ist aber sehr gut geschrieben und sauber ausgearbeitet.

    Danke

  3. Hallo,

    entweder habe ich den Artikel nicht richtig gelesen bzw. die für mich wichtige Stelle scheinbar überlesen …

    Werden nun zwei öffentliche IP-Adressen benötigt? Dies ist doch so gut wie garnicht zu realisieren.

    Gruß
    Jochen

    p.s. Sehr schöne Anleitung!

  4. Hallo Jochen,

    du hast dich nicht verlesen, es werden zwei öffentliche Adressen benötigt. Sehr unwahrscheinlich ist das ganze nicht, ein kleines IP-Netz mit 8 oder 16 Adressen bekommt man (noch) relativ leicht, die Kosten sind zwar nicht mit einem DSL-Anschluss für zuhause zu vergleichen, aber dafür hat man seine eigenen öffentlichen Adressen und i.d.R. einen Business-Anschluss mit garantierten Verfügbarkeiten. Wir haben mehrere Kunden die einen Block von festen IP-Adressen haben, teilweise 8 Adressen, teilweise 32, wir selbst haben sogar ein komplettes C-Netz. Oft werden mehrere Dienste in einer Firma angeboten, die dann nicht über eine Adresse zur Verfügung gestellt werden können oder sollen, wie unter anderem Direct Access.
    Ich vermute allerdings, das das Thema „Direct Access“ in Zukunft anders geregelt werden wird, sobald IPv6-Adressen zur Verfügung stehen und nutzbar werden, da dann z.B. das herkömmliche NAT wegfällt und nahezu beliebig viele Adressen zur Verfügung stehen.

    Gruß, Jan

  5. Hallo zusammen

    Muss sagen, super HowTo!

    Habt ihr schon erfahrung mit SBS2011?
    Sollte auf SBS2011 ja mit einem Server realiesierbar sein?!

    gruss Sandro

  6. Hi,

    nein haben wir noch nicht, da die einzige SBS2011-Installation bisher nur virtuell von mir gemacht wurde um mir das System mal anzuschauen. Produktiv haben wir noch keine Installation…

    Gruß, Jan

  7. Pingback: Einrichtung eines Remote Desktop Services Remotedesktopgateway « Technikblog

  8. Hi,

    kurze Frage: ist DirectAccess eine andere Bezeichnung von Mobile IPv6?

    Gruss, Dorian

  9. Hi,
    Direct Access und Mobile IPv6 sind nicht das gleiche…
    Gruß, Jan

  10. Hallo,

    Ihr habt Euch wirklich viel Arbeit damit gemacht. Funktioniert aber nicht wirklich. Weder nach Eurem Tutorial, noch nach dem von MS. APP01 kann nicht aufgelöst werden. Schade, ist bei mir aber auch kein Einzelfall.
    Habe den alten Guide von August 2009 noch einmal hervorgeholt, auch damit nicht mehr.

    Torsten

  11. Pingback: Troubleshooting bei DirectAccess und der DirectAccess Connectivity Assistant « Technikblog

  12. Hallo und Gruß,

    Nochmal ein spätes Dankeschön für die wirklich tolle Hilfe!
    Da ich selbst Direct Access in einer virtuellen Umgebung erfolgreich aufgebaut habe, biete ich hier meine persönliche Dokumentation:
    Bei Interesse auf: http://www.freewebs.com/headshaker/project_it_directaccess.htm

    Gutes Gelingen!

    Gruß, Kaj

  13. Hi zusammen
    ich wollte noch einen kleine Tip anfügen, der mich gut 5 Tage Arbeit gekostet hat.
    Wenn man im Intranet bereits IPV6 eingeführt hat, und z.b. ein AAAA:BBBB:CCCC:DDDD::/64 per Router/Firewall intern zur Verfügung stellt (weil z.b. Der Provider einem schon ein IPV6 Netzwerk bereit stellt).
    Dann richtet der Direct Access Server seinen ISATAP Dienst nicht ein (das ist auch gut so).
    Allerdings kommen die Pakete dann aus den verschiedenen Tunneln mit folgenden IPV6 Adressen zum z.b. DNS Server dahinter
    TEREDO 2001:0::/32
    6TO4 2002:/16
    bei HTTPS: die Addressen wo man definiert hat.
    Der DNS (in diesem Falle stellvertetend für alle Server im Intranet die IPV6 konfiguriert haben) weiss jetzt nicht mehr wohin mit dem Paket und schickt es daher an den einzigen Router der ihm bekannt ist, den Router/Firewall mit dem man das IPV6 Präfix intern public gemacht hat.
    Der schmeisst das Paket dann einfach weg…und man selber rätselt warum die Tunnels stehen, und nix drübergeht.
    Einfach Lösung dazu:
    auf dem Router/Firewall statische Routen eintragen für die oben erwähnten Adressen an den Direct Access Server…und siehe da, alles geht.
    Gruss aus der Schweiz
    Alex

  14. Pingback: DirectAccess for SMB and Lab environments – Design, Step by Step and Troubleshooting Guide | Thomas Maurer (tm) - Just another sys engineering weblog

  15. Eine simple Frage aus Anwendersicht. Wenn das Direvt-Access-Notebook außerhalb vom Firmennetz keine Internetverbindung bekommt ist es dann offline benutzbar, sprich bekommt der User Zugriff auf die Offline-Dateien?

  16. Hallo,
    das sollte kein Problem sein, da die Offline-Dateien ja immer dabei sind und wenn das Notebook offline ist sollte der Zugriff auf diese Dateien problemlos funktionieren. Getestet haben wir das allerdings noch nicht :)

    Gruß, Jan

  17. Hi,

    super Dokumentation. Ich werde mich die Tage an die Installation machen.
    Eine Frage bleibt jedoch noch.

    Wir haben derzeit unser Netz hinter einer Hardware Firewall gesetzt. In der Dokumentation steht direkt „öffentliche IP-Adressen zuweisen“. Eine NAT Übersetzung wird/sol nicht funktionieren. Daher die Frage:

    Muss der DirectAccess Server vor die Firewall? Oder wie wäre die Firewall zu konfigurieren? 1-to-1 NAT?

  18. Hallo Maik,
    es werden zwingend öffentliche IP-Adressen benötigt, d.h. direkt aus dem Internet ansprechbare Adressen. Ein NAT geht nicht, auch nicht ein 1-zu-1 NAT. Wenn Ihr einen Internetanschluss habt der nur eine IP hat funktioniert DA nicht.
    Gruß, Jan

  19. Hallo Jan,

    ich versuch mich gerade an der Installation. Das mit der IP hat sich geklärt. Wir haben feste, aufeinanderfolgende.

    Ich habe nur folgendes Problem:

    Hier steht:
    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”.

    Ich habe in der mmc im Snap-In den lokalen Computer ausgewählt. Jedoch habe
    ich nur „Eigene Zertifikate“. Hier gibt es kein Zertifikate „Unterordner“.

    Wenn ich in „Eigene Zertifikate“ ein neues anfordere, bekomme ich im Wizard nicht das Zertifikat „Web Server 2008 (DirectAccess)“ zur Auswahl. Dieses habe ich jedoch auf dem DC korrekt (nach Anleitung) installiert.

    Die Installation lief bis zu diesem Punkt exakt nach Anleitung. Einziger Unterschied. Mein Server1 ist ein SBS2011.

    Eine Idee?

    Danke

    Maik

  20. So,

    nach einem Neustart der Server habe ich jetzt auch auf dem DA-Server das Verzeichnis Zertifikate unter „Eigene Zertifikate“. Allerdings bleibt das Problem bestehen, dass ich im Wizard nicht das Zertifikat „Web Server 2008 (DirectAccess)“ zur auswahl bekomme.

  21. Hallo Maik,
    wir können uns das Problem gerne einmal gemeinsan in einer Fernwartungssitzung anschauen, ich denke ich kann dir da weiterhelfen…
    Gruß und schönes Wochenende,
    Jan

  22. Hallo!

    Herzlichen Dank für dieses interessante HowTo – Test-VMen installieren gerade ;)

    Ich habe aber noch eine Frage in Bezug auf Firewall/Security:

    Wie sicher ist diese Art von DirectAccess? Grundsátzlich hángt der DA Server – welcher ja auch in der Dománe ist dann direkt im Internet.

    Würde euch das sicherheitstechnisch Sorgen bereiten?
    Direct Accrss via NAT ist ja sowiso nicht möglich. Welche möglichkeiten habe ich, Direct Access zusátzlich über eine Firewall zu routen?

    Danke für eure Antworten :)

  23. Hallo MC,
    der Server sollte zum einen mit der lokalen Firewall abgesichert werden, weiterhin kann problemlos eine weitere Hardware-Firewall verwendet werden, die nur die benötigten Ports hineinlässt. Ob man dann noch bereit ist das restliche „Risiko“ einzugehen ist vermutlich eine persönliche oder eine vertraglich geregelte Geschichte…
    Gruß, Jan

  24. Hallo Jan,

    Also du meinst Absicherung mit einer Hardwarefirewall – und öffnen nur der definierten Ports. Welche Ports brauche ich für DA?

    Aber Direct Access über NAT funktioniert definitiv nicht, oder?

    Ja rechtliches Risiko bin ich der sowie glücklichen und auch unglücklichen Lage – das selbst zu entscheiden.
    Sollte es Probleme geben muss ich selbst für mein Unternehmen gerade stehen.

    Danke,

    gruss MC

  25. Hallo!

    Konnte zum Punkt von Maik am 11.November 2011 eine Lösung gefunden werden?
    Ich stehe genau am selben Punkt.

    dh.: Wenn ich auf meinem Direct Access Server unter „Eigene Zertifikate“ – „Zertifikate“ ein neues Zertifikat anfordern will bekomme ich einen Wizard welcher mir nur Zertifikatregistrierungsrichtlinien anzeigt – dort sehe ich als einzige Richtlinie jene, welche in einem vorangegangenem Schritt per GPO verteilt wurde – also nur die für das Autoenrollment „Computerkonto“

    Interessanterweise zeigt ein Windows Server 2008 korrekt den Wizard mit „Zertifikat anfordern“
    Nur beim R2 kommen die Richtlinien

    Vielen Dank für die Rückantwort

    Gruss, Chris

  26. Hallo Chris,
    als Richtlinie wird „Active Directory-Registrierungsrichtlinie“ genommen, also der Wert der per Standard ausgewählt ist (http://technikblog.rachfahl.de/wp-content/uploads/2012/01/directaccess_richtlinie-300×217.png). Nach einem Klick auf Weiter erscheinen die Vorlagen, die nutzbar sind…
    Gruß, Jan

  27. Hallo Jan!

    Tatsächlich! Ich habe nicht auf Weiter geklickt, da ich angenommen habe, dass ich bereits am Holzweg bin.
    Eines der Beispiele bei dem übereilte Skepsis nicht angegbracht ist. :)

    Vielen Dank
    Gruß, Chris

  28. Hallo!

    Ich habe da mal eine schwierige Frage. Mir ist klar, dass das nicht viel Informationen sind aber ich habe mehrheitlich alles wie beschrieben konfiguriert allerdings nur auf 3 Win 2K8 R2 Server:

    -Server1 mit DC, DNS für intern, DHCP, Webserver (IIS), und CA.

    -Server2 mit DNS für simuliertes Internet, einen Webserver (IIS) und dem
    Feature für Direct Access.

    -Server3 als Direct Access Client.

    -Das ganze läuft auf einer virtualisierten Umgebung mit VMware Workstation.

    -Ich habe ein „internes“ Netzwerk und ein „externes“ Netzwerk Welches das Internet simulieren soll. Schlussendlich ist Server 1 und 2 im internen Netz und Server 2 und 3 im externen Netz angesiedelt.

    Bei der Konfiguration hat alles geklappt, keine Fehler und nix. Aber am Ende kriege ich einfach keine Verbindung zustande.
    Kann mir vielleicht irgendwer einen Rat geben wo ich noch nach einem Fehler suchen könnte?

    Vielen Dank für jede Hilfe
    Gruss, Remo

  29. Hallo!

    Danke für diesen hervorragenden Blogeintrag.

    Eine Frage habe ich, an folgender Stelle im Text:

    >Externe Verbindung:
    >http://crl.contoso.com/crld/.crl

    Aktiviert Ihr „In die IDP-Erweiterung ausgestellter CRLs einbeziehen“.

    Wozu? Welchem Ziel dient das?

    Welche Fehler könnten auftreten, wenn man das nicht aktiviert?

    Danke im Voraus!

  30. Hallo Jan,
    diese Einstellung wurde so in dem Guide von Microsoft gemacht, daher habe ich das hier übernommen. Ob die Verbindung auch funktioniert wenn der Haken nicht gesetzt ist weiß ich nicht, habe ich nicht getestet.
    Gruß, Jan

  31. Hallo,
    super Artikel, hilft auch bei Windows 2012 R2 mit Windows 7 noch weiter. Aber bei einer Sache habe ich ein großes Problem: Bei uns werden einige Laufwerke über Gruppenrichtlinien gemappt, das Home-Laufwerk des Benutzers hingegen über sein AD-Objekt, Registerkarte Profile. Nun dauert das Login über DirectAccess eine ganze Weile und danach werden im Explorer alle Netzlaufwerke mit einem roten x gekennzeichnet. Klickt man drauf, erscheint dennoch der Inhalt. Das wäre noch hinnehmbar, aber das Home-Laufwerk fehlt komplett. Man könnte es zwar nachträglich mit net use mappen, aber das kann nicht die Lösung sein. Es sieht aus, als würde versucht, die Laufwerke zu mappen, ehe die Namensauflösung über DirectAccess funktioniert. Ist ein ähnliches Verhalten bekannt? Und kennen Sie dafür eine Lösung? Jeder Hinweis wird dankend angenommen :-)

    Gruß, Leipold

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *