Krok 1. Planowanie zaawansowanej infrastruktury DirectAccess

Pierwszym krokiem planowania zaawansowanego wdrożenia funkcji DirectAccess na jednym serwerze jest zaplanowanie infrastruktury wymaganej do wdrożenia. W tym temacie opisano kroki planowania infrastruktury. Te zadania planowania nie muszą być wykonywane w określonej kolejności.

1.1 Planowanie topologii i ustawień sieci

W tej sekcji opisano sposób planowania sieci, w tym:

• 1.1.1 Planowanie kart sieciowych i adresowania IP

• 1.1.2 Planowanie łączności intranetowej IPv6

• 1.1.3 Planowanie tunelowania wymuszonego

1.1.1 Planowanie adapterów sieciowych i adresów IP

1. Zidentyfikuj topologię karty sieciowej, której chcesz użyć. Funkcję DirectAccess można skonfigurować przy użyciu jednej z następujących topologii:

   • Dwie karty sieciowe. Serwer DirectAccess można zainstalować na granicy sieci z jedną kartą sieciową połączoną z Internetem i drugą z siecią wewnętrzną, lub zainstalować go za translatorem adresów sieciowych, zaporą sieciową lub routerem, z jedną kartą sieciową połączoną z siecią obwodową i drugą z siecią wewnętrzną.

   • Jedna karta sieciowa. Serwer DirectAccess jest zainstalowany za urządzeniem NAT, a pojedyncza karta sieciowa jest podłączona do sieci wewnętrznej.

2. Zidentyfikuj wymagania dotyczące adresowania IP:

   Funkcja DirectAccess używa protokołu IPv6 z protokołem IPsec, aby utworzyć bezpieczne połączenie między komputerami klienckimi funkcji DirectAccess i wewnętrzną siecią firmową. Jednak funkcja DirectAccess nie musi wymagać łączności z Internetem IPv6 lub natywną obsługą protokołu IPv6 w sieciach wewnętrznych. Zamiast tego automatycznie konfiguruje i wykorzystuje technologie przejścia IPv6 do tunelowania ruchu IPv6 przez Internet IPv4 (przy użyciu 6to4, Teredo lub IP-HTTPS) oraz w intranecie obsługującym tylko IPv4 (przy użyciu NAT64 lub ISATAP). Aby zapoznać się z omówieniem tych technologii przejściowych, zobacz następujące zasoby:

   • technologie przejściowe IPv6

   • IP-HTTPS specyfikacja protokołu tunelowania

3. Skonfiguruj wymagane adaptery i adresy zgodnie z poniższą tabelą. W przypadku wdrożeń korzystających z jednej karty sieciowej i skonfigurowanych za urządzeniem NAT skonfiguruj adresy IP przy użyciu tylko kolumny Wewnętrzna karta sieciowa .

   Description	Zewnętrzna karta sieciowa	Wewnętrzna karta sieciowa	Wymagania dotyczące routingu
   IPv4 Internet i IPv4 intranet	Skonfiguruj dwa statyczne kolejne publiczne adresy IPv4 z odpowiednimi maskami podsieci (wymaganymi tylko dla teredo). Skonfiguruj również domyślny adres IPv4 bramy zapory internetowej lub lokalnego routera usługodawcy internetowego. Nuta: Serwer funkcji DirectAccess wymaga dwóch kolejnych publicznych adresów IPv4, dzięki czemu może działać jako serwer Teredo i klienci z systemem Windows mogą używać serwera DirectAccess do wykrywania typu urządzenia NAT, które znajdują się za nimi.	Skonfiguruj następujące elementy: — adres intranetowy IPv4 z odpowiednią maską podsieci. - Sufiks DNS przestrzeni nazw intranetu specyficzny dla połączenia. Serwer DNS powinien być również skonfigurowany w interfejsie wewnętrznym. Ostrożność: Nie należy konfigurować bramy domyślnej w żadnych interfejsach intranetowych.	Aby skonfigurować serwer funkcji DirectAccess, aby uzyskać dostęp do wszystkich podsieci w wewnętrznej sieci IPv4, wykonaj następujące czynności: — Wyświetl listę przestrzeni adresowych IPv4 dla wszystkich lokalizacji w intranecie. - Użyj polecenia route add -p lub netsh interface ipv4 add route, aby dodać przestrzenie adresowe IPv4 jako trasy statyczne w tabeli routingu IPv4 serwera DirectAccess.
   Internet IPv6 i intranet IPv6	Skonfiguruj następujące elementy: — Użyj konfiguracji adresu dostarczonej przez usługodawcę internetowego. — Użyj polecenia Route Print , aby upewnić się, że istnieje domyślna trasa IPv6 i wskazuje router isP w tabeli routingu IPv6. - Określ, czy usługodawca internetowy i routery intranetowe korzystają z domyślnych preferencji routera opisanych w specyfikacji RFC 4191, oraz czy używają wyższej domyślnej preferencji niż lokalne routery intranetowe. Jeśli obie te wartości są prawdziwe, nie jest wymagana żadna inna konfiguracja trasy domyślnej. Wyższa preferencja routera usługodawcy internetowego gwarantuje, że aktywna domyślna trasa IPv6 serwera DirectAccess wskazuje na sieć IPv6 Internet. Ponieważ serwer DirectAccess jest routerem IPv6, jeśli masz natywną infrastrukturę IPv6, interfejs internetowy może także łączyć się z kontrolerami domeny w intranecie. W takim przypadku dodaj filtry pakietów do kontrolera domeny w sieci obwodowej, które uniemożliwiają łączność z adresem IPv6 interfejsu skierowanego na Internet serwera DirectAccess.	Skonfiguruj następujące elementy: — Jeśli nie używasz domyślnych poziomów preferencji, możesz skonfigurować interfejsy intranetowe przy użyciu następującego polecenianetsh interface ipv6 set InterfaceIndex ignoredefaultroutes=enabled. To polecenie zapewnia, że dodatkowe trasy domyślne wskazujące routery intranetowe nie zostaną dodane do tabeli routingu IPv6. Indeks interfejsu interfejsów intranetowych można uzyskać przy użyciu następującego polecenia: netsh interface ipv6 show interface.	Jeśli masz intranet IPv6, skonfiguruj serwer DirectAccess, aby uzyskać dostęp do wszystkich lokalizacji IPv6, wykonaj następujące czynności: — Wyświetl listę przestrzeni adresowych IPv6 dla wszystkich lokalizacji w intranecie. — Użyj polecenia netsh interface ipv6 add route, aby dodać przestrzenie adresów IPv6 jako trasy statyczne w tablicy tras IPv6 serwera funkcji DirectAccess.
   Internet IPv4 i intranet IPv6	Serwer DirectAccess przekazuje domyślną trasę ruchu IPv6 przez adapter Microsoft 6to4 do przekaźnika 6to4 w Internecie IPv4. Serwer DirectAccess dla adresu IPv4 karty Microsoft 6to4 można skonfigurować przy użyciu następującego polecenia: netsh interface ipv6 6to4 set relay name=<ipaddress> state=enabled.

   Note

   • Jeśli klient funkcji DirectAccess ma przypisany publiczny adres IPv4, użyje technologii przejścia 6to4 w celu nawiązania połączenia z intranetem. Jeśli jest przypisany prywatny adres IPv4, będzie on używał teredo. Jeśli klient funkcji DirectAccess nie może nawiązać połączenia z serwerem funkcji DirectAccess za pomocą protokołu 6to4 lub Teredo, użyje protokołu IP-HTTPS.
   • Aby użyć Teredo, należy skonfigurować dwa kolejne adresy IP na zewnętrznym interfejsie sieciowym.
   • Nie można użyć teredo, jeśli serwer funkcji DirectAccess ma tylko jedną kartę sieciową.
   • Komputery klienckie z natywnym IPv6 mogą łączyć się z serwerem DirectAccess za pośrednictwem natywnego protokołu IPv6 i nie jest wymagana technologia przejściowa.

1.1.2 Planowanie łączności intranetowej IPv6

Do zarządzania zdalnymi klientami funkcji DirectAccess wymagany jest protokół IPv6. Protokół IPv6 umożliwia serwerom zarządzania funkcji DirectAccess łączenie się z klientami funkcji DirectAccess znajdującymi się w Internecie w celu zdalnego zarządzania.

1.1.3 Planowanie tunelowania wymuszonego

W przypadku protokołów IPv6 i tabeli zasad rozpoznawania nazw (NRPT) klienci funkcji DirectAccess domyślnie oddzielają swój intranet i ruch internetowy w następujący sposób:

• Kwerendy nazw DNS dla w pełni kwalifikowanych nazw domen intranetowych (FQDNs) i cały ruch intranetowy są wymieniane za pośrednictwem tuneli utworzonych za pomocą serwera DirectAccess lub bezpośrednio z serwerami intranetowymi. Ruch intranetowy z klientów funkcji DirectAccess to ruch IPv6.

• Kwerendy nazw DNS dla nazw FQDN, które odpowiadają regułom wykluczania lub nie są zgodne z intranetową przestrzenią nazw, a cały ruch do serwerów internetowych jest wymieniany za pośrednictwem interfejsu fizycznego połączonego z Internetem. Ruch internetowy z klientów funkcji DirectAccess jest zwykle ruchem IPv4.

Z kolei domyślnie niektóre implementacje wirtualnej sieci prywatnej (VPN) dostępu zdalnego, w tym klienta sieci VPN, wysyłają cały ruch intranetowy i internetowy przez połączenie sieci VPN dostępu zdalnego. Ruch związany z Internetem jest kierowany przez serwer sieci VPN do intranetowych serwerów proxy sieci Web IPv4 w celu uzyskania dostępu do zasobów internetowych IPv4. Można oddzielić ruch intranetowy i internetowy dla klientów zdalnego dostępu VPN przy użyciu tunelowania podzielonego. Obejmuje to skonfigurowanie tabeli routingu protokołu internetowego (IP) na klientach sieci VPN, tak aby ruch do lokalizacji intranetowych był wysyłany za pośrednictwem połączenia sieci VPN, a ruch do wszystkich innych lokalizacji jest wysyłany przy użyciu interfejsu fizycznego połączonego z Internetem.

Klientów funkcji DirectAccess można skonfigurować tak, aby wysyłali cały ruch przez tunele do serwera DirectAccess przy użyciu wymuszonego tunelowania. Po skonfigurowaniu tunelowania wymuszonego klienci funkcji DirectAccess wykrywają, że znajdują się w Internecie i usuwają trasę domyślną IPv4. Z wyjątkiem ruchu podsieci lokalnej cały ruch wysyłany przez klienta funkcji DirectAccess to ruch IPv6 przechodzący przez tunele do serwera funkcji DirectAccess.

Włączenie wymuszonego tunelowania ma następujące konsekwencje:

• Klienci funkcji DirectAccess używają tylko protokołu internetowego za pośrednictwem protokołu Secure Hypertext Transfer Protocol (IP-HTTPS), aby uzyskać łączność IPv6 z serwerem funkcji DirectAccess za pośrednictwem Internetu IPv4.

• Jedynymi lokalizacjami, do których klient funkcji DirectAccess może domyślnie nawiązać połączenie z ruchem IPv4, są te w podsieci lokalnej. Cały inny ruch wysyłany przez aplikacje i usługi uruchomione na kliencie funkcji DirectAccess to ruch IPv6, który jest wysyłany za pośrednictwem połączenia funkcji DirectAccess. W związku z tym aplikacje tylko IPv4 na kliencie funkcji DirectAccess nie mogą być używane do uzyskiwania dostępu do zasobów internetowych, z wyjątkiem aplikacji w podsieci lokalnej.

1.2 Planowanie wymagań dotyczących zapory

Jeśli serwer funkcji DirectAccess znajduje się za zaporą brzegową, następujące wyjątki są wymagane dla ruchu dostępu zdalnego, gdy serwer funkcji DirectAccess znajduje się w Internecie IPv4:

• Port docelowy 3544 przychodzący protokołu Teredo traffic-User Datagram Protocol (UDP) i źródłowy port UDP 3544 wychodzący.

• 6to4 traffic-IP Protocol 41 dla ruchu przychodzącego i wychodzącego.

• IP-HTTPS-Transmission protokół kontrolny (TCP) z docelowym portem 443 i wychodzącym portem źródłowym TCP 443.

• Jeśli wdrażasz dostęp zdalny za pomocą jednej karty sieciowej i instalujesz serwer lokalizacji sieciowej na serwerze funkcji DirectAccess, port TCP 62000 powinien być również wykluczony.

  Note

  Wykluczenie to znajduje się na serwerze DirectAccess, a wszystkie inne wykluczenia znajdują się na zaporze sieciowej krawędziowej.

W przypadku ruchu Teredo i 6to4 należy zastosować te wyjątki dla obu kolejnych publicznych adresów IPv4 skierowanych do Internetu na serwerze DirectAccess. W przypadku protokołu IP-HTTPS należy zastosować wyjątki na adresie zarejestrowanym na publicznym serwerze DNS.

Następujące wyjątki są wymagane w przypadku ruchu dostępu zdalnego, gdy serwer funkcji DirectAccess znajduje się w Internecie IPv6:

• Identyfikator protokołu IP 50

• Port docelowy UDP 500 przychodzący i źródłowy port UDP 500 wychodzący

• Ruch przychodzący i wychodzący ICMPv6 (tylko w przypadku korzystania z usługi Teredo)

W przypadku korzystania z dodatkowych zapór zastosuj następujące wyjątki zapory sieci wewnętrznej dla ruchu dostępu zdalnego:

• ISATAP-Protocol 41 przychodzące i wychodzące

• Tcp/UDP dla całego ruchu IPv4 i IPv6

• Protokół ICMP dla całego ruchu IPv4 i IPv6 (tylko w przypadku używania protokołu Teredo)

1.3 Planowanie wymagań dotyczących certyfikatów

Istnieją trzy scenariusze, które wymagają certyfikatów podczas wdrażania pojedynczego serwera DirectAccess.

• Krok 1. Zaplanuj infrastrukturę zaawansowanego DirectAccess
  • 1.1 Planowanie topologii i ustawień sieci
    • 1.1.1 Planowanie kart sieciowych i adresowania IP
    • 1.1.2 Planowanie łączności intranetowej IPv6
    • 1.1.3 Planowanie tunelowania wymuszonego
  • 1.2 Planowanie wymagań dotyczących zapory
  • 1.3 Planowanie wymagań dotyczących certyfikatów
    • 1.3.1 Planowanie certyfikatów komputerów na potrzeby uwierzytelniania protokołu IPsec
    • 1.3.2 Planowanie certyfikatów dla protokołu IP-HTTPS
    • 1.3.3 Planowanie certyfikatów stron internetowych dla serwera lokalizacji sieciowej
  • 1.4 Planowanie wymagań DNS
    • 1.4.1 Planowanie wymagań serwera DNS
    • 1.4.2 Planowanie lokalnego rozpoznawania nazw
  • 1.5 Planowanie serwera lokalizacji sieciowej
    • 1.5.1 Planowanie certyfikatów dla serwera lokalizacji sieciowej
    • 1.5.2 Planowanie systemu DNS dla serwera lokalizacji sieciowej
  • 1.6 Planowanie serwerów zarządzania
  • 1.7 Planowanie usług Active Directory Domain Services
    • 1.7.1 Planowanie uwierzytelniania klienta
    • 1.7.2 Planowanie wielu domen
  • 1.8 Planowanie obiektów grupy zasad
    • 1.8.1 Konfigurowanie automatycznie utworzonych obiektów zasad grupy (GPO)
    • 1.8.2 Konfigurowanie ręcznie utworzonych obiektów zasad grupy
    • 1.8.3 Zarządzanie obiektami zasad grupy w środowisku kontrolerów domen wielodomenowych
    • 1.8.4 Zarządzaj GPO dostępu zdalnego z ograniczonymi uprawnieniami
    • 1.8.5 Odzyskiwanie usuniętego obiektu zasad grupy
  • Następne kroki

Wymagania urzędu certyfikacji dla każdego scenariusza zostały podsumowane w poniższej tabeli.

1.3.1 Planowanie certyfikatów komputerów na potrzeby uwierzytelniania protokołu IPsec

Jeśli używasz uwierzytelniania IPsec opartego na certyfikatach, zarówno serwer DirectAccess, jak i klienci muszą uzyskać certyfikat komputera. Najprostszym sposobem instalowania certyfikatów jest skonfigurowanie automatycznej rejestracji opartej na zasadach grupy dla certyfikatów komputerów. Dzięki temu wszyscy członkowie domeny uzyskają certyfikat z centrum certyfikacji przedsiębiorstwa. Jeśli nie masz wewnętrznego urzędu certyfikacji skonfigurowanego w Twojej organizacji, zobacz Usługi certyfikatów Active Directory.

Ten certyfikat ma następujące wymagania:

• Certyfikat powinien zawierać rozszerzone użycie klucza do uwierzytelniania klienta (EKU).

• Certyfikat klienta i certyfikat serwera powinny być powiązane z tym samym certyfikatem głównym. Ten certyfikat główny należy wybrać w ustawieniach konfiguracji funkcji DirectAccess.

1.3.2 Planowanie certyfikatów dla IP-HTTPS

Serwer DirectAccess działa jako nasłuchujący IP-HTTPS i należy ręcznie zainstalować certyfikat HTTPS na serwerze. Podczas planowania należy wziąć pod uwagę następujące kwestie:

• Zaleca się używanie publicznego urzędu certyfikacji, aby listy odwołania certyfikatów (CRL) mogły być łatwo dostępne.

• W polu Podmiot określ adres IPv4 karty internetowej serwera funkcji DirectAccess lub nazwę FQDN adresu URL IP-HTTPS (adres ConnectTo). Jeśli serwer funkcji DirectAccess znajduje się za urządzeniem NAT, należy określić publiczną nazwę lub adres urządzenia NAT.

• Nazwa pospolita certyfikatu powinna być zgodna z nazwą witryny IP-HTTPS.

• W polu Rozszerzone użycie klucza użyj identyfikatora obiektu uwierzytelniania serwera (OID).

• W polu Punkty dystrybucji listy CRL określ punkt dystrybucji listy CRL, który jest dostępny dla klientów funkcji DirectAccess połączonych z Internetem.

• Certyfikat IP-HTTPS musi mieć klucz prywatny.

• Certyfikat IP-HTTPS należy zaimportować bezpośrednio do magazynu osobistego.

• IP-HTTPS certyfikaty mogą mieć symbole wieloznaczne w nazwie.

Jeśli planujesz używać IP-HTTPS na porcie niestandardowym, wykonaj następujące kroki na serwerze DirectAccess:

1. Usuń istniejące powiązanie certyfikatu dla 0.0.0.0:443 i zastąp je powiązaniem certyfikatu dla wybranego portu. Na potrzeby tego przykładu jest używany port 44500. Przed usunięciem powiązania certyfikatu pokaż i skopiuj identyfikator appid.

   1. Aby usunąć powiązanie certyfikatu, wprowadź:

      netsh http delete ssl ipport=0.0.0.0:443
      

   2. Aby dodać nowe powiązanie certyfikatu, wprowadź:

      netsh http add ssl ipport=0.0.0.0:44500 certhash=<use the thumbprint from the DirectAccess server SSL cert> appid=<use the appid from the binding that was deleted>
      

2. Aby zmodyfikować adres URL IP-HTTPS na serwerze, wprowadź:

   Netsh int http set int url=https://<DirectAccess server name (for example server.contoso.com)>:44500/IPHTTPS
   

   Net stop iphlpsvc & net start iphlpsvc
   

3. Zmień rezerwację adresu URL dla kdcproxy.

   1. Aby usunąć istniejącą rezerwację adresu URL, wprowadź:

      netsh http del urlacl url=https://+:443/KdcProxy/
      

   2. Aby dodać nową rezerwację adresu URL, wprowadź:

      netsh http add urlacl url=https://+:44500/KdcProxy/ sddl=D:(A;;GX;;;NS)
      

4. Dodaj ustawienie umożliwiające nasłuchiwanie przez kppsvc na porcie niestandardowym. Aby dodać wpis rejestru, wprowadź:

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\KPSSVC\Settings /v HttpsUrlGroup /t REG_MULTI_SZ /d +:44500 /f
   

5. Aby ponownie uruchomić usługę kdcproxy na kontrolerze domeny, wprowadź:

   net stop kpssvc & net start kpssvc
   

Aby użyć IP-HTTPS na porcie niestandardowym, wykonaj następujące kroki na kontrolerze domeny:

1. Zmodyfikuj ustawienie IP-HTTPS w obiekcie zasad grupy klienta.

   1. Otwórz edytor zasad grupy.

   2. Przejdź do pozycji Konfiguracja komputera=Zasady=>>Szablony administracyjne=> Sieć=>ustawienia TCPIP =>technologie przejścia IPv6.

   3. Otwórz ustawienie stanu IP-HTTPS i zmień adres URL na nazwę serwera https://< DirectAccess (na przykład server.contoso.com)>:44500/IPHTTPS.

   4. Kliknij przycisk Zastosuj.

2. Zmodyfikuj ustawienia klienta proxy Kerberos w GPO klienta.

   1. W edytorze zasad grupy przejdź do pozycji Konfiguracja komputera=>Zasady=>Szablony administracyjne=> System=>Kerberos => Określ serwery proxy centrum dystrybucji kluczy dla klientów protokołu Kerberos.

   2. Otwórz ustawienie stanu IPHTTPS i zmień adres URL na nazwę serwera https://< DirectAccess (na przykład server.contoso.com)>:44500/IPHTTPS.

   3. Kliknij przycisk Zastosuj.

3. Zmodyfikuj ustawienia zasad protokołu IPsec klienta, aby używać funkcji ComputerKerb i UserKerb.

   1. W edytorze zasad grupy przejdź do pozycji Konfiguracja komputera=>Zasady= Ustawienia systemu Windows=> Ustawienia zabezpieczeń =>> Zapora systemu Windows z zabezpieczeniami zaawansowanymi.

   2. Kliknij pozycję Reguły zabezpieczeń połączeń, a następnie kliknij dwukrotnie regułę protokołu IPsec.

   3. Na karcie Uwierzytelnianie kliknij pozycję Zaawansowane.

   4. Usuń istniejącą metodę uwierzytelniania Auth1 i zastąp ją metodą ComputerKerb. Auth2: Usuń istniejącą metodę uwierzytelniania i zastąp ją metodą UserKerb.

   5. Kliknij przycisk Zastosuj, a następnie kliknij przycisk OK.

Aby ukończyć proces ręczny do korzystania z portu IP-HTTPS niestandardowym, uruchom polecenie gpupdate /force na komputerach klienckich i serwerze funkcji DirectAccess.

1.3.3 Planowanie certyfikatów witryny sieci Web dla serwera lokalizacji sieciowej

Podczas planowania witryny serwera lokalizacji w sieci należy wziąć pod uwagę następujące kwestie:

• W polu Podmiot określ adres IP intranetowego interfejsu serwera lokalizacji sieciowej lub nazwę FQDN adresu URL lokalizacji sieciowej.

• W polu Rozszerzone użycie klucza użyj identyfikatora OID uwierzytelniania serwera.

• W polu Punkty dystrybucji listy CRL użyj punktu dystrybucji listy CRL, który jest dostępny dla klientów DirectAccess połączonych z intranetem. Ten punkt dystrybucji listy CRL nie powinien być dostępny spoza sieci wewnętrznej.

• Jeśli planujesz później skonfigurować wdrożenie wielu lokacji lub klastrów, nazwa certyfikatu nie powinna być zgodna z wewnętrzną nazwą dowolnego serwera funkcji DirectAccess, który zostanie dodany do wdrożenia.

  Note

  Upewnij się, że certyfikaty dla IP-HTTPS i serwera lokalizacji sieciowej mają nazwę podmiotu. Jeśli certyfikat nie ma nazwy podmiotu, ale ma alternatywną nazwę, nie zostanie zaakceptowany przez Kreatora dostępu zdalnego.

1.4 Planowanie wymagań DNS

W tej sekcji opisano wymagania DNS dotyczące żądań klientów funkcji DirectAccess i serwerów infrastruktury we wdrożeniu dostępu zdalnego. Zawiera ona następujące podsekcje:

• 1.4.1 Planowanie wymagań serwera DNS

• 1.4.2 Planowanie lokalnego rozpoznawania nazw

Żądania klienta DirectAccess

System DNS służy do rozpoznawania żądań z komputerów klienckich funkcji DirectAccess, które nie znajdują się w sieci wewnętrznej (lub firmowej). Klienci funkcji DirectAccess próbują nawiązać połączenie z serwerem lokalizacji sieciowej funkcji DirectAccess w celu określenia, czy znajdują się one w Internecie, czy w sieci wewnętrznej.

• Jeśli połączenie zakończy się pomyślnie, klienci są identyfikowani jako zlokalizowani w sieci wewnętrznej, funkcja DirectAccess nie jest używana, a żądania klientów są rozwiązywane przy użyciu serwera DNS skonfigurowanego na karcie sieciowej komputera klienckiego.

• Jeśli połączenie nie powiedzie się, zakłada się, że klienci znajdują się w Internecie, a klienci funkcji DirectAccess będą używać tabeli zasad rozpoznawania nazw (NRPT), aby określić, który serwer DNS ma być używany podczas rozpoznawania żądań nazw.

Można określić, że klienci używają funkcji DirectAccess DNS64 do rozpoznawania nazw lub alternatywnego wewnętrznego serwera DNS. Podczas rozpoznawania nazw, NRPT jest używana przez klientów funkcji DirectAccess do identyfikowania sposobu obsługi żądania. Klienci żądają nazwy FQDN lub nazwy pojedynczej etykiety, takiej jak https://internal. Jeśli żądana jest nazwa z pojedynczą etykietą, sufiks DNS jest dołączany w celu utworzenia pełnej kwalifikowanej nazwy domeny (FQDN). Jeśli zapytanie DNS pasuje do wpisu w tabeli NRPT, a dns64 lub serwer DNS w sieci wewnętrznej jest określony dla wpisu, zapytanie jest wysyłane do rozpoznawania nazw przy użyciu określonego serwera. Jeśli dopasowanie istnieje, ale nie określono żadnego serwera DNS, oznacza to regułę wykluczania i stosowane jest normalne rozpoznawanie nazw.

Automatyczne wykrywanie działa w następujący sposób:

• Jeśli sieć firmowa jest oparta na protokole IPv4 lub używa protokołu IPv4 i IPv6, domyślnym adresem DNS64 karty wewnętrznej na serwerze funkcji DirectAccess.

• Jeśli sieć firmowa jest oparta na protokole IPv6, domyślnym adresem jest adres IPv6 serwerów DNS w sieci firmowej.

Serwery infrastruktury

• Serwer lokalizacji sieciowej

  Klienci funkcji DirectAccess próbują uzyskać dostęp do serwera lokalizacji sieciowej, aby ustalić, czy znajdują się w sieci wewnętrznej. Klienci w sieci wewnętrznej muszą być w stanie rozpoznać nazwę serwera lokalizacji sieciowej, ale należy uniemożliwić rozpoznawanie nazwy, gdy znajdują się one w Internecie. Aby upewnić się, że tak się stanie, domyślnie nazwa FQDN serwera lokalizacji sieciowej jest dodawana jako reguła wykluczania do tabeli NRPT. Ponadto podczas konfigurowania dostępu zdalnego są tworzone automatycznie następujące reguły:

  • Reguła sufiksu DNS dla domeny głównej lub nazwy domeny serwera DirectAccess, oraz adresy IPv6, które odpowiadają adresom DNS64. W firmowych sieciach tylko z IPv6, intranetowe serwery DNS są konfigurowane na serwerze funkcji DirectAccess. Jeśli na przykład serwer DirectAccess jest członkiem domeny corp.contoso.com, zostanie utworzona reguła dla sufiksu DNS corp.contoso.com.

  • Reguła zwolnienia dotycząca FQDN serwera lokalizacji sieciowej. Jeśli na przykład adres URL serwera lokalizacji sieciowej jest https://nls.corp.contoso.com, zostanie utworzona reguła wykluczania dla nazwy FQDN nls.corp.contoso.com.

• serwerIP-HTTPS

  Serwer funkcji DirectAccess działa jako nasłuchujący IP-HTTPS i używa certyfikatu serwera do uwierzytelniania się przed IP-HTTPS klientami. Nazwa IP-HTTPS musi być rozpoznawana przez klientów DirectAccess korzystających z publicznych serwerów DNS.

• Sprawdzanie odwołania CRL

  DirectAccess używa sprawdzania odwołań certyfikatów dla połączenia IP-HTTPS między klientami DirectAccess a serwerem DirectAccess oraz dla połączenia opartego na HTTPS między klientem DirectAccess a serwerem lokalizacji sieciowej. W obu przypadkach klienci DirectAccess muszą mieć możliwość rozpoznania i dostępu do lokalizacji punktu dystrybucji CRL.

• ISATAP

  Protokół ISATAP umożliwia komputerom firmowym uzyskanie adresu IPv6 i hermetyzuje pakiety IPv6 w nagłówku IPv4. Jest używany przez serwer DirectAccess do zapewnienia łączności IPv6 z hostami ISATAP w intranecie. W środowisku sieciowym bez natywnego protokołu IPv6 serwer funkcji DirectAccess konfiguruje się automatycznie jako router ISATAP.

  Ponieważ protokół ISATAP nie jest już obsługiwany w funkcji DirectAccess, należy upewnić się, że serwery DNS nie są skonfigurowane do odpowiadania na zapytania ISATAP. Domyślnie usługa serwera DNS blokuje rozpoznawanie nazw dla nazwy ISATAP za pośrednictwem globalnej listy bloków zapytań DNS. Nie usuwaj nazwy ISATAP z globalnej listy bloków zapytań.

• Weryfikatory łączności

  Dostęp zdalny tworzy domyślną sondę webową, która jest używana przez klienckie komputery DirectAccess do weryfikowania łączności z siecią wewnętrzną. Aby upewnić się, że sonda działa zgodnie z oczekiwaniami, następujące nazwy muszą być zarejestrowane ręcznie w systemie DNS:

  • directaccess-webprobehost-Powinien rozpoznawać wewnętrzny adres IPv4 serwera funkcji DirectAccess lub adres IPv6 w środowisku tylko do protokołu IPv6.

  • directaccess-corpconnectivityhost-Powinien rozpoznać adres hosta lokalnego (sprzężenie zwrotne). Należy utworzyć następujące rekordy zasobów hosta (A) i (AAAA): rekord zasobu hosta (A) o wartości 127.0.0.1 i rekord zasobu hosta (AAAA) z wartością utworzoną z prefiksu NAT64 z ostatnich 32 bitów jako 127.0.0.1. Prefiks NAT64 można pobrać, uruchamiając polecenie programu Windows PowerShell get-netnattransitionconfiguration.

    Note

    Jest to prawidłowe tylko w środowisku tylko IPv4. W środowisku IPv4 plus IPv6 lub tylko IPv6 należy utworzyć tylko rekord zasobu hosta (AAAA) z adresem IP sprzężenia zwrotnego ::1.

  Dodatkowe weryfikatory łączności można utworzyć przy użyciu innych adresów internetowych za pośrednictwem protokołu HTTP lub za pomocą polecenia ping. Dla każdego weryfikatora łączności musi istnieć wpis DNS.

1.4.1 Planowanie wymagań serwera DNS

Poniżej przedstawiono wymagania dotyczące systemu DNS podczas wdrażania funkcji DirectAccess.

• W przypadku klientów funkcji DirectAccess należy użyć serwera DNS z systemem Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008 lub dowolnego innego serwera DNS obsługującego protokół IPv6.

  Note

  Nie zaleca się używania serwerów DNS z systemem Windows Server 2003 podczas wdrażania funkcji DirectAccess. Mimo że serwery DNS systemu Windows Server 2003 obsługują rekordy IPv6, system Windows Server 2003 nie jest już obsługiwany przez firmę Microsoft. Ponadto nie należy wdrażać funkcji DirectAccess, jeśli kontrolery domeny korzystają z systemu Windows Server 2003 z powodu problemu z usługą replikacji plików. Aby uzyskać więcej informacji, zobacz Nieobsługiwane konfiguracje funkcji DirectAccess.

• Użyj serwera DNS, który obsługuje aktualizacje dynamiczne. Można użyć serwerów DNS, które nie obsługują aktualizacji dynamicznych, ale należy ręcznie zaktualizować wpisy na tych serwerach.

• Nazwa FQDN dla internetowych punktów dystrybucji listy CRL musi być rozpoznawalna przy użyciu internetowych serwerów DNS. Na przykład, jeśli adres URL https://crl.contoso.com/crld/corp-DC1-CA.crl znajduje się w polu Punkty dystrybucji listy CRL certyfikatu IP-HTTPS serwera DirectAccess, upewnij się, że nazwę FQDN crld.contoso.com można rozpoznać przy użyciu serwerów DNS w Internecie.

1.4.2 Planowanie lokalnego rozpoznawania nazw

Podczas planowania lokalnego rozpoznawania nazw należy wziąć pod uwagę następujące problemy:

NRPT

W następujących przypadkach może być konieczne utworzenie dodatkowych reguł NRPT:

• Jeśli musisz dodać więcej sufiksów DNS dla przestrzeni nazw intranetu.

• Jeśli w pełni kwalifikowana nazwa domeny (FQDN) punktów dystrybucji listy CRL jest oparta na przestrzeni nazw intranetu, należy dodać reguły wykluczania dla nazw FQDN punktów dystrybucji listy CRL.

• Jeśli masz środowisko DNS z podziałem mózgów, musisz dodać reguły wykluczania dla nazw zasobów, dla których klienci funkcji DirectAccess znajdują się w Internecie w celu uzyskania dostępu do wersji internetowej, a nie wersji intranetowej.

• Jeśli przekierowujesz ruch do zewnętrznej witryny internetowej za pośrednictwem intranetowych serwerów proxy sieci Web, zewnętrzna witryna internetowa jest dostępna tylko z intranetu i używa adresów serwerów proxy sieci Web, aby zezwolić na żądania przychodzące. W takim przypadku dodaj regułę wykluczania dla nazwy FQDN zewnętrznej witryny internetowej i określ, że reguła używa intranetowego serwera proxy sieci Web, a nie adresów IPv6 intranetowych serwerów DNS.

  Jeśli na przykład testujesz zewnętrzną witrynę internetową o nazwie test.contoso.com, ta nazwa nie jest rozpoznawana za pośrednictwem internetowych serwerów DNS, ale serwer proxy sieci Web firmy Contoso wie, jak rozpoznać nazwę i kierować żądania dotyczące witryny internetowej do zewnętrznego serwera internetowego. Aby uniemożliwić użytkownikom, którzy nie znajdują się w intranecie firmy Contoso dostępu do witryny, zewnętrzna witryna internetowa zezwala na żądania tylko z adresu internetowego IPv4 serwera proxy firmy Contoso. W związku z tym użytkownicy intranetowi mogą uzyskać dostęp do witryny internetowej, ponieważ używają internetowego serwera proxy firmy Contoso, ale użytkownicy funkcji DirectAccess nie mogą uzyskać do niej dostępu, ponieważ nie korzystają z internetowego serwera proxy firmy Contoso. Konfigurując regułę wykluczenia NRPT dla test.contoso.com, która korzysta z serwera proxy sieci web Contoso, żądania stron internetowych dla test.contoso.com są kierowane do wewnętrznego serwera proxy sieci web przez Internet IPv4.

Nazwy pojedynczych etykiet

Nazwy pojedynczych etykiet, takie jak https://paycheck, są czasami używane dla serwerów intranetowych. Jeśli żądana jest nazwa pojedynczej etykiety i skonfigurowano listę wyszukiwania sufiksów DNS, sufiksy DNS na liście zostaną dołączone do nazwy pojedynczej etykiety. Na przykład gdy użytkownik na komputerze, który jest członkiem typów https://paycheck domen corp.contoso.com w przeglądarce internetowej, nazwa FQDN, która jest skonstruowana jako nazwa jest paycheck.corp.contoso.com. Domyślnie dołączony sufiks jest oparty na podstawowym sufiksie DNS komputera klienckiego.

Jeśli w organizacji wdrożono wiele domen i usługi nazw internetowych systemu Windows (WINS) i łączysz się zdalnie, pojedyncze nazwy można rozpoznać w następujący sposób:

• Wdróż strefę wyszukiwania do przodu WINS w systemie DNS. Podczas próby rozwiązania computername.dns.zone1.corp.contoso.com żądanie jest kierowane do serwera WINS, który używa tylko nazwy komputera. Klient uważa, że wystawia zwykły rekord zasobu hosta DNS (A), ale w rzeczywistości jest to żądanie NetBIOS. Aby uzyskać więcej informacji, zobacz Zarządzanie strefą wyszukiwania do przodu.

• Dodaj sufiks DNS, na przykład dns.zone1.corp.contoso.com, do domyślnego obiektu zasad grupy.

Dns z podziałem mózgu

System DNS z podziałem mózgów jest używany przez tę samą domenę DNS na potrzeby rozpoznawania nazw internetowych i intranetowych.

W przypadku wdrożeń DNS typu split-brain należy sporządzić listę nazw FQDN zduplikowanych w Internecie i intranecie oraz zdecydować, które zasoby klient DirectAccess powinien uzyskać: intranetowe czy internetowe. Dla każdej nazwy odpowiadającej zasobowi, dla którego klienci funkcji DirectAccess mają uzyskać dostęp do wersji internetowej, należy dodać odpowiednią nazwę FQDN jako regułę wykluczania do tabeli NRPT dla klientów funkcji DirectAccess.

W środowisku DNS z podziałem mózgów, jeśli chcesz, aby obie wersje zasobu były dostępne, skonfiguruj zasoby intranetowe przy użyciu alternatywnych nazw, które nie są duplikatami nazw używanych w Internecie, i poinstruuj użytkowników, aby używali alternatywnej nazwy w intranecie. Na przykład skonfiguruj alternatywną nazwę www.internal.contoso.com dla nazwy wewnętrznej www.contoso.com.

W środowisku DNS bez podziału mózgów przestrzeń nazw w Internecie różni się od przestrzeni nazw intranetu. Na przykład firma Contoso Corporation używa contoso.com w Internecie i corp.contoso.com w intranecie. Ponieważ wszystkie zasoby intranetowe używają sufiksu DNS corp.contoso.com, reguła NRPT dla corp.contoso.com kieruje wszystkie zapytania nazw DNS dla zasobów intranetowych do intranetowych serwerów DNS. Kwerendy nazw DNS dla nazw z sufiksem contoso.com nie odpowiadają regule przestrzeni nazw intranetu corp.contoso.com w tabeli NRPT i w związku z tym są wysyłane do internetowych serwerów DNS. W przypadku wdrożenia DNS bez podziału mózgów, ponieważ nie ma duplikowania nazw FQDN dla zasobów intranetowych i internetowych, nie ma dodatkowej konfiguracji wymaganej dla tabeli NRPT. Klienci funkcji DirectAccess mogą uzyskiwać dostęp zarówno do zasobów internetowych, jak i intranetowych w organizacji.

Zachowanie lokalnego rozpoznawania nazw dla klientów DirectAccess

Jeśli nazwy nie można rozpoznać za pomocą DNS, to w celu rozpoznania nazwy w podsieci lokalnej, usługa klienta DNS w systemie Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Windows 8 i Windows 7 może używać lokalnego rozpoznawania nazw za pomocą protokołów Rozpoznawania Nazw Lokalnych (LLMNR) oraz NetBIOS przez TCP/IP.

Lokalne rozpoznawanie nazw jest zwykle wymagane w przypadku komunikacji równorzędnej, gdy komputer znajduje się w sieciach prywatnych, takich jak domowe sieci z jedną podsiecią. Gdy usługa klienta DNS wykonuje lokalne rozpoznawanie nazw dla nazw serwerów intranetowych, a komputer jest połączony z udostępnioną podsiecią w Internecie, złośliwi użytkownicy mogą przechwytywać llMNR i NetBIOS za pośrednictwem komunikatów TCP/IP w celu określenia nazw serwerów intranetowych. Na stronie DNS w Kreatorze instalacji serwera infrastruktury skonfigurujesz zachowanie lokalnego rozpoznawania nazw na podstawie typów odpowiedzi otrzymywanych z intranetowych serwerów DNS. Dostępne są następujące opcje:

• Użyj lokalnego rozpoznawania nazw, jeśli nazwa nie istnieje w systemie DNS. Ta opcja jest najbezpieczniejsza, ponieważ klient funkcji DirectAccess wykonuje lokalne rozpoznawanie nazw tylko dla nazw serwerów, których nie można rozpoznać przez intranetowe serwery DNS. Jeśli intranetowe serwery DNS są dostępne, nazwy serwerów intranetowych zostaną rozpoznane. Jeśli nie można uzyskać dostępu do intranetowych serwerów DNS lub występują inne typy błędów DNS, nazwy serwerów intranetowych nie wyciekają do podsieci za pośrednictwem lokalnego rozpoznawania nazw.

• Użyj lokalnego rozpoznawania nazw, jeśli nazwa nie istnieje na serwerach DNS lub DNS nie jest osiągalna, gdy komputer kliencki znajduje się w sieci prywatnej (zalecane). Ta opcja jest zalecana, ponieważ umożliwia korzystanie z lokalnego rozpoznawania nazw w sieci prywatnej tylko wtedy, gdy intranetowe serwery DNS są niedostępne.

• Użyj lokalnego rozpoznawania nazw dla dowolnego rodzaju błędu rozpoznawania nazw DNS (najmniej bezpieczne). Jest to najmniej bezpieczna opcja, ponieważ nazwy intranetowych serwerów sieciowych można wyciekać do podsieci lokalnej za pośrednictwem lokalnego rozpoznawania nazw.

1.5 Planowanie serwera lokalizacji sieciowej

Serwer lokalizacji sieciowej to witryna internetowa służąca do wykrywania, czy klienci funkcji DirectAccess znajdują się w sieci firmowej. Klienci w sieci firmowej nie używają funkcji DirectAccess do uzyskania dostępu do zasobów wewnętrznych, ale łączą się bezpośrednio.

Witryna internetowa serwera lokalizacji sieciowej może być hostowana na serwerze DirectAccess lub na innym serwerze w organizacji. Jeśli hostujesz serwer lokalizacji sieciowej na serwerze funkcji DirectAccess, witryna internetowa jest tworzona automatycznie podczas instalowania roli serwera dostępu zdalnego. Jeśli hostujesz serwer lokalizacji sieciowej na innym serwerze w organizacji z systemem operacyjnym Windows, upewnij się, że na tym serwerze zainstalowano usługi Internet Information Services (IIS) i że witryna internetowa została utworzona. DirectAccess nie konfiguruje ustawień na zdalnym serwerze lokalizacyjnym sieci.

Upewnij się, że witryna sieci Web serwera lokalizacji sieciowej spełnia następujące wymagania:

• Jest to witryna internetowa z certyfikatem serwera HTTPS.

• Komputery klienckie korzystające z DirectAccess muszą ufać urzędowi certyfikacji, który wystawił certyfikat serwera w witrynie serwera lokalizacji sieciowej.

• Komputery klienckie funkcji DirectAccess w sieci wewnętrznej muszą być w stanie rozpoznać nazwę lokacji serwera lokalizacji sieciowej.

• Lokacja serwera lokalizacji sieciowej musi mieć wysoką dostępność dla komputerów w sieci wewnętrznej.

• Serwer lokalizacji sieciowej nie może być dostępny dla klienckich komputerów DirectAccess w Internecie.

• Certyfikat serwera należy sprawdzić pod kątem listy CRL.

1.5.1 Planowanie certyfikatów dla serwera lokalizacji sieciowej

Podczas uzyskiwania certyfikatu witryny internetowej do użycia dla serwera lokalizacji sieciowej należy wziąć pod uwagę następujące kwestie:

1. W polu Podmiot określ adres IP intranetowego interfejsu serwera lokalizacji sieciowej lub nazwę FQDN adresu URL lokalizacji sieciowej.

2. W polu Rozszerzone użycie klucza użyj identyfikatora OID uwierzytelniania serwera.

3. W polu Punkty dystrybucji listy CRL użyj punktu dystrybucji listy CRL, który jest dostępny dla klientów DirectAccess połączonych z intranetem. Ten punkt dystrybucji listy CRL nie powinien być dostępny spoza sieci wewnętrznej.

1.5.2 Planowanie systemu DNS dla serwera lokalizacji sieciowej

Klienci funkcji DirectAccess próbują uzyskać dostęp do serwera lokalizacji sieciowej, aby ustalić, czy znajdują się w sieci wewnętrznej. Klienci w sieci wewnętrznej muszą być w stanie rozpoznać nazwę serwera lokalizacji sieciowej, ale należy uniemożliwić rozpoznawanie nazwy, gdy znajdują się one w Internecie. Aby upewnić się, że tak się stanie, domyślnie nazwa FQDN serwera lokalizacji sieciowej jest dodawana jako reguła wykluczania do tabeli NRPT.

1.6 Planowanie serwerów zarządzania

Klienci funkcji DirectAccess inicjują komunikację z serwerami zarządzania, które zapewniają usługi, takie jak Windows Update i aktualizacje antywirusowe. Klienci funkcji DirectAccess używają również protokołu Kerberos do kontaktowania się z kontrolerami domeny w celu uwierzytelnienia przed uzyskaniem dostępu do sieci wewnętrznej. Podczas zdalnego zarządzania klientami funkcji DirectAccess serwery zarządzania komunikują się z komputerami klienckimi w celu wykonywania funkcji zarządzania, takich jak oceny spisu oprogramowania lub sprzętu. Dostęp zdalny może automatycznie odnajdywać niektóre serwery zarządzania, w tym:

• Automatyczne odnajdywanie kontrolerów domeny jest wykonywane dla wszystkich domen w tym samym lesie, co serwer DirectAccess i komputery klienckie.

• Serwery programu Microsoft Endpoint Configuration Manager — automatyczne odnajdywanie serwerów programu Configuration Manager jest wykonywane dla wszystkich domen w tym samym lesie co serwer funkcji DirectAccess i komputery klienckie.

Kontrolery domeny i serwery programu Configuration Manager są automatycznie wykrywane podczas pierwszej konfiguracji funkcji DirectAccess. Wykryte kontrolery domeny nie są wyświetlane w konsoli programu , ale ustawienia można pobrać przy użyciu polecenia cmdlet programu Windows PowerShell Get-DAMgmtServer -Type Wszystkie. Jeśli kontroler domeny lub serwery Configuration Manager zostaną zmodyfikowane, kliknięcie Odśwież serwery zarządzania w konsoli Zarządzania Dostępem Zdalnym odświeża listę serwerów zarządzania.

Wymagania dotyczące serwera zarządzania

• Serwery zarządzania muszą być dostępne za pośrednictwem pierwszego tunelu (infrastruktury). Podczas konfigurowania dostępu zdalnego dodawanie serwerów do listy serwerów zarządzania automatycznie sprawia, że są one dostępne za pośrednictwem tego tunelu.

• Serwery zarządzania, które inicjują połączenia z klientami funkcji DirectAccess, muszą w pełni obsługiwać protokół IPv6 za pomocą natywnego adresu IPv6 lub przy użyciu jednego przypisanego przez protokół ISATAP.

1.7 Planowanie usług Active Directory Domain Services

W tej sekcji wyjaśniono, jak funkcja DirectAccess korzysta z usług Active Directory Domain Services (AD DS) i zawiera następujące podsekcje:

• 1.7.1 Planowanie uwierzytelniania klienta

• 1.7.2 Planowanie wielu domen

Funkcja DirectAccess używa obiektów zasad grupy (GPO) usług AD DS i Active Directory w następujący sposób:

• Authentication

  Usługi AD DS są używane do uwierzytelniania. Tunel infrastruktury używa uwierzytelniania NTLMv2 dla konta komputera łączącego się z serwerem DirectAccess, a konto musi być zarejestrowane w domenie usługi Active Directory. Tunel intranetowy używa uwierzytelniania Kerberos dla użytkownika w celu utworzenia drugiego tunelu.

• Obiekty zasad grupy

  DirectAccess gromadzi ustawienia konfiguracyjne w GPO, które są stosowane do serwerów DirectAccess, klientów oraz wewnętrznych serwerów aplikacji.

• Grupy zabezpieczeń

  DirectAccess używa grup zabezpieczeń do zbierania i identyfikowania komputerów klienckich DirectAccess. Obiekty zasad grupy są zastosowane do grupy zabezpieczeń, która jest wymagana.

• Rozszerzone zasady protokołu IPsec

  DirectAccess może używać uwierzytelniania IPsec i szyfrowania między klientami a serwerem DirectAccess. Uwierzytelnianie i szyfrowanie protokołu IPsec można rozszerzyć z klienta na określone wewnętrzne serwery aplikacji. W tym celu dodaj wymagane serwery aplikacji do grupy zabezpieczeń.

wymagania AD DS

Podczas planowania AD DS dla wdrożenia funkcji DirectAccess należy wziąć pod uwagę następujące wymagania:

• Co najmniej jeden kontroler domeny musi być zainstalowany z systemem operacyjnym Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2 lub Windows Server 2008.

  Jeśli kontroler domeny znajduje się w sieci obwodowej (i w związku z tym osiągalny z karty sieciowej skierowanej do Internetu serwera funkcji DirectAccess), należy uniemożliwić serwerowi funkcji DirectAccess dotarcie do niego przez dodanie filtrów pakietów na kontrolerze domeny, aby zablokować łączność z adresem IP karty sieciowej.

• Serwer DirectAccess musi być członkiem domeny.

• Klienci DirectAccess muszą być członkami domeny. Klienci mogą należeć do:

  • Dowolna domena w tym samym lesie co serwer DirectAccess.

  • Każda domena, która ma zaufanie dwukierunkowe z domeną serwera DirectAccess.

  • Każda domena w lesie domen, która ma dwukierunkową relację zaufania z lasem domen, do którego należy domena DirectAccess.

1.7.1 Planowanie uwierzytelniania klienta

Funkcja DirectAccess umożliwia wybór między użyciem certyfikatów na potrzeby uwierzytelniania komputera IPsec lub wbudowanego serwera proxy Kerberos, który uwierzytelnia się przy użyciu nazw użytkowników i haseł.

W przypadku korzystania z poświadczeń Ad DS do uwierzytelniania DirectAccess używa jednego tunelu zabezpieczeń, który używa Kerberos dla komputerów do pierwszego uwierzytelniania i Kerberos dla użytkowników do drugiego uwierzytelniania. W przypadku korzystania z tego trybu uwierzytelniania funkcja DirectAccess używa pojedynczego tunelu zabezpieczeń, który zapewnia dostęp do serwera DNS, kontrolera domeny i innych serwerów w sieci wewnętrznej.

W przypadku wyboru uwierzytelniania dwuskładnikowego lub systemu ochrony dostępu do sieci, DirectAccess używa dwóch tuneli zabezpieczeń. Kreator instalacji dostępu zdalnego konfiguruje zaporę systemu Windows z regułami zabezpieczeń zaawansowanych zabezpieczeń, które określają użycie następujących typów poświadczeń podczas negocjowania skojarzeń zabezpieczeń protokołu IPsec dla tuneli do serwera funkcji DirectAccess:

• Tunel infrastruktury używa poświadczeń Kerberos komputera do pierwszego uwierzytelniania i poświadczeń Kerberos użytkownika na potrzeby drugiego uwierzytelniania.

• Tunel intranetowy używa certyfikatów komputerowych do pierwszego uwierzytelniania i protokołu Kerberos użytkownika do drugiego uwierzytelniania.

Kiedy DirectAccess decyduje się na umożliwienie dostępu klientom korzystającym z systemu Windows 7 lub w wdrożeniu wielosiedliskowym, wykorzystuje dwa tunele zabezpieczające. Kreator instalacji dostępu zdalnego konfiguruje zaporę systemu Windows z regułami zabezpieczeń zaawansowanych zabezpieczeń, które określają użycie następujących typów poświadczeń podczas negocjowania skojarzeń zabezpieczeń protokołu IPsec dla tuneli do serwera funkcji DirectAccess:

• Tunel infrastruktury używa poświadczeń certyfikatu komputera do pierwszego uwierzytelniania i NTLMv2 na potrzeby drugiego uwierzytelniania. Poświadczenia NTLMv2 wymuszają użycie uwierzytelnionego protokołu internetowego (AuthIP) i zapewniają dostęp do serwera DNS i kontrolera domeny, zanim klient funkcji DirectAccess będzie mógł używać poświadczeń Protokołu Kerberos dla tunelu intranetowego.

• Tunel intranetowy używa certyfikatów komputerowych do pierwszego uwierzytelniania i protokołu Kerberos użytkownika do drugiego uwierzytelniania.

1.7.2 Planowanie wielu domen

Lista serwerów zarządzania powinna zawierać kontrolery domeny ze wszystkich domen, które zawierają grupy zabezpieczeń, które obejmują komputery klienckie funkcji DirectAccess. Powinna zawierać wszystkie domeny zawierające konta użytkowników, które mogą używać komputerów skonfigurowanych jako klienci funkcji DirectAccess. Dzięki temu użytkownicy, którzy nie znajdują się w tej samej domenie co używany komputer kliencki, są uwierzytelniani przy użyciu kontrolera domeny w domenie użytkownika. Odbywa się to automatycznie, jeśli domeny znajdują się w tym samym lesie.

Jeśli to możliwe, sufiksy wspólnych nazw domen należy dodać do tabeli zasad rozpoznawania nazw (NRPT) podczas wdrażania dostępu zdalnego. Jeśli na przykład masz dwie domeny, domain1.corp.contoso.com i domain2.corp.contoso.com, zamiast dodawać dwa wpisy do tabeli NRPT, można dodać wspólny wpis sufiksu DNS, gdzie sufiks nazwy domeny jest corp.contoso.com. Dzieje się to automatycznie w przypadku domen w tym samym katalogu głównym, ale domeny, które nie znajdują się w tym samym katalogu głównym, należy dodać ręcznie.

Jeśli usługa nazw internetowych systemu Windows (WINS) jest wdrożona w wielu środowiskach domeny, należy wdrożyć strefę wyszukiwania do przodu WINS w systemie DNS. Aby uzyskać więcej informacji, zobacz Nazwy pojedynczych etykiet w sekcji Planowanie lokalnego rozpoznawania nazw we wcześniejszej części tego dokumentu.

1.8 Planowanie obiektów zasad grupy

W tej sekcji opisano rolę obiektów zasad grupy (GPO) w infrastrukturze dostępu zdalnego i zawiera następujące podsekcje:

• 1.8.1 Konfigurowanie automatycznie utworzonych obiektów zasad grupy (GPO)

• 1.8.2 Konfigurowanie ręcznie utworzonych obiektów zasad grupy

• 1.8.3 Zarządzanie obiektami zasad grupy w środowisku kontrolerów domen wielodomenowych

• 1.8.4 Zarządzaj GPO dostępu zdalnego z ograniczonymi uprawnieniami

• 1.8.5 Odzyskiwanie usuniętego obiektu zasad grupy

Ustawienia funkcji DirectAccess skonfigurowane podczas konfigurowania dostępu zdalnego są zbierane w obiektach zasad grupy. Następujące typy obiektów zasad grupy są wypełniane ustawieniami funkcji DirectAccess i są one dystrybuowane w następujący sposób:

• Obiekt zasad grupy klienta DirectAccess

  Ten GPO zawiera ustawienia klienta, w tym ustawienia technologii przejściowej IPv6, wpisy NRPT i zaporę systemu Windows z zaawansowanymi zabezpieczeniami oraz reguły zabezpieczeń połączeń. Zasady GPO są stosowane do grup zabezpieczeń określonych dla komputerów klienckich.

• GPO serwera DirectAccess

  Ten Obiekt zasad grupy (GPO) zawiera ustawienia konfiguracji DirectAccess stosowane do dowolnego serwera skonfigurowanego jako serwer DirectAccess w twoim wdrożeniu. Zawiera również zaporę systemu Windows z regułami zabezpieczeń połączeń zaawansowanych.

• GPO serwerów aplikacji

  Ten GPO zawiera ustawienia dla wybranych serwerów aplikacji, dla których można opcjonalnie rozszerzyć uwierzytelnianie i szyfrowanie z klientów DirectAccess. Jeśli uwierzytelnianie i szyfrowanie nie zostaną rozszerzone, ta polityka grupy nie jest używana.

GPO można skonfigurować na dwa sposoby.

• Automatycznie możesz określić, że są one tworzone automatycznie. Dla każdego obiektu zasad grupy jest określona nazwa domyślna.

• Ręcznie — możesz użyć obiektów zasad grupy, które zostały wstępnie zdefiniowane przez administratora usługi Active Directory.

Niezależnie od tego, czy używasz automatycznie, czy ręcznie skonfigurowanych obiektów GPO, musisz dodać politykę wykrywania wolnego łącza, jeśli klienci będą używać sieci 3G. Ścieżka dla Polityka: Konfigurowanie wykrywania powolnego łącza zasad grupy to: Konfiguracja komputera/Polityki/Szablony administracyjne/System/Zasady grupy.

Jeśli nie istnieją poprawne uprawnienia (wymienione w poniższych sekcjach) do łączenia obiektów zasad grupy, zostanie wyświetlone ostrzeżenie. Operacja dostępu zdalnego będzie kontynuowana, ale nie nastąpi łączenie. Jeśli to ostrzeżenie zostanie wyświetlone, linki nie zostaną utworzone automatycznie, nawet jeśli uprawnienia zostaną dodane później. Zamiast tego administrator musi ręcznie utworzyć łącza.

1.8.1 Konfigurowanie automatycznie utworzonych obiektów zasad grupy

Podczas korzystania z automatycznie utworzonych obiektów zasad grupy należy wziąć pod uwagę następujące kwestie.

Automatycznie utworzone obiekty zasad grupy (GPO) są stosowane zgodnie z lokalizacją i parametrem celu łącza w następujący sposób:

• Dla obiektu zasad grupy serwera DirectAccess parametr lokalizacji i parametr łącza wskazują domenę zawierającą serwer DirectAccess.

• Po utworzeniu obiektów zasad grupy klienta i serwera aplikacji lokalizacja jest ustawiona na jedną domenę, w której zostanie utworzony obiekt zasad grupy. Nazwa obiektu zasad grupy jest wyszukiwana w każdej domenie i wypełniana ustawieniami DirectAccess, jeśli obiekt istnieje. Element docelowy łącza jest ustawiony na katalog główny domeny, w której utworzono obiekt zasad grupy. Dla każdej domeny zawierającej komputery klienckie lub serwery aplikacji tworzony jest OZG, który jest połączony z katalogiem głównym odpowiedniej domeny.

W przypadku korzystania z automatycznie utworzonych obiektów zasad grupy w celu konfigurowania ustawień DirectAccess administrator dostępu zdalnego wymaga następujących uprawnień:

• Uprawnienia do tworzenia GPO dla każdej domeny

• Uprawnienia do linków dla wszystkich wybranych domen głównych klientów

• Uprawnienia do łączenia dla katalogów głównych domeny obiektu zasad grupy serwera

Ponadto potrzebne są następujące uprawnienia:

• Uprawnienia do tworzenia, edytowania, usuwania i modyfikowania zabezpieczeń są wymagane dla obiektów zasad grupy.

• Zalecamy, aby administrator dostępu zdalnego miał uprawnienia do odczytu obiektu zasad grupy dla każdej wymaganej domeny. Dzięki temu dostęp zdalny umożliwia sprawdzenie, czy obiekty zasad grupy o zduplikowanych nazwach nie istnieją podczas tworzenia obiektów zasad grupy.

1.8.2 Konfigurowanie ręcznie utworzonych obiektów zasad grupy

Podczas korzystania z ręcznie utworzonych obiektów zasad grupy należy wziąć pod uwagę następujące kwestie:

• Obiekty zasad grupy powinny istnieć przed uruchomieniem Kreatora konfiguracji dostępu zdalnego.

• Aby zastosować ustawienia funkcji DirectAccess, administrator dostępu zdalnego wymaga pełnych uprawnień GPO (Edycja, Usuwanie, Modyfikowanie uprawnień zabezpieczeń) w ręcznie utworzonych GPO.

• W całej domenie prowadzone jest wyszukiwanie w celu znalezienia linku do obiektu zasad grupy. Jeśli obiekt zasad grupy nie jest połączony w domenie, link zostanie automatycznie utworzony w katalogu głównym domeny. Jeśli wymagane uprawnienia do utworzenia linku nie są dostępne, zostanie wyświetlone ostrzeżenie.

1.8.3 Zarządzanie obiektami zasad grupy w środowisku kontrolera z wieloma domenami

Każdy GPO jest zarządzany przez określony kontroler domeny w następujący sposób:

• Grupowy obiekt zasad (GPO) serwera jest zarządzany przez jeden z kontrolerów domeny w witrynie usługi Active Directory, która jest skojarzona z serwerem. Jeśli kontrolery domeny w tej lokacji są tylko do odczytu, obiekt zasad grupy serwera jest zarządzany przez kontroler domeny z włączoną obsługą zapisu, który znajduje się najbliżej serwera funkcji DirectAccess.

• Obiekty zasad grupy klienta i serwera aplikacji są zarządzane przez kontroler domeny, który jest uruchomiony jako podstawowy kontroler domeny (PDC).

Jeśli chcesz ręcznie zmodyfikować ustawienia obiektu zasad grupy, rozważ następujące kwestie:

• W przypadku obiektu zasad grupy serwera, aby określić, który kontroler domeny jest skojarzony z serwerem funkcji DirectAccess, w wierszu polecenia z podwyższonym poziomem uprawnień na serwerze funkcji DirectAccess uruchom polecenie nltest /dsgetdc: /writable.

• Domyślnie w przypadku wprowadzania zmian za pomocą poleceń cmdlet programu Windows PowerShell w sieci lub wprowadzania zmian z konsoli zarządzania zasadami grupy używany jest kontroler domeny, który działa jako kontroler PDC.

Ponadto w przypadku modyfikowania ustawień na kontrolerze domeny, który nie jest kontrolerem domeny skojarzonym z serwerem funkcji DirectAccess (dla obiektu zasad grupy serwera) lub kontrolera PDC (dla obiektów zasad grupy klienta i serwera aplikacji), należy wziąć pod uwagę następujące kwestie:

• Przed zmodyfikowaniem ustawień upewnij się, że kontroler domeny jest replikowany z up-to-date obiektu zasad grupy i utworzyć kopię zapasową ustawień obiektu zasad grupy. Aby uzyskać więcej informacji, zobacz Tworzenie kopii zapasowej i przywracanie konfiguracji dostępu zdalnego. Jeśli obiekt zasad grupy nie zostanie zaktualizowany, mogą wystąpić konflikty scalania podczas replikacji, co może spowodować uszkodzenie konfiguracji dostępu zdalnego.

• Po zmodyfikowaniu ustawień należy poczekać, aż zmiany zostaną zreplikowane na kontrolery domeny skojarzone z obiektami zasad grupy. Nie wprowadzaj dodatkowych zmian przy użyciu konsoli zarządzania dostępem zdalnym lub poleceń cmdlet programu PowerShell dostępu zdalnego do momentu ukończenia replikacji. Jeśli obiekt zasad grupy jest edytowany na dwóch kontrolerach domeny przed zakończeniem replikacji, mogą wystąpić konflikty scalania, co może spowodować uszkodzenie konfiguracji dostępu zdalnego.

Alternatywnie można zmienić ustawienie domyślne przy użyciu okna dialogowego Zmienianie kontrolera domeny w konsoli zarządzania zasadami grupy lub za pomocą polecenia cmdlet programu Windows PowerShell Open-NetGPO, aby zmiany używały określonego kontrolera domeny.

• Aby to zrobić w konsoli zarządzania zasadami grupy, kliknij prawym przyciskiem myszy kontener domeny lub lokacji, a następnie kliknij polecenie Zmień kontroler domeny.

• Aby to zrobić w programie Windows PowerShell, określ parametr DomainController dla polecenia cmdlet Open-NetGPO . Aby na przykład włączyć profile prywatne i publiczne w Zaporze systemu Windows w obiekcie zasad grupy o nazwie domain1\DA_Server_GPO _Europe przy użyciu kontrolera domeny o nazwie europe-dc.corp.contoso.com, wprowadź następujące polecenie:

  $gpoSession = Open-NetGPO -PolicyStore "domain1\DA_Server_GPO _Europe" -DomainController "europe-dc.corp.contoso.com"
  Set-NetFirewallProfile -GpoSession $gpoSession -Name @("Private","Public") -Enabled True
  Save-NetGPO -GpoSession $gpoSession
  

1.8.4 Zarządzanie obiektami zasad grupy dostępu zdalnego z ograniczonymi uprawnieniami

Aby zarządzać wdrożeniem dostępu zdalnego, administrator dostępu zdalnego musi mieć pełne uprawnienia GPO (odczyt, edycja, usuwanie i modyfikacja uprawnień zabezpieczeń) na obiektach GPO używanych we wdrożeniu. Dzieje się tak, ponieważ konsola zarządzania dostępem zdalnym i moduły programu PowerShell dostępu zdalnego odczytują konfigurację i zapisują ją w obiektach zasad grupy dostępu zdalnego (czyli obiektach zasad grupy klienta, serwera i serwera aplikacji).

W wielu organizacjach administrator domeny odpowiedzialny za operacje GPO nie jest tą samą osobą, co administrator odpowiedzialny za konfigurację dostępu zdalnego. Te organizacje mogą mieć zasady ograniczające administratorowi dostępu zdalnego pełne uprawnienia do obiektów zasad grupy w domenie. Administrator domeny może być również wymagany do przejrzenia konfiguracji zasad przed zastosowaniem jej do dowolnego komputera w domenie.

Aby spełnić te wymagania, administrator domeny powinien utworzyć dwie kopie każdej zasady grupy: wersje przejściowe i produkcyjne. Administrator dostępu zdalnego ma pełne uprawnienia do przygotowawczych obiektów zasad grupy. Administrator dostępu zdalnego określa tymczasowe obiekty zasad grupy w konsoli zarządzania dostępem zdalnym i w poleceniach cmdlet programu Windows PowerShell jako obiekty zasad grupy używane do wdrożenia dostępu zdalnego. Dzięki temu administrator dostępu zdalnego może odczytywać i modyfikować konfigurację dostępu zdalnego zgodnie z wymaganiami i w razie potrzeby.

Administrator domeny musi upewnić się, że obiekty zasad grupy (GPO) w fazie testowej nie są połączone z żadnym zakresem zarządzania w domenie, a administrator dostępu zdalnego nie ma uprawnień do łączenia GPO w domenie. Zapewnia to, że zmiany wprowadzone przez administratora dostępu zdalnego do początkowych obiektów zasad grupy nie mają żadnego wpływu na komputery w domenie.

Administrator domeny łączy produkcyjne zasady grupy z wymaganym zakresem zarządzania i nakłada odpowiednie filtrowanie zabezpieczeń. Dzięki temu zmiany tych obiektów zasad grupy są stosowane do komputerów w domenie (komputery klienckie, serwery DirectAccess i serwery aplikacji). Administrator dostępu zdalnego nie ma uprawnień do produkcyjnych GPO.

Gdy administrator domeny wprowadza zmiany w GPOs w środowisku testowym, może przejrzeć konfigurację zasad w tych obiektach, aby upewnić się, że spełniają one wymagania bezpieczeństwa w organizacji. Następnie administrator domeny eksportuje ustawienia z obiektów GPO w środowisku testowym przy użyciu funkcji tworzenia kopii zapasowej i importuje ustawienia do odpowiednich produkcyjnych obiektów GPO, które zostaną zastosowane do komputerów w domenie.

Na poniższym diagramie przedstawiono tę konfigurację.

1.8.5 Odzyskiwanie usuniętego obiektu zasad grupy

Jeśli obiekt zasad grupy klienta, serwera DirectAccess lub serwera aplikacji został przypadkowo usunięty i nie ma dostępnej kopii zapasowej, musisz usunąć ustawienia konfiguracji i ponownie je skonfigurować. Jeśli kopia zapasowa jest dostępna, możesz przywrócić GPO z kopii zapasowej.

Konsola zarządzania dostępem zdalnym wyświetli następujący komunikat o błędzie: Nie można odnaleźć GPO (nazwa obiektu zasad grupy). Aby usunąć ustawienia konfiguracji, wykonaj następujące czynności:

1. Uruchom polecenie cmdlet programu Windows PowerShell Uninstall-remoteaccess.

2. Otwórz konsolę zarządzania dostępem zdalnym.

3. Zostanie wyświetlony komunikat o błędzie informujący, że obiekt zasad grupy (GPO) nie został znaleziony. Kliknij Usuń ustawienia konfiguracji. Po zakończeniu serwer zostanie przywrócony do stanu nieskonfigurowanego.

Dalsze kroki

• Krok 2. Planowanie wdrożeń funkcji DirectAccess