Schritt 1: Planen der Infrastruktur für den Remotezugriff

  • Artikel

Gilt für: Windows Server 2022, Windows Server 2019, Windows Server 2016

Hinweis

Durch Windows Server 2016 werden DirectAccess und RRAS (Routing and Remote Access Service, Routing- und RAS-Dienst) zu einer einzigen Remotezugriffsrolle zusammengefasst.

In diesem Thema werden die Schritte zur Planung einer Infrastruktur beschrieben, mit der Sie einen einzelnen RAS-Server für die Remoteverwaltung von DirectAccess-Clients einrichten können. In der folgenden Tabelle sind die Schritte aufgeführt. Diese Planungsaufgaben müssen jedoch nicht in einer bestimmten Reihenfolge ausgeführt werden.

Aufgabe BESCHREIBUNG
Planen der Netzwerktopologie und Servereinstellungen Entscheiden Sie über den Standort des RAS-Servers (am Edge oder hinter einem NAT-Gerät oder einer Firewall), und planen Sie die IP-Adressenvergabe und das Routing.
Planen der Firewallanforderungen Planen Sie, den Remotezugriff über Edge-Firewalls zuzulassen.
Planen der Zertifikatanforderungen Entscheiden Sie, ob Sie das Kerberos-Protokoll oder Zertifikate für die Clientauthentifizierung verwenden möchten, und planen Sie Websitezertifikate.

IP-HTTPS ist ein Übergangsprotokoll, das von DirectAccess-Clients zum Tunneln von IPv6-Datenverkehr über IPv4-Netzwerke verwendet wird. Entscheiden Sie, ob die Authentifizierung für den Server per IP-HTTPS über ein Zertifikat erfolgen soll, das durch eine Zertifizierungsstelle (CA) ausgegeben wird, oder durch ein selbstsigniertes Zertifikat, das automatisch vom RAS-Server ausgestellt wird.
Planen der DNS-Anforderungen Planen Sie DNS-Einstellungen (Domain Name System) für den RAS-Server, die Infrastrukturserver, die Optionen für die lokale Namensauflösung und die Clientkonnektivität.
Planen der Konfiguration des Netzwerkadressenservers Entscheiden Sie, ob die Netzwerkadressenserver-Website in Ihrer Organisation platziert werden soll (auf dem RAS-Server oder einem anderen Server), und planen Sie die Zertifikatanforderungen, wenn sich der Netzwerkadressenserver auf dem RAS-Server befindet. Hinweis: Der Netzwerkadressenserver wird von DirectAccess-Clients verwendet, um zu ermitteln, ob sie sich im internen Netzwerk befinden.
Planen der Konfigurationen von Verwaltungsservern Berücksichtigen Sie bei der Planung Verwaltungsserver (beispielsweise Updateserver), die für die Verwaltung von Remoteclients verwendet werden. Hinweis: Administrator*innen können DirectAccess-Clientcomputer, die sich außerhalb des Unternehmensnetzwerks befinden, remote über das Internet verwalten.
Planen der Active Directory-Anforderungen Planen Sie Ihre Domänencontroller, Ihre Active Directory-Anforderungen, die Clientauthentifizierung und Ihre Struktur mit mehreren Domänen.
Planen der Erstellung von Gruppenrichtlinienobjekten Entscheiden Sie, welche Gruppenrichtlinienobjekte (GPOs) in Ihrer Organisation erforderlich sind und wie diese erstellt oder bearbeitet werden.

Planen der Netzwerktopologie und -einstellungen

Wenn Sie Ihr Netzwerk planen, müssen Sie die Topologie des Netzwerkadapters, die Einstellungen für die IP-Adressierung und die Anforderungen für ISATAP berücksichtigen.

Planen von Netzwerkadaptern und IP-Adressierung

  1. Bestimmen Sie die Netzwerkadaptertopologie, die Sie verwenden möchten. Der Remotezugriff kann mit folgenden Topologien eingerichtet werden:

    • Mit zwei Netzwerkadaptern: Der RAS-Server wird am Edge installiert, wobei ein Netzwerkadapter mit dem Internet und der andere mit dem internen Netzwerk verbunden ist.

    • Mit zwei Netzwerkadaptern: Der RAS-Server wird hinter einem NAT-Gerät, einer Firewall oder einem Router installiert, wobei ein Netzwerkadapter mit einem Umkreisnetzwerk und der andere mit dem internen Netzwerk verbunden ist.

    • Mit einem Netzwerkadapter: Der Remotezugriffsserver wird hinter einem NAT-Gerät installiert, und der einzige Netzwerkadapter wird mit dem internen Netzwerk verbunden.

  2. Identifizieren Sie Ihre IP-Adressierungsanforderungen:

    DirectAccess verwendet IPv6 mit IPsec, um eine sichere Verbindung zwischen DirectAcces-Clientcomputern und dem internen Unternehmensnetzwerk herzustellen. Jedoch erfordert DirectAccess nicht unbedingt Konnektivität mit dem IPv6-Internet oder nativen IPv6-Support auf internen Netzwerken. Stattdessen werden automatisch IPv6-Übergangstechnologien konfiguriert und verwendet, um IPv6-Datenverkehr durch das IPv4-Internet (durch die Verwendung von 6to4, Teredo oder IP-HTTPS) und durch Ihr reines IPv4-Intranet (durch die Verwendung von NAT64 oder ISATAP) zu tunneln. Eine Übersicht über diese Übergangstechnologien finden Sie in folgenden Ressourcen:

  3. Konfigurieren Sie erforderliche Adapter und Adressen entsprechend folgender Tabelle. Bei Bereitstellungen hinter einem NAT-Gerät mit einem einzelnen Netzwerkadapter konfigurieren Sie die IP-Adressen nur mit der Spalte Interner Netzwerkadapter.

    BESCHREIBUNG Externer Netzwerkadapter Interner Netzwerkadapter1, oben Routinganforderungen
    IPv4-Internet und IPv4-Intranet Konfigurieren Sie Folgendes:

    - Zwei statische, aufeinanderfolgende öffentliche IPv4-Adressen mit den entsprechenden Subnetzmasken (nur für Teredo erforderlich)
    - Eine IPv4-Adresse für das Standardgateway der Internetfirewall oder des lokalen Routers Ihres Internetdienstanbieters (Internet Service Provider, ISP) Hinweis: Der RAS-Server benötigt zwei aufeinanderfolgende öffentliche IPv4-Adressen, damit er als Teredo-Server fungieren kann und damit Windows-basierte Teredo-Clients mithilfe des RAS-Servers den Typ des NAT-Geräts erkennen können.    		 Konfigurieren Sie Folgendes:

    - Eine IPv4-Intranetadresse mit der entsprechenden Subnetzmaske
    - Ein verbindungsspezifisches DNS-Suffix für Ihren Intranetnamespace Zudem sollte ein DNS-Server auf der internen Schnittstelle konfiguriert werden. Achtung: Konfigurieren Sie kein Standardgateway an Intranetschnittstellen.    		 Gehen Sie wie folgt vor, um den RAS-Server so zu konfigurieren, dass er alle Subnetze im internen IPv4-Netzwerk erreicht:

    - Listen Sie die IPv4-Adressbereiche für alle Standorte im Intranet auf.
    - Verwenden Sie den Befehl route add -p oder netsh interface ipv4 add route, um der IPv4-Routingtabelle des RAS-Servers die IPv4-Adressbereiche als statische Routen hinzuzufügen.
    IPv6-Internet und IPv6-Intranet Konfigurieren Sie Folgendes:

    - Verwenden Sie die von Ihrem Internetdienstanbieter (ISP) automatisch konfigurierte Adresskonfiguration.
    - Verwenden Sie den Befehl route print, um sicherzustellen, dass in der IPv6-Routingtabelle eine IPv6-Standardroute vorhanden ist, die auf den ISP-Router zeigt.
    - Ermitteln Sie, ob der ISP und die Intranetrouter die in RFC 4191 beschriebenen Standardroutervoreinstellungen und eine höhere Standardvoreinstellung als die lokalen Intranetrouter verwenden. Wenn beide Fälle zutreffen, ist keine weitere Konfiguration für die Standardroute erforderlich. Die höhere Präferenz für den ISP-Router stellt sicher, dass die aktive IPv6-Standardroute des Remotezugriffsservers auf das IPv6-Internet zeigt.

    Wenn Sie über eine systemeigene IPv6-Infrastruktur verfügen, kann die Internetschnittstelle außerdem auch die Domänencontroller im Intranet erreichen, da der DirectAccess-Server ein IPv6-Router ist. Fügen Sie in diesem Fall auf dem Domänencontroller im Umkreisnetzwerk Paketfilter hinzu, die Konnektivität mit der IPv6-Adresse der Internetschnittstelle des RAS-Servers verhindern.    		 Konfigurieren Sie Folgendes:

    Wenn Sie nicht die Standardvoreinstellungsebenen verwenden, konfigurieren Sie Ihre Intranetschnittstellen mit dem Befehl netsh interface ipv6 set InterfaceIndex ignoredefaultroutes=enabled. Dieser Befehl stellt sicher, dass der IPv6-Routingtabelle keine weiteren Standardrouten hinzugefügt werden, die auf Intranetrouter zeigen. Den Schnittstellenindex Ihrer Intranetschnittstellen können Sie mit dem Befehl netsh interface show interface abrufen.    		 Wenn Sie ein IPv6-Intranet haben, führen Sie folgende Schritte aus, um den Remotezugriffsserver so zu konfigurieren, dass er alle IPv6-Speicherorte erreicht:

    - Listen Sie die IPv6-Adressbereiche für alle Standorte im Intranet auf.
    - Verwenden Sie den Befehl netsh interface ipv6 add route, um der IPv6-Routingtabelle des RAS-Servers die IPv6-Adressbereiche als statische Routen hinzuzufügen.
    IPv4-Internet und IPv6-Intranet Der RAS-Server leitet den Datenverkehr für die IPv6-Standardroute mit dem IP6-zu-IP4-Adapter von Microsoft an ein IP6-zu-IP4-Relay im IPv4-Internet weiter. Wenn im Unternehmensnetzwerk kein natives IPv6 bereitgestellt wurde, können Sie den folgenden Befehl verwenden, um einen RAS-Server für die IPv4-Adresse des 6to4-Relays von Microsoft im IPv4-Internet zu konfigurieren: netsh interface ipv6 6to4 set relay name=<ipaddress> state=enabled.

    Hinweis

    • Wenn dem DirectAccess-Client eine öffentliche IPv4-Adresse zugewiesen wurde, verwendet er die 6to4-Relaytechnologie für die Verbindung mit dem Internet. Wenn dem Client eine private IPv4-Adresse zugewiesen wurde, wird Teredo verwendet. Wenn der DirectAccess-Client weder mit IP6-zu-IP4 noch mit Teredo eine Verbindung mit dem DirectAccess-Server herstellen kann, wird IP-HTTPS verwendet.
    • Um Teredo zu verwenden, müssen Sie zwei aufeinander folgende IP-Adressen auf dem nach außen verfügbaren Netzwerkadapter konfigurieren.
    • Sie können Teredo nicht verwenden, wenn der RAS-Server nur einen Netzwerkadapter hat.
    • Systemeigene IPv6-Clientcomputer können über eine systemeigene IPv6 eine Verbindung zum Remotezugriffsserver herstellen, und es ist keine Übergangstechnologie erforderlich.

Planen von ISATAP-Anforderungen

ISATAP ist für die Remoteverwaltung von DirectAccess-Clients erforderlich, damit DirectAccess-Verwaltungsserver eine Verbindung mit DirectAccess-Clients im Internet herstellen können. ISATAP ist nicht erforderlich, um Verbindungen zu unterstützen, die durch DirectAccess-Clientcomputer mit IPv4-Ressourcen in Ihrem Organisationsnetzwerk initiiert werden. Für diese Zwecke wird NAT64/DNS64 verwendet. Wenn Ihre Bereitstellung ISATAP erfordert, können Sie Ihre Anforderungen mithilfe der folgenden Tabelle ermitteln.

ISATAP-Bereitstellungsszenario Requirements (Anforderungen)
Vorhandenes natives IPv6-Intranet (kein ISATAP erforderlich) Bei einer vorhandenen nativen IPv6-Infrastruktur geben Sie das Präfix der Organisation während der Remotezugriffsbereitstellung an, und der RAS-Server konfiguriert sich nicht selbst als ISATAP-Router. Gehen Sie folgendermaßen vor:

1. Um sicherzustellen, dass DirectAccess-Clients aus dem Intranet erreichbar sind, müssen Sie das IPv6-Routing ändern, sodass der Datenverkehr der Standardroute an den RAS-Server weitergeleitet wird. Wenn der IPv6-Adressraum in Ihrem Intranet eine andere Adresse als ein einzelnes 48-Bit-IPv6-Adresspräfix verwendet, müssen Sie während der Bereitstellung das entsprechende IPv6-Präfix Ihrer Organisation angeben.
2. Wenn derzeit eine Verbindung mit dem IPv6-Internet besteht, müssen Sie den Datenverkehr über die Standardroute so konfigurieren, dass dieser an den RAS-Server weitergeleitet wird. Anschließend müssen die entsprechenden Verbindungen und Routen auf dem RAS-Server konfiguriert werden, damit der Datenverkehr über die Standardroute an das mit dem IPv6-Internet verbundene Gerät weitergeleitet wird.
Vorhandene ISATAP-Bereitstellung Wenn Sie bereits über eine ISATAP-Infrastruktur verfügen, werden Sie während der Bereitstellung zur Eingabe des 48-Bit-Präfixes der Organisation aufgefordert, und der RAS-Server konfiguriert sich selbst nicht als ISATAP-Router. Um sicherzustellen, dass DirectAccess-Clients aus dem Intranet erreichbar sind, müssen Sie Ihre IPv6-Routinginfrastruktur ändern, sodass der Datenverkehr der Standardroute an den RAS-Server weitergeleitet wird. Diese Änderung muss auf dem vorhandenen ISATAP-Router erfolgen, an den die Intranetclients bereits den Standarddatenverkehr weiterleiten.
Keine vorhandene IPv6-Konnektivität Wenn der Einrichtungs-Assistent für den Remotezugriff erkennt, dass der Server über keine native oder ISATAP-basierte IPv6-Konnektivität verfügt, leitet er automatisch ein 6to4-basiertes 48-Bit-Präfix für das Intranet ab und konfiguriert den RAS-Server als ISATAP-Router, um IPv6-Konnektivität mit ISATAP-Hosts in Ihrem Intranet bereitzustellen. (Ein 6to4-basiertes Präfix wird nur verwendet, wenn der Server über öffentliche Adressen verfügt, andernfalls wird das Präfix automatisch aus einem eindeutigen lokalen Adressbereich generiert.)

Gehen Sie wie folgt vor, um ISATAP zu verwenden:

1. Registrieren Sie den ISATAP-Namen auf einem DNS-Server für jede Domäne, in der Sie ISATAP-basierte Konnektivität aktivieren möchten, damit der ISATAP-Name vom internen DNS-Server in die interne IPv4-Adresse des RAS-Servers aufgelöst werden kann.
2. Standardmäßig blockieren DNS-Server mit Windows Server 2012, Windows Server 2008 R2, Windows Server 2008 oder Windows Server 2003 die Auflösung des ISATAP-Namens mithilfe der globalen Abfragesperrliste. Um ISATAP zu aktivieren, müssen Sie den ISATAP-Namen aus der Sperrliste entfernen. Weitere Informationen finden Sie unter Entfernen von ISATAP aus der globalen DNS-Abfragesperrliste.

ISATAP-Hosts mit Windows, die den ISATAP-Namen auflösen können, konfigurieren automatisch wie folgt eine Adresse mit dem RAS-Server:

1. Eine ISATAP-basierte IPv6-Adresse an einer ISATAP-Tunnelschnittstelle
2. Eine 64-Bit-Route, die Konnektivität mit den anderen ISATAP-Hosts im Intranet bereitstellt
3. Eine IPv6-Standardroute, die auf den RAS-Server verweist Die Standardroute stellt sicher, dass ISATAP-Intranethosts die DirectAccess-Clients erreichen können.

Wenn Ihre Windows-basierten ISATAP-Hosts eine ISATAP-basierte IPv6-Adresse erhalten, beginnen sie über ISATAP-gekapselten Datenverkehr zu kommunizieren, sofern das Ziel ebenfalls ein ISATAP-Host ist. Da ISATAP für das gesamte Intranet ein einzelnes 64-Bit-Subnetz verwendet, wechselt die Kommunikation von einem segmentierten IPv4-Kommunikationsmodell zu einem IPv6-Kommunikationsmodell mit einem einzigen Subnetz. Dies kann sich auf das Verhalten von Active Directory Domain Services (AD DS) und anderer Anwendungen auswirken, die auf die vorhandene Konfiguration von Active Directory-Standorte und -Dienste aufbauen. Wenn Sie das Snap-In Active Directory-Standorte und -Dienste beispielsweise verwendet haben, um Standorte, IPv4-basierte Subnetze und die standortübergreifende Übertragung zur Weiterleitung von Anforderungen innerhalb von Standorten zu konfigurieren, wird diese Konfiguration von ISATAP-Hosts nicht verwendet.

  1. Um Active Directory-Standorte und -Dienste für die Weiterleitung innerhalb von Standorten für ISATAP-Hosts zu konfigurieren, müssen Sie für jedes IPv4-Subnetzobjekt ein entsprechendes IPv6-Subnetzobjekt konfigurieren, in dem das IPv6-Adresspräfix für das Subnetz denselben ISATAP-Hostadressbereich wie das IPv4-Subnetz adressiert. Beispielsweise lautet für das IPv4-Subnetz 192.168.99.0/24 und das 64-Bit-ISATAP-Adresspräfix 2002:836b:1:8000::/64 das entsprechende IPv6-Adresspräfix für das IPv6-Subnetzobjekt 2002:836b:1:8000:0:5efe:192.168.99.0/120. Für eine beliebige IPv4-Adresspräfixlänge (im Beispiel 24) berechnen Sie die entsprechende IPv6-Präfixlänge über die Formel: 96 + IPv4-Präfixlänge.
  2. Für die IPv6-Adressen der DirectAccess-Clients fügen Sie Folgendes hinzu:

    • Für Teredo-basierte DirectAccess-Clients: Ein IPv6-Subnetz für den Bereich 2001:0:WWXX:YYZZ::/64, wobei WWXX:YYZZ die Hexadezimalnotation mit Doppelpunkt der ersten IPv4-Adresse des RAS-Servers mit Internetzugriff ist. .
    • Für IP-HTTPS-basierte DirectAccess-Clients: Ein IPv6-Subnetz für den Bereich 2002:WWXX:YYZZ:8100::/56, wobei WWXX:YYZZ die Hexadezimalnotation mit Doppelpunkt der ersten IPv4-Adresse (w.x.y.z) des RAS-Servers mit Internetzugriff ist. .
    • Für 6to4-DirectAccess-Clients: Eine Reihe IPv6-zu-IPv4-basierter IPv6-Präfixe, die mit 2002: beginnen und die regionalen, öffentlichen IPv4-Adresspräfixe darstellen, die von der IANA (Internet Assigned Numbers Authority) und regionalen Registraren verwaltet werden. Das IP6-zu-IP4-basierte Präfix für das öffentliche IPv4-Adresspräfix w.x.y.z/n ist 2002:WWXX:YYZZ::/[16 +n], wobei WWXX:YYZZ die Hexadezimalnotation mit Doppelpunkt von w.x.y.z ist.

      Der Bereich 7.0.0.0/8 wird z. B. von der ARIN (American Registry for Internet Numbers) für Nordamerika verwaltet. Das entsprechende IPv6-zu-IPv4-basierte Präfix für diesen öffentlichen IPv6-Adressbereich ist 2002:700::/24. Weitere Informationen zum öffentlichen IPv4-Adressbereich finden Sie in der IANA-IPv4-Adressraumregistrierung. .

Wichtig

Stellen Sie sicher, dass an der internen Schnittstelle des DirectAccess-Servers keine öffentlichen IP-Adressen vorhanden sind. Wenn Sie an der internen Schnittstelle über eine öffentliche IP-Adresse verfügen, kann die Konnektivität über ISATAP fehlschlagen.

Planen der Firewallanforderungen

Wenn sich der Remotezugriffsserver hinter einer Edge-Firewall befindet, sind folgende Ausnahmen für Remotezugriff-Datenverkehr erforderlich, wenn sich der Remotezugriffsserver auf dem IPv4-Internet befindet:

  • Für IP-HTTPS: TCP-Zielport 443 (Transmission Control Protocol) eingehend und TCP-Quellport 443 ausgehend

  • Für Teredo-Datenverkehr: UDP-Zielport 3544 (User Datagram Protocol) eingehend und UDP-Quellport 3544 ausgehend

  • Für 6to4-Datenverkehr: IP-Protokoll 41 ein- und ausgehend.

    Hinweis

    Bei Teredo- und IP6-zu-IP4-Datenverkehr sollten diese Ausnahmen für beide aufeinander folgenden öffentlichen IPv4-Adressen mit Internetzugriff auf dem RAS-Server angewendet werden.

    Für IP-HTTPS müssen die Ausnahmen auf die Adresse angewandt werden, die auf dem öffentlichen DNS-Server registriert ist.

  • Wenn Sie den Remotezugriff mit einem einzigen Netzwerkadapter bereitstellen und den Netzwerkadressenserver auf dem RAS-Server installieren, sollte der TCP-Port 62000 ebenfalls ausgenommen werden.

    Hinweis

    Diese Ausnahme erfolgt auch dem RAS-Server, und alle vorherigen Ausnahmen befinden sich auf der Edge-Firewall.

Die folgenden Ausnahmen sind für RAS-Datenverkehr erforderlich, wenn sich der RAS-Server im IPv6-Internet befindet:

  • IP-Protokoll 50

  • UDP-Zielport 500 eingehend und UDP-Quellport 500 ausgehend.

  • ICMPv6-Datenverkehr ein- und ausgehend (nur wenn Teredo verwendet wird).

Wenden Sie bei zusätzlichen Firewalls die folgenden internen Netzwerkfirewallausnahmen für RAS-Datenverkehr an:

  • Für ISATAP: Protokoll 41 ein- und ausgehend

  • Für den gesamten IPv4/IPv6-Datenverkehr: TCP/UDP

  • Für Teredo: ICMP für den gesamten IPv4/IPv6-Datenverkehr

Planen der Zertifikatanforderungen

Es gibt drei Szenarien, die Zertifikate erfordern, wenn Sie einen einzigen RAS-Server bereitstellen.

  • IPsec-Authentifizierung: Zertifikatsanforderungen für IPsec beinhalten ein Computerzertifikat, das von DirectAccess-Clientcomputern verwendet wird, wenn diese die IPsec-Verbindung mit dem RAS-Server herstellen, und ein Computerzertifikat, das von RAS-Servern für das Einrichten von IPsec-Verbindungen mit DirectAccess-Clients verwendet wird.

    Für DirectAccess unter Windows Server 2012 ist die Verwendung dieser IPsec-Zertifikate nicht verpflichtend. Als Alternative kann der RAS-Server als Proxy für die Kerberos-Authentifizierung fungieren, sodass keine Zertifikate erforderlich sind. Wenn die Kerberos-Authentifizierung verwendet wird, funktioniert diese über SSL, und das Kerberos-Protokoll verwendet das Zertifikat, das für IP-HTTPS konfiguriert wurde. Einige Unternehmensszenarien (einschließlich Bereitstellungen für mehrere Standorte und Einmalkennwort-Clientauthentifizierung) erfordern die Verwendung der Zertifikatsauthentifizierung, und nicht die Kerberos-Authentifizierung.

  • IP-HTTPS-Server: Wenn Sie den Remotezugriff konfigurieren, wird der RAS-Server automatisch als IP-HTTPS-Weblistener konfiguriert. Die IP-HTTPS-Website erfordert ein Websitezertifikat, und Clientcomputer müssen in der Lage sein, die CRL-Website (Certificate Revocation List, Zertifikatsperrlisten) für das Zertifikat zu kontaktieren.

  • Netzwerkadressenserver: Der Netzwerkadressenserver ist eine Website, die erkennt, ob sich Clientcomputer im Unternehmensnetzwerk befinden. Der Netzwerkadressenserver erfordert ein Websitezertifikat. DirectAccess-Clients müssen die CRL-Website für das Zertifikat kontaktieren können.

In der folgenden Tabelle werden die Zertifizierungsstellenanforderungen für diese Szenarien zusammengefasst.

IPsec-Authentifizierung IP-HTTPS-Server Netzwerkadressenserver
Es ist eine interne Zertifizierungsstelle erforderlich, um Computerzertifikate für den RAS-Server und die Clients für die IPsec-Authentifizierung auszustellen, wenn Sie nicht das Kerberos-Protokoll für die Authentifizierung verwenden. Interne Zertifizierungsstelle: Sie können eine interne Zertifizierungsstelle verwenden, um ein IP-HTTPS-Zertifikat auszustellen. Sie müssen dann jedoch sicherstellen, dass der Sperrlisten-Verteilungspunkt extern verfügbar ist. Interne Zertifizierungsstelle: Sie können eine interne Zertifizierungsstelle verwenden, um das Websitezertifikat für den Netzwerkadressenserver auszustellen. Stellen Sie sicher, dass der Sperrlisten-Verteilungspunkt eine hohe Verfügbarkeit vom internen Netzwerk aus hat.
Selbstsigniertes Zertifikat: Sie können ein selbstsigniertes Zertifikat für den IP-HTTPS-Server verwenden. Ein selbstsigniertes Zertifikat kann nicht in Bereitstellungen für mehrere Standorte verwendet werden. Selbstsigniertes Zertifikat: Sie können ein selbstsigniertes Zertifikat für die die Website des Netzwerkadressenservers verwenden. Für Bereitstellungen mit mehreren Standorten können Sie jedoch kein selbstsigniertes Zertifikat verwenden.
Öffentliche Zertifizierungsstelle: Es wird empfohlen, für das Ausstellen des IP-HTTPS-Zertifikats eine öffentliche Zertifizierungsstelle zu verwenden. Dadurch wird sichergestellt, dass der Sperrlisten-Verteilungspunkt extern verfügbar ist.

Planen von Computerzertifikaten für IPsec-Authentifizierung

Wenn Sie die zertifikatsbasierte IPsec-Authentifizierung verwenden, müssen der RAS-Server und die Clients ein Computerzertifikat erhalten. Die einfachste Möglichkeit für die Installation der Zertifikate stellt die Verwendung von Gruppenrichtlinien dar, mit denen Computerzertifikate automatisch ausgestellt werden. Dadurch wird sichergestellt, dass alle Domänenmitglieder ein Zertifikat von einer Unternehmenszertifizierungsstelle erhalten. Wenn Sie keine Unternehmenszertifizierungsstelle in Ihrer Organisation eingerichtet haben, finden Sie unterActive Directory Certificate Services.

Für dieses Zertifikat gelten die folgenden Anforderungen:

  • Das Zertifikat sollte eine Clientauthentifizierungs-EKU (Extended Key Usage, Erweiterte Schlüsselverwendung) aufweisen.

  • Das Clientzertifikat und das Serverzertifikat sollten vom selben Stammzertifikat abgeleitet sein. Das Stammzertifikat muss in den DirectAccess-Konfigurationseinstellungen ausgewählt sein.

Planen von Zertifikaten für IP-HTTPS

Der Remotezugriffsserver fungiert als IP-HTTPS-Listener, und Sie müssen manuell ein HTTPS-Websitezertifikat auf dem Server installieren. Beachten Sie Folgendes bei der Planung:

  • Die Verwendung einer öffentlichen Zertifizierungsstelle wird empfohlen, damit Zertifikatsperrlisten schneller verfügbar sind.

  • Geben Sie im Feld „Antragsteller“ die IPv4-Adresse des Internetadapters des RAS-Servers oder den FQDN der IP-HTTPS-URL an (die ConnectTo-Adresse). Falls sich der Remotezugriffsserver hinter einem NAT-Gerät befindet, sollte der öffentliche Name oder die Adresse des NAT-Geräts angegeben werden.

  • Der allgemeine Name des Zertifikats sollte dem Namen der IP-HTTPS-Website entsprechen.

  • Geben Sie im Feld Erweiterte Schlüsselverwendung die Serverauthentifizierungs-OID (Objekt-ID) an.

  • Geben Sie im Feld Sperrlisten-Verteilungspunkte einen Zertifikatsperrlisten-Verteilungspunkt an, auf den mit dem Internet verbundene DirectAccess-Clients zugreifen können.

    Hinweis

    Dies ist nur bei Clients erforderlich, auf denen Windows 7 ausgeführt wird.

  • Das IP-HTTPS-Zertifikat muss einen privaten Schlüssel enthalten.

  • Das IP-HTTPS-Zertifikat muss direkt in den persönlichen Speicher importiert werden.

  • Die Namen von IP-HTTPS-Zertifikaten können Platzhalter enthalten.

Planen von Websitezertifikaten für den Netzwerkadressenserver

Beachten Sie Folgendes bei der Planung der Website des Netzwerkadressenservers:

  • Im Feld Antragsteller muss eine IP-Adresse der Intranetschnittstelle des Netzwerkadressenservers oder der FQDN der Netzwerkadressen-URL angegeben sein.

  • Verwenden Sie im Feld Erweiterte Schlüsselverwendung die Serverauthentifizierungs-OID.

  • Verwenden Sie im Feld Sperrlisten-Verteilungspunkte einen Zertifikatssperrlisten-Verteilungspunkt, auf den mit dem Intranet verbundene DirectAccess-Clients zugreifen können. Der Zertifikatsperrlisten-Verteilungspunkt sollte nicht von außerhalb des internen Netzwerks zugänglich sein.

Hinweis

Stellen Sie sicher, dass die Zertifikate für IP-HTTPS und den Netzwerkadressenserver einen Antragstellernamen haben. Wenn das Zertifikat einen anderen Namen verwendet, wird es vom RAS-Assistenten nicht akzeptiert.

Planen der DNS-Anforderungen

In diesem Abschnitt werden die DNS-Anforderungen für Clients und Server in einer RAS-Bereitstellung erklärt.

DirectAccess-Clientanfragen

DNS wird verwendet, um Anforderungen von DirectAccess-Clientcomputern aufzulösen, die sich nicht im internen Netzwerk befinden. DirectAccess-Clients versuchen, eine Verbindung mit dem DirectAccess-Netzwerkadressenserver herzustellen, um zu bestimmen, ob sie sich im Internet oder im internen Netzwerk befinden.

  • Bei erfolgreicher Verbindung werden die Clients als im Intranet befindlich identifiziert, DirectAccess wird nicht verwendet, und Clientanforderungen werden mithilfe des DNS-Servers aufgelöst, der im Netzwerkadapter des Clientcomputers konfiguriert ist.

  • Wenn keine Verbindung hergestellt werden kann, wird davon ausgegangen, dass sich die Clients im Internet befinden. DirectAccess-Clients verwenden die Richtlinientabelle für die Namensauflösung, um zu ermitteln, welcher DNS-Server beim Auflösen von Namensanforderungen verwendet werden soll. Sie können angeben, dass Clients DirectAccess-DNS64 oder einen anderen internen DNS-Server für die Auflösung von Namen verwenden.

Wenn Sie eine Namensauflösung durchführen, wird die NRPT von DirectAccess-Clients verwendet, um festzulegen, wie eine Anfrage behandelt werden soll. Clients fordern einen vollqualifizierten Domänennamen (FQDN) oder einen Namen mit einer einzelnen Bezeichnung an, z. B. <https://internal>. Wenn ein Name mit einer einzelnen Bezeichnung gefordert ist, wird ein DNS-Suffix angehängt, um einen FQDN zu bilden. Wenn die DNS-Abfrage einem Eintrag in der NRPT entspricht, und DNS4 oder ein Intranet-DNS-Server für den Eintrag angegeben wurde, wird die Abfrage zur Namensauflösung mithilfe des angegebenen Servers gesendet. Wenn eine Übereinstimmung vorhanden ist, aber kein DNS-Server angegeben wurde, weist dies auf eine Ausnahmeregel hin, und die normale Namensauflösung wird verwendet.

Wenn der NRPT in der RAS-Verwaltungskonsole ein neues Suffix hinzugefügt wird, können die Standard-DNS-Server für das Suffix automatisch erkannt werden, wenn Sie Erkennen auswählen. Die automatische Erkennung funktioniert wie folgt:

  • Wenn das Unternehmensnetzwerk auf IPv4 basiert oder IPv4 und IPv6 verwendet, ist die Standardadresse die DNS64-Adresse des internen Adapters auf dem RAS-Server.

  • Wenn das Unternehmensnetzwerk IPv6-basiert ist, ist die Standardadresse die IPv6-Adresse der DNS-Server auf dem Unternehmensnetzwerk.

Infrastrukturserver

  • Netzwerkadressenserver

    DirectAccess-Clients versuchen, den Netzwerkadressenserver zu erreichen, um zu bestimmen, ob sie sich auf dem internen Netzwerk befinden. Clients im internen Netzwerk müssen in der Lage sein, den Namen des Netzwerkadressenservers aufzulösen, befinden sie sich jedoch im Internet, dürfen sie den Namen nicht auflösen. Um dies zu gewährleisten, wird der FQDN des Netzwerkadressenservers standardmäßig als Ausnahmeregel zum NRPT hinzugefügt. Außerdem werden bei der Konfiguration von RAS folgende Regeln automatisch erstellt:

    • Eine DNS-Suffixregel für die Stammdomäne oder den Domänennamen des RAS-Servers und die IPv6-Adressen, die den auf dem Remotezugriffsserver konfigurierten Intranet-DNS-Servern entsprechen. Wenn der Remotezugriffsserver z. B. Mitglied der Domäne corp.contoso.com ist, wird für das DNS-Suffix .corp.contoso.com eine Regel erstellt.

    • Eine Ausnahmeregel für den FQDN des Netzwerkadressenservers. Wenn die Netzwerkadressenserver-URL z. B. https://nls.corp.contoso.com lautet, wird eine Ausnahmeregel für den FQDN nls.corp.contoso.com erstellt.

  • IP-HTTPS-Server

    Der RAS-Server fungiert als IP-HTTPS-Listener und verwendet das Serverzertifikat zur Authentifizierung der IP-HTTPS-Clients. Der IP-HTTPS-Name muss von den DirectAccess-Clients aufgelöst werden können, die öffentliche DNS-Server verwenden.

Verbindungsprüfer

RAS erstellt einen Standard-Webtest, der von DirectAccess-Clientcomputern dazu verwendet wird, die Konnektivität zum internen Netzwerk zu prüfen. Damit der Test wie erwartet funktioniert, müssen folgende Namen manuell in dem DNS registriert werden:

  • directaccess-webprobehost sollte in die interne IPv4-Adresse des RAS-Servers oder in einer reinen IPv6-Umgebung in die IPv6-Adresse aufgelöst werden.

  • directaccess-corpconnectivityhost sollte in die Adresse des lokalen Hosts (Loopback) aufgelöst werden. Sie sollten A- und AAAA-Datensätze erstellen. Der Wert des A-Datensatzes ist 127.0.0.1, und der Wert des AAAA-Datensatzes wird aus dem NAT64-Präfix mit den letzten 32 Bit als 127.0.0.1 erstellt. Das NAT64-Präfix kann durch Ausführen des Windows PowerShell-Cmdlets Get-netnatTransitionConfiguration abgerufen werden.

    Hinweis

    Dies gilt nur in IPv4-Umgebungen. In einer Umgebung mit IPv4 und IPv6 oder in einer reinen IPv6-Umgebung sollte nur ein AAAA-Datensatz mit der Loopback-IP-Adresse ::1 erstellt werden.

Mithilfe anderer Webadressen über HTTP oder PING können Sie weitere Verbindungsprüfer erstellen. Für jeden Verbindungsprüfer muss ein DNS-Eintrag vorhanden sein.

DNS-Serveranforderungen

  • Für DirectAccess-Clients müssen Sie entweder einen DNS-Server, auf dem Windows Server 2012, Windows Server 2008 R2, Windows Server 2008 oder Windows Server 2003 ausgeführt wird, oder einen DNS-Server verwenden, der IPv6 unterstützt.

  • Verwenden Sie einen DNS-Server, der dynamische Updates unterstützt. Sie können DNS-Server verwenden, die keine dynamischen Updates unterstützen, Sie müssen dann jedoch die Einträge auf diesen Servern manuell aktualisieren.

  • Der FQDN für die Sperrlisten-Verteilungspunkte müssen über DNS-Server im Internet auflösbar sein. Wenn sich beispielsweise die URL https://crl.contoso.com/crld/corp-DC1-CA.crl im Feld Zertifikatssperrlisten-Verteilungspunkte des IP-HTTPS-Zertifikats für den RAS-Server befindet, muss sichergestellt werden, dass der FQDN crld.contoso.com über DNS-Server im Internet aufgelöst werden kann.

Planen der lokalen Namensauflösung

Berücksichtigen Sie bei der Planung der lokalen Namensauflösung Folgendes:

NRPT

In den folgenden Situationen müssen Sie möglicherweise zusätzliche NRPT-Regeln (Name Resolution Policy Table) erstellen:

  • Sie müssen zusätzliche DNS-Suffixe für den Intranetnamespace hinzufügen.

  • Wenn die FQDNs der Zertifikatssperrlisten-Verteilungspunkte auf dem Intranetnamespace beruhen, müssen Sie Ausnahmeregeln für die FQDNs der Zertifikatssperrlisten-Verteilungspunkte hinzufügen.

  • Wenn Sie über eine Split-Brain-DNS-Umgebung verfügen, müssen Sie Ausnahmeregeln für die Namen von Ressourcen hinzufügen, für die DirectAccess-Clients im Internet auf die Internetversion anstatt auf die Intranetversion zugreifen sollen.

  • Wenn Sie Datenverkehr über Ihre Webproxyserver im Intranet an eine externe Website weiterleiten, ist die externe Website nur über das Internet verfügbar. Sie verwendet die Adressen Ihrer Webproxyserver, um eingehende Anforderungen zuzulassen. Fügen Sie in diesem Fall eine Ausnahmeregel für den FQDN der externen Website hinzu, und geben Sie an, dass die Regel den Intranet-Webproxyserver und nicht die IPv6-Adressen des Intranet-DNS-Servers verwenden soll.

    Angenommen, Sie testen eine externe Website mit dem Namen test.contoso.com. Dieser Name kann nicht über Internet-DNS-Server aufgelöst werden. Der Webproxyserver von Contoso kann den Namen jedoch auflösen und Anforderungen an die Website an den externen Webserver weiterleiten. Um den Sitezugriff durch Benutzer zu verhindern, die sich nicht im Contoso-Intranet befinden, lässt die externe Website nur Anforderungen von der IPv4-Internetadresse des Contoso-Webproxys zu. Da Intranetbenutzer*innen den Contoso-Webproxy verwenden, können sie auf die Website zugreifen. Dies gilt jedoch nicht für DirectAccess-Benutzer*innen, da diese den Contoso-Webproxy nicht verwenden. Wenn eine NRPT-Ausnahmeregel für test.contoso.com konfiguriert wird, die den Contoso-Webproxy verwendet, werden Webseitenanforderungen für test.contoso.com über das IPv4-Internet zum Intranet-Webproxyserver weitergeleitet.

Einteilige Namen

Für Intranetserver werden manchmal einteilige Namen verwendet, z. B. <https://paycheck>. Wenn ein einteiliger Name verwendet werden soll und eine DNS-Suffixsuchliste konfiguriert wird, werden die DNS-Suffixe in der Liste an den einteiligen Namen angefügt. Wenn Benutzer*innen beispielsweise auf einem Computer, der ein Mitglied der Domäne corp.contoso.com ist, im Webbrowser <https://paycheck> eingeben, wird als Name der FQDN paycheck.corp.contoso.com erstellt. Standardmäßig basiert das angehängte Suffix auf dem primären DNS-Suffix des Clientcomputers.

Hinweis

In einem Szenario mit getrennten Namespaces, in dem mindestens ein Domänencomputer ein DNS-Suffix aufweist, das nicht der Active Directory-Domäne entspricht, zu dem die Computer gehören, müssen Sie sicherstellen, dass die Suchliste alle erforderlichen Suffixe enthält. Der RAS-Assistent wird den Active Directory-DNS-Namen standardmäßig als primäres DNS-Suffix auf dem Client konfigurieren. Stellen Sie sicher, dass Sie das DNS-Suffix hinzufügen, das von den Clients für die Namensauflösung verwendet wird.

Wenn in der Organisation mehrere Domänen und Windows Internet Name Service (WINS) bereitgestellt werden und Sie eine Remoteverbindung herstellen, können einteilige Namen wie folgt aufgelöst werden:

  • Durch Bereitstellen einer WINS-Forward-Lookupzone im DNS. Wenn versucht wird, computername.dns.zone1.corp.contoso.com aufzulösen, wird die Anforderung an den WINS-Server umgeleitet, der nur den Computernamen verwendet. Der Client geht davon aus, dass ein regulärer DNS-A-Datensatz ausgegeben wird, obwohl es sich eigentlich um eine NetBIOS-Anforderung handelt.

    Weitere Informationen finden Sie unter Verwalten einer Forward-Lookupzone.

  • Durch Hinzufügen eines DNS-Suffix (z. B. dns.zone1.corp.contoso.com) zum Standarddomänen-Gruppenrichtlinienobjekt.

Split-Brain-DNS

Wird sowohl für Internet- als auch für Intranet-Namensauflösung die gleiche DNS-Domäne verwendet, wird dies als „Split-Brain-DNS“ bezeichnet.

Bei Bereitstellungen mit Split-Brain-DNS müssen Sie die duplizierten FQDNs auflisten, die sowohl im Internet als auch Intranet vorhanden sind. Zudem muss festgelegt werden, auf welche Ressourcen der DirectAccess-Client zugreifen kann: auf die Intranet- oder die Internetversion. Wenn die DirectAccess-Clients auf die Internetversion zugreifen sollen, müssen Sie der NRPT den entsprechenden FQDN als Ausnahmeregel für jede Ressource hinzufügen.

Wenn in einer Split-Brain-DNS-Umgebung beide Versionen der Ressource verfügbar sein sollen, konfigurieren Sie die Intranetressourcen mit anderen Namen als denen, die im Internet verwendet werden. Weisen Sie dann Ihre Benutzer*innen an, den alternativen Namen zu verwenden, wenn sie auf die Ressource im Intranet zugreifen. So können Sie beispielsweise für das Intranet den Namen www.internal.contoso.com anstelle von www.contoso.com konfigurieren.

In einer Umgebung ohne Split-Brain-DNS unterscheidet sich der Internetnamespace vom Intranetnamespace. Die Contoso Corporation verwendet z. B. im Internet contoso.com und im Intranet corp.contoso.com. Da alle Intranetressourcen das DNS-Suffix corp.contoso.com verwenden, leitet die NRPT-Regel für corp.contoso.com alle DNS-Namensabfragen für Intranetressourcen an Intranet-DNS-Server weiter. DNS-Abfragen für Namen mit dem Suffix contoso.com entsprechen nicht der Intranetnamespaceregel „corp.contoso.com“ in der NRPT und werden daher an Internet-DNS-Server gesendet. Bei einer Bereitstellung ohne Split-Brain-DNS ist für die NRPT keine zusätzliche Konfiguration erforderlich, da keine Doppelung der FQDNs für Intranet- und Internetressourcen auftritt. DirectAccess-Clients können sowohl auf die Internet- als auch auf die Intranetressourcen ihrer Organisation zugreifen.

Planen des lokalen Namensauflösungsverhaltens für DirectAccess-Clients

Wenn ein Name nicht mit DNS aufgelöst werden kann, kann der DNS-Clientdienst in Windows Server 2012, Windows 8, Windows Server 2008 R2 und Windows 7 den Namen mithilfe einer lokalen Namensauflösung mit LLMNR (Link-Local Multicast-Namensauflösung) und NetBIOS über TCP/IP-Protokolle im lokalen Subnetz auflösen. Die lokale Namensauflösung ist in der Regel für Peer-zu-Peer-Verbindungen erforderlich, wenn sich der Computer in privaten Netzwerken befindet, z. B. in einem Heimnetzwerk mit einem einzelnen Subnetz.

Wenn der DNS-Clientdienst eine lokale Namensauflösung für Intranetservernamen ausführt und der Computer mit einem freigegebenen Subnetz im Internet verbunden ist, können böswillige Benutzer*innen über TCP/IP-Nachrichten LLMNR und NetBIOS erfassen, um Intranetservernamen zu ermitteln. Auf der Seite „DNS“ des Setup-Assistenten für den Infrastrukturserver konfigurieren Sie das lokale Namensauflösungsverhalten anhand der von den Intranet-DNS-Servern empfangenen Antworttypen. Die folgenden Optionen sind verfügbar:

  • Die lokale Namensauflösung verwenden, wenn der Name nicht im DNS vorhanden ist: Diese Option ist die sicherste, da der DirectAccess-Client nur für die Servernamen eine lokale Namensauflösung ausführt, die nicht von den Intranet-DNS-Servern aufgelöst werden können. Wenn die Intranet-DNS-Server erreicht werden können, werden die Namen der Intranetserver aufgelöst. Wenn die Intranet-DNS-Server nicht erreicht werden können, oder wenn andere DNS-Fehler auftreten, werden die Intranetservernamen nicht über die lokale Namensauflösung ins Subnetz durchgelassen.

  • Lokale Namensauflösung verwenden, falls der Name nicht im DNS vorhanden ist oder DNS-Server nicht erreichbar sind, wenn sich der Clientcomputer in einem privaten Netzwerk befindet (empfohlen): Diese Option wird empfohlen, da sie die Verwendung der lokalen Namensauflösung in einem privaten Netzwerk gestattet, wenn die Intranet-DNS-Server nicht erreichbar sind.

  • Lokale Namensauflösung für sämtliche DNS-Namensauflösungsfehler verwenden (unsicher): Dies ist die unsicherste Option, da die Namen von Netzwerkservern im Intranet über die lokale Namensauflösung zum lokalen Subnetz durchgelassen werden können.

Planen der Konfiguration des Netzwerkadressenservers

Der Netzwerkadressenserver ist eine Website, die erkennt, ob sich DirectAccess-Clients im Unternehmensnetzwerk befinden. Clients im Unternehmensnetzwerk verwenden kein DirectAccess, um interne Ressourcen zu erreichen, stattdessen stellen sie direkt eine Verbindung her.

Die Website des Netzwerkadressenservers kann auf dem RAS-Server oder auf einem anderen Server in Ihrem Unternehmen gehostet werden. Wenn Sie den Netzwerkadressenserver auf dem RAS-Server hosten, wird die Website automatisch erstellt, wenn Sie Remotezugriff bereitstellen. Wenn Sie den Netzwerkadressenserver auf einem anderen Server in Ihrer Organisation hosten, auf dem ein Windows-Betriebssystem ausgeführt wird, müssen Sie sicherstellen, dass Internetinformationsdienste (Internet Information Services, IIS) auf diesem Server installiert ist und dass die Website erstellt wurde. RAS konfiguriert keine Einstellungen auf dem Netzwerkadressenserver.

Stellen Sie sicher, dass die Website des Netzwerkadressenservers folgende Anforderungen erfüllt:

  • Besitzt ein HTTPS-Serverzertifikat

  • Verfügt über Hochverfügbarkeit für Computer im internen Netzwerk

  • Ist nicht für DirectAccess-Clientcomputer im Internet erreichbar

Beachten Sie außerdem die folgenden Anforderungen für Clients, wenn Sie die Website für den Netzwerkadressenserver einrichten:

  • DirectAccess-Clientcomputer müssen der Zertifizierungsstelle vertrauen, die das Serverzertifikat zur Netzwerkadressenserver-Website ausgegeben hat.

  • DirectAccess-Clientcomputer auf dem internen Netzwerk müssen in der Lage sein, den Namen der Netzwerkadressenserver-Website aufzulösen.

Planen von Zertifikaten für den Netzwerkadressenserver

Beachten Sie Folgendes, wenn Sie das Websitezertifikat für den Netzwerkadressenserver abrufen:

  • Im Feld Antragsteller muss die IP-Adresse der Intranetschnittstelle des Netzwerkadressenservers oder der FQDN der Netzwerkadressen-URL angegeben sein.

  • Verwenden Sie im Feld Erweiterte Schlüsselverwendung die Serverauthentifizierungs-OID.

  • Das Zertifikat des Netzwerkadressenservers muss anhand einer Zertifikatssperrliste (Certificate Revocation List, CRL) überprüft werden. Verwenden Sie im Feld Sperrlisten-Verteilungspunkte einen Zertifikatssperrlisten-Verteilungspunkt, auf den mit dem Intranet verbundene DirectAccess-Clients zugreifen können. Der Zertifikatsperrlisten-Verteilungspunkt sollte nicht von außerhalb des internen Netzwerks zugänglich sein.

Planen von DNS für den Netzwerkadressenserver

DirectAccess-Clients versuchen, den Netzwerkadressenserver zu erreichen, um zu bestimmen, ob sie sich auf dem internen Netzwerk befinden. Clients im internen Netzwerk müssen in der Lage sein, den Namen des Netzwerkadressenservers aufzulösen, befinden sie sich jedoch im Internet, dürfen sie den Namen nicht auflösen. Um dies zu gewährleisten, wird der FQDN des Netzwerkadressenservers standardmäßig als Ausnahmeregel zum NRPT hinzugefügt.

Planen der Konfigurationen von Verwaltungsservern

DirectAccess-Clients initiieren die Kommunikation mit Verwaltungsservern, die Dienste wie Windows Update und Antivirus-Updates zur Verfügung stellen. DirectAccess-Clients verwenden zudem das Kerberos-Protokoll für die Authentifizierung bei Domänencontrollern, bevor sie auf das interne Netzwerk zugreifen. Während der Remoteverwaltung von DirectAccess-Clients kommunizieren Verwaltungsserver mit Clientcomputern, um Verwaltungsfunktionen wie zum Beispiel Software- oder Hardware-Bestandsbewertungen durchzuführen. Der Remotezugriff kann automatisch bestimmte Verwaltungsserver erkennen, zum Beispiel:

  • Domänencontroller: Die automatische Ermittlung von Domänencontrollern erfolgt für die Domänen, die Clientcomputer enthalten, und für alle Domänen in derselben Gesamtstruktur wie der RAS-Server.

  • Microsoft Endpoint Configuration Manager-Server

Domänencontroller und Configuration Manager-Server werden automatisch erkannt, wenn DirectAccess erstmalig konfiguriert wird. Die erkannten Domänencontroller werden nicht an der Konsole angezeigt, aber die Einstellungen können über Windows PowerShell-Cmdlets abgerufen werden. Wenn der Domänencontroller oder die Configuration Manager-Server geändert werden, aktualisieren Sie die Liste der Verwaltungsserver an der Remotezugriffs-Verwaltungskonsole durch die Auswahl von Verwaltungsserver aktualisieren.

Verwaltungsserveranforderungen

  • Verwaltungsserver müssen über den Infrastrukturtunnel erreichbar sein. Wenn Sie Remotezugriff konfigurieren, werden diese beim Hinzufügen von Servern zur Verwaltungsserverliste automatisch über diesen Tunnel erreichbar gemacht.

  • Verwaltungsserver, die Verbindungen mit DirectAccess-Clients initiieren, müssen IPv6 vollständig unterstützen – entweder durch eine native IPv6-Adresse oder die Verwendung einer durch ISATAP zugewiesenen Adresse.

Planen der Active Directory-Anforderungen

RAS verwendet Active Directory wie folgt:

  • Authentifizierung: Der Infrastrukturtunnel verwendet NTLMv2-Authentifizierung für das Computerkonto, das eine Verbindung mit dem RAS-Server herstellt, und das Konto muss einer Active Directory-Domäne angehören. Der Intranettunnel verwendet für Benutzer*innen die Kerberos-Authentifizierung, um den Intranettunnel zu erstellen.

  • Gruppenrichtlinienobjekte: RAS erfasst die Konfigurationseinstellungen in den Gruppenrichtlinienobjekten (GPOs), die auf den RAS-Servern, den Clients und internen Anwendungsservern angewandt werden.

  • Sicherheitsgruppen: RAS verwendet Sicherheitsgruppen, um DirectAccess-Clientcomputer zu sammeln und zu identifizieren. Die Gruppenrichtlinienobjekte (GPOs) werden auf die erforderlichen Sicherheitsgruppen angewandt.

Wenn Sie eine Active Directory-Umgebung für eine RAS-Bereitstellung planen, sollten Sie die folgenden Anforderungen berücksichtigen:

  • Mindestens ein Domänencontroller wurde unter den Betriebssystemen Windows Server 2012, Windows Server 2008 R2, Windows Server 2008 oder Windows Server 2003 installiert.

    Wenn sich der Domänencontroller in einem Umkreisnetzwerk befindet (und deshalb von einem Netzwerkadapter mit Internetzugriff des RAS-Servers aus erreichbar ist), müssen Sie verhindern, dass der RAS-Server den Domänencontroller erreicht. Fügen Sie auf dem Domänencontroller Paketfilter hinzu, um Verbindungen mit der IP-Adresse des Internetadapters zu verhindern.

  • Der RAS-Server muss Domänenmitglied sein.

  • DirectAccess-Clients müssen Domänenmitglieder sein. Clients können folgenden Domänen angehören:

    • Domänen, die zur gleichen Gesamtstruktur wie der Remotezugriffsserver gehören.

    • Domänen mit bidirektionaler Vertrauensstellung zur Remotezugriffsserverdomäne.

    • Domänen in einer Gesamtstruktur mit bidirektionaler Vertrauensstellung mit der Gesamtstruktur, der die Domäne des RAS-Servers angehört.

Hinweis

  • Der Remotezugriffsserver kann nicht als Domänencontroller verwendet werden.
  • Der für den Remotezugriff verwendete Active Directory-Domänencontroller darf nicht von einem externen Internetadapter des RAS-Servers aus erreichbar sein (der Adapter darf sich nicht im Domänenprofil der Windows-Firewall befinden).

Planen der Clientauthentifizierung

Bei RAS unter Windows Server 2012 können Sie zwischen der integrierten Kerberos-Authentifizierung, die Benutzernamen und Kennwörter verwendet, und Zertifikaten für die IPsec-Computerauthentifizierung wählen.

Kerberos-Authentifizierung: Wenn Sie Active Directory-Anmeldeinformationen für die Authentifizierung verwenden, verwendet DirectAccess zunächst die Kerberos-Authentifizierung für Computer und dann die Kerberos-Authentifizierung für Benutzer*innen. Bei diesem Authentifizierungsmodus nutzt DirectAccess einen einzigen Sicherheitstunnel, der Zugriff auf den DNS-Server, den Domänencontroller, und andere Server im internen Netzwerk bietet.

IPsec-Authentifizierung: Wenn Sie sich für die Zwei-Faktor-Authentifizierung oder Netzwerkzugriffsschutz entscheiden, verwendet DirectAccess zwei Sicherheitstunnel. Der Setup-Assistent für RAS konfiguriert die Verbindungssicherheitsregeln in der Windows-Firewall mit erweiterter Sicherheit. Diese Regeln geben bei der Aushandlung der IPsec-Sicherheit mit dem RAS-Server die folgenden Anmeldeinformationen an:

  • Für den Infrastrukturtunnel erfolgt die erste Authentifizierung über die Anmeldeinformationen im Computerzertifikat und die zweite über Benutzeranmeldeinformationen (NTLMv2). Bei Benutzeranmeldeinformationen wird die Verwendung von AuthIP (Authenticated Internet Protocol) erzwungen und Zugriff auf einen DNS-Server und einen Domänencontroller bereitgestellt, bevor der DirectAccess-Client für den Intranettunnel Kerberos-Anmeldeinformationen verwenden kann.

  • Für den Intranettunnel erfolgt die erste Authentifizierung über die Anmeldeinformationen im Computerzertifikat und die zweite über Benutzeranmeldeinformationen (Kerberos v5).

Planen mehrerer Domänen

Die Liste der Verwaltungsserver sollte die Domänencontroller von allen Domänen umfassen, welche Sicherheitsgruppen enthalten, die DirectAccess-Clientcomputer beinhalten. Es sollten alle Domänen enthalten sein, die Benutzerkonten umfassen, die möglicherweise Computer nutzen, die als DirectAccess-Clients konfiguriert sind. Dadurch wird sichergestellt, dass Benutzer, die sich nicht in derselben Domäne wie der von ihnen genutzte Clientcomputer befinden, mit einem Domänencontroller in der Benutzerdomäne authentifiziert werden.

Diese Authentifizierung erfolgt automatisch, wenn sich Domänen in derselben Gesamtstruktur befinden. Im Fall von Sicherheitsgruppen mit Clientcomputern oder Anwendungsserver in unterschiedlichen Gesamtstrukturen werden die Domänencontroller dieser Gesamtstrukturen nicht automatisch erkannt. Gesamtstrukturen werden ebenfalls nicht automatisch erkannt. Sie können die Aufgabe Verwaltungsserver aktualisieren an der Remotezugriffs-Verwaltungskonsole ausführen, um diese Domänencontroller zu ermitteln.

Wenn möglich sollten allgemeine Domänennamensuffixe während der RAS-Bereitstellung der Richtlinientabelle für die Namensauflösung (Name Resolution Policy Table, NRPT) hinzugefügt werden. Wenn es zum Beispiel zwei Domänen gibt, domain1.corp.contoso.com und domain2.corp.contoso.com, können Sie, anstatt zwei Einträge zur NRPT hinzuzufügen, auch einen allgemeinen DNS-Suffix-Eintrag hinzufügen, bei dem das Domänennamensuffix corp.contoso.com ist. Dies erfolgt für Domänen im selben Stamm automatisch. Domänen, die sich nicht im selben Stamm befinden, müssen manuell hinzugefügt werden.

Planen der Erstellung von Gruppenrichtlinienobjekten

Die beim Konfigurieren des Remotezugriffs konfigurierten DirectAccess-Einstellungen werden in Gruppenrichtlinienobjekten (GPO) gesammelt. Zwei Gruppenrichtlinienobjekte werden mit DirectAccess-Einstellungen aufgefüllt und wie folgt verteilt:

  • DirectAccess-Client-Gruppenrichtlinienobjekt: Dieses Gruppenrichtlinienobjekt enthält die Clienteinstellungen, einschließlich der Einstellungen für die IPv6-Übergangstechnologie, der NRPT-Einträge und der Verbindungssicherheitsregeln für die Windows-Firewall mit erweiterter Sicherheit. Das Gruppenrichtlinienobjekt wird auf die für die Clientcomputer angegebenen Sicherheitsgruppen angewendet.

  • DirectAccess-Server-Gruppenrichtlinienobjekt: Dieses Gruppenrichtlinienobjekt enthält die DirectAccess-Konfigurationseinstellungen, die auf den als RAS-Server konfigurierten Server in Ihrer Bereitstellung angewandt werden. Außerdem enthält es die Verbindungssicherheitsregeln für die Windows-Firewall mit erweiterter Sicherheit.

Hinweis

Die Konfiguration von Anwendungsservern wird in der Remoteverwaltung von DirectAccess-Clients nicht unterstützt, da Clients nicht auf das interne Netzwerk des DirectAccess-Servers zugreifen können, in dem sich die Anwendungsserver befinden. Schritt 4 auf dem Konfigurationsbildschirm für die RAS-Einrichtung ist für diesen Konfigurationstyp nicht verfügbar.

Sie können Gruppenrichtlinienobjekte automatisch oder manuell konfigurieren.

Automatisch: Wenn Sie angeben, dass Gruppenrichtlinienobjekte automatisch erstellt werden, wird für jedes Gruppenrichtlinienobjekt ein Standardname verwendet.

Manuell: Sie können Gruppenrichtlinienobjekte verwenden, die von Active Directory-Administrator*innen vordefiniert wurden.

Beachten Sie beim Konfigurieren Ihrer Gruppenrichtlinienobjekte die folgenden Warnungen:

  • Es können keine anderen Gruppenrichtlinienobjekte mehr konfiguriert werden, nachdem DirectAccess auf die Verwendung bestimmter Gruppenrichtlinienobjekte konfiguriert wurde.

  • Wenden Sie folgendes Verfahren an, um alle RAS-Gruppenrichtlinienobjekte zu sichern, bevor Sie die DirectAccess-Cmdlets ausführen:

    Sichern und Wiederherstellen der Remotezugriffkonfiguration.

  • Unabhängig davon, ob Sie automatisch oder manuell konfigurierte Gruppenrichtlinienobjekte verwenden, müssen Sie für die Erkennung langsamer Verbindungen eine Richtlinie hinzufügen, wenn die Clients 3G verwenden. Der Pfad für die Richtlinie: Konfigurieren der Erkennung langsamer Verbindungen für die Gruppenrichtlinie lautet:

    Computerkonfiguration/Richtlinien/Administrative Vorlagen/System/Gruppenrichtlinie.

  • Wenn die korrekten Berechtigungen zum Verknüpfen der Gruppenrichtlinienobjekte nicht vorhanden sind, wird eine Warnung ausgegeben. Der Remotezugriffsvorgang wird fortgesetzt, Verknüpfungen werden jedoch nicht erstellt. Wenn diese Warnung ausgegeben wird, werden Verknüpfungen nicht automatisch erstellt, selbst wenn die Berechtigungen zu einem späteren Zeitpunkt hinzugefügt werden. Stattdessen muss der Administrator die Links manuell erstellen.

Automatisch erstellte Gruppenrichtlinienobjekte

Berücksichtigen Sie beim Verwenden automatisch erstellter Gruppenrichtlinienobjekte Folgendes:

Automatisch erstellte Gruppenrichtlinienobjekte werden entsprechend dem Standort und Verknüpfungsziel wie folgt angewandt:

  • Bei Gruppenrichtlinienobjekten des DirectAccess-Servers zeigen der Standort und das Verknüpfungsziel auf die Domäne mit dem RAS-Server.

  • Beim Erstellen der Gruppenrichtlinienobjekte für Client und Anwendungsserver wird der Standort auf eine Domäne einzelne festgelegt. Der Name des Gruppenrichtlinienobjekts wird in jeder Domäne nachgeschlagen, und die Domäne wird mit DirectAccess-Einstellungen aufgefüllt, falls vorhanden.

  • Das Verknüpfungsziel wird auf den Stamm der Domäne festgelegt, in der das Gruppenrichtlinienobjekt erstellt wurde. Für jede Domäne, die Clientcomputer oder Anwendungsserver enthält, wird ein Gruppenrichtlinienobjekt erstellt, und das Gruppenrichtlinienobjekt wird mit dem Stamm der entsprechenden Domäne verknüpft.

Beim Verwenden automatisch erstellter Gruppenrichtlinienobjekte benötigen DirectAccess-Serveradministrator*innen zum Anwenden der DirectAccess-Einstellungen folgende Berechtigungen:

  • Berechtigungen zum Erstellen von Gruppenrichtlinienobjekten für jede Domäne

  • Verknüpfungsberechtigungen für alle ausgewählten Clientdomänenstämme

  • Verknüpfungsberechtigungen für die GPO-Serverdomänenstämme

  • Sicherheitsberechtigungen zum Erstellen, Bearbeiten, Löschen und Ändern der Gruppenrichtlinienobjekte

  • Berechtigungen zum Lesen von GPOs für alle erforderlichen Domänen. Diese Berechtigung ist nicht erforderlich, wird jedoch empfohlen, da sie RAS ermöglicht, beim Erstellen von Gruppenrichtlinienobjekten zu überprüfen, ob Gruppenrichtlinienobjekte mit doppelten Namen vorhanden sind.

Manuell erstellte Gruppenrichtlinienobjekte

Beachten Sie beim Verwenden manuell erstellter Gruppenrichtlinienobjekte Folgendes:

  • Die Gruppenrichtlinienobjekte sollten vorhanden sein, bevor Sie den Remotezugriffs-Setup-Assistenten ausführen.

  • Remotezugriffsadministrator*innen benötigen zum Anwenden von DirectAccess-Einstellungen für die manuell erstellten Gruppenrichtlinienobjekte uneingeschränkte Berechtigungen (Erstellen, Bearbeiten, Löschen, Ändern).

  • In der gesamten Domäne erfolgt eine Suche nach einer Verknüpfung mit dem Gruppenrichtlinienobjekt. Wenn das Gruppenrichtlinienobjekt in der Domäne nicht verknüpft ist, wird im Domänenstamm automatisch eine Verknüpfung erstellt. Wenn die zum Erstellen der Verknüpfung erforderlichen Berechtigungen nicht verfügbar sind, wird eine Warnung ausgegeben.

Wiederherstellen eines gelöschten Gruppenrichtlinienobjekts

Wenn ein Gruppenrichtlinienobjekt auf einem RAS-Server, Client oder Anwendungsserver versehentlich gelöscht wurde, wird die folgende Fehlermeldung angezeigt: Gruppenrichtlinienobjekt (GPO-Name) nicht gefunden.

Wenn eine Sicherung verfügbar ist, können Sie das Gruppenrichtlinienobjekt aus der Sicherung wiederherstellen. Wenn keine Sicherung verfügbar ist, müssen Sie die Konfigurationseinstellungen entfernen und neu konfigurieren.

So entfernen Sie Konfigurationseinstellungen

  1. Führen Sie das Windows PowerShell-Cmdlet Uninstall-RemoteAccess aus.

  2. Öffnen Sie die Remotezugriffsverwaltung.

  3. In der angezeigten Fehlermeldung werden Sie darauf hingewiesen, dass das Gruppenrichtlinienobjekt nicht gefunden werden konnte. Klicken Sie auf Konfigurationseinstellungen entfernen. Nach Abschluss des Vorgangs wird der Server in einem nicht konfigurierten Zustand wiederhergestellt, und Sie können die Einstellungen neu konfigurieren.