Megosztás:

1. lépés Az Advanced DirectAccess-infrastruktúra megtervezése

A speciális DirectAccess-telepítés egyetlen kiszolgálón történő tervezésének első lépése az üzembe helyezéshez szükséges infrastruktúra megtervezése. Ez a témakör az infrastruktúra tervezési lépéseit ismerteti. Ezeket a tervezési feladatokat nem kell meghatározott sorrendben elvégezni.

Task Description
1.1 Hálózati topológia és beállítások tervezése Döntse el, hogy hová helyezze a DirectAccess-kiszolgálót (a peremhálózaton vagy egy hálózati címfordítási (NAT-) eszköz vagy tűzfal mögött), és tervezze meg az IP-címzést, az útválasztást és az bújtatás kényszerítését.
1.2 Tűzfalkövetelmények tervezése Tervezze meg a DirectAccess-forgalom peremhálózati tűzfalakon keresztüli engedélyezését.
1.3 Tanúsítványkövetelmények tervezése Döntse el, hogy Kerberost vagy tanúsítványokat szeretne-e használni az ügyfél-hitelesítéshez, és tervezze meg a webhely tanúsítványait. IP-HTTPS egy átmeneti protokoll, amelyet a DirectAccess-ügyfelek használnak az IPv6-forgalom IPv4-hálózatokon való alagútba való bújtatásához. Döntse el, hogy hitelesítést kíván-e végezni a IP-HTTPS-kiszolgálón egy hitelesítésszolgáltató (CA) által kiadott tanúsítvány használatával, vagy a DirectAccess-kiszolgáló által automatikusan kibocsátott önaláírt tanúsítvány használatával.
1.4 DNS-követelmények tervezése Tervezze meg a Tartománynévrendszer (DNS) beállításait a DirectAccess-kiszolgálóhoz, az infrastruktúra-kiszolgálókhoz, a helyi névfeloldási beállításokhoz és az ügyfélkapcsolathoz.
1.5 A hálózati hely kiszolgálójának megtervezése A DirectAccess-ügyfelek a hálózati helykiszolgálót használják annak meghatározására, hogy a belső hálózaton találhatók-e. Döntse el, hogy hová helyezze a hálózatihely-kiszolgáló webhelyét a szervezetében (a DirectAccess-kiszolgálón vagy egy másik kiszolgálón), és tervezze meg a tanúsítványkövetelményeket, ha a hálózatihely-kiszolgáló a DirectAccess-kiszolgálón található.
1.6 tervkezelési kiszolgálók Távolról kezelheti az interneten a vállalati hálózaton kívül található DirectAccess-ügyfélszámítógépeket. Tervezze meg a távoli ügyfélkezelés során használt felügyeleti kiszolgálókat (például frissítési kiszolgálókat).
1.7 Az Active Directory Domain Services tervezése Tervezze meg a tartományvezérlőket, az Active Directory követelményeit, az ügyfélhitelesítést és több tartományt.
1.8 Csoportházirend-objektumok tervezése Döntse el, hogy milyen csoportházirend-objektumokra van szükség a szervezetben, és hogyan hozhatja létre vagy szerkesztheti a csoportházirend-objektumokat.

1.1 Hálózati topológia és beállítások tervezése

Ez a szakasz bemutatja, hogyan tervezheti meg a hálózatot, többek között a következőket:

1.1.1 Hálózati adapterek és IP-címek tervezése

  1. Azonosítsa a használni kívánt hálózati adapter topológiát. A DirectAccess az alábbi topológiák egyikével állítható be:

    • Két hálózati adapter. A DirectAccess-kiszolgáló a peremhálózaton telepíthető az egyik hálózati adapterrel, amely csatlakozik az internethez, a másik pedig a belső hálózathoz, vagy egy NAT-, tűzfal- vagy útválasztó-eszköz mögött telepíthető, és az egyik hálózati adapter egy szegélyhálózathoz csatlakozik, a másik pedig a belső hálózathoz.

    • Egy hálózati adapter. A DirectAccess-kiszolgáló nat-eszköz mögött van telepítve, és az egyetlen hálózati adapter csatlakozik a belső hálózathoz.

  2. Az IP-címzési követelmények azonosítása:

    A DirectAccess az IPv6 és az IPsec használatával hoz létre biztonságos kapcsolatot a DirectAccess ügyfélszámítógépek és a belső vállalati hálózat között. A DirectAccess azonban nem feltétlenül igényel iPv6-internetkapcsolatot vagy natív IPv6-támogatást a belső hálózatokon. Ehelyett automatikusan konfigurálja és használja az IPv6-áttűnési technológiákat az IPv6-forgalom alagúton keresztül az IPv4-interneten (6to4, Teredo vagy IP-HTTPShasználatával) és az IPv4-alapú intraneten (NAT64 vagy ISATAP használatával). Az áttűnési technológiák áttekintéséhez tekintse meg a következő forrásokat:

  3. Konfigurálja a szükséges adaptereket és címeket az alábbi táblázat szerint. Az IP-címeket csak a belső hálózati adapter oszlop használatával konfigurálhatja azokban a telepítésekben, amelyek egyetlen hálózati adaptert használnak, és NAT-eszköz mögött vannak beállítva.

    Description Külső hálózati adapter Belső hálózati adapter Útválasztási követelmények
    IPv4 Internet és IPv4 intranet Konfiguráljon két statikus, egymást követő nyilvános IPv4-címet a megfelelő alhálózati maszkokkal (csak Teredo esetén szükséges).

    Konfigurálja továbbá az internetes tűzfal vagy a helyi internetszolgáltatói útválasztó alapértelmezett IPv4-címét is. Jegyzet: A DirectAccess-kiszolgáló két egymást követő nyilvános IPv4-címet igényel, hogy Teredo-kiszolgálóként működjön, a Windows-alapú ügyfelek pedig a DirectAccess-kiszolgálóval észlelhetik a mögöttes NAT-eszköz típusát.    		 Konfigurálja a következőket:

    - Egy IPv4 intranetes cím a megfelelő alhálózati maszkkal.
    - Az intranetes névtér kapcsolatspecifikus DNS-utótagja. Egy DNS-kiszolgálót is konfigurálni kell a belső felületen. Figyelmeztet: Ne konfiguráljon alapértelmezett átjárót intranetes adaptereken.    		 Ha úgy szeretné konfigurálni a DirectAccess-kiszolgálót, hogy elérje a belső IPv4-hálózat összes alhálózatát, tegye a következőket:

    – Listázhatja az intraneten található összes hely IPv4-címtereit.
    – A útvonal add -p vagy a netsh interface ipv4 add route paranccsal adja hozzá az IPv4 címtereket statikus útvonalként a DirectAccess-kiszolgáló IPv4 útválasztási táblájában.
    IPv6 Internet és IPv6 intranet Konfigurálja a következőket:

    – Használja az internetszolgáltató által megadott címkonfigurációt.
    – Az Útvonal nyomtatása paranccsal győződjön meg arról, hogy létezik egy alapértelmezett IPv6-útvonal, és az IPv6 útválasztási táblában az INTERNETP-útválasztóra mutat.
    – Annak meghatározása, hogy az internetszolgáltató és az intranetes útválasztó az RFC 4191-ben ismertetett alapértelmezett útválasztó-beállításokat használja-e, és a helyi intranetes útválasztóknál magasabb alapértelmezett beállítást használ-e.
    Ha mindkettő igaz, nincs szükség más konfigurációra az alapértelmezett útvonalhoz. Az internetszolgáltató útválasztójának magasabb preferenciája biztosítja, hogy a DirectAccess-kiszolgáló aktív alapértelmezett IPv6-útvonala az IPv6 internetre mutatjon.

    Mivel a DirectAccess-kiszolgáló egy IPv6-útválasztó, ha natív IPv6-infrastruktúrával rendelkezik, az internetkapcsolat az intranet tartományvezérlőit is elérheti. Ebben az esetben adjon hozzá csomagszűrőket a szegélyhálózat tartományvezérlőjéhez, amely megakadályozza a DirectAccess-kiszolgáló internetkapcsolattal rendelkező felületének IPv6-címéhez való kapcsolódást.    		 Konfigurálja a következőket:

    - Ha nem az alapértelmezett beállítási szinteket használja, az intranet felületeit a következő paranccsal konfigurálhatja:netsh interface ipv6 set InterfaceIndex ignoredefaultroutes=enabled.
    Ez a parancs biztosítja, hogy az intranetes útválasztókra mutató további alapértelmezett útvonalak ne legyenek hozzáadva az IPv6 útválasztási táblához. Az intranetes adapterek felületindexét a következő paranccsal szerezheti be: netsh interface ipv6 show interface.    		 Ha rendelkezik IPv6-intranetel, a DirectAccess-kiszolgáló konfigurálásához az összes IPv6-hely eléréséhez tegye a következőket:

    – Listázhatja az intraneten található összes hely IPv6-címtereit.
    – A netsh interface ipv6 add route paranccsal adja hozzá az IPv6 címtereket statikus útvonalként a DirectAccess-kiszolgáló IPv6 útválasztási táblájában.
    IPv4 Internet és IPv6 intranet A DirectAccess-kiszolgáló továbbítja az alapértelmezett IPv6-útvonal forgalmát a Microsoft 6to4-adapteren keresztül egy 6to4-reléhez az IPv4 Interneten. A Microsoft 6to4-adapter IPv4-címéhez konfigurálhat DirectAccess-kiszolgálót a következő paranccsal: netsh interface ipv6 6to4 set relay name=<ipaddress> state=enabled.

    Note

    • Ha a DirectAccess-ügyfélhez nyilvános IPv4-cím van hozzárendelve, a 6to4 áttűnési technológiával csatlakozik az intranethez. Ha egy privát IPv4-cím van hozzárendelve, akkor a Teredót fogja használni. Ha a DirectAccess-ügyfél nem tud csatlakozni a DirectAccess-kiszolgálóhoz a 6to4 vagy a Teredo használatával, ip-HTTPS-t fog használni.
    • A Teredo használatához két egymást követő IP-címet kell konfigurálnia a külső hálózati adapteren.
    • A Teredo nem használható, ha a DirectAccess-kiszolgáló csak egy hálózati adapterrel rendelkezik.
    • Natív IPv6-ügyfélszámítógépek natív IPv6-tal csatlakozhatnak a DirectAccess-kiszolgálóhoz, és nincs szükség áttűnési technológiára.

1.1.2 IPv6 intranetes kapcsolat tervezése

A távoli DirectAccess-ügyfelek kezeléséhez IPv6 szükséges. Az IPv6 lehetővé teszi, hogy a DirectAccess felügyeleti kiszolgálói távoli felügyelet céljából csatlakozzanak az interneten található DirectAccess-ügyfelekhez.

Note

  • Az IPv6 használata a hálózaton nem szükséges a DirectAccess ügyfélszámítógépek által kezdeményezett kapcsolatok támogatásához a szervezeti hálózat IPv4-erőforrásaihoz. Erre a célra NAT64/DNS64 használható.
  • Ha nem kezeli a távoli DirectAccess-ügyfeleket, nem kell üzembe helyeznie az IPv6-ot.
  • Intra-Site Automatikus alagútcímzési protokoll (ISATAP) nem támogatott a DirectAccess-környezetekben.
  • Az IPv6 használatakor engedélyezheti az IPv6-gazdagép (AAAA) erőforrásrekord-lekérdezését a DNS64-hez a következő Windows PowerShell-paranccsal: Set-NetDnsTransitionConfiguration -OnlySendAQuery $false.

1.1.3 A kényszerített alagútépítés terve

Az IPv6 és a névfeloldási házirendtáblával (NRPT) alapértelmezés szerint a DirectAccess-ügyfelek az alábbiak szerint választják el az intranetes és az internetes forgalmat:

  • Dns-névlekérdezések az intranet teljes tartományneveihez (FQDN-ekhez), és az intranetes forgalom a DirectAccess-kiszolgálóval vagy közvetlenül intranetes kiszolgálókkal létrehozott alagutakon keresztül történik. A DirectAccess-ügyfelek intranetes forgalma IPv6-forgalom.

  • Az olyan teljes tartománynevek DNS-névlekérdezései, amelyek megfelelnek a kivételszabályoknak, vagy nem felelnek meg az intranetes névtérnek, és az internetkiszolgálók felé irányuló összes forgalom az internethez csatlakoztatott fizikai felületen történik. A DirectAccess-ügyfelek internetes forgalma általában IPv4-forgalom.

Ezzel szemben alapértelmezés szerint néhány távelérési virtuális magánhálózati (VPN-) implementáció, beleértve a VPN-ügyfelet is, az összes intranetes és internetes forgalmat a távelérési VPN-kapcsolaton keresztül küldi el. Az internethez kötött forgalmat a VPN-kiszolgáló irányítja az intranetes IPv4-webproxy-kiszolgálókra az IPv4 internetes erőforrásokhoz való hozzáférés érdekében. A távelérésű VPN-ügyfelek intranetes és internetes forgalmát osztott bújtatással lehet elkülöníteni. Ehhez konfigurálnia kell az Internet Protocol (IP) útválasztási táblát a VPN-ügyfeleken, hogy az intranetes helyekre irányuló forgalom a VPN-kapcsolaton keresztül legyen továbbítva, és az összes többi helyre irányuló forgalmat az internethez csatlakoztatott fizikai adapterrel küldi el.

A DirectAccess-ügyfeleket úgy konfigurálhatja, hogy azok az összes forgalmukat az alagutakon keresztül kényszerített alagútkezeléssel küldjék el a DirectAccess-kiszolgálóra. A kényszerített bújtatás konfigurálásakor a DirectAccess-ügyfelek észlelik, hogy az interneten vannak, és eltávolítják az alapértelmezett IPv4-útvonalukat. A helyi alhálózati forgalom kivételével a DirectAccess-ügyfél által küldött összes forgalom az IPv6-forgalom, amely a DirectAccess-kiszolgáló felé az alagutakon halad át.

Important

Ha kényszerítő bújtatást tervez használni, vagy a jövőben hozzáadja, két alagútkonfigurációt kell üzembe helyeznie. Biztonsági megfontolások miatt az egyetlen alagútkonfiguráció kényszerítése nem támogatott.

A kényszerített bújtatás engedélyezése a következő következményekkel jár:

  • A DirectAccess-ügyfelek csak az Internet Protocol protokollt használják a Secure Hypertext Transfer Protocol (IP-HTTPS) protokollon keresztül, hogy IPv6-kapcsolatot szerezzenek be a DirectAccess-kiszolgálóval az IPv4-interneten keresztül.

  • A DirectAccess-ügyfél alapértelmezés szerint csak az IPv4-forgalommal érheti el azokat a helyeket, amelyek a helyi alhálózatán találhatók. A DirectAccess-ügyfélen futó alkalmazások és szolgáltatások által küldött összes többi forgalom az IPv6-forgalom, amelyet a Rendszer a DirectAccess-kapcsolaton keresztül küld el. Ezért a DirectAccess-ügyfélen található csak IPv4-alkalmazások nem használhatók internetes erőforrások elérésére, kivéve a helyi alhálózaton lévőket.

Important

A DNS64- és NAT64-alapú kényszerített bújtatáshoz IPv6-internetkapcsolatot kell megvalósítani. Ennek egyik módja az, hogy a IP-HTTPS előtagot globálisan elérhetetlenné teszi, így ipv6.msftncsi.com elérhető lesz az IPv6-on keresztül, és az internetkiszolgáló és a IP-HTTPS ügyfelek válasza a DirectAccess-kiszolgálón keresztül is vissza tud térni.

Mivel ez a legtöbb esetben nem kivitelezhető, a legjobb megoldás a virtuális NCSI-kiszolgálók létrehozása a vállalati hálózaton belül az alábbiak szerint:

  1. Adjon hozzá egy NRPT-bejegyzést az ipv6.msftncsi.com-hoz, és kösse össze DNS64-en keresztül egy belső webhelyre (ez lehet IPv4-webhely).
  2. Adjon hozzá egy NRPT-bejegyzést a dns.msftncsi.com címhez, és oldja fel egy vállalati DNS-kiszolgálón az fd3e:4f5a:5b81::1 IPv6 hoszt (AAAA) erőforrásrekord visszaadásához. (Lehetséges, hogy a DNS64 használata a gazdagép (A) erőforrásrekord-lekérdezések küldésére ennél a teljes tartománynévnél nem fog működni, mivel csak IPv4-es környezetekben van beállítva, ezért közvetlenül a vállalati DNS-t kell konfigurálnia ehhez a feloldáshoz.)

1.2 Tűzfalkövetelmények tervezése

Ha a DirectAccess-kiszolgáló peremhálózati tűzfal mögött található, a távelérési forgalomhoz a következő kivételek szükségesek, ha a DirectAccess-kiszolgáló az IPv4-interneten található:

  • Teredo traffic-User Datagram Protocol (UDP) célport 3544 bejövő, UDP forrásport 3544 kimenő.

  • 6to4 traffic-IP Protocol 41 bejövő és kimenő.

  • AZ IP-HTTPS-Transmission Control Protocol (TCP) célportja 443, a TCP-forrásport pedig a 443-at kimenő.

  • Ha a távelérést egyetlen hálózati adapterrel állítja be, és a hálózati helykiszolgálót a DirectAccess-kiszolgálóra telepíti, akkor a 62000-es TCP-portot is ki kell zárni.

    Note

    Ez a kivétel a DirectAccess-kiszolgálón található, és az összes többi kivétel a peremhálózati tűzfalon található.

Teredo- és 6to4-forgalom esetén ezeket a kivételeket a DirectAccess-kiszolgálón lévő, internetes elérésű, egymást követő nyilvános IPv4-címekre kell alkalmazni. IP-HTTPS esetén a kivételeket a nyilvános DNS-kiszolgálón regisztrált címre kell alkalmazni.

A távelérési forgalomhoz a következő kivételek szükségesek, ha a DirectAccess-kiszolgáló az IPv6-interneten található:

  • IP-protokoll azonosító 50

  • UDP-célport 500 bejövő és UDP forrásport 500 kimenő

  • Bejövő és kimenő ICMPv6-forgalom (csak Teredo használata esetén)

Ha további tűzfalakat használ, alkalmazza a következő belső hálózati tűzfal-kivételeket a távelérési forgalomra:

  • ISATAP-Protocol 41 bejövő és kimenő forgalom

  • TCP/UDP az összes IPv4- és IPv6-forgalomhoz

  • ICMP az összes IPv4- és IPv6-forgalomhoz (csak Teredo használata esetén)

1.3 Tanúsítványkövetelmények tervezése

Egyetlen DirectAccess-kiszolgáló üzembe helyezésekor három esetben van szükség tanúsítványokra:

Az egyes forgatókönyvek hitelesítésszolgáltatói (CA) követelményeit az alábbi táblázat foglalja össze.

IPsec-hitelesítés IP-HTTPS kiszolgáló Hálózati hely kiszolgálója
Ha nem használja a Kerberos-proxyt hitelesítéshez, belső hitelesítésszolgáltatóra van szükség a DirectAccess-kiszolgáló és az ügyfelek számára az IPsec-hitelesítéshez szükséges számítógép-tanúsítványok kiállításához Belső hitelesítésszolgáltató:

A IP-HTTPS tanúsítványt belső hitelesítésszolgáltatóval is kibocsáthatja; Azonban meg kell győződnie arról, hogy a CRL terjesztési pont külsőleg elérhető.		 Belső hitelesítésszolgáltató:

A hálózati helykiszolgáló webhelytanúsítványának kiállításához használhat belső hitelesítésszolgáltatót. Győződjön meg arról, hogy a CRL terjesztési pont magas rendelkezésre állással rendelkezik a belső hálózatról.
Önaláírt tanúsítvány:

Használhat önaláírt tanúsítványt a IP-HTTPS kiszolgálóhoz; Azonban meg kell győződnie arról, hogy a CRL terjesztési pont külsőleg elérhető.

Önaláírt tanúsítvány nem használható többhelyszínes telepítésekben.		 Önaláírt tanúsítvány:

A hálózati helykiszolgáló webhelyéhez használhat önaláírt tanúsítványt.

Önaláírt tanúsítvány nem használható többhelyszínes telepítésekben.
Recommended

Nyilvános hitelesítésszolgáltató:

Javasoljuk, hogy a IP-HTTPS tanúsítvány kiállításához nyilvános hitelesítésszolgáltatót használjon. Ez biztosítja, hogy a CRL terjesztési pont külsőleg elérhető legyen.

1.3.1 Számítógéptanúsítványok tervezése IPsec-hitelesítéshez

Ha tanúsítványalapú IPsec-hitelesítést használ, a DirectAccess-kiszolgálónak és az ügyfeleknek számítógép-tanúsítványt kell beszerezniük. A tanúsítványok telepítésének legegyszerűbb módja a csoportházirend-alapú automatikus regisztráció konfigurálása a számítógéptanúsítványokhoz. Ez biztosítja, hogy minden tartománytag tanúsítványt szerezzen be egy vállalati hitelesítésszolgáltatótól. Ha nincs beállítva vállalati hitelesítésszolgáltató a szervezetben, tekintse meg Active Directory tanúsítványszolgáltatásokcímű témakört.

Ez a tanúsítvány a következő követelményekkel rendelkezik:

  • A tanúsítványnak kiterjesztett kulcshasználatként ügyfél-hitelesítést (EKU) kell tartalmaznia.

  • Az ügyféltanúsítványnak és a kiszolgálótanúsítványnak ugyanahhoz a főtanúsítványhoz kell láncot fűznie. Ezt a főtanúsítványt ki kell jelölni a DirectAccess konfigurációs beállításai között.

1.3.2 Tanúsítványok tervezése IP-HTTPS

A DirectAccess-kiszolgáló IP-HTTPS figyelőként működik, és manuálisan kell telepítenie egy HTTPS-webhelytanúsítványt a kiszolgálón. A tervezés során vegye figyelembe a következőket:

  • Nyilvános hitelesítésszolgáltató használata ajánlott, hogy a visszavont tanúsítványok listája (CRL-ek) könnyen elérhetők legyenek.

  • A Tárgy mezőben adja meg a DirectAccess-kiszolgáló internetes adapterének IPv4-címét vagy a IP-HTTPS URL-címének teljes tartománynevét (a ConnectTo-címet). Ha a DirectAccess-kiszolgáló NAT-eszköz mögött található, meg kell adni a NAT-eszköz nyilvános nevét vagy címét.

  • A tanúsítvány általános nevének meg kell egyeznie a IP-HTTPS hely nevével.

  • A Bővített kulcshasználat mezőben használja a kiszolgálóhitelesítési objektum azonosítóját (OID).

  • A CRL terjesztési pontok mezőben adjon meg egy olyan CRL-terjesztési pontot, amelyet az internethez csatlakozó DirectAccess-ügyfelek érhetnek el.

  • A IP-HTTPS tanúsítványnak titkos kulccsal kell rendelkeznie.

  • A IP-HTTPS tanúsítványt közvetlenül a személyes tárolóba kell importálni.

  • IP-HTTPS tanúsítványok helyettesítő karaktereket tartalmazhatnak a névben.

Ha nem szabványos porton szeretné használni a IP-HTTPS, hajtsa végre a következő lépéseket a DirectAccess-kiszolgálón:

  1. Távolítsa el a meglévő tanúsítványkötést a 0.0.0.0:443-hoz, és cserélje le a választott porthoz tartozó tanúsítványkötésre. Ebben a példában a 44500-s portot használjuk. A tanúsítványkötés törlése előtt jelenítse meg és másolja ki az appidot.

    1. A tanúsítványkötés törléséhez írja be a következőt:

      netsh http delete ssl ipport=0.0.0.0:443

    2. Az új tanúsítványkötés hozzáadásához írja be a következőt:

      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. A kiszolgáló IP-HTTPS URL-címének módosításához írja be a következőt:

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

    Net stop iphlpsvc & net start iphlpsvc

  3. Módosítsa a kdcproxy URL-foglalását.

    1. A meglévő URL-foglalás törléséhez írja be a következőt:

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

    2. Új URL-foglalás hozzáadásához írja be a következőt:

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

  4. Adja hozzá a beállítást, hogy a kppsvc figyelje a nem szabványos portot. A beállításjegyzék-bejegyzés hozzáadásához írja be a következőt:

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

  5. A kdcproxy szolgáltatás tartományvezérlőn való újraindításához írja be a következőt:

    net stop kpssvc & net start kpssvc

Ha nem szabványos porton szeretné használni a IP-HTTPS, hajtsa végre a következő lépéseket a tartományvezérlőn:

  1. Módosítsa a IP-HTTPS beállítást az ügyfél GPO-jában.

    1. Nyissa meg a Csoportházirend-szerkesztőt.

    2. Navigáljon a Számítógép konfigurációja=>Házirendek=>Felügyeleti sablonok=> Hálózat=>TCP/IP beállítások=>IPv6 áttűnési technológiák.

    3. Nyissa meg a IP-HTTPS állapotbeállítást, és módosítsa az URL-címet https://<DirectAccess-kiszolgáló nevére (például server.contoso.com)>:44500/IPHTTPS.

    4. Kattintson az Alkalmaz gombra.

  2. Módosítsa a Kerberos proxy kliens beállításait az ügyfél csoportházirend-objektumában (GPO).

    1. A Csoportházirend-szerkesztőben keresse meg a Számítógép konfigurációja=>Házirendek=>Felügyeleti sablonok=> System=>Kerberos => Adja meg a Kerberos-ügyfelek KDC proxy kiszolgálóit.

    2. Nyissa meg az IPHTTPS állapotbeállítást, és módosítsa az URL-címet https://<DirectAccess-kiszolgáló nevére (például server.contoso.com)>:44500/IPHTTPS.

    3. Kattintson az Alkalmaz gombra.

  3. Módosítsa az ügyfél IPsec-házirend-beállításait a ComputerKerb és a UserKerb használatára.

    1. A Csoportházirend-szerkesztőben lépjen a következő helyre: Számítógép konfigurációja=>Házirendek=> Windows-beállítások=> Biztonsági beállítások=> Windows tűzfal speciális biztonsági beállításokkal.

    2. Kattintson a kapcsolat-biztonsági szabályokra, és kattintson duplán a IPsec-szabályra.

    3. A Hitelesítés lapon kattintson a Speciális gombra.

    4. Hitelesítés1 esetén: Távolítsa el a meglévő hitelesítési módszert, és cserélje le a ComputerKerbre. Hitelesítés2 esetén: Távolítsa el a meglévő hitelesítési módszert, és cserélje le a UserKerbre.

    5. Kattintson az Alkalmaz gombra, majd az OK gombra.

A IP-HTTPS nem szabványos port használatára vonatkozó manuális folyamat befejezéséhez futtassa a gpupdate /force parancsot az ügyfélszámítógépeken és a DirectAccess-kiszolgálón.

1.3.3 Webhelytanúsítványok tervezése a hálózati helykiszolgálóhoz

A hálózatihely-kiszolgáló webhelyének tervezésekor vegye figyelembe a következőket:

  • A Tárgy mezőben adja meg a hálózatihely-kiszolgáló intranetes adapterének IP-címét vagy a hálózati hely URL-címének teljes tartománynevét.

  • A Bővített kulcshasználat mezőben használja a Kiszolgálóhitelesítési OID-t.

  • A CRL terjesztési pontok mezőben használjon egy CRL-terjesztési pontot, amelyet az intranethez csatlakozó DirectAccess-ügyfelek érhetnek el. Ez a CRL-terjesztési pont nem lehet elérhető a belső hálózaton kívülről.

  • Ha később többhelyes vagy fürttelepítés konfigurálását tervezi, a tanúsítvány neve nem egyezhet meg az üzembe helyezéshez hozzáadandó DirectAccess-kiszolgáló belső nevével.

    Note

    Győződjön meg arról, hogy a IP-HTTPS és a hálózatihely-kiszolgáló tanúsítványai tulajdonosnévvel rendelkeznek. Ha a tanúsítvány nem rendelkezik tulajdonosnévvel, de alternatív névvel rendelkezik, a távelérési varázsló nem fogadja el.

1.4 DNS-követelmények tervezése

Ez a szakasz a DirectAccess-ügyfélkérelmekre és az infrastruktúra-kiszolgálókra vonatkozó DNS-követelményeket ismerteti egy távelérési üzemelő példányban. A következő alszakaszokat tartalmazza:

DirectAccess-ügyfélkérések

A DNS a nem a belső (vagy vállalati) hálózaton található DirectAccess-ügyfélszámítógépekről érkező kérelmek megoldására szolgál. A DirectAccess-ügyfelek megpróbálnak csatlakozni a DirectAccess hálózati helykiszolgálóhoz annak megállapításához, hogy az interneten vagy a belső hálózaton találhatók-e.

  • Ha a kapcsolat sikeres, az ügyfeleket a rendszer a belső hálózaton találhatóként azonosítja, a DirectAccess nincs használatban, és az ügyfélkéréseket az ügyfélszámítógép hálózati adapterén konfigurált DNS-kiszolgáló használatával oldja fel.

  • Ha a kapcsolat nem sikerül, a rendszer feltételezi, hogy az ügyfelek az interneten találhatók, a DirectAccess-ügyfelek pedig a névfeloldási házirendtáblát (NRPT) használják annak meghatározására, hogy melyik DNS-kiszolgálót kell használni a névkérések feloldásakor.

Megadhatja, hogy az ügyfelek a DirectAccess DNS64 használatával oldják fel a neveket, vagy egy másik belső DNS-kiszolgálót. A névfeloldás végrehajtásakor a DirectAccess-ügyfelek az NRPT-t használják a kérések kezeléséhez. Az ügyfelek teljes tartománynevet vagy egycímkés nevet kérnek, például https://internal. Ha egycímkés nevet kér, a rendszer hozzáfűz egy DNS-utótagot a teljes tartománynév létrehozásához. Ha a DNS-lekérdezés megfelel az NRPT-ben egy bejegyzésnek, és a bejegyzéshez a DNS64 vagy a belső hálózat DNS-kiszolgálója van megadva, a rendszer a megadott kiszolgálóval küldi el a lekérdezést névfeloldáshoz. Ha létezik egyezés, de nincs megadva DNS-kiszolgáló, ez egy kivételi szabályt jelez, és a normál névfeloldás lesz alkalmazva.

Note

Vegye figyelembe, hogy ha a távelérés-kezelési konzol új utótagot ad hozzá az NRPT-hez, az utótag alapértelmezett DNS-kiszolgálói az Detect (Észlelés) gombra kattintva automatikusan felderíthetők.

Az automatikus észlelés a következőképpen működik:

  • Ha a vállalati hálózat IPv4-alapú, vagy IPv4- és IPv6-alapú, az alapértelmezett cím a DirectAccess-kiszolgáló belső adapterének DNS64-címe.

  • Ha a vállalati hálózat IPv6-alapú, az alapértelmezett cím a vállalati hálózaton lévő DNS-kiszolgálók IPv6-címe.

Note

A Windows 10 2020. májusi frissítésétől kezdve az ügyfél már nem regisztrálja IP-címét a névfeloldási házirendtáblában (NRPT) konfigurált DNS-kiszolgálókon. Ha DNS-regisztrációra van szükség, például a Manage Out (Kikezelés) funkcióra, az ügyfélen az alábbi beállításkulcs használatával explicit módon engedélyezhető:

Elérési út: HKLM\System\CurrentControlSet\Services\Dnscache\Parameters
Típus: DWORD
Érték neve: DisableNRPTForAdapterRegistration
Values:
1 – A DNS-regisztráció le van tiltva (alapértelmezés a Windows 10 2020. májusi frissítése óta)
0 – A DNS-regisztráció engedélyezve van

Infrastruktúra-kiszolgálók

  • hálózati helykiszolgáló

    A DirectAccess-ügyfelek megpróbálják elérni a hálózati helykiszolgálót annak megállapításához, hogy a belső hálózaton vannak-e. A belső hálózaton lévő ügyfeleknek képesnek kell lenniük feloldani a hálózati helykiszolgáló nevét, de meg kell akadályozni őket a név feloldásában, amikor az interneten találhatók. Ennek biztosítása érdekében alapértelmezés szerint a hálózatihely-kiszolgáló teljes tartományneve kivételszabályként lesz hozzáadva az NRPT-hez. Emellett a távelérés konfigurálásakor a következő szabályok automatikusan létrejönnek:

    • Dns-utótagszabály a gyökértartományra vagy a DirectAccess-kiszolgáló tartománynevére, valamint a DNS64-címnek megfelelő IPv6-címekre. Csak IPv6-alapú vállalati hálózatokban az intranetes DNS-kiszolgálók a DirectAccess-kiszolgálón vannak konfigurálva. Ha például a DirectAccess-kiszolgáló a corp.contoso.com tartomány tagja, a rendszer létrehoz egy szabályt a corp.contoso.com DNS-utótaghoz.

    • A hálózati hely kiszolgáló teljes tartománynevére vonatkozó kivételszabály. "Ha például a hálózati helykiszolgáló URL-címe https://nls.corp.contoso.com, akkor a teljes tartománynév nls.corp.contoso.com esetén létrejön egy kivételszabály."

  • IP-HTTPS kiszolgáló

    A DirectAccess-kiszolgáló IP-HTTPS figyelőként működik, és kiszolgálói tanúsítványával hitelesíti IP-HTTPS ügyfeleket. A IP-HTTPS nevét nyilvános DNS-kiszolgálókat használó DirectAccess-ügyfeleknek kell feloldani.

  • CRL visszavonási állapot ellenőrzése

    A DirectAccess tanúsítványvisszavonás-ellenőrzést használ a DirectAccess-ügyfelek és a DirectAccess-kiszolgáló közötti IP-HTTPS kapcsolat, valamint a DirectAccess-ügyfél és a hálózati helykiszolgáló közötti HTTPS-alapú kapcsolat esetében. Mindkét esetben a DirectAccess-ügyfeleknek képesnek kell lenniük a CRL terjesztési pont helyének feloldására és elérésére.

  • ISATAP

    Az ISATAP lehetővé teszi, hogy a vállalati számítógépek IPv6-címet szerezzenek be, és az IPv6-csomagokat egy IPv4-fejlécbe ágyazza. A DirectAccess-kiszolgáló IPv6-kapcsolatot biztosít az ISATAP-gazdagépekhez egy intraneten keresztül. Nem natív IPv6 hálózati környezetben a DirectAccess-kiszolgáló automatikusan ISATAP-útválasztóként konfigurálja magát.

    Mivel az ISATAP már nem támogatott a DirectAccessben, győződjön meg arról, hogy a DNS-kiszolgálók úgy vannak konfigurálva, hogy ne válaszoljanak az ISATAP-lekérdezésekre. Alapértelmezés szerint a DNS-kiszolgáló szolgáltatás letiltja az ISATAP-név névfeloldást a DNS globális lekérdezésblokklistáján keresztül. Ne távolítsa el az ISATAP-nevet a globális lekérdezésblokkok listájából.

  • Kapcsolat-ellenőrzők

    A Távelérés létrehoz egy alapértelmezett webes mintavételt, amelyet a DirectAccess-ügyfélszámítógépek használnak a belső hálózathoz való kapcsolódás ellenőrzéséhez. Annak érdekében, hogy a mintavétel a várt módon működjön, a következő neveket manuálisan kell regisztrálni a DNS-ben:

    • directaccess-webprobehost–A Megoldás a DirectAccess-kiszolgáló belső IPv4-címére vagy egy csak IPv6-környezetben lévő IPv6-címre kell feloldani.

    • directaccess-corpconnectivityhost- A helyi gazdagép (visszacsatolás) címére kell feloldani. A következő gazdagép (A) és (AAAA) erőforrásrekordokat kell létrehozni: egy gazdagép (A) erőforrásrekordot 127.0.0.1 értékkel, és egy gazdagép (AAAA) erőforrásrekordot a NAT64 előtagból, az utolsó 32 bitként 127.0.0.1-gyel. A NAT64 előtag a get-netnattransitionconfiguration Windows PowerShell-parancs futtatásával kérhető le.

      Note

      Ez csak csak IPv4-környezetben érvényes. IPv4 és IPv6 vagy csak IPv6 környezetekben csak egy gazdagép (AAAA) erőforrásrekordot kell létrehozni a visszacsatolási IP-címmel::1.

    További kapcsolat-ellenőrzőket hozhat létre más webcímek HTTP-en keresztüli használatával vagy pingelésével. Minden kapcsolat-ellenőrzőhöz dns-bejegyzésnek kell léteznie.

1.4.1 A DNS-kiszolgáló követelményeinek tervezése

A DirectAccess telepítésekor az alábbi követelmények vonatkoznak a DNS-re.

  • DirectAccess-ügyfelek esetén olyan DNS-kiszolgálót kell használnia, amely Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008 vagy bármely más, az IPv6-ot támogató DNS-kiszolgálót futtat.

    Note

    A DirectAccess telepítésekor nem ajánlott Windows Server 2003 rendszert futtató DNS-kiszolgálókat használni. Bár a Windows Server 2003 DNS-kiszolgálók támogatják az IPv6-rekordokat, a Microsoft már nem támogatja a Windows Server 2003-at. Ezenkívül nem szabad telepítenie a DirectAccesst, ha a tartományvezérlők Windows Server 2003 rendszert futtatnak a fájlreplikációs szolgáltatással kapcsolatos probléma miatt. További információ: DirectAccess nem támogatott konfigurációk.

  • Dinamikus frissítéseket támogató DNS-kiszolgálót használjon. Olyan DNS-kiszolgálókat is használhat, amelyek nem támogatják a dinamikus frissítéseket, de manuálisan kell frissítenie a bejegyzéseket ezeken a kiszolgálókon.

  • Az internetről elérhető CRL-terjesztési pontok teljes tartománynevének feloldhatónak kell lennie internetes DNS-kiszolgálók használatával. Ha például az URL-https://crl.contoso.com/crld/corp-DC1-CA.crl a DirectAccess-kiszolgáló IP-HTTPS tanúsítványának CRL terjesztési pontjai mezőjében található, akkor internetes DNS-kiszolgálók használatával meg kell győződnie arról, hogy a teljes tartománynév crld.contoso.com feloldható.

1.4.2 Helyi névfeloldás tervezése

A helyi névfeloldás tervezésekor vegye figyelembe a következő problémákat:

NRPT

Előfordulhat, hogy további NRPT-szabályokat kell létrehoznia a következő esetekben:

  • Ha további DNS-utótagokat kell hozzáadnia az intranetes névtérhez.

  • Ha a CRL-terjesztési pontok teljes tartományneve (FQDN) az intranetes névtéren alapul, fel kell vennie a crl terjesztési pontok teljes tartománynevére vonatkozó kivételszabályokat.

  • Ha kettős DNS-környezettel rendelkezik, fel kell vennie a kivételszabályokat azoknak az erőforrásoknak a neveire, amelyekhez az interneten található DirectAccess-ügyfeleknek az intranetes verzió helyett az internetes verzióhoz kell hozzáférniük.

  • Ha az intranetes webproxy-kiszolgálókon keresztül átirányítja a forgalmat egy külső webhelyre, a külső webhely csak az intranetről érhető el, és a webproxy-kiszolgálók címeit használja a bejövő kérések engedélyezéséhez. Ebben az esetben adjon hozzá egy kivételi szabályt a külső webhely teljes tartománynevéhez, és adja meg, hogy a szabály az intranetes webproxy-kiszolgálót használja az intranetes DNS-kiszolgálók IPv6-címei helyett.

    Ha például egy test.contoso.com nevű külső webhelyet tesztel, ez a név nem oldható fel internetes DNS-kiszolgálókon keresztül, de a Contoso webproxy-kiszolgáló tudja, hogyan oldhatja fel a nevet, és hogyan irányíthatja a webhelyre irányuló kéréseket a külső webkiszolgálóra. Annak érdekében, hogy a Contoso intraneten nem található felhasználók ne férhessenek hozzá a webhelyhez, a külső webhely csak a Contoso webproxy IPv4-internetcíméről engedélyezi a kéréseket. Az intranetes felhasználók így hozzáférhetnek a webhelyhez, mert a Contoso webes proxyt használják, de a DirectAccess-felhasználók nem férhetnek hozzá, mert nem a Contoso webes proxyt használják. A Contoso webproxyt használó test.contoso.com NRPT-kivételi szabályának konfigurálásával a test.contoso.com weblapkérései az intranetes webproxy-kiszolgálóra lesznek irányítva az IPv4 interneten keresztül.

Egy címkés nevek

Az intranetes kiszolgálókhoz néha egycímkés neveket használnak, például https://paycheck. Ha egyetlen címkenevet kér, és egy DNS-utótag keresési lista van konfigurálva, a listában szereplő DNS-utótagok hozzá lesznek fűzve az egyetlen címke nevéhez. Például amikor egy felhasználó beírja a https://paycheck kifejezést a webböngészőben egy olyan számítógépen, amely a corp.contoso.com tartomány tagja, a névként létrehozott teljes tartománynév a paycheck.corp.contoso.com lesz. Alapértelmezés szerint a hozzáfűzött utótag az ügyfélszámítógép elsődleges DNS-utótagján alapul.

Note

Különálló névtér esetén (ahol egy vagy több tartományszámítógép DNS-utótagja nem egyezik meg azzal az Active Directory-tartománnyal, amelyhez a számítógépek tartoznak), győződjön meg arról, hogy a keresési lista testreszabott, hogy tartalmazza az összes szükséges utótagot. Alapértelmezés szerint a Távelérés varázsló az Active Directory DNS-nevét állítja be elsődleges DNS-utótagként az ügyfélen. Adja hozzá az ügyfelek által névfeloldáshoz használt DNS-utótagot.

Ha több tartomány és a Windows Internet Name Service (WINS) van üzembe helyezve a szervezetben, és távolról csatlakozik, az egynevek az alábbiak szerint oldhatók fel:

  • WINS előre néző zóna üzembe helyezése a DNS-ben. A computername.dns.zone1.corp.contoso.com feloldásakor a rendszer a kérelmet a csak számítógépnevet használó WINS-kiszolgálóra irányítja. Az ügyfél úgy véli, hogy egy normál DNS-állomás (A) erőforrásrekordot ad ki, de valójában egy NetBIOS-kérés. További információ: Forward Lookup Zone kezelése.

  • Adjon hozzá egy DNS-utótagot (például dns.zone1.corp.contoso.com) az alapértelmezett tartományházirend csoportházirend-objektumához.

Agyi DNS felosztása

Az osztott agyú DNS ugyanazt a DNS-tartományt használja az internet- és intranetes névfeloldáshoz.

Osztott agyú DNS-telepítések esetén fel kell sorolnia az interneten és az intraneten duplikált teljes tartományneveket, és el kell döntenie, hogy a DirectAccess-ügyfélnek mely erőforrásoknak kell elérniük az intranetet vagy az internetes verziót. Minden olyan erőforrásnak megfelelő névnél, amelynek a DirectAccess-ügyfeleknek el szeretné érni az internetverziót, fel kell vennie a megfelelő teljes tartománynevet kivételszabályként a DirectAccess-ügyfelek NRPT-jéhez.

Osztott agyú DNS-környezetben, ha azt szeretné, hogy az erőforrás mindkét verziója elérhető legyen, konfigurálja az intranetes erőforrásokat alternatív névvel, amelyek nem duplikálják az interneten használt neveket, és arra utasítja a felhasználókat, hogy az intraneten használják a másodlagos nevet. Például konfigurálja a belső névhez tartozó másodlagos nevet www.internal.contoso.comwww.contoso.com.

Nem felosztott agyú DNS-környezetben az internetes névtér eltér az intranetes névtértől. A Contoso Corporation például contoso.com használ az interneten, az intraneten pedig corp.contoso.com. Mivel az összes intranetes erőforrás a corp.contoso.com DNS-utótagot használja, a corp.contoso.com NRPT-szabálya az intranetes erőforrások dns-név lekérdezéseit az intranetes DNS-kiszolgálókra irányítja. A DNS-név lekérdezések a contoso.com utótaggal nem egyeznek meg az NRPT corp.contoso.com intranetes névtérszabályával, és az internetes DNS-kiszolgálókra lesznek elküldve. Nem felosztott agyi DNS-telepítés esetén, mivel az intranetes és internetes erőforrások teljes tartományneveinek duplikálása nem történik meg, nincs szükség további konfigurációra az NRPT-hez. A DirectAccess-ügyfelek hozzáférhetnek a szervezet internetes és intranetes erőforrásaihoz is.

DirectAccess-ügyfelek helyi névfeloldási viselkedése

Ha egy név dns-sel nem oldható fel, a név a helyi alhálózaton való feloldásához a Windows Server 2012 R2, a Windows Server 2012, a Windows Server 2008 R2, a Windows 8 és a Windows 7 DNS-ügyfélszolgáltatása használhat helyi névfeloldást a Link-Local Csoportos küldési névfeloldással (LLMNR) és a NetBIOS-val TCP/IP protokollon keresztül.

A helyi névfeloldás általában a társközi kapcsolatokhoz szükséges, ha a számítógép magánhálózatokon, például önálló alhálózati otthoni hálózatokon található. Ha a DNS-ügyfélszolgáltatás helyi névfeloldásokat végez az intranetes kiszolgálónevek esetében, és a számítógép egy megosztott alhálózathoz csatlakozik az interneten, a rosszindulatú felhasználók tcp/IP-üzeneteken keresztül rögzíthetik az LLMNR-t és a NetBIOS-t az intranetes kiszolgálónevek meghatározásához. Az Infrastruktúra-kiszolgáló telepítővarázslójának DNS-lapján konfigurálja a helyi névfeloldási viselkedést az intranetes DNS-kiszolgálóktól kapott válaszok típusai alapján. A következő lehetőségek érhetők el:

  • Használjon helyi névfeloldást, ha a név nem létezik a DNS-ben. Ez a beállítás a legbiztonságosabb, mert a DirectAccess-ügyfél csak az intranetes DNS-kiszolgálók által nem feloldható kiszolgálónevek esetében hajtja végre a helyi névfeloldásokat. Ha az intranetes DNS-kiszolgálók elérhetők, a rendszer feloldja az intranetes kiszolgálók nevét. Ha az intranetes DNS-kiszolgálók nem érhetők el, vagy ha más típusú DNS-hibák lépnek fel, az intranetes kiszolgáló nevei nem szivárognak ki az alhálózatba a helyi névfeloldás révén.

  • Helyi névfeloldást kell használni, ha a név nem létezik a DNS-ben, vagy ha a DNS-kiszolgálók nem érhetők el, amikor az ügyfélszámítógép magánhálózaton van (ajánlott). Ez a beállítás azért ajánlott, mert csak akkor engedélyezi a helyi névfeloldást egy magánhálózaton, ha az intranetes DNS-kiszolgálók nem érhetők el.

  • A helyi névfeloldás használata bármilyen (legkevésbé biztonságos) DNS-feloldási hiba esetén. Ez a legkevésbé biztonságos lehetőség, mert az intranetes hálózati kiszolgálók neve a helyi névfeloldás révén kiszivároghat a helyi alhálózatba.

1.5 A hálózati hely kiszolgálójának megtervezése

A hálózatihely-kiszolgáló egy webhely, amely annak észlelésére szolgál, hogy a DirectAccess-ügyfelek a vállalati hálózaton találhatók-e. A vállalati hálózaton lévő ügyfelek nem a DirectAccess használatával érik el a belső erőforrásokat, hanem közvetlenül csatlakoznak.

A hálózatihely-kiszolgáló webhelye üzemeltethető a DirectAccess-kiszolgálón vagy a szervezet egy másik kiszolgálóján. Ha a hálózati helykiszolgálót a DirectAccess-kiszolgálón üzemelteti, a rendszer automatikusan létrehozza a webhelyet a távelérési kiszolgálói szerepkör telepítésekor. Ha a hálózati helykiszolgálót a szervezet egy másik, Windows operációs rendszert futtató kiszolgálóján üzemelteti, győződjön meg arról, hogy az Internet Information Services (IIS) telepítve van a kiszolgálón, és hogy létrejön a webhely. A DirectAccess nem konfigurálja a távoli hálózati helykiszolgáló beállításait.

Győződjön meg arról, hogy a hálózati hely kiszolgálójának webhelye megfelel a következő követelményeknek:

  • Ez egy HTTPS-kiszolgálótanúsítvánnyal rendelkező webhely.

  • A DirectAccess ügyfélszámítógépeknek meg kell bízniuk abban a hitelesítésszolgáltatóban, amely a kiszolgálótanúsítványt a hálózati helyszín-kiszolgáló weboldalához adta ki.

  • A belső hálózaton lévő DirectAccess-ügyfélszámítógépek képeseknek kell lenniük a hálózati helykiszolgáló helyének nevének feloldására.

  • A hálózati hely kiszolgálóhelyének magas rendelkezésre állásúnak kell lennie a belső hálózaton lévő számítógépek számára.

  • A hálózati hely kiszolgálójának nem lehet elérhető a DirectAccess-ügyfélszámítógépek számára az interneten.

  • A kiszolgálótanúsítványt crL-sel kell ellenőrizni.

1.5.1 A hálózatihely-kiszolgáló tanúsítványainak megtervezése

A hálózati helykiszolgálóhoz használandó webhelytanúsítvány beszerzésekor vegye figyelembe a következőket:

  1. A Tárgy mezőben adja meg a hálózatihely-kiszolgáló intranetes adapterének IP-címét vagy a hálózati hely URL-címének teljes tartománynevét.

  2. A Bővített kulcshasználat mezőben használja a Kiszolgálóhitelesítési OID-t.

  3. A CRL terjesztési pontok mezőben használjon egy CRL-terjesztési pontot, amelyet az intranethez csatlakozó DirectAccess-ügyfelek érhetnek el. Ez a CRL-terjesztési pont nem lehet elérhető a belső hálózaton kívülről.

1.5.2 A hálózati helykiszolgáló DNS-ének megtervezése

A DirectAccess-ügyfelek megpróbálják elérni a hálózati helykiszolgálót annak megállapításához, hogy a belső hálózaton vannak-e. A belső hálózaton lévő ügyfeleknek képesnek kell lenniük feloldani a hálózati helykiszolgáló nevét, de meg kell akadályozni őket a név feloldásában, amikor az interneten találhatók. Ennek biztosítása érdekében alapértelmezés szerint a hálózatihely-kiszolgáló teljes tartományneve kivételszabályként lesz hozzáadva az NRPT-hez.

1.6 Felügyeleti kiszolgálók tervezése

A DirectAccess-ügyfelek olyan felügyeleti kiszolgálókkal kezdeményeznek kommunikációt, amelyek olyan szolgáltatásokat nyújtanak, mint a Windows Update és a víruskereső frissítések. A DirectAccess-ügyfelek a Kerberos protokoll használatával is kapcsolatba lépnek a tartományvezérlőkkel a hitelesítéshez, mielőtt hozzáférnek a belső hálózathoz. A DirectAccess-ügyfelek távoli kezelése során a felügyeleti kiszolgálók kommunikálnak az ügyfélszámítógépekkel olyan felügyeleti funkciók végrehajtásához, mint a szoftver- vagy hardverleltár-felmérések. A távelérés képes automatikusan felderíteni néhány felügyeleti kiszolgálót, például:

  • A tartományvezérlők automatikus felderítése a DirectAccess-kiszolgálóval és az ügyfélszámítógépekkel azonos erdőben lévő összes tartományban történik.

  • Microsoft Endpoint Configuration Manager-kiszolgálók – A Configuration Manager-kiszolgálók automatikus felderítése a DirectAccess-kiszolgálóval és az ügyfélszámítógépekkel azonos erdőben lévő összes tartomány esetében történik.

A rendszer automatikusan észleli a tartományvezérlőket és a Configuration Manager-kiszolgálókat a DirectAccess első konfigurálásakor. Az észlelt tartományvezérlők nem jelennek meg a konzolon, de a beállítások a Windows PowerShell parancsmag Get-DAMgmtServer -Type Az összesparancsmaggal kérhetők le. Ha a tartományvezérlő vagy a Configuration Manager-kiszolgálók módosulnak, a távelérés-kezelési konzol Frissítéskezelési kiszolgálók gombra kattintva frissíti a felügyeleti kiszolgáló listáját.

felügyeleti kiszolgáló követelményei

  • A felügyeleti kiszolgálóknak elérhetőnek kell lenniük az első (infrastruktúra-) alagúton keresztül. A távelérés konfigurálásakor a kiszolgálók hozzáadása a felügyeleti kiszolgálók listájához automatikusan elérhetővé teszi őket ezen a tunnel-en keresztül.

  • A DirectAccess-ügyfelekkel kapcsolatot kezdeményező felügyeleti kiszolgálóknak teljes mértékben támogatniuk kell az IPv6-ot natív IPv6-cím vagy az ISATAP által hozzárendelt cím használatával.

Active Directory tartományi szolgáltatások tervezése

Ez a szakasz bemutatja, hogyan használja a DirectAccess az Active Directory Domain Servicest (AD DS), és az alábbi alszakaszokat tartalmazza:

A DirectAccess AD DS- és Active Directory-csoportházirend-objektumokat (GPO-kat) használ az alábbiak szerint:

  • Authentication

    Az AD DS a hitelesítéshez használatos. Az infrastruktúra-alagút NTLMv2-hitelesítést használ a DirectAccess-kiszolgálóhoz csatlakozó számítógépfiókhoz, és a fióknak egy Active Directory-tartományban kell szerepelnie. Az intranetes alagút Kerberos-hitelesítést használ a felhasználó számára a második alagút létrehozásához.

  • csoportházirend-objektumok

    A DirectAccess összegyűjti és csoportházirend-objektumokban tárolja a konfigurációs beállításokat, amelyeket a DirectAccess kiszolgálókra, az ügyfelekre és a belső alkalmazáskiszolgálókra alkalmaznak.

  • Biztonsági csoportok

    A DirectAccess biztonsági csoportokkal gyűjti össze és azonosítja a DirectAccess-ügyfélszámítógépeket. A csoportházirend-objektumok a szükséges biztonsági csoportra lesznek alkalmazva.

  • kiterjesztett IPsec-szabályzatok

    A DirectAccess IPsec-hitelesítést és titkosítást használhat az ügyfelek és a DirectAccess-kiszolgáló között. Az IPsec-hitelesítést és -titkosítást kiterjesztheti az ügyfélről a megadott belső alkalmazáskiszolgálókra. Ehhez adja hozzá a szükséges alkalmazáskiszolgálót egy biztonsági csoporthoz.

AD DS-követelmények

Ha az AD DS-t DirectAccess-telepítésre tervezi, vegye figyelembe a következő követelményeket:

  • Legalább egy tartományvezérlőt telepíteni kell a Windows Server 2016, a Windows Server 2012 R2, a Windows Server 2012, a Windows Server 2008 R2 vagy a Windows Server 2008 operációs rendszerrel.

    Ha a tartományvezérlő szegélyhálózaton található (és ezért elérhető a DirectAccess-kiszolgáló internetre néző hálózati adapteréről), meg kell akadályoznia, hogy a DirectAccess-kiszolgáló elérhesse azt úgy, hogy csomagszűrőket ad hozzá a tartományvezérlőhöz, hogy megakadályozza az internetadapter IP-címéhez való kapcsolódást.

  • A DirectAccess-kiszolgálónak tartománytagnak kell lennie.

  • A DirectAccess-ügyfeleknek tartományi tagoknak kell lenniük. Az ügyfelek a következőhöz tartozhatnak:

    • Azon erdő bármely tartománya, ahol a DirectAccess-kiszolgáló található.

    • Minden olyan tartomány, amely kétirányú bizalommal rendelkezik a DirectAccess-kiszolgáló tartományával.

    • Az erdő bármelyik tartománya, amely kétirányú bizalmi kapcsolattal rendelkezik azzal az erdővel, amelyhez a DirectAccess-tartomány tartozik.

Note

  • A DirectAccess-kiszolgáló nem lehet tartományvezérlő.
  • A DirectAccesshez használt AD DS-tartományvezérlő nem lehet elérhető a DirectAccess-kiszolgáló külső internetes adapteréről (vagyis az adapter nem lehet a Windows tűzfal tartományprofiljában).

1.7.1 Ügyfélhitelesítés tervezése

A DirectAccess lehetővé teszi, hogy válasszon az IPsec-alapú számítógép-hitelesítés tanúsítványainak használata vagy egy beépített Kerberos-proxy használata között, amely felhasználónevek és jelszavak használatával hitelesít.

Az Ad DS hitelesítő adatainak hitelesítéshez való használatakor a DirectAccess egy biztonsági alagutat használ, amely a Számítógép Kerberost használja az első hitelesítéshez, a második hitelesítéshez pedig a Felhasználói Kerberost. Ha ezt a módot használja a hitelesítéshez, a DirectAccess egyetlen biztonsági alagutat használ, amely hozzáférést biztosít a DNS-kiszolgálóhoz, a tartományvezérlőhöz és a belső hálózat más kiszolgálóihoz.

Ha kéttényezős hitelesítést vagy hálózati hozzáférés-védelmet használ, a DirectAccess két biztonsági alagutat használ. A Távelérés beállítása varázsló speciális biztonsági kapcsolatbiztonsági szabályokkal konfigurálja a Windows tűzfalat, amely a következő típusú hitelesítő adatok használatát határozza meg az alagutak IPsec biztonsági társításainak a DirectAccess-kiszolgálóval való egyeztetése során:

  • Az infrastruktúra-alagút a számítógép Kerberos-hitelesítő adatait használja az első hitelesítéshez, a másodikhoz pedig a Felhasználói Kerberost.

  • Az intranetes alagút a számítógép tanúsítványának hitelesítő adatait használja az első hitelesítéshez, a másodikhoz pedig a Kerberos felhasználót.

Ha a DirectAccess úgy dönt, hogy engedélyezi a Hozzáférést a Windows 7-et futtató vagy többhelyes üzemelő ügyfelek számára, két biztonsági alagutat használ. A Távelérés beállítása varázsló speciális biztonsági kapcsolatbiztonsági szabályokkal konfigurálja a Windows tűzfalat, amely a következő típusú hitelesítő adatok használatát határozza meg az alagutak IPsec biztonsági társításainak a DirectAccess-kiszolgálóval való egyeztetése során:

  • Az infrastruktúra-alagút az első hitelesítéshez a számítógép tanúsítványának hitelesítő adatait, a második hitelesítéshez pedig az NTLMv2-t használja. Az NTLMv2 hitelesítő adatai kikényszerítik a Hitelesített Internet Protocol (AuthIP) használatát, és hozzáférést biztosítanak egy DNS-kiszolgálóhoz és tartományvezérlőhöz, mielőtt a DirectAccess-ügyfél kerberos hitelesítő adatokat használhat az intranetes alagúthoz.

  • Az intranetes alagút a számítógép tanúsítványának hitelesítő adatait használja az első hitelesítéshez, a másodikhoz pedig a Kerberos felhasználót.

1.7.2 Több tartomány tervezése

A felügyeleti kiszolgálók listájának tartalmaznia kell a DirectAccess ügyfélszámítógépeket tartalmazó biztonsági csoportokat tartalmazó összes tartomány tartományvezérlőit. Minden olyan tartományt tartalmaznia kell, amely felhasználói fiókokat tartalmaz, amelyek DirectAccess-ügyfélként konfigurált számítógépeket használhatnak. Ez biztosítja, hogy azok a felhasználók, akik nem ugyanabban a tartományban találhatók, mint a használt ügyfélszámítógép, hitelesítve legyenek egy tartományvezérlővel a felhasználói tartományban. Ez automatikusan megtörténik, ha a tartományok ugyanabban az erdőben találhatók.

Note

Ha vannak olyan számítógépek a biztonsági csoportokban, amelyeket különböző erdőkben lévő ügyfélszámítógépekhez vagy alkalmazáskiszolgálókhoz használnak, a rendszer nem észleli automatikusan az erdők tartományvezérlőit. A tartományvezérlők észleléséhez futtathatja a feladat Frissítéskezelési kiszolgálók a távelérés-kezelési konzolon.

Ahol lehetséges, a távelérés beállítása során a Névfeloldási Házirendtáblához (NRPT) gyakori tartománynév-utótagokat kell hozzáadni. Ha például két tartománya van, domain1.corp.contoso.com és domain2.corp.contoso.com, ahelyett, hogy két bejegyzést ad hozzá az NRPT-hez, felvehet egy gyakori DNS-utótag-bejegyzést, amelyben a tartománynév utótagja corp.contoso.com. Ez automatikusan történik az azonos gyökértartományban lévő tartományok esetében, de manuálisan kell hozzáadni azokat a tartományokat, amelyek nem ugyanabban a gyökérben találhatók.

Ha a Windows Internet Name Service (WINS) több tartományi környezetben van üzembe helyezve, egy WINS-továbbítási keresési zónát kell üzembe helyeznie a DNS-ben. További információ: A helyi névfeloldás 1.4.2-es tervének szakaszában egycímke neve jelenik meg a dokumentum korábbi részében.

1.8 Csoportházirend-objektumok tervezése

Ez a szakasz ismerteti a csoportházirend-objektumok (CSOPORTHÁZIREND-k) szerepét a távelérési infrastruktúrában, és az alábbi alszakaszokat tartalmazza:

Amikor a Távoli elérés konfigurálását végrehajtja, a DirectAccess-beállításokat a rendszer csoportházirend-objektumokba gyűjti. A következő GPO-k DirectAccess-beállításokkal vannak feltöltve, és az alábbi módon oszlanak el:

  • DirectAccess-ügyfél csoportházirend

    Ez a csoportházirend-objektum ügyfélbeállításokat tartalmaz, beleértve az IPv6-áttűnési technológiai beállításokat, az NRPT-bejegyzéseket és az Advanced Security kapcsolatbiztonsági szabályokkal rendelkező Windows tűzfalat. A csoportházirend-objektum az ügyfélszámítógépekhez megadott biztonsági csoportokra lesz alkalmazva.

  • DirectAccess-kiszolgáló GPO

    Ez a csoportházirend-objektum tartalmazza azokat a DirectAccess-konfigurációs beállításokat, amelyek a telepítésben DirectAccess-kiszolgálóként konfigurált kiszolgálókra vonatkoznak. Emellett speciális biztonsági kapcsolatbiztonsági szabályokkal rendelkező Windows tűzfalat is tartalmaz.

  • alkalmazáskiszolgálók Csoportházirend (GPO)

    Ez a csoportházirend-objektum a kiválasztott alkalmazáskiszolgálók beállításait tartalmazza, amelyekhez opcionálisan kiterjeszthető a hitelesítés és a titkosítás a DirectAccess kliensekkel. Ha a hitelesítés és a titkosítás nincs kibővítve, ezt a csoportházirendet nem alkalmazzák.

A csoportházirend-objektumok kétféleképpen konfigurálhatók:

  • Automatikusan megadhatja, hogy azok automatikusan létre legyenek hozva. Minden Csoportházirend-objektumhoz (GPO) alapértelmezett név van megadva.

  • Manuálisan használhatja az Active Directory-rendszergazda által előre definiált csoportházirend-objektumokat.

Note

Miután a DirectAccess adott csoportházirend-objektumok használatára van konfigurálva, nem konfigurálható különböző csoportházirend-objektumok használatára.

Akár automatikusan, akár manuálisan konfigurált csoportházirend-objektumokat használ, hozzá kell adnia egy irányelvet a lassú kapcsolatészleléshez, amennyiben az ügyfelek 3G-hálózatokat fognak használni. A szabályzat elérési útja: A csoportházirend lassú kapcsolatészlelési konfigurálása a következő: Számítógép konfigurációja/Házirendek/Felügyeleti sablonok/Rendszer/Csoportházirend.

Caution

Az alábbi eljárással biztonsági másolatot készíthet az összes távelérési csoportházirend-objektumról a DirectAccess-parancsmagok futtatása előtt: Távelérés konfigurációjának biztonsági mentése és visszaállítása.

Ha nem léteznek a megfelelő engedélyek a csoportházirend-objektumok összekapcsolására (amelyek a következő szakaszokban szerepelnek), figyelmeztetést adunk. A távelérési művelet folytatódik, de a csatolás nem történik meg. Ha ez a figyelmeztetés megjelenik, a hivatkozások nem jönnek létre automatikusan, még akkor sem, ha az engedélyeket később hozzáadják. Ehelyett a rendszergazdának manuálisan kell létrehoznia a hivatkozásokat.

1.8.1 Automatikusan létrehozott csoportházirend-objektumok konfigurálása

Az automatikusan létrehozott csoportházirend-objektumok használatakor vegye figyelembe az alábbiakat.

Az automatikusan létrehozott csoportházirend-objektumok a hely és a hivatkozás célparaméterének megfelelően lesznek alkalmazva, az alábbiak szerint:

  • A DirectAccess-kiszolgáló csoportházirend-objektuma esetében a helyparaméter és a hivatkozásparaméter a DirectAccess-kiszolgálót tartalmazó tartományra mutat.

  • Az ügyfél- és alkalmazáskiszolgáló csoportházirend-objektumainak létrehozásakor a hely egyetlen tartományra van állítva, amelyben a csoportházirend-objektum létrejön. A GPO (Csoportházirend-objektum) neve minden tartományban megkeresésre kerül, és ha létezik, DirectAccess-beállításokkal tölthető fel. A hivatkozási cél annak a tartománynak a gyökerére van állítva, amelyben a csoportházirend-objektum létre lett hozva. A rendszer minden olyan tartományhoz létrehoz egy csoportházirend-objektumot, amely ügyfélszámítógépeket vagy alkalmazáskiszolgálót tartalmaz, és a csoportházirend-objektum a megfelelő tartomány gyökeréhez van csatolva.

Ha automatikusan létrehozott csoportházirend-objektumokat használ a DirectAccess-beállítások alkalmazásához, a távelérési rendszergazdának a következő engedélyekre van szüksége:

  • A GPO engedélyeket hoz létre minden tartomány számára

  • Az összes kijelölt ügyféltartomány-gyökér hivatkozási engedélyei

  • A kiszolgálói csoportházirend-objektumok tartománygyökereinek hivatkozási engedélyei

Emellett a következő engedélyekre van szükség:

  • A csoportházirend-objektumokhoz biztonsági engedélyek létrehozása, szerkesztése, törlése és módosítása szükséges.

  • Javasoljuk, hogy a távelérési rendszergazda minden szükséges tartományhoz rendelkezik csoportházirend-objektum olvasási engedélyével. Ez lehetővé teszi a távelérés számára annak ellenőrzését, hogy az ismétlődő névvel rendelkező csoportházirend-objektumok nem léteznek-e a csoportházirend-objektumok létrehozásakor.

1.8.2 Manuálisan létrehozott csoportházirend-objektumok konfigurálása

A manuálisan létrehozott csoportházirend-objektumok (GPO-k) használata során figyelembe kell venni a következőket:

  • A csoportházirend-objektumoknak létezniük kell a távelérés telepítővarázslójának futtatása előtt.

  • A DirectAccess-beállítások alkalmazásához a távelérési rendszergazdának teljes csoportházirend-hozzáférési engedélyre (Szerkesztés, Törlés, Biztonsági engedélyek módosítása) van szüksége a manuálisan létrehozott csoportházirend-objektumokra.

  • A teljes tartományban keresés történik az csoportházirend-objektumra mutató hivatkozásra. Ha a csoportházirend-objektum nincs a tartományhoz csatolva, a rendszer automatikusan létrehoz egy hivatkozást a tartománygyökérben. Ha a hivatkozás létrehozásához szükséges engedélyek nem érhetők el, a rendszer figyelmeztetést ad ki.

1.8.3 Csoportházirend-objektumok kezelése több tartományvezérlős környezetben

Az egyes GPO-kat egy adott tartományvezérlő kezeli, az alábbiak szerint:

  • A kiszolgáló csoportházirend-objektumát a kiszolgálóhoz társított Active Directory-hely egyik tartományvezérlője kezeli. Ha a hely tartományvezérlői írásvédettek, a kiszolgáló csoportházirend-objektumát a DirectAccess-kiszolgálóhoz legközelebbi írásvédett tartományvezérlő kezeli.

  • Az ügyfél- és alkalmazáskiszolgáló csoportházirend-objektumokat az elsődleges tartományvezérlőként (PDC) futó tartományvezérlő felügyeli.

Ha manuálisan szeretné módosítani a GPO beállításait, vegye figyelembe a következőket:

  • A kiszolgáló GPO-jának esetében a DirectAccess-kiszolgálón emelt jogú parancssorból futtassa a következő parancsot, hogy azonosítsa, melyik tartományvezérlő van társítva a DirectAccess-kiszolgálóhoz: nltest /dsgetdc: /writable.

  • Alapértelmezés szerint, ha a hálózati Windows PowerShell-parancsmagokkal vagy a csoportházirend-kezelési konzolon módosítja a módosításokat, a rendszer a PDC-ként működő tartományvezérlőt használja.

Ezenkívül ha olyan tartományvezérlő beállításait módosítja, amely nem a DirectAccess-kiszolgálóhoz (a kiszolgáló csoportházirend-objektumához) vagy a PDC-hez (ügyfél- és alkalmazáskiszolgálói csoportházirend-objektumokhoz) társított tartományvezérlő, vegye figyelembe a következőket:

  • A beállítások módosítása előtt győződjön meg arról, hogy a tartományvezérlőt egy up-todátumú csoportházirend-objektummal replikálja, és biztonsági másolatot készít a csoportházirend-objektum beállításairól. További információ: Távelérési konfiguráció biztonsági mentése és visszaállítása. Ha a csoportházirend-objektum nem frissül, a replikáció alatt egyesítési ütközések léphetnek fel, ami sérült távelérési konfigurációt eredményezhet.

  • A beállítások módosítása után meg kell várnia, amíg a módosítások replikálódnak a csoportházirend-objektumokhoz társított tartományvezérlőkre. Ne végezzen további módosításokat a távelérés-kezelési konzol vagy a Távelérés PowerShell-parancsmagok használatával, amíg a replikáció be nem fejeződik. Ha a replikáció befejezése előtt két tartományvezérlőn szerkeszt egy csoportházirend-objektumot, egyesítési ütközések léphetnek fel, ami sérült távelérési konfigurációt eredményezhet.

Másik lehetőségként módosíthatja az alapértelmezett beállítást a csoportházirend-kezelési konzol Tartományvezérlő módosítása párbeszédpanelen, vagy a Windows PowerShell-parancsmag Open-NetGPOhasználatával, hogy a módosítások a megadott tartományvezérlőt használják.

  • Ehhez a csoportházirend-kezelési konzolon kattintson a jobb gombbal a tartományra vagy a helyek tárolójára, majd kattintson a Tartományvezérlő módosításaparancsra.

  • Ehhez a Windows PowerShellben adja meg az Open-NetGPO parancsmag DomainController paraméterét. Ha például egy europe-dc.corp.contoso.com nevű tartományvezérlő használatával szeretné engedélyezni a windowsos tűzfal privát és nyilvános profiljait egy 1\DA_Server_GPO _Europe nevű csoportházirend-objektumon, írja be a következőket:

    $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 Korlátozott engedélyekkel rendelkező távelérési GPO-k kezelése

A távelérési telepítés kezeléséhez a távelérési adminisztrátor teljes csoportházirend-engedélyeket (olvasási, szerkesztési, törlési és módosítási biztonsági engedélyeket) igényel az üzembe helyezés során használt csoportházirend-objektumokon. Ennek az az oka, hogy a távelérés-kezelési konzol és a távelérési PowerShell-modulok beolvasják a konfigurációt, és beírják a távelérési csoportházirend-objektumokba (vagyis ügyfél-, kiszolgáló- és alkalmazáskiszolgálói csoportházirend-objektumokba).

Számos szervezetben a csoportházirend-objektum műveleteiért felelős tartományi rendszergazda nem ugyanaz a személy, mint a távelérés konfigurációjáért felelős rendszergazda. Ezek a szervezetek olyan szabályzatokkal rendelkezhetnek, amelyek korlátozzák a távfelügyeleti rendszergazdát abban, hogy teljes körű hozzáférést kapjon a tartomány csoportházirend-azonosítóihoz. Előfordulhat, hogy a tartományi rendszergazdának át kell tekintenie a szabályzatkonfigurációt, mielőtt a tartomány bármely számítógépére alkalmazva lenne.

Ezeknek a követelményeknek való megfelelés érdekében a domainek rendszergazdájának minden csoportházirend-objektumból két példányt kell létrehoznia: teszt és éles környezet. A távelérési adminisztrátor teljes körű engedélyeket kap a tesztelési csoportházirend-objektumokhoz. A távelérési rendszergazda a távelérés-kezelési konzolon és a Windows PowerShell-parancsmagokban adja meg az átmeneti csoportházirend-objektumokat a távelérés központi telepítéséhez használt csoportházirend-objektumokként. Ez lehetővé teszi a távelérési rendszergazda számára a távelérési konfiguráció szükség szerinti és szükség szerinti olvasását és módosítását.

A tartományi rendszergazdának meg kell győződnie arról, hogy az átmeneti csoportházirend-objektumok nincsenek társítva a tartomány egyetlen felügyeleti hatóköréhez sem, és hogy a távelérési rendszergazda nem rendelkezik csoportházirend-objektum hivatkozási engedélyekkel a tartományban. Ez biztosítja, hogy a távelérési rendszergazda által az átmeneti csoportházirend-objektumokon végzett módosítások ne gyakoroljanak semmilyen hatást a tartomány számítógépeire.

A tartományi rendszergazda összekapcsolja a produkciós GPO-kat a szükséges menedzsment hatókörrel, és alkalmazza a biztonsági szűrést. Ez biztosítja, hogy a csoportházirend-objektumok (GPO-k) módosításai alkalmazva legyenek a tartomány számítógépein (ügyfélszámítógépeken, DirectAccess-kiszolgálókon és alkalmazáskiszolgálókon). A távelérési rendszergazda nem rendelkezik engedélyekkel az éles csoportházirend-objektumokhoz.

Az átmeneti csoportházirend-objektumok módosításakor a tartományi rendszergazda áttekintheti a csoportházirend-objektumok házirendkonfigurációját, hogy meggyőződjön arról, hogy az megfelel a szervezet biztonsági követelményeinek. A tartományi rendszergazda ezután a biztonsági mentési funkcióval exportálja a beállításokat a tesztelési csoportházirend-objektumokból, majd importálja a beállításokat a megfelelő éles csoportházirend-objektumokba, amelyeket a számítógépek a tartományban fognak alkalmazni.

Az alábbi ábrán ez a konfiguráció látható.

Távoli hozzáférés csoportházirend-objektumok kezelése

1.8.5 Törölt csoportházirend-objektum helyreállítása

Ha egy ügyfél, DirectAccess-kiszolgáló vagy alkalmazáskiszolgáló csoportházirend-objektuma véletlenül törölve lett, és nem áll rendelkezésre biztonsági másolat, el kell távolítania a konfigurációs beállításokat, és újra kell konfigurálnia őket. Ha rendelkezésre áll biztonsági másolat, visszaállíthatja a csoportházirend-objektumot a biztonsági másolatból.

A távelérés-kezelési konzol a következő hibaüzenetet jeleníti meg: csoportházirend-objektum (csoportházirend-objektum neve) nem található. A konfigurációs beállítások eltávolításához hajtsa végre a következő lépéseket:

  1. Futtassa az Uninstall-remoteaccess Windows PowerShell-parancsmagot.

  2. Nyissa meg a távelérés-kezelési konzolt.

  3. Hibaüzenet jelenik meg arról, hogy a csoportházirend-objektum (GPO) nem található. Kattintson a Konfigurációs beállítások eltávolításaelemre. A befejezés után a kiszolgáló nem konfigurált állapotba kerül.

Következő lépések

  • Last updated on