Schritt 1 Planen der Remotezugriffsinfrastruktur

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

Hinweis

Windows Server 2016 kombiniert DirectAccess und Routing und Remote Access Service (RRAS) in eine einzelne Remotezugriffsrolle.

In diesem Thema werden die Schritte zur Planung einer Infrastruktur beschrieben, die Sie zum Einrichten eines einzelnen Remotezugriffsservers für die Remoteverwaltung von DirectAccess-Clients verwenden können. In der folgenden Tabelle sind die Schritte aufgeführt, diese Planungsaufgaben müssen jedoch in einer bestimmten Reihenfolge nicht ausgeführt werden.

Aufgabe BESCHREIBUNG
Planen von Netzwerktopologie- und Servereinstellungen Entscheiden Sie, wo Sie den Remotezugriffsserver (am Edge oder hinter einem Netzwerkadressenübersetzungsgerät oder einer FIREWALL) platzieren und IP-Adressierung und Routing planen.
Planen der Firewallanforderungen Planen Sie, den Remotezugriff über Edge-Firewalls zuzulassen.
Planen der Zertifikatanforderungen Entscheiden Sie, ob Sie Kerberos-Protokoll oder Zertifikate für die Clientauthentifizierung verwenden und Ihre Websitezertifikate planen.

IP-HTTPS ist ein Übergangsprotokoll, das von DirectAccess-Clients zum Tunneln von IPv6-Datenverkehr über IPv4-Netzwerke verwendet wird. Entscheiden Sie, ob sie IP-HTTPS für den Server authentifizieren möchten, indem Sie ein Zertifikat verwenden, das von einer Zertifizierungsstelle (Zertifizierungsstelle) ausgestellt wird, oder indem Sie ein selbst signiertes Zertifikat verwenden, das automatisch vom Remotezugriffsserver ausgestellt wird.
Planen der DNS-Anforderungen Planen Sie die Einstellungen des Domänennamensystems (DNS) für den Remotezugriffsserver, Infrastrukturserver, optionen für die lokale Namensauflösung und clientkonnektivität.
Planen der Netzwerkspeicherserverkonfiguration Entscheiden Sie, wo die Website des Netzwerkspeicherortservers in Ihrer Organisation (auf dem Remotezugriffsserver oder einem alternativen Server) platziert werden soll, und planen Sie die Zertifikatanforderungen, wenn sich der Netzwerkstandortserver auf dem Remotezugriffsserver befindet. Hinweis: Der Netzwerkstandortserver wird von DirectAccess-Clients verwendet, um festzustellen, ob sie sich im internen Netzwerk befinden.
Konfigurationen der Verwaltungsserver planen Berücksichtigen Sie bei der Planung Verwaltungsserver (beispielsweise Updateserver), die für die Verwaltung von Remoteclients verwendet werden. Hinweis: Administratoren können DirectAccess-Clientcomputer, die sich außerhalb des Unternehmensnetzwerks befinden, remote verwalten, indem Sie das Internet verwenden.
Planen von Active Directory-Anforderungen Planen Sie Ihre Domänencontroller, Ihre Active Directory-Anforderungen, die Clientauthentifizierung und mehrere Domänenstruktur.
Planen Gruppenrichtlinie Objekterstellung Entscheiden Sie, welche GPOs in Ihrer Organisation erforderlich sind und wie Sie die GPOs erstellen und bearbeiten können.

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. Identifizieren Sie die Topologie des Netzwerkadapters, die Sie verwenden möchten. Remotezugriff kann mit einer der folgenden Topologien eingerichtet werden:

    • Mit zwei Netzwerkadaptern: Der Remotezugriffsserver wird am Edge mit einem Netzwerkadapter installiert, der mit dem Internet und dem anderen mit dem internen Netzwerk verbunden ist.

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

    • Mit einem Netzwerkadapter: Der Remotezugriffsserver wird hinter einem NAT-Gerät installiert, und der einzelne Netzwerkadapter ist 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 konfiguriert und verwendet IPv6-Übergangstechnologien automatisch zum Tunneln von IPv6-Datenverkehr über das IPv4-Internet (6to4, Teredo oder IP-HTTPS) und über Ihr IPv4-only Intranet (NAT64 oder ISATAP). Eine Übersicht über diese Übergangstechnologien finden Sie in folgenden Ressourcen:

  3. Konfigurieren Sie erforderliche Adapter und Adressen entsprechend folgender Tabelle. Für Bereitstellungen, die sich hinter einem NAT-Gerät mit einem einzelnen Netzwerkadapter befinden, konfigurieren Sie Ihre IP-Adressen mithilfe der Spalte "Interner Netzwerkadapter ".

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

    - Zwei statische öffentliche IPv4-Adressen mit den entsprechenden Subnetzmasken (nur für Teredo erforderlich).
    - Eine Standard-Gateway-IPv4-Adresse für Ihren Internet-Firewall oder lokalen Internetdienstanbieter (ISP)-Router. Hinweis: Der Remotezugriffsserver erfordert zwei aufeinander folgende öffentliche IPv4-Adressen, damit er als Teredo-Server fungieren kann und Windows-basierte Teredo-Clients den Remotezugriffsserver verwenden können, um den Typ des NAT-Geräts zu erkennen.
    Konfigurieren Sie Folgendes:

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

    - Listen Sie die IPv4-Adressräume für alle Speicherorte im Intranet auf.
    - Verwenden Sie die route add -pnetsh interface ipv4 add route Befehle, um die IPv4-Adressräume als statische Routen in der IPv4-Routingtabelle des Remotezugriffsservers hinzuzufügen.
    IPv6-Internet und IPv6-Intranet Konfigurieren Sie Folgendes:

    - Verwenden Sie die von Ihrem ISP bereitgestellte automatisch konfigurierte Adresskonfiguration.
    - Verwenden Sie den route print Befehl, um sicherzustellen, dass eine Standard-IPv6-Route, die auf den ISP-Router verweist, in der IPv6-Routingtabelle vorhanden ist.
    - Bestimmen Sie, ob die ISP- und Intranet-Router standardroutereinstellungen verwenden, wie in RFC 4191 beschrieben, und wenn sie eine höhere Standardeinstellung als Ihre lokalen Intranet-Router 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 Paketfilter zum Domänencontroller im Umkreisnetzwerk hinzu, die die Konnektivität mit der IPv6-Adresse der Internetschnittstelle des Remotezugriffsservers verhindern.
    Konfigurieren Sie Folgendes:

    Wenn Sie keine Standardeinstellungsstufen verwenden, konfigurieren Sie Ihre Intranetschnittstellen mithilfe des netsh interface ipv6 set InterfaceIndex ignoredefaultroutes=enabled Befehls. Dieser Befehl stellt sicher, dass der IPv6-Routingtabelle keine weiteren Standardrouten hinzugefügt werden, die auf Intranetrouter zeigen. Sie können den InterfaceIndex Ihrer Intranetschnittstellen aus der Anzeige des netsh interface show interface Befehls 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-Adressräume für alle Speicherorte in Ihrem Intranet auf.
    - Verwenden Sie den netsh interface ipv6 add route Befehl, um die IPv6-Adressräume als statische Routen in der IPv6-Routingtabelle des Remotezugriffsservers hinzuzufügen.
    IPv4-Internet und IPv6-Intranet Der Remotezugriffsserver leitet den standardmäßigen IPv6-Routingdatenverkehr über die Microsoft 6to4-Adapterschnittstelle an ein 6to4-Relay im IPv4-Internet weiter. Wenn systemeigene IPv6 nicht im Unternehmensnetzwerk bereitgestellt wird, können Sie den folgenden Befehl verwenden, um einen Remotezugriffsserver für die IPv4-Adresse des Microsoft 6to4-Relays 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, wird die 6to4-Relaytechnologie verwendet, um eine Verbindung mit dem Intranet herzustellen. Wenn dem Client eine private IPv4-Adresse zugewiesen wird, 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 Remotezugriffsserver nur über einen Netzwerkadapter verfügt.
    • 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 DirectAccessclients erforderlich, sodass DirectAccess-Verwaltungsserver eine Verbindung mit DirectAccess-Clients herstellen können, die sich im Internet befinden. ISATAP ist nicht erforderlich, um Verbindungen zu unterstützen, die von DirectAccess-Clientcomputern an IPv4-Ressourcen im Unternehmensnetzwerk initiiert werden. Für diese Zwecke wird NAT64/DNS64 verwendet. Wenn Ihre Bereitstellung ISATAP erfordert, verwenden Sie die folgende Tabelle, um Ihre Anforderungen zu identifizieren.

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

1. Um sicherzustellen, dass DirectAccess-Clients über das Intranet erreichbar sind, müssen Sie Ihr IPv6-Routing so ändern, dass der Standardroutendatenverkehr an den Remotezugriffsserver weitergeleitet wird. Wenn Ihr Intranet-IPv6-Adressbereich eine andere Adresse als ein einzelnes IPv6-Bit-IPv6-Adresspräfix verwendet, müssen Sie das relevante Organisations-IPv6-Präfix während der Bereitstellung angeben.
2. Wenn Sie derzeit mit dem IPv6-Internet verbunden sind, müssen Sie ihren Standardroutendatenverkehr so konfigurieren, dass er an den Remotezugriffsserver weitergeleitet wird, und konfigurieren Sie dann die entsprechenden Verbindungen und Routen auf dem Remotezugriffsserver, sodass der Standardroutendatenverkehr an das Gerät weitergeleitet wird, das mit dem IPv6-Internet verbunden ist.
Vorhandene ISATAP-Bereitstellung Wenn Sie über eine vorhandene ISATAP-Infrastruktur verfügen, werden Sie während der Bereitstellung zum 48-Bit-Präfix der Organisation aufgefordert, und der Remotezugriffsserver konfiguriert sich nicht als ISATAP-Router. Um sicherzustellen, dass DirectAccess-Clients über das Intranet erreichbar sind, müssen Sie Ihre IPv6-Routinginfrastruktur so ändern, dass der Standardroutendatenverkehr an den Remotezugriffsserver weitergeleitet wird. Diese Änderung muss auf dem vorhandenen ISATAP-Router erfolgen, an den die Intranetclients bereits den Standarddatenverkehr weiterleiten müssen.
Keine vorhandene IPv6-Konnektivität Wenn der Remotezugriffs-Setup-Assistent erkennt, dass der Server keine systemeigene oder ISATAP-basierte IPv6-Konnektivität aufweist, leitet er automatisch ein 6to4-basiertes 48-Bit-Präfix für das Intranet ab und konfiguriert den Remotezugriffsserver als ISATAP-Router, um IPv6-Konnektivität mit ISATAP-Hosts im 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, auf der Sie ISATAP-basierte Konnektivität aktivieren möchten, sodass der ISATAP-Name vom internen DNS-Server an die interne IPv4-Adresse des Remotezugriffsservers aufgelöst werden kann.
2. Standardmäßig werden DNS-Server mit Windows Server 2012 , Windows Server 2008 R2 , Windows Server 2008 oder Windows Server 2003-Blockauflösung des ISATAP-Namens mithilfe der globalen Abfrageblockliste verwendet. Um ISATAP zu aktivieren, müssen Sie den ISATAP-Namen aus der Blockliste entfernen. Weitere Informationen finden Sie unter Entfernen von ISATAP aus der globalen DNS-Abfragesperrliste.

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

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

Wenn Ihre Windows-basierten ISATAP-Hosts eine ISATAP-basierte IPv6-Adresse abrufen, beginnen sie mit der Verwendung von ISATAP-gekapselten Datenverkehr, um zu kommunizieren, wenn das Ziel auch ein ISATAP-Host ist. Da ISATAP ein einzelnes 64-Bit-Subnetz für das gesamte Intranet verwendet, wechselt Ihre Kommunikation von einem segmentierten IPv4-Kommunikationsmodell zu einem einzelnen Subnetzkommunikationsmodell mit IPv6. Dies kann sich auf das Verhalten einiger Active Directory Domain Services (AD DS) und Anwendungen auswirken, die auf Ihrer Active Directory-Website- und Dienstkonfiguration basieren. Wenn Sie beispielsweise das Active Directory Sites and Services-Snap-In verwendet haben, um Standorte, IPv4-basierte Subnetze und Intersite-Transporte zum Weiterleiten von Anforderungen an Server innerhalb von Standorten zu konfigurieren, wird diese Konfiguration nicht von ISATAP-Hosts 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 Bereich von ISATAP-Hostadressen wie das IPv4-Subnetz ausgibt. Beispiel: 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 lautet 2002:836b:1:8000:0:5efe:192.168.99.0/120. Für eine beliebige IPv4-Präfixlänge (festgelegt auf 24 im Beispiel) können Sie die entsprechende IPv6-Präfixlänge aus der Formel 96 + IPv4PrefixLength ermitteln.
  2. Fügen Sie für die IPv6-Adressen von DirectAccess-Clients Folgendes hinzu:

    • Für Teredo-basierte DirectAccess-Clients: Ein IPv6-Subnetz für den Bereich 2001:0:WWXX:YYZZ:::/64, in dem WWXX:YYZZ die Hexadezimalversion der ersten internetbasierten IPv4-Adresse des Remotezugriffsservers ist. .
    • Für IP-HTTPS-basierte DirectAccess-Clients: Ein IPv6-Subnetz für den Bereich 2002:WWXX:YYZZ:8100::/56, in dem WWXX:YYZZ die Doppel hexadezimale Version der ersten internetbasierten IPv4-Adresse (w.x.y.z) des Remotezugriffsservers ist. .
    • Für 6to4-basierte DirectAccess-Clients: Eine Reihe von 6to4-basierten IPv6-Präfixen, die mit 2002 beginnen: und stellen die regionalen, öffentlichen IPv4-Adresspräfixe dar, die von der Internet Assigned Numbers Authority (IANA) und regionalen Registrierungen 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 6to4-basierte Präfix für diesen öffentlichen IPv6-Adressbereich ist 2002:700:::/24. Informationen zum öffentlichen Adressbereich von IPv4 finden Sie in der IANA IPv4 Address Space Registry. .

Wichtig

Stellen Sie sicher, dass Auf der internen Schnittstelle des DirectAccess-Servers keine öffentlichen IP-Adressen vorhanden sind. Wenn Sie über eine öffentliche IP-Adresse auf der internen Schnittstelle verfügen, schlägt die Konnektivität über ISATAP möglicherweise fehl.

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 und TCP-Quellport 443 ausgehend.

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

  • Für 6to4 Datenverkehr: IP-Protokoll 41 eingehender und ausgehender Datenverkehr.

    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 ausnahmen auf die Adresse angewendet werden, die auf dem öffentlichen DNS-Server registriert ist.

  • Wenn Sie Remotezugriff mit einem einzelnen Netzwerkadapter bereitstellen und den Netzwerkspeicherortserver auf dem Remotezugriffsserver installieren, port 62000.

    Hinweis

    Diese Ausnahme befindet sich auf dem Remotezugriffsserver, und die vorherigen Ausnahmen befinden sich auf der Edgefirewall.

Die folgenden Ausnahmen sind für Remotezugriffsdatenverkehr erforderlich, wenn sich der Remotezugriffsserver im IPv6-Internet befindet:

  • IP-Protokoll 50

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

  • ICMPv6-Datenverkehr eingehender und ausgehender Datenverkehr (nur bei Verwendung von Teredo).

Wenn Sie zusätzliche Firewalls verwenden, wenden Sie die folgenden internen Netzwerkfirewall-Ausnahmen für Remotezugriffsdatenverkehr an:

  • Für ISATAP: Protokoll 41 eingehendes und ausgehendes Protokoll

  • Für alle IPv4/IPv6-Datenverkehr: TCP/UD

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

Planen der Zertifikatanforderungen

Es gibt drei Szenarien, die Zertifikate erfordern, wenn Sie einen einzelnen Remotezugriffsserver bereitstellen.

  • IPsec-Authentifizierung: Zertifikatanforderungen für IPsec umfassen ein Computerzertifikat, das von DirectAccess-Clientcomputern verwendet wird, wenn sie die IPsec-Verbindung mit dem Remotezugriffsserver einrichten, und ein Computerzertifikat, das von Remotezugriffsservern verwendet wird, um IPsec-Verbindungen mit DirectAccess-Clients einzurichten.

    Für DirectAccess in Windows Server 2012 ist die Verwendung dieser IPsec-Zertifikate nicht obligatorisch. Alternativ kann der Remotezugriffsserver ohne Zertifikate als Proxy für die Kerberos-Authentifizierung fungieren. Wenn die Kerberos-Authentifizierung verwendet wird, funktioniert sie über SSL, und das Kerberos-Protokoll verwendet das Zertifikat, das für IP-HTTPS konfiguriert wurde. Einige Unternehmensszenarien (einschließlich Multisite-Bereitstellung und einmaliger Kennwortclientauthentifizierung) erfordern die Verwendung der Zertifikatauthentifizierung und nicht die Kerberos-Authentifizierung.

  • IP-HTTPS-Server: Wenn Sie Remotezugriff konfigurieren, wird der Remotezugriffsserver automatisch so konfiguriert, dass er als IP-HTTPS-Weblistener fungiert. 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.

  • Netzwerkspeicherortserver: Der Netzwerkspeicherortserver ist eine Website, die verwendet wird, um zu ermitteln, 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.

Die Anforderungen der Zertifizierungsstelle für jede dieser Szenarien werden in der folgenden Tabelle zusammengefasst.

IPsec-Authentifizierung IP-HTTPS-Server Netzwerkadressenserver
Eine interne Zertifizierungsstelle ist erforderlich, um Computerzertifikate an den Remotezugriffsserver und Clients für die IPsec-Authentifizierung auszustellen, wenn Sie das Kerberos-Protokoll nicht für die Authentifizierung verwenden. Interne Zertifizierungsstelle: Sie können eine interne Zertifizierungsstelle verwenden, um das IP-HTTPS-Zertifikat auszustellen; Sie müssen jedoch sicherstellen, dass der CRL-Verteilungspunkt extern verfügbar ist. Interne Zertifizierungsstelle: Sie können eine interne Zertifizierungsstelle verwenden, um das Websitezertifikat des Netzwerkspeicherortservers auszugeben. 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 Website des Netzwerkspeicherortservers verwenden; Sie können jedoch kein selbstsigniertes Zertifikat in bereitstellungen mit mehreren Websites verwenden.
Öffentliche Zertifizierungsstelle: Es wird empfohlen, eine öffentliche Zertifizierungsstelle zum Ausgeben des IP-HTTPS-Zertifikats zu verwenden. Dadurch wird sichergestellt, dass der CRL-Verteilungspunkt extern verfügbar ist.

Planen von Computerzertifikaten für IPsec-Authentifizierung

Wenn Sie die zertifikatbasierte IPsec-Authentifizierung verwenden, sind der Remotezugriffsserver und die Clients erforderlich, um ein Computerzertifikat abzurufen. Die einfachste Möglichkeit zum Installieren der Zertifikate besteht darin, Gruppenrichtlinie zum Konfigurieren der automatischen Registrierung für Computerzertifikate zu verwenden. 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 über die Erweiterte Schlüsselverwendung (EKU) für die Clientauthentifizierung verfügen.

  • Der Client und die Serverzertifikate sollten sich auf dasselbe Stammzertifikat beziehen. 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 Betrefffeld die IPv4-Adresse des Internetadapters des Remotezugriffsservers oder den FQDN der IP-HTTPS-URL (die ConnectTo-Adresse) an. 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.

  • Verwenden Sie für das Feld "Erweiterte Schlüsselverwendung " den Serverauthentifizierungsobjektbezeichner (OID).

  • 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 für Clients erforderlich, die Windows 7 ausführen.

  • 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

Berücksichtigen Sie folgendes, wenn Sie die Website des Netzwerkspeicherortservers planen:

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

  • Verwenden Sie für das Feld " Erweiterte Schlüsselverwendung " das Serverauthentifizierungs-OID.

  • Verwenden Sie für das Feld CRL-Verteilungspunkte einen CRL-Verteilungspunkt , auf den directAccess-Clients zugegriffen werden kann, die mit dem Intranet verbunden sind. Der Zertifikatsperrlisten-Verteilungspunkt sollte nicht von außerhalb des internen Netzwerks zugänglich sein.

Hinweis

Stellen Sie sicher, dass die Zertifikate für DEN IP-HTTPS- und Netzwerkspeicherortserver einen Antragstellernamen haben. Wenn das Zertifikat einen alternativen Namen verwendet, wird es vom Remotezugriffs-Assistenten nicht akzeptiert.

Planen der DNS-Anforderungen

In diesem Abschnitt werden die DNS-Anforderungen für Clients und Server in einer Remotezugriffsbereitstellung erläutert.

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-Netzwerkspeicherortserver herzustellen, um festzustellen, ob sie sich im Internet oder im Unternehmensnetzwerk befinden.

  • Wenn die Verbindung erfolgreich ist, werden Clients bestimmt, dass sie sich im Intranet befinden, DirectAccess wird nicht verwendet, und Clientanforderungen werden mithilfe des DNS-Servers aufgelöst, der auf dem 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 FQDN- oder Einzelbezeichnungsnamen an, z <https://internal>. B. . Wenn ein Name mit einer einzelnen Bezeichnung gefordert ist, wird ein DNS-Suffix angehängt, um einen FQDN zu bilden. Wenn die DNS-Abfrage mit einem Eintrag im NRPT und DNS4 übereinstimmt oder ein Intranet-DNS-Server für den Eintrag angegeben wird, wird die Abfrage mithilfe des angegebenen Servers zur Namensauflösung gesendet. Wenn eine Übereinstimmung vorhanden ist, aber kein DNS-Server angegeben wird, wird eine Ausnahmeregel und normale Namensauflösung angewendet.

Wenn der NRPT in der Remotezugriffsverwaltungskonsole ein neues Suffix hinzugefügt wird, können die Standard-DNS-Server für das Suffix automatisch ermittelt werden, indem Sie auf die Schaltfläche " Erkennen " klicken. Die automatische Erkennung funktioniert wie folgt:

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

  • 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 den Namen des Netzwerkspeicherortservers auflösen können, und sie müssen daran gehindert werden, den Namen zu auflösen, wenn sie sich im Internet befinden. 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 Remotezugriffsservers und die IPv6-Adressen, die den Intranet-DNS-Servern entsprechen, die auf dem Remotezugriffsserver konfiguriert sind. 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 z. B. die URL des Netzwerkspeicherortservers lautet https://nls.corp.contoso.com, wird eine Ausnahmeregel für den FQDN-nls.corp.contoso.com erstellt.

  • IP-HTTPS-Server

    Der Remotezugriffsserver fungiert als IP-HTTPS-Listener und verwendet sein Serverzertifikat, um sich bei IP-HTTPS-Clients zu authentifizieren. Der IP-HTTPS-Name muss von DirectAccess-Clients aufgelöst werden, 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 auf die interne IPv4-Adresse des Remotezugriffsservers oder auf die IPv6-Adresse in einer IPv6-Umgebung aufgelöst werden.

  • directaccess-corpconnectivityhost sollte in die lokale Hostadresse (Loopback) aufgelöst werden. Sie sollten A- und AAAA-Einträge erstellen. Der Wert des A-Eintrags ist 127.0.0.1, und der Wert des AAAA-Eintrags wird aus dem NAT64-Präfix mit den letzten 32 Bits als 127.0.0.1 erstellt. Das NAT64-Präfix kann abgerufen werden, indem das Cmdlet Get-netnatTransitionConfiguration Windows PowerShell ausgeführt wird.

    Hinweis

    Dies ist nur in IPv4-Umgebungen gültig. Erstellen Sie in einer IPv4 plus IPv6- oder IPv6-only-Umgebung nur einen AAAA-Eintrag mit der Loopback-IP-Adresse ::1.

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

DNS-Serveranforderungen
  • Für DirectAccess-Clients müssen Sie einen DNS-Server mit Windows Server 2012 , Windows Server 2008 R2, Windows Server 2008, Windows Server 2003 oder einen beliebigen DNS-Server verwenden, der IPv6 unterstützt.

  • Sie sollten einen DNS-Server verwenden, der dynamische Updates unterstützt. Sie können DNS-Server verwenden, die keine dynamischen Updates unterstützen, aber dann müssen Einträge manuell aktualisiert werden.

  • Der FQDN für Ihre CRL-Verteilungspunkte muss mithilfe von Internet-DNS-Servern aufgelöst werden. Wenn sich z. B. die URL https://crl.contoso.com/crld/corp-DC1-CA.crl im Feld "CRL-Verteilungspunkte " des IP-HTTPS-Zertifikats des Remotezugriffsservers befindet, müssen Sie sicherstellen, dass der FQDN-crld.contoso.com mithilfe von Internet-DNS-Servern aufgelöst werden kann.

Planen der Auflösung lokaler Namen

Berücksichtigen Sie folgendes, wenn Sie die Lösung für lokale Namen planen:

NRPT

Möglicherweise müssen Sie in den folgenden Situationen zusätzliche Regeln für die Namensauflösungsrichtlinie (NRPT) erstellen:

  • Sie müssen weitere DNS-Suffixe für Ihren Intranetnamespace hinzufügen.

  • Wenn die FQDNs Ihrer CRL-Verteilungspunkte auf Ihrem Intranetnamespace basieren, müssen Sie Ausnahmenregeln für die FQDNs der CRL-Verteilungspunkte hinzufügen.

  • Wenn Sie über eine DNS-Umgebung mit geteiltem Gehirn verfügen, müssen Sie Ausnahmeregeln für die Namen von Ressourcen hinzufügen, für die sich DirectAccess-Clients befinden, die sich im Internet befinden, anstatt auf die Intranetversion zuzugreifen.

  • Wenn Sie den Datenverkehr über Ihre Intranetwebproxyserver an eine externe Website umleiten, ist die externe Website nur über das Intranet verfügbar. Es verwendet die Adressen Ihrer Webproxyserver, um die eingehenden Anforderungen zuzulassen. Fügen Sie in dieser Situation eine Ausnahmeregel für den FQDN der externen Website hinzu, und geben Sie an, dass die Regel Ihren Intranetwebproxyserver anstelle der IPv6-Adressen von Intranet-DNS-Servern verwendet.

    Angenommen, Sie testen eine externe Website mit dem Namen test.contoso.com. Dieser Name kann nicht über Internet-DNS-Server aufgelöst werden, aber der Contoso-Webproxyserver weiß, wie der Name aufgelöst wird und wie Anforderungen für die Website an den externen Webserver weitergeleitet werden. 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. Daher können Intranetbenutzer auf die Website zugreifen, da sie den Contoso-Webproxy verwenden, aber DirectAccess-Benutzer können nicht, weil sie 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

Einzelne Bezeichnungsnamen, z <https://paycheck>. B. , werden manchmal für Intranetserver verwendet. Wenn ein einzelner Bezeichnungsname angefordert wird und eine DNS-Suffixsuchliste konfiguriert ist, werden die DNS-Suffixe in der Liste an den Namen der einzelnen Bezeichnung angefügt. Wenn beispielsweise ein Benutzer auf einem Computer, der Mitglied der corp.contoso.com Domänentypen <https://paycheck> im Webbrowser ist, den FQDN, der als Name erstellt wird, paycheck.corp.contoso.com. Standardmäßig basiert das angefügte Suffix auf dem primären DNS-Suffix des Clientcomputers.

Hinweis

In einem nicht zusammenhängenden Namensraumszenario (bei dem mindestens ein Domänencomputer über ein DNS-Suffix verfügt, das nicht mit der Active Directory-Domäne übereinstimmt, mit der die Computer Mitglieder sind), sollten Sie sicherstellen, dass die Suchliste angepasst wird, um alle erforderlichen Suffixe einzuschließen. Standardmäßig konfiguriert der Remotezugriffs-Assistent den Active Directory-DNS-Namen als primäres DNS-Suffix auf dem Client. Stellen Sie sicher, dass Sie das DNS-Suffix hinzufügen, das von den Clients für die Namensauflösung verwendet wird.

Wenn mehrere Domänen und Windows Internet Name Service (WINS) in Ihrer Organisation bereitgestellt werden und Sie remote eine Verbindung herstellen, können Einzelnamen wie folgt aufgelöst werden:

  • Indem Sie eine WINS-Nachschlagezone im DNS bereitstellen. Beim Versuch, computername.dns.zone1.corp.contoso.com zu beheben, wird die Anforderung an den WINS-Server weitergeleitet, der nur den Computernamen verwendet. Der Client denkt, dass es eine reguläre DNS A-Eintragsanforderung ausgibt, aber es ist tatsächlich eine NetBIOS-Anforderung.

    Weitere Informationen finden Sie unter Verwalten einer Forward Lookup Zone.

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

Split-Brain-DNS

Split-Brain DNS bezieht sich auf die Verwendung derselben DNS-Domäne für die Auflösung von Internet- und Intranetnamen.

Bei Split-Brain-DNS-Bereitstellungen müssen Sie die FQDNs auflisten, die im Internet und Intranet dupliziert sind, und entscheiden, welche Ressourcen der DirectAccess-Client über das Intranet oder die Internetversion verfügen soll. Wenn DirectAccess-Clients die Internetversion erreichen möchten, müssen Sie den entsprechenden FQDN als Ausnahmeregel zum NRPT für jede Ressource hinzufügen.

Konfigurieren Sie in einer Dns-Umgebung mit geteiltem Gehirn, wenn beide Versionen der Ressource verfügbar sein sollen, Ihre Intranetressourcen mit Namen, die nicht die Namen duplizieren, die im Internet verwendet werden. Weisen Sie die Benutzer dann an, den alternativen Namen zu verwenden, wenn sie auf die Ressource im Intranet zugreifen. Konfigurieren Sie beispielsweise www.internal.contoso.com für den internen Namen von www.contoso.com.

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 contoso.com Suffix entsprechen nicht der corp.contoso.com Intranet-Namespaceregel im NRPT, und sie werden 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 Internet- als auch Intranetressourcen für ihre 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 die lokale Namenauflösung verwenden, wobei die Link-Local Multicast Name Resolution (LLMNR) und NetBIOS over TCP/IP-Protokolle verwendet werden, um den Namen im lokalen Subnetz zu beheben. 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 lokale Namenauflösung für Intranetservernamen ausführt und der Computer mit einem freigegebenen Subnetz im Internet verbunden ist, können böswillige Benutzer LLMNR und NetBIOS über TCP/IP-Nachrichten erfassen, um Intranetservernamen zu bestimmen. Auf der DNS-Seite des Assistenten zum Einrichten des Infrastrukturservers können Sie das lokale Namensauflösungsverhalten basierend auf den Typen der von Intranet-DNS-Servern empfangenen Antworten konfigurieren. Die folgenden Optionen sind verfügbar:

  • Verwenden Sie die lokale Namensauflösung, wenn der Name nicht in DNS vorhanden ist: Diese Option ist am sichersten, da der DirectAccess-Client nur lokale Namenauflösung für Servernamen ausführt, die von Intranet-DNS-Servern nicht 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.

  • Verwenden Sie die lokale Namensauflösung, wenn der Name nicht auf DNS- oder DNS-Servern vorhanden ist, wenn sich der Clientcomputer auf einem privaten Netzwerk befindet (empfohlen): Diese Option wird empfohlen, da die Verwendung der lokalen Namensauflösung in einem privaten Netzwerk nur möglich ist, wenn die Intranet-DNS-Server nicht erreichbar sind.

  • Verwenden Sie die lokale Namensauflösung für einen beliebigen DNS-Auflösungsfehler (am wenigsten sicher): Dies ist die am wenigsten sichere Option, da die Namen von Intranetnetzwerkservern über die lokale Namenauflösung an das lokale Subnetz verleckt werden können.

Planen der Netzwerkspeicherserverkonfiguration

Der Netzwerkadressenserver ist eine Website, die erkennt, ob sich DirectAccess-Clients im Unternehmensnetzwerk befinden. Clients im Unternehmensnetzwerk verwenden directAccess nicht, um interne Ressourcen zu erreichen; stattdessen verbinden sie sich direkt.

Die Website des Netzwerkspeicherortservers kann auf dem Remotezugriffsserver oder auf einem anderen Server in Ihrer Organisation gehostet werden. Wenn Sie den Netzwerkspeicherortserver auf dem Remotezugriffsserver hosten, wird die Website automatisch erstellt, wenn Sie Remotezugriff bereitstellen. Wenn Sie den Netzwerkspeicherortserver auf einem anderen Server hosten, auf dem ein Windows Betriebssystem ausgeführt wird, müssen Sie sicherstellen, dass Internetinformationsdienste (IIS) auf diesem Server installiert ist und dass die Website erstellt wird. Remotezugriff konfiguriert keine Einstellungen auf dem Netzwerkspeicherortserver.

Stellen Sie sicher, dass die Website des Netzwerkstandortservers die folgenden Anforderungen erfüllt:

  • Verfügt über ein HTTPS-Serverzertifikat.

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

  • Ist nicht auf DirectAccess-Clientcomputer im Internet zugänglich.

Berücksichtigen Sie außerdem die folgenden Anforderungen für Clients, wenn Sie Ihre Netzwerkstandortserverwebsite 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 Netzwerkspeicherortserver

Wenn Sie das Websitezertifikat abrufen, das für den Netzwerkspeicherortserver verwendet werden soll, sollten Sie folgendes berücksichtigen:

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

  • Verwenden Sie für das Feld "Erweiterte Schlüsselverwendung " das Serverauthentifizierungs-OID.

  • Das Netzwerkspeicherserverzertifikat muss auf eine Zertifikatsperrliste (CRL) überprüft werden. Verwenden Sie für das Feld "CRL-Verteilerpunkte" einen CRL-Verteilungspunkt , auf den DirectAccess-Clients zugreifen können, die mit dem Intranet verbunden sind. Der Zertifikatsperrlisten-Verteilungspunkt sollte nicht von außerhalb des internen Netzwerks zugänglich sein.

Planen von DNS für den Netzwerkspeicherortserver

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.

Konfiguration von Verwaltungsservern planen

DirectAccess-Clients initiieren die Kommunikation mit Verwaltungsservern, die Dienste wie Windows Update und Antivirusupdates bereitstellen. DirectAccess-Clients verwenden auch das Kerberos-Protokoll, um sich bei Domänencontrollern zu authentifizieren, 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: Automatische Ermittlung von Domänencontrollern wird für die Domänen ausgeführt, die Clientcomputer enthalten und für alle Domänen in derselben Gesamtstruktur wie der Remotezugriffsserver.

  • Microsoft Endpoint Configuration Manager Server

Domänencontroller und Configuration Manager Server werden automatisch erkannt, wenn DirectAccess zum ersten Mal konfiguriert ist. Die erkannten Domänencontroller werden in der Konsole nicht angezeigt, die Einstellungen können jedoch mithilfe Windows PowerShell Cmdlets abgerufen werden. Wenn Domänencontroller oder Configuration Manager Server geändert werden, klicken Sie auf Update-Verwaltungsserver in der Konsole aktualisiert die Verwaltungsserverliste.

Verwaltungsserveranforderungen

  • Verwaltungsserver müssen über den Infrastrukturtunnel zugänglich 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, indem sie eine native IPv6-Adresse oder eine von ISATAP zugewiesene Adresse verwenden.

Planen von Active Directory-Anforderungen

Remotezugriff verwendet Active Directory wie folgt:

  • Authentifizierung: Der Infrastrukturtunnel verwendet DIE NTLMv2-Authentifizierung für das Computerkonto, das eine Verbindung mit dem Remotezugriffsserver herstellt, und das Konto muss sich in einer Active Directory-Domäne befinden. Der Intranettunnel verwendet die Kerberos-Authentifizierung für den Benutzer, um den Intranettunnel zu erstellen.

  • Gruppenrichtlinie Objekte: Remote Access sammelt Konfigurationseinstellungen in Gruppenrichtlinie Objekte (GPOs), die auf Remotezugriffsserver, Clients und interne Anwendungsserver angewendet werden.

  • Sicherheitsgruppen: Remotezugriff verwendet Sicherheitsgruppen zum Sammeln und Identifizieren von DirectAccess-Clientcomputern. GPOs werden auf die erforderlichen Sicherheitsgruppen angewendet.

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

  • Mindestens ein Domänencontroller wird auf dem Windows Server 2012, Windows Server 2008 R2 Windows Server 2008 oder Windows Server 2003 Betriebssystem installiert.

    Wenn sich der Domänencontroller auf einem Umkreisnetzwerk befindet (und daher über den internetseitigen Netzwerkadapter des Remotezugriffsservers erreichbar ist), verhindern Sie, dass der Remotezugriffsserver darauf zugreifen kann. Sie müssen Paketfilter auf dem Domänencontroller hinzufügen, um die Verbindung 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.

    • Jede Domäne in einer Gesamtstruktur, die eine Zwei-Wege-Vertrauensstellung mit der Gesamtstruktur der Remotezugriffsserverdomäne aufweist.

Hinweis

  • Der Remotezugriffsserver kann nicht als Domänencontroller verwendet werden.
  • Der Active Directory-Domänencontroller, der für Remotezugriff verwendet wird, darf nicht über den externen Internetadapter des Remotezugriffsservers erreichbar sein (der Adapter darf sich nicht im Domänenprofil der Windows Firewall befinden).

Planen der Clientauthentifizierung

In remote Access in Windows Server 2012 können Sie zwischen der integrierten Kerberos-Authentifizierung wählen, die Benutzernamen und Kennwörter verwendet oder Zertifikate für die IPsec-Computerauthentifizierung verwendet.

Kerberos-Authentifizierung: Wenn Sie Active Directory-Anmeldeinformationen für die Authentifizierung verwenden, verwendet DirectAccess zuerst die Kerberos-Authentifizierung für den Computer, und dann wird die Kerberos-Authentifizierung für den Benutzer verwendet. Wenn Sie diesen Authentifizierungsmodus verwenden, verwendet DirectAccess einen einzelnen Sicherheitstunnel, der Zugriff auf den DNS-Server, den Domänencontroller und alle anderen Server im internen Netzwerk bereitstellt.

IPsec-Authentifizierung: Wenn Sie die zweistufige Authentifizierung oder den Netzwerkzugriffsschutz verwenden, verwendet DirectAccess zwei Sicherheitstunnel. Der Remotezugriffs-Setup-Assistent konfiguriert Verbindungssicherheitsregeln in Windows Firewall mit erweiterter Sicherheit. Diese Regeln geben die folgenden Anmeldeinformationen beim Verhandeln von IPsec-Sicherheit auf den Remotezugriffsserver an:

  • Der Infrastrukturtunnel verwendet Computerzertifikatanmeldeinformationen für die erste Authentifizierung und die Anmeldeinformationen (NTLMv2) für die zweite Authentifizierung. Benutzeranmeldeinformationen erzwingen die Verwendung des authentifizierten Internetprotokolls (AuthIP), und sie bieten Zugriff auf einen DNS-Server und Domänencontroller, bevor der DirectAccess-Client Kerberos-Anmeldeinformationen für den Intranettunnel verwenden kann.

  • Der Intranettunnel verwendet Computerzertifikatanmeldeinformationen für die erste Authentifizierung und den Benutzer (Kerberos V5) für die zweite Authentifizierung.

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 sollte alle Domänen enthalten, die Benutzerkonten enthalten, die Computer verwenden können, 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 ist automatisch, wenn sich die Domänen in derselben Gesamtstruktur befinden. Wenn eine Sicherheitsgruppe mit Clientcomputern oder Anwendungsservern vorhanden ist, die sich in verschiedenen Gesamtstrukturen befinden, werden die Domänencontroller dieser Gesamtstrukturen nicht automatisch erkannt. Auch Gesamtstrukturen werden nicht automatisch erkannt. Sie können die Aufgabenaktualisierungsverwaltungsserver in der Remotezugriffsverwaltung ausführen, um diese Domänencontroller zu erkennen.

Bei der Remotezugriffsbereitstellung sollten häufig verwendete Domänennamenssuffixe dem 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 geschieht automatisch für Domänen im gleichen Stamm. Domänen, die sich nicht im gleichen Stamm befinden, müssen manuell hinzugefügt werden.

Planen Gruppenrichtlinie Objekterstellung

Wenn Sie Remotezugriff konfigurieren, werden DirectAccess-Einstellungen in Gruppenrichtlinie Objekte (GPOs) gesammelt. Zwei GPOs werden mit DirectAccess-Einstellungen aufgefüllt, und sie werden wie folgt verteilt:

  • DirectAccess-Client-GPO: Dieses Gruppenrichtlinienobjekt enthält Clienteinstellungen, einschließlich IPv6-Übergangstechnologieneinstellungen, NRPT-Einträge und Verbindungssicherheitsregeln für 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 jeden Server angewendet werden, den Sie in Ihrer Bereitstellung als Remotezugriffsserver konfiguriert haben. Es enthält auch Verbindungssicherheitsregeln für 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, auf den sich die Anwendungsserver befinden. Schritt 4 im Konfigurationsbildschirm für den Remotezugriff ist für diesen Konfigurationstyp nicht verfügbar.

Sie können GPOs automatisch oder manuell konfigurieren.

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

Manuell: Sie können GPOs verwenden, die vom Active Directory-Administrator vordefinierte Wurden.

Wenn Sie Ihre GPOs konfigurieren, sollten Sie die folgenden Warnungen berücksichtigen:

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

  • Verwenden Sie das folgende Verfahren, um alle Remotezugriffs-Gruppenrichtlinie Objekte zu sichern, bevor Sie DirectAccess-Cmdlets ausführen:

    Sichern und Wiederherstellen der Remotezugriffkonfiguration.

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

    Computerkonfiguration/Richtlinien/Administrative Vorlagen/System/Gruppenrichtlinie.

  • Wenn die richtigen Berechtigungen für die Verknüpfung von GPOs nicht vorhanden sind, wird eine Warnung ausgegeben. Der Remotezugriffsvorgang wird fortgesetzt, die Verknüpfung tritt jedoch nicht auf. Wenn diese Warnung ausgestellt wird, werden Links nicht automatisch erstellt, auch wenn die Berechtigungen später hinzugefügt werden. Stattdessen muss der Administrator die Links manuell erstellen.

Automatisch erstellte GPOs

Berücksichtigen Sie folgendes, wenn Sie automatisch erstellte GPOs verwenden:

Automatisch erstellte GPOS werden entsprechend dem Standort- und Linkziel wie folgt angewendet:

  • Für das DirectAccess-Server-Gruppenrichtlinienobjekt verweist der Speicherort und der Linkziel auf die Domäne, die den Remotezugriffsserver enthält.

  • Wenn Client- und Anwendungsserver-GPOs erstellt werden, wird der Speicherort auf eine einzelne Domäne festgelegt. Der GPO-Name wird in jeder Domäne nachschlagen, und die Domäne wird mit DirectAccess-Einstellungen ausgefüllt, sofern 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.

Wenn Sie automatisch erstellte GPOs verwenden, um DirectAccess-Einstellungen anzuwenden, erfordert der Remotezugriffsserveradministrator die folgenden Berechtigungen:

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

  • Berechtigungen zum Verknüpfen mit allen ausgewählten Clientdomänenstammen.

  • Berechtigungen zum Verknüpfen mit den Stammwurzeln der Server-GPO-Domäne.

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

  • GPO-Leseberechtigungen für jede erforderliche Domäne. Diese Berechtigung ist nicht erforderlich, es wird jedoch empfohlen, weil der Remotezugriff aktiviert, um zu überprüfen, ob GPOs mit doppelten Namen nicht vorhanden sind, wenn GPOs erstellt werden.

Manuelles Erstellen von GPOs

Beachten Sie beim Verwenden manuell erstellter Gruppenrichtlinienobjekte Folgendes:

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

  • Um DirectAccess-Einstellungen anzuwenden, erfordert der Remotezugriffsserveradministrator vollständige Sicherheitsberechtigungen zum Erstellen, Bearbeiten, Löschen und Ändern der manuell erstellten GPOs.

  • Eine Suche wird für einen Link zum Gruppenrichtlinienobjekt in der gesamten Domäne erstellt. 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 GPO auf einem Remotezugriffsserver, Client oder Anwendungsserver versehentlich gelöscht wurde, wird die folgende Fehlermeldung angezeigt: GPO (GPO-Name) kann nicht gefunden werden.

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 erneut 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 wird der Server in einen nicht konfigurierten Zustand wiederhergestellt, und Sie können die Einstellungen neu konfigurieren.