Table of contents
TOC
Comprimi il sommario
Espandi il sommario

Passaggio 1 pianificare l'infrastruttura di accesso remoto

James McIllece|Ultimo aggiornamento: 10/03/2017
|
1 Collaboratore

Si applica a: Windows Server 2016

Nota: Windows Server 2016 combina DirectAccess e Routing e accesso remoto (RRAS) in un unico ruolo Accesso remoto.

In questo argomento vengono descritti i passaggi per la pianificazione di un'infrastruttura che è possibile utilizzare per configurare un singolo server di accesso remoto per la gestione remota dei client DirectAccess. Nella tabella seguente vengono elencati i passaggi, ma queste attività di pianificazione non è necessario essere eseguita in un ordine specifico.

AttivitàDescrizione
Pianificare le impostazioni di server e di topologia di reteDecidere dove collocare il server di accesso remoto (alla periferia o dietro un dispositivo Network Address Translation (NAT) o un firewall) e pianificare gli indirizzi IP e routing.
Pianificare i requisiti firewallPiano per consentire l'accesso remoto attraverso i firewall perimetrali.
Pianificare i requisiti dei certificatiDecidere se si utilizza il protocollo Kerberos o i certificati per l'autenticazione client e pianificare i certificati del sito Web.

IP-HTTPS è un protocollo di transizione utilizzata dai client DirectAccess per il tunneling del traffico IPv6 in reti IPv4. Decidere se eseguire l'autenticazione IP-HTTPS per il server con un certificato emesso da un'autorità di certificazione (CA) oppure utilizzando un certificato autofirmato emesso automaticamente dal server di accesso remoto.
Pianificare i requisiti DNSPianificare le impostazioni di sistema DNS (Domain Name) per il server Accesso remoto, i server dell'infrastruttura, opzioni di risoluzione dei nomi locali e la connettività dei client.
Pianificare la configurazione di server di percorso di reteDecidere dove collocare il sito Web server percorsi di rete all'interno dell'organizzazione (nel server di accesso remoto o un server alternativo) e pianificare i requisiti del certificato se il server dei percorsi di rete utilizzeranno un percorso sul server di accesso remoto. Nota: il server dei percorsi di rete viene utilizzato dai client DirectAccess per determinare se si trovano nella rete interna.
Pianificare le configurazioni dei server di gestionePiano per i server di gestione (ad esempio i server di aggiornamento) che vengono utilizzati durante la gestione del client remoto. Nota: gli amministratori possono gestire in remoto i computer client DirectAccess che si trovano all'esterno della rete aziendale tramite Internet.
Pianificare i requisiti di Active DirectoryPianificare i controller di dominio, i requisiti di Active Directory, l'autenticazione client e più struttura del dominio.
Pianificare la creazione di oggetti Criteri di gruppoDecidere quali oggetti Criteri di gruppo sono necessarie nell'organizzazione e come creare e modificare oggetti Criteri di gruppo.

Pianificare la topologia di rete e impostazioni

Quando si pianifica la rete, è necessario prendere in considerazione la topologia delle schede di rete, le impostazioni per gli indirizzi IP e i requisiti per ISATAP.

Pianificare le schede di rete e gli indirizzi IP

  1. Identificare la topologia delle schede di rete che si desidera utilizzare. Accesso remoto può essere impostato con una delle seguenti topologie:

    • Con due schede di rete: server di accesso remoto viene installato nella periferia con una scheda di rete connessa a Internet e l'altra alla rete interna.

    • Con due schede di rete: server di accesso remoto viene installato dietro un dispositivo NAT, firewall o router, con una scheda di rete connessa a una rete perimetrale e l'altra alla rete interna.

    • Con una scheda di rete: il server di accesso remoto viene installato dietro un dispositivo NAT e l'unica scheda di rete è connesso alla rete interna.

  2. Identificare i requisiti di indirizzi IP:

    DirectAccess Usa IPv6 con IPsec per creare una connessione sicura tra i computer client DirectAccess e la rete aziendale interna. Tuttavia, DirectAccess non richiede necessariamente la connettività a Internet IPv6 o il supporto IPv6 nativo nelle reti interne. Al contrario, configura e usa automaticamente tecnologie di transizione IPv6 per eseguire il tunneling del traffico IPv6 attraverso la rete Internet IPv4 (6to4, Teredo o IP-HTTPS) e nella rete intranet solo IPv4 (NAT64 o ISATAP). Per una panoramica di queste tecnologie di transizione, vedere le risorse seguenti:

  3. Configurare le schede necessari e gli indirizzi in base alla tabella seguente. Per le distribuzioni che sono protetti da un dispositivo NAT con una sola scheda di rete, configurare gli indirizzi IP utilizzando solo la scheda di rete interna colonna.

    Scheda di rete esternaScheda di rete interna1, precedenteRequisiti di routing
    Internet IPv4 e intranet IPv4Configurare quanto segue:

    -Statico due indirizzi IPv4 pubblici consecutivi con le subnet mask appropriate (richiesto solo per Teredo).
    -Un indirizzo IPv4 per il firewall Internet o del router del provider di servizi Internet locale di gateway predefinito. Nota: il server di accesso remoto richiede due indirizzi IPv4 pubblici consecutivi in modo che possa fungere da server Teredo e i client Teredo basati su Windows possono utilizzare il server di accesso remoto per rilevare il tipo di dispositivo NAT.
    Configurare quanto segue:

    -Un indirizzo intranet IPv4 con subnet mask appropriata.
    -Un suffisso DNS specifico della connessione dello spazio dei nomi intranet. Un server DNS deve inoltre essere configurato nell'interfaccia interna. Attenzione: non si configura un gateway predefinito in alcuna interfaccia intranet.
    Per configurare il server di accesso remoto per raggiungere tutte le subnet nella rete IPv4 interna, eseguire le operazioni seguenti:

    : Elenca gli spazi degli indirizzi IPv4 per tutti i percorsi nella intranet.
    -Utilizzare il route add -po netsh interface ipv4 add routespazi degli indirizzi di comandi per aggiungere IPv4 come route statiche nella tabella di routing IPv4 del server di accesso remoto.
    Internet IPv6 e intranet IPv6Configurare quanto segue:

    -Utilizzare la configurazione degli indirizzi autoconfigurati fornita dall'ISP.
    -Utilizzare il route printcomando per verificare l'esistenza di una route IPv6 predefinita che punta al router ISP nella tabella di routing IPv6.
    -Determinare se i router ISP e intranet stanno usando preferenze del router predefinite come descritto in RFC 4191 e in tal caso, utilizzare una preferenza predefinita superiore rispetto ai router intranet locali. Se entrambe queste condizioni sono vere, è richiesta alcuna altra configurazione per la route predefinita. La preferenza superiore per il router ISP garantisce che la route IPv6 predefinita attiva dei punti di server di accesso remoto alla rete Internet IPv6.

    Poiché il server di accesso remoto è un router IPv6, se si dispone di un'infrastruttura IPv6 nativa, l'interfaccia Internet può raggiungere i controller di dominio sulla intranet. In questo caso, aggiungere filtri pacchetti al controller di dominio nella rete perimetrale per impedire la connettività all'indirizzo IPv6 dell'interfaccia Internet del server di accesso remoto.
    Configurare quanto segue:

    Se non si utilizza livelli di preferenza predefiniti, configurare le interfacce intranet usando il netsh interface ipv6 set InterfaceIndex ignoredefaultroutes=enabledcomando. Questo comando verifica che route predefinite aggiuntive che puntano ai router della intranet non verranno aggiunte alla tabella di routing IPv6. È possibile ottenere l'elemento InterfaceIndex delle interfacce intranet dalla visualizzazione del netsh interface show interfacecomando.
    Se si dispone di una intranet IPv6, per configurare il server di accesso remoto affinché possa raggiungere tutti i percorsi IPv6, eseguire le operazioni seguenti:

    : Elenca gli spazi degli indirizzi IPv6 per tutti i percorsi nella intranet.
    -Utilizzare il netsh interface ipv6 add routecomando per aggiungere gli spazi degli indirizzi IPv6 come route statiche nella tabella di routing IPv6 del server di accesso remoto.
    Intranet a Internet IPv4 e IPv6Server di accesso remoto inoltra il traffico della route IPv6 predefinita usando l'interfaccia di scheda Microsoft 6to4 a un relay 6to4 nella rete Internet IPv4. Quando IPv6 nativo non viene distribuito nella rete aziendale, è possibile utilizzare il comando seguente per configurare un server di accesso remoto per l'indirizzo IPv4 del relay Microsoft 6to4 nella rete Internet IPv4:netsh interface ipv6 6to4 set relay name=<ipaddress> state=enabled.
    Nota
    • Se il client DirectAccess è stato assegnato un indirizzo IPv4 pubblico, utilizzerà la tecnologia di relay 6to4 per connettersi alla intranet. Se il client viene assegnato un indirizzo IPv4 privato, userà Teredo. Se il client DirectAccess non può connettersi al server DirectAccess con 6to4 o Teredo, utilizzerà IP-HTTPS.
    • Per usare Teredo, è necessario configurare due indirizzi IP consecutivi nella scheda di rete con connessione esterna.
    • Se il server di accesso remoto ha una sola scheda di rete, è possibile utilizzare Teredo.
    • Computer client IPv6 nativo può connettersi al server di accesso remoto con un IPv6 nativo, ed è richiesta alcuna tecnologia di transizione.

Pianificare i requisiti di ISATAP

ISATAP è richiesto per la gestione remota di DirectAccessclients, in modo che il server di Gestione DirectAccess può connettersi ai client DirectAccess su Internet. ISATAP non è necessaria per supportare le connessioni avviate dai computer client DirectAccess alle risorse IPv4 nella rete aziendale. A questo scopo, viene usato NAT64/DNS64. Se la distribuzione richiede ISATAP, utilizzare la tabella seguente per identificare i requisiti.

Scenario di distribuzione di ISATAPRequisiti
Esistente intranet IPv6 nativo (non è necessaria alcuna ISATAP)Con un'infrastruttura IPv6 nativa esistente, specificare il prefisso dell'organizzazione durante la distribuzione di accesso remoto e server di accesso remoto non configurerà automaticamente come router ISATAP. Eseguire le operazioni seguenti:

1. Per assicurarsi che i client DirectAccess siano raggiungibili dalla intranet, è necessario modificare il routing IPv6 in modo che il traffico della route predefinita venga inoltrato al server di accesso remoto. Se lo spazio di indirizzi IPv6 intranet utilizza un indirizzo diverso da un singolo prefisso di indirizzo IPv6 a 48-bit, è necessario specificare il prefisso IPv6 dell'organizzazione pertinenti durante la distribuzione.
2. Se si è attualmente connessi alla rete Internet IPv6, è necessario configurare il traffico della route predefinita in modo che venga inoltrato al server di accesso remoto e quindi configurare le connessioni appropriate e le route nel server di accesso remoto, in modo che il traffico della route predefinita venga inoltrato al dispositivo che è connesso alla rete Internet IPv6.
Distribuzione di ISATAP esistenteSe si dispone di un'infrastruttura ISATAP esistente, durante la distribuzione richiesto il prefisso a 48 bit dell'organizzazione e il server di accesso remoto non configurerà automaticamente come router ISATAP. Per garantire che i client DirectAccess siano raggiungibili dalla intranet, è necessario modificare l'infrastruttura di routing IPv6 in modo che il traffico della route predefinita venga inoltrato al server di accesso remoto. Questa modifica deve essere eseguita sul router ISATAP esistente in cui i client intranet devono essere inoltro del traffico predefinito.
Nessuna connettività IPv6 esistenteQuando la configurazione guidata accesso remoto rileva che il server non disponga di nessuna connettività IPv6 nativa o basata su ISATAP, automaticamente deriva un prefisso a 48 bit basato su 6to4 per la rete intranet e configura il server di accesso remoto come router ISATAP per fornire connettività IPv6 agli host ISATAP nella intranet. (Un prefisso basato su 6to4 viene utilizzato solo se il server dispone di indirizzi pubblici, in caso contrario il prefisso viene generato automaticamente da un intervallo di indirizzo locale univoco).

Per utilizzare ISATAP eseguire le operazioni seguenti:

1. Registrare il nome ISATAP in un server DNS per ogni dominio in cui si desidera abilitare la connettività basata su ISATAP, in modo che il nome ISATAP sia risolvibile dal server DNS interno per l'indirizzo IPv4 interno del server di accesso remoto.
2. Per impostazione predefinita, server DNS che eseguono Windows Server 2012, Windows Server 2008 R2, Windows Server 2008 o Windows Server 2003 bloccare la risoluzione del nome ISATAP con elenco globale delle query blocco. Per abilitare ISATAP, è necessario rimuovere il nome ISATAP dall'elenco di blocco. Per ulteriori informazioni, vedere rimuovere ISATAP dall'elenco di blocco Query globale DNS.

Host ISATAP basati su Windows in grado di risolvere automaticamente il nome ISATAP configurare un indirizzo con il server di accesso remoto come segue:

1. Un indirizzo IPv6 basato su ISATAP in un'interfaccia di tunneling ISATAP
2. Una route a 64 bit che fornisce la connettività ad altri host ISATAP nella intranet
3. Una route IPv6 predefinita che punta al server di accesso remoto. La route predefinita assicura che gli host ISATAP intranet possano raggiungere i client DirectAccess

Quando gli host ISATAP basati su Windows Ottieni un indirizzo IPv6 basato su ISATAP, iniziano a utilizzare il traffico incapsulato da ISATAP per comunicare se la destinazione è anche un host ISATAP. Poiché ISATAP utilizza una singola subnet a 64 bit per l'intera rete intranet, la comunicazione passa da un modello di IPv4 segmentato di comunicazione, a un modello di comunicazione singola subnet con IPv6. Questo può influire sul comportamento di alcuni servizi di dominio Active Directory (AD DS) e applicazioni che utilizzano la configurazione di Active Directory Sites and Services. Ad esempio, se è stato usato i siti di Active Directory e snap-in servizi per configurare siti, subnet basate su IPv4 e trasporti tra siti per inoltrare richieste ai server all'interno dei siti, questa configurazione non viene utilizzata dagli host ISATAP.

  1. Per configurare Active Directory Sites and Services per l'inoltro all'interno dei siti per gli host ISATAP, per ogni oggetto della subnet IPv4, è necessario configurare un oggetto subnet IPv6 equivalente, in cui il prefisso dell'indirizzo IPv6 per la subnet esprima gli stesso intervallo di indirizzi host ISATAP della subnet IPv4. Ad esempio, per IPv4 192.168.99.0 # subnet/24 e l'indirizzo ISATAP a 64 bit del prefisso 2002:836b:1:8000:::/ 64, il prefisso dell'indirizzo IPv6 equivalente per l'oggetto della subnet IPv6 è 2002:836b:1:8000:0:5efe:192.168.99.0/120. Per IPv4 prefisso lunghezza arbitraria (impostata su 24 nell'esempio), è possibile determinare la lunghezza del prefisso IPv6 corrispondente dalla formula 96 + IPv4PrefixLength.
  2. Per gli indirizzi IPv6 dei client DirectAccess, aggiungere quanto segue:

    • Per i client DirectAccess basati su Teredo: subnet IPv6 per l'intervallo di 2001:0:WWXX:YYZZ::/ 64, in cui WWXX: YYZZ è la versione esadecimale con due punti del primo indirizzo IPv4 con connessione Internet del server di accesso remoto. .
    • Per i client DirectAccess basati su IP-HTTPS: subnet IPv6 per l'intervallo di 2002:WWXX:YYZZ:8100::/ / 56, in cui WWXX: YYZZ è la versione esadecimale con due punti del primo indirizzo IPv4 con connessione Internet (w.x.y. z) del server di accesso remoto. .
    • Per i client DirectAccess basato su 6to4: una serie di prefissi IPv6 basati su 6to4-che iniziano con 2002: e rappresentano i pubblici prefissi degli indirizzi IPv4 amministrati da IANA Internet Assigned Numbers autorità () e registri di sistema internazionali. Il prefisso basato su 6to4 per un w.x.y.z/n prefisso di indirizzo IPv4 pubblico è 2002:WWXX:YYZZ::/ / [16 + n], in cui WWXX: YYZZ è la versione esadecimale con due punti w.x.y.z.

      Ad esempio, l'intervallo di 7.0.0.0/8 è amministrato da American del Registro di sistema per Internet Numbers (ARIN) per il Nord America. Il corrispondente prefisso basato su 6to4 per questo intervallo di indirizzi IPv6 pubblico è 2002:700:::/ 24. Per informazioni sullo spazio di indirizzi pubblici IPv4, vedere registro dello spazio degli indirizzi IPv4 di IANA. .
Importante

Assicurarsi che non è indirizzi IP pubblici nell'interfaccia interna del server DirectAccess. Se hai l'indirizzo IP pubblico nell'interfaccia interna, la connettività tramite ISATAP potrebbe non riuscire.

Pianificare i requisiti firewall

Se il server di accesso remoto è protetto da un firewall periferico, le seguenti eccezioni sono necessarie per il traffico di accesso remoto quando il server di accesso remoto è nella rete Internet IPv4:

  • Per IP-HTTPS: Porta di destinazione di protocollo TCP (Transmission Control) 443 e porta TCP di origine 443 in uscita.

  • Per il traffico Teredo: porta di destinazione di protocollo UDP (User Datagram) 3544 in entrata e porta UDP di origine 3544 in uscita.

  • Per il traffico 6to4: protocollo IP 41 in entrata e in uscita.

    Nota

    Per il traffico Teredo e 6to4, queste eccezioni devono essere applicate per entrambi i con connessione Internet indirizzi IPv4 pubblici consecutivi nel server di accesso remoto.

    Per IP-HTTPS le eccezioni devono essere applicate all'indirizzo registrato nel server DNS pubblico.

  • Se si distribuisce accesso remoto con una sola scheda di rete e si installa il server dei percorsi di rete nel server di accesso remoto, la porta TCP 62000.

    Nota

    Questa esenzione si trova nel server di accesso remoto e le esenzioni precedenti sono sul firewall periferico.

Le seguenti eccezioni sono necessarie per il traffico di accesso remoto quando il server di accesso remoto nella rete Internet IPv6:

  • Protocollo IP 50

  • Porta UDP di destinazione 500 in entrata e porta UDP di origine 500 in uscita.

  • Traffico ICMPv6 in entrata e in uscita (solo quando si usa Teredo).

Quando si utilizzano altri firewall, applicare le seguenti eccezioni firewall di rete interna per il traffico di accesso remoto:

  • Per ISATAP: Protocollo 41 in entrata e in uscita

  • Per tutto il traffico IPv4/IPv6: TCP/UD

  • Per Teredo: ICMP per tutto il traffico IPv4/IPv6

Pianificare i requisiti dei certificati

Esistono tre scenari che richiedono certificati quando si distribuisce un singolo server di accesso remoto.

  • L'autenticazione IPsec: requisiti dei certificati per IPsec includono un certificato del computer usato dai computer client DirectAccess quando stabiliscono la connessione IPsec con il server di accesso remoto e certificato di un computer viene utilizzato dal server di accesso remoto per stabilire le connessioni IPsec con i client DirectAccess.

    Per DirectAccess in Windows Server 2012, l'uso di questi certificati IPsec non è obbligatorio. In alternativa, il server di accesso remoto può fungere da proxy per l'autenticazione Kerberos senza necessità di certificati. Se viene utilizzata l'autenticazione Kerberos, viene eseguito su SSL e il protocollo Kerberos Usa il certificato è stato configurato per IP-HTTPS. Alcuni scenari aziendali (inclusi distribuzione multisito e l'autenticazione client password monouso) richiedono l'utilizzo di autenticazione del certificato e non l'autenticazione Kerberos.

  • Server IP-HTTPS: quando si configura accesso remoto, il server di accesso remoto viene configurato automaticamente per funzionare come listener web IP-HTTPS. Il sito IP-HTTPS richiede un certificato del sito Web e i computer client devono essere in grado di contattare il certificato revoche di certificati (CRL) sito per il certificato.

  • Server dei percorsi di rete: il server dei percorsi di rete è un sito Web che consente di rilevare se i computer client si trovano nella rete aziendale. Il server dei percorsi di rete richiede un certificato del sito Web. I client DirectAccess devono essere in grado di contattare il sito CRL per il certificato.

Requisiti di autorità di certificazione per ognuno di questi scenari è riepilogato nella tabella seguente.

Autenticazione IPsecServer IP-HTTPSServer dei percorsi di rete
Una CA interna è necessaria per emettere certificati del computer per il server di accesso remoto e i client per l'autenticazione IPsec quando non si utilizza il protocollo Kerberos per l'autenticazione.CA interna: È possibile utilizzare una CA interna per emettere il certificato IP-HTTPS. Tuttavia, è necessario assicurarsi che il punto di distribuzione CRL sia disponibile esternamente.CA interna: È possibile utilizzare una CA interna per emettere il certificato di sito Web server percorsi di rete. Assicurarsi che il punto di distribuzione CRL sia a disponibilità elevata nella rete interna.
Certificato autofirmato: È possibile utilizzare un certificato autofirmato per il server IP-HTTPS. Un certificato autofirmato non può essere utilizzato in una distribuzione multisito.Certificato autofirmato: È possibile utilizzare un certificato autofirmato per il sito Web server percorsi di rete; Tuttavia, è possibile utilizzare un certificato autofirmato nelle distribuzioni multisite.
CA pubblica: È consigliabile che usare una CA pubblica per emettere il certificato IP-HTTPS, questo assicura che il punto di distribuzione CRL sia disponibile esternamente.

Pianificare i certificati del computer per l'autenticazione IPsec

Se si utilizza l'autenticazione IPsec basata su certificato, il server di accesso remoto e i client sono necessari per ottenere un certificato del computer. Il modo più semplice per installare i certificati consiste nell'usare criteri di gruppo per configurare la registrazione automatica dei certificati del computer. Ciò garantisce che tutti i membri del dominio ottenere un certificato da una CA dell'organizzazione. Se non si dispone di un'organizzazione CA impostato all'interno dell'organizzazione, vedere Servizi certificati Active Directory.

Questo certificato ha i seguenti requisiti:

  • Il certificato deve avere l'autenticazione client utilizzo chiave esteso (EKU).

  • Il client e i certificati del server devono riguardano lo stesso certificato radice. Questo certificato radice deve essere selezionato nelle impostazioni di configurazione di DirectAccess.

Pianificare i certificati per IP-HTTPS

È necessario installare manualmente un certificato del sito Web HTTPS nel server e server di accesso remoto funge da listener IP-HTTPS. Quando si pianifica, considerare quanto segue:

  • È consigliabile l'uso di una CA pubblica, in modo che siano immediatamente disponibili CRL.

  • Nel campo soggetto, specificare l'indirizzo IPv4 della scheda Internet del server di accesso remoto o il nome FQDN dell'URL IP-HTTPS (indirizzo ConnectTo). Se il server di accesso remoto si trova dietro un dispositivo NAT, deve essere specificato il nome pubblico o l'indirizzo del dispositivo NAT.

  • Il nome comune del certificato deve corrispondere al nome del sito IP-HTTPS.

  • Per il Enhanced Key Usage campo, utilizzare l'identificatore di oggetto (OID) autenticazione Server.

  • Per il punti di distribuzione CRL, specificare un punto di distribuzione CRL accessibile dai client DirectAccess connessi a Internet.

    Nota

    Questo è solo necessario per i client che eseguono Windows 7.

  • Il certificato IP-HTTPS deve avere una chiave privata.

  • Il certificato IP-HTTPS deve essere importato direttamente nell'archivio personale.

  • I certificati IP-HTTPS possono essere presenti caratteri jolly nel nome.

Pianificare i certificati del sito Web per il server dei percorsi di rete

Quando si pianifica il sito Web server percorsi di rete, considerare quanto segue:

  • Nel soggetto, specificare un indirizzo IP dell'interfaccia intranet del server del percorso di rete o il nome di dominio completo dell'URL del percorso di rete.

  • Per il Enhanced Key Usage campo, utilizzare l'OID di autenticazione Server.

  • Per il punti di distribuzione CRL campo, utilizzare un punto di distribuzione CRL accessibile dai client DirectAccess connessi alla intranet. Il punto di distribuzione CRL non deve essere accessibile dall'esterno della rete interna.

Nota

Assicurarsi che i certificati per server dei percorsi di rete e IP-HTTPS abbiano un nome soggetto. Se il certificato viene utilizzato un nome alternativo, non sarà accettato dalla procedura guidata accesso remoto.

Pianificare i requisiti DNS

Questa sezione illustra i requisiti DNS per i client e server in una distribuzione di accesso remoto.

Richieste dei client DirectAccess

DNS viene usato per risolvere le richieste provenienti dai computer client DirectAccess non presenti nella rete interna. I client DirectAccess tentano di connettersi al server dei percorsi di rete DirectAccess per determinare se si trovano su Internet o nella rete aziendale.

  • Se la connessione ha esito positivo, vengono rilevati che i client della rete Intranet, DirectAccess non viene usato e le richieste client vengono risolte usando il server DNS configurato nella scheda di rete del computer client.

  • Se la connessione non riesce, si presuppone che i client su Internet. I client DirectAccess utilizzerà la tabella dei criteri risoluzione nomi (NRPT) per determinare quale server DNS usare per la risoluzione delle richieste di nomi. È possibile specificare che i client debbano usare DirectAccess DNS64 per risolvere i nomi o un server DNS interno alternativo.

Quando si esegue la risoluzione dei nomi, la risoluzione dei nomi viene utilizzato dai client DirectAccess per stabilire come gestire una richiesta. I client richiedono un nome di dominio completo o un nome con etichetta singola, ad esempio http://internal. Se viene richiesto un nome con etichetta singola, viene aggiunto un suffisso DNS per rendere un FQDN. Se la query DNS corrisponde a una voce nella tabella NRPT ed è specificato DNS4 o un server DNS intranet per la voce, la query viene inviata per la risoluzione dei nomi utilizzando il server specificato. Se esiste una corrispondenza, ma non viene specificato alcun server DNS, una regola di esenzione e la normale risoluzione dei nomi viene applicata.

Quando viene aggiunto un nuovo suffisso per la risoluzione dei nomi nella console di gestione accesso remoto, i server DNS predefiniti per il suffisso possono essere individuati automaticamente facendo il rileva pulsante. Il rilevamento automatico funziona come segue:

  • Se la rete aziendale è basata su IPv4 o Usa IPv4 e IPv6, l'indirizzo predefinito è l'indirizzo DNS64 della scheda interna nel server di accesso remoto.

  • Se la rete aziendale è basata su IPv6, l'indirizzo predefinito è l'indirizzo IPv6 del server DNS nella rete aziendale.

Server dell'infrastruttura
  • Server dei percorsi di rete

    I client DirectAccess tentano di raggiungere il server dei percorsi di rete per determinare se si trovano sulla rete interna. I client nella rete interna devono essere in grado di risolvere il nome del server del percorso di rete e deve essere ha impediti la risoluzione del nome quando si trovano su Internet. Per garantire che ciò si verifica, per impostazione predefinita, il nome FQDN del server del percorso di rete viene aggiunto come una regola di esenzione a NRPT. Inoltre, quando si configura accesso remoto, vengono create automaticamente le regole seguenti:

    • Regola per il dominio radice o il nome di dominio del server di accesso remoto e gli indirizzi IPv6 corrispondenti ai server DNS intranet configurati nel server di accesso remoto suffisso un DNS. Ad esempio, se il server di accesso remoto è un membro del dominio corp.contoso.com, viene creata una regola per il suffisso DNS corp.contoso.com.

    • Una regola di esenzione per il nome FQDN del server del percorso di rete. Ad esempio, se l'URL server percorsi di rete è https://nls.corp.contoso.com, viene creata una regola di esenzione per il nome FQDN nls.corp.contoso.com.

  • Server IP-HTTPS

    Il server di accesso remoto funge da listener IP-HTTPS e Usa il certificato del server per autenticarsi nei client IP-HTTPS. Il nome IP-HTTPS deve essere risolvibile dai client DirectAccess che usano i server DNS pubblici.

Strumenti di verifica della connettività

Accesso remoto crea un probe web predefinito usato dai computer client DirectAccess per verificare la connettività alla rete interna. Per garantire che il funzionamento del probe, è necessario registrare manualmente i nomi seguenti in DNS:

  • DirectAccess-webprobehost dovrebbe risolvere l'indirizzo IPv4 interno del server di accesso remoto o l'indirizzo IPv6 in un ambiente solo IPv6.

  • DirectAccess-corpconnectivityhost dovrebbe risolvere l'indirizzo dell'host locale (loopback). È necessario creare record a e AAAA. Il valore del record è 127.0.0.1 e il valore del record AAAA è costituito dal prefisso NAT64 con gli ultimi 32 bit come 127.0.0.1. Il prefisso NAT64 può essere recuperato eseguendo il Get-netnatTransitionConfiguration cmdlet di Windows PowerShell.

    Nota

    Questo è valido solo in ambienti solo IPv4. In un IPv4 più IPv6 o un ambiente solo IPv6, creare un solo record AAAA con l'indirizzo IP di loopback:: 1.

È possibile creare strumenti di verifica della connettività aggiuntivi con altri indirizzi web su HTTP oppure PING. Per ogni strumento di verifica della connettività deve esistere una voce DNS.

Requisiti del server DNS
  • Per i client DirectAccess, è necessario utilizzare un server DNS che esegue Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows Server 2003 o qualsiasi server DNS che supporti IPv6.

  • È consigliabile utilizzare un server DNS che supporti gli aggiornamenti dinamici. È possibile utilizzare i server DNS che non supportano gli aggiornamenti dinamici, ma quindi voci devono essere aggiornate manualmente.

  • Il nome di dominio completo per i punti di distribuzione CRL deve essere risolvibile con i server DNS Internet. Ad esempio, se l'URL http://crl.contoso.com/crld/corp-DC1-CA.crl il punti di distribuzione CRL campo del certificato IP-HTTPS del server di accesso remoto, è necessario assicurarsi che il nome crld.contoso.com sia risolvibile mediante server DNS Internet.

Piano per la risoluzione dei nomi locali

Quando si pianifica la risoluzione dei nomi locali, tenere presente quanto segue:

RISOLUZIONE DEI NOMI

Potrebbe essere necessario creare regole dei criteri tabella (NRPT) di risoluzione dei nomi aggiuntive nelle situazioni seguenti:

  • È necessario aggiungere ulteriori suffissi DNS per lo spazio dei nomi intranet.

  • Se i nomi di dominio completi dei punti di distribuzione CRL sono basati sullo spazio dei nomi intranet, è necessario aggiungere regole di esenzione per i nomi di dominio completi dei punti di distribuzione CRL.

  • Se si dispone di un ambiente DNS "split Brain", è necessario aggiungere regole di esenzione per i nomi delle risorse per cui si desidera che i client DirectAccess che si trovano su Internet di accedere la versione di Internet, anziché alla versione intranet.

  • Se si reindirizza traffico a un sito Web esterno attraverso i server di proxy web intranet, il sito Web esterno è disponibile solo dalla intranet. Usa gli indirizzi dei server proxy web per consentire le richieste in entrata. In questo caso, aggiungere una regola di esenzione per il nome FQDN del sito Web esterno e specificare che la regola utilizza il server proxy web intranet, anziché gli indirizzi IPv6 dei server DNS intranet.

    Ad esempio, si supponga che si sta testando un sito Web esterno denominato test.contoso.com. Questo nome non è risolvibile con i server DNS Internet, ma il server proxy web di Contoso sa come risolvere il nome e indirizzare le richieste per il sito Web al server web esterno. Per impedire agli utenti che non si trovano nella intranet di Contoso di accedere al sito, il sito Web esterno consente le richieste solo dall'indirizzo Internet IPv4 del proxy web di Contoso. Di conseguenza, gli utenti della intranet possono accedere al sito Web poiché utilizzano il proxy web di Contoso, ma gli utenti di DirectAccess non è possibile perché non si utilizza il proxy web di Contoso. Configurando una regola di esenzione NRPT per test.contoso.com che utilizza il proxy web di Contoso, le richieste di una pagina Web per test.contoso.com vengono indirizzate al server proxy web intranet sulla rete Internet IPv4.

Nomi con etichetta singola

Nomi con etichetta singola, ad esempio http://paycheck, vengono talvolta utilizzati per i server intranet. Se viene richiesto un nome con etichetta singola e un elenco di ricerca suffissi DNS è configurato, i suffissi DNS nell'elenco verranno aggiunto al nome con etichetta singola. Ad esempio, quando un utente in un computer che è un membro dei tipi di dominio corp.contoso.com http://paycheck nel web browser, il nome di dominio completo costruito come nome è paycheck.corp.contoso.com. Per impostazione predefinita, il suffisso aggiunto si basa sul suffisso DNS primario del computer client.

Nota

In un scenario di spazio dei nomi indipendente (in cui uno o più computer del dominio hanno un suffisso DNS che non corrisponde al dominio di Active Directory in cui i computer sono membri), è necessario assicurarsi che l'elenco di ricerca sia personalizzato e includa tutti i suffissi richiesti. Per impostazione predefinita, la configurazione guidata accesso remoto configura il nome DNS di Active Directory come suffisso DNS primario nel client. Assicurarsi di aggiungere il suffisso DNS utilizzato dai client per la risoluzione dei nomi.

Se vengono distribuiti più domini e Windows Internet Name Service (WINS) nell'organizzazione e si connette in remoto, i nomi singoli possono essere risolti come segue:

  • Distribuendo una zona di ricerca diretta WINS in DNS. Quando si tenta di risolvere computername.dns.zone1.corp.contoso.com, la richiesta viene indirizzata al server WINS che usa solo il nome del computer. Il client ritiene di emettere una richiesta di record DNS A regolare, ma è effettivamente una richiesta NetBIOS.

    Per ulteriori informazioni, vedere la gestione di una zona di ricerca diretta.

  • Aggiungendo un suffisso DNS (ad esempio, dns.zone1.corp.contoso.com) per l'oggetto Criteri di gruppo di dominio predefinito.

Split-brain DNS

Split-brain DNS si intende l'uso dello stesso dominio DNS per la risoluzione dei nomi Internet e intranet.

Per le distribuzioni DNS "split Brain", è necessario elencare i nomi di dominio completi duplicati in Internet e intranet e decidere quali risorse il client DirectAccess deve raggiungere la rete intranet o la versione di Internet. Quando vuoi che i client DirectAccess raggiungano la versione di Internet, è necessario aggiungere il nome di dominio completo corrispondente come regola di esenzione a NRPT per ogni risorsa.

In un ambiente DNS "split Brain", se si desidera entrambe le versioni della risorsa sia disponibile, configurare le risorse intranet con nomi che non duplicare i nomi utilizzati in Internet. Quindi comunicare agli utenti di usare il nome alternativo quando si accede alla risorsa nella intranet. Ad esempio, configurare www.internal.contoso.com per il nome interno del www.contoso.com.

In un ambiente DNS non-"split-Brain", lo spazio dei nomi Internet è diverso dallo spazio dei nomi intranet. Ad esempio, Contoso Corporation utilizza contoso.com su Internet e corp.contoso.com nella intranet. Poiché tutte le risorse intranet utilizzano il suffisso DNS corp.contoso.com, la regola NRPT per corp.contoso.com indirizza tutte le query relative ai nomi DNS per le risorse intranet ai server DNS intranet. Le query DNS per i nomi con il suffisso contoso.com corrisponde alla regola dello spazio dei nomi intranet di corp.contoso.com nella tabella NRPT e inviati ai server DNS Internet. Con una distribuzione DNS non-"split-Brain", poiché non vengono duplicati di nomi di dominio completi per risorse intranet e Internet, non esiste alcuna configurazione aggiuntiva per la risoluzione dei nomi. I client DirectAccess possono accedere alle risorse Internet e intranet per l'organizzazione.

Pianificare il comportamento di risoluzione dei nomi locali per i client DirectAccess

Se non è possibile risolvere un nome con DNS, il servizio Client DNS in Windows Server 2012, Windows 8, Windows Server 2008 R2 e Windows 7 possono utilizzare risoluzione dei nomi locali, con il Link-Local Multicast Name LLMNR (Resolution) e NetBIOS su protocolli TCP/IP, per risolvere il nome nella subnet locale. Risoluzione dei nomi locali è in genere necessaria per la connettività peer-to-peer quando il computer si trova in reti private, ad esempio reti domestiche a subnet singola.

Quando il servizio Client DNS esegue la risoluzione dei nomi locali per i nomi dei server intranet e il computer è connesso a una subnet condivisa in Internet, utenti malintenzionati possono acquisire LLMNR e NetBIOS su messaggi TCP/IP per determinare i nomi dei server intranet. Nella pagina DNS della configurazione guidata del Server di infrastruttura, è possibile configurare il comportamento di risoluzione dei nomi locali in base ai tipi di risposte ricevuti dai server DNS intranet. Sono disponibili le opzioni seguenti:

  • Usa la risoluzione dei nomi locali se il nome non esiste nel DNS: questa opzione è la più sicura perché il client DirectAccess esegue la risoluzione dei nomi locali solo per i nomi dei server che non possono essere risolti dai server DNS intranet. Se è possibile raggiungere i server DNS intranet, i nomi dei server intranet vengono risolti. Se il server DNS intranet non sono raggiungibili o se sono presenti altri tipi di errori DNS, i nomi dei server intranet non vengono comunicati alla subnet tramite risoluzione dei nomi locali.

  • Usa risoluzione dei nomi locali se il nome non esiste nel DNS o i server DNS non sono raggiungibili quando il computer client è in una rete privata (scelta consigliata): questa opzione è consigliata perché consente l'uso di risoluzione dei nomi locali in una rete privata solo quando i server DNS intranet sono raggiungibili.

  • Usa la risoluzione dei nomi locali per qualsiasi tipo di errore di risoluzione DNS (opzione meno sicura): si tratta dell'opzione meno sicura perché i nomi dei server di rete intranet possono essere comunicati alla subnet locale mediante risoluzione dei nomi locali.

Pianificare la configurazione di server di percorso di rete

Il server dei percorsi di rete è un sito Web che consente di rilevare se i client DirectAccess si trovano nella rete aziendale. I client nella rete aziendale non usano DirectAccess per raggiungere le risorse interne; ma al contrario, si connettono direttamente.

Il sito Web server percorsi di rete può essere ospitato nel server di accesso remoto o in un altro server dell'organizzazione. Se si ospita il server dei percorsi di rete nel server di accesso remoto, il sito Web viene creato automaticamente quando si distribuisce accesso remoto. Se si ospita il server dei percorsi di rete in un altro server che eseguono un sistema operativo Windows, è necessario verificare che Internet Information Services (IIS) sia installato nel server e che il sito Web viene creato. Accesso remoto non configurare le impostazioni nel server del percorso di rete.

Assicurarsi che il sito Web server percorsi di rete soddisfi i requisiti seguenti:

  • Dispone di un certificato del server HTTPS.

  • Con disponibilità elevata per i computer nella rete interna.

  • Non è accessibile ai computer client DirectAccess su Internet.

Inoltre, considerare i seguenti requisiti per i client quando si configura il sito Web server percorsi di rete:

  • I computer client DirectAccess devono considerare attendibile la CA che ha rilasciato il certificato del server per il sito Web server percorsi di rete.

  • I computer client DirectAccess nella rete interna devono essere in grado di risolvere il nome del sito di rete percorso server.

Pianificare i certificati per il server dei percorsi di rete

Una volta ottenuto il certificato del sito Web da utilizzare per il server dei percorsi di rete, considerare quanto segue:

  • Nel soggetto, specificare l'indirizzo IP dell'interfaccia intranet del server del percorso di rete o il nome di dominio completo dell'URL del percorso di rete.

  • Per il Enhanced Key Usage campo, utilizzare l'OID di autenticazione Server.

  • Il certificato server percorsi di rete deve essere confrontato con un elenco di revoche di certificati (CRL). Per il punti di distribuzione CRL campo, utilizzare un punto di distribuzione CRL accessibile dai client DirectAccess connessi alla intranet. Il punto di distribuzione CRL non deve essere accessibile dall'esterno della rete interna.

Pianificare il DNS per il server dei percorsi di rete

I client DirectAccess tentano di raggiungere il server dei percorsi di rete per determinare se si trovano sulla rete interna. I client nella rete interna devono essere in grado di risolvere il nome del server del percorso di rete, ma devono essere ha impediti la risoluzione del nome quando si trovano su Internet. Per verificarlo, per impostazione predefinita, il nome FQDN del server del percorso di rete viene aggiunto come una regola di esenzione a NRPT.

Pianificare la configurazione dei server di gestione

I client DirectAccess avviano le comunicazioni con i server di gestione che forniscono servizi quali Windows Update e gli aggiornamenti antivirus. Inoltre, i client DirectAccess utilizzano il protocollo Kerberos per autenticare i controller di dominio prima di accedere alla rete interna. Durante la gestione remota dei client DirectAccess, server di gestione comunicano con i computer client per eseguire funzioni di gestione quali le valutazioni degli inventari software o hardware. Accesso remoto può individuare automaticamente alcuni server di gestione, tra cui:

  • I controller di dominio: l'individuazione automatica dei controller di dominio viene eseguita per i domini contenenti computer client e per tutti i domini nella stessa foresta del server di accesso remoto.

  • Server di System Center Configuration Manager

Controller di dominio e System Center Configuration Manager Server vengono rilevati automaticamente la prima volta DirectAccess è configurato. Il controller di dominio rilevati non vengono visualizzati nella console, ma le impostazioni possono essere recuperate tramite il cmdlet di Windows PowerShell. Se vengono modificati i controller di dominio o server System Center Configuration Manager, fare clic su server di gestione aggiornamento nella console Aggiorna l'elenco dei server di gestione.

Requisiti del server di gestione

  • Server di gestione devono essere accessibili tramite il tunnel dell'infrastruttura. Quando si configura accesso remoto, aggiungendo automaticamente i server all'elenco di server di gestione li rende accessibile attraverso questo tunnel.

  • Server di gestione che avviano connessioni ai client DirectAccess devono supportare completamente IPv6, tramite un indirizzo IPv6 nativo o usando un indirizzo assegnato da ISATAP.

Pianificare i requisiti di Active Directory

Accesso remoto Usa Active Directory come segue:

  • Autenticazione: il tunnel dell'infrastruttura Usa l'autenticazione NTLMv2 per l'account computer che si sta connettendo al server di accesso remoto e l'account deve essere in un dominio di Active Directory. Il tunnel intranet Usa l'autenticazione Kerberos per l'utente per creare il tunnel della intranet.

  • Oggetti Criteri di gruppo: accesso remoto raccoglie le impostazioni di configurazione in oggetti Criteri di gruppo (GPO), che vengono applicati ai server di accesso remoto, i client e server applicazioni interni.

  • Gruppi di sicurezza: accesso remoto Usa i gruppi di sicurezza per raccogliere e identificare i computer client DirectAccess. Oggetti Criteri di gruppo vengono applicate ai gruppi di sicurezza richiesti.

Quando si pianifica un ambiente Active Directory per una distribuzione di accesso remoto, prendere in considerazione i seguenti requisiti:

  • Almeno un controller di dominio viene installato il sistema operativo Windows Server 2012, Windows Server 2008 R2 Windows Server 2008 o Windows Server 2003.

    Se il controller di dominio si trova su una rete perimetrale (ed è pertanto raggiungibile dalla scheda di rete con connessione Internet del server di accesso remoto), impedire il server di accesso remoto di raggiungerlo. È necessario aggiungere filtri pacchetti sul controller di dominio per impedire la connettività all'indirizzo IP della scheda Internet.

  • Il server di accesso remoto deve essere un membro del dominio.

  • I client DirectAccess devono essere membri del dominio. I client possono appartenere a:

    • Qualsiasi dominio nella stessa foresta del server di accesso remoto.

    • Qualsiasi dominio che abbia un trust bidirezionale con il dominio del server Accesso remoto.

    • Qualsiasi dominio in una foresta che abbia un trust bidirezionale con la foresta del dominio del server di accesso remoto.

Nota
  • Server di accesso remoto non può essere un controller di dominio.
  • Il controller di dominio Active Directory che viene utilizzato per l'accesso remoto non deve essere raggiungibile dalla scheda Internet esterna del server di accesso remoto (la scheda non deve trovarsi nel profilo del dominio di Windows Firewall).

Pianificare l'autenticazione client

Accesso remoto in Windows Server 2012, è possibile scegliere tra l'utilizzo di autenticazione Kerberos incorporata, che utilizza i nomi utente e password, o usare i certificati per l'autenticazione computer IPsec.

L'autenticazione Kerberos: quando si sceglie di utilizzare le credenziali Active Directory per l'autenticazione, DirectAccess Usa innanzitutto l'autenticazione Kerberos per il computer e quindi Usa l'autenticazione Kerberos per l'utente. Quando si usa questa modalità di autenticazione, DirectAccess Usa un solo tunnel di sicurezza che fornisce l'accesso al server DNS, il controller di dominio e qualsiasi altro server nella rete interna

L'autenticazione IPsec: quando si sceglie di utilizzare autenticazione a due fattori o protezione accesso alla rete, DirectAccess usa due tunnel di sicurezza. La configurazione guidata accesso remoto Configura regole di sicurezza della connessione in Windows Firewall con sicurezza avanzata. Queste regole specificano le credenziali seguenti quando la negoziazione della protezione IPsec al server di accesso remoto:

  • Il tunnel dell'infrastruttura Usa le credenziali del certificato computer per la prima autenticazione e le credenziali utente (NTLMv2) per la seconda autenticazione. Le credenziali dell'utente forzare l'uso di Authenticated Internet Protocol (AuthIP) e forniscono l'accesso a un server DNS e controller di dominio prima che il client DirectAccess può utilizzare le credenziali Kerberos per il tunnel della intranet.

  • Il tunnel intranet Usa le credenziali del certificato computer per la prima autenticazione e le credenziali utente (Kerberos V5) per la seconda autenticazione.

Pianificare più domini

Elenco di server di gestione deve includere i controller di dominio di tutti i domini che contengono gruppi di sicurezza che includono i computer client DirectAccess. Deve contenere tutti i domini che contengono gli account utente che potrebbero usare i computer configurati come client DirectAccess. Ciò garantisce che gli utenti che non si trovano nello stesso dominio del computer client che utilizzano vengono autenticati con un controller di dominio nel dominio utente.

Questa autenticazione è automatica se i domini sono nella stessa foresta. Se è presente un gruppo di sicurezza con i computer client o server applicazioni che si trovano in foreste diverse, i controller di dominio di queste foreste non vengono rilevati automaticamente. Gli insiemi di strutture anche non vengono rilevati automaticamente. È possibile eseguire l'attività server di gestione aggiornamento nel Gestione accesso remoto per rilevare questi controller di dominio.

Dove possibile, devono essere aggiunti suffissi di nome di dominio comuni per la risoluzione dei nomi durante la distribuzione di accesso remoto. Ad esempio, se si dispone di due domini, domain1.corp.contoso.com e domain2.corp.contoso.com, invece di due voci nella tabella, è possibile aggiungere una voce del suffisso DNS comune, in cui il suffisso del nome di dominio è corp.contoso.com. Questo avviene automaticamente per i domini nella stessa radice. Domini che non sono nella stessa radice devono essere aggiunti manualmente.

Pianificare la creazione di oggetti Criteri di gruppo

Quando si configura accesso remoto, le impostazioni di DirectAccess vengono raccolte in oggetti Criteri di gruppo (GPO). Due oggetti Criteri di gruppo vengono popolati con impostazioni DirectAccess e distribuiti come segue:

  • Il client DirectAccess oggetto Criteri di gruppo: questo oggetto Criteri di gruppo contiene le impostazioni client, tra cui impostazioni della tecnologia di transizione IPv6, le voci NRPT e regole di sicurezza della connessione per Windows Firewall con sicurezza avanzata. Oggetto Criteri di gruppo viene applicato ai gruppi di sicurezza specificati per i computer client.

  • DirectAccess server oggetto Criteri di gruppo: questo oggetto Criteri di gruppo contiene le impostazioni di configurazione DirectAccess applicate a qualsiasi server che è stato configurato come server di accesso remoto nella distribuzione. Contiene inoltre regole di sicurezza della connessione per Windows Firewall con sicurezza avanzata.

Nota

Configurazione del server applicazioni non è supportata in Gestione remota dei client DirectAccess perché i client non possono accedere alla rete interna del server DirectAccess in cui risiedono i server applicazioni. Passaggio 4 nella schermata di configurazione di installazione di accesso remoto non è disponibile per questo tipo di configurazione.

È possibile configurare oggetti Criteri di gruppo automaticamente o manualmente.

Automaticamente: quando si specifica che i GPO vengono creati automaticamente, viene specificato un nome predefinito per ogni oggetto Criteri di gruppo.

Manualmente: È possibile utilizzare oggetti Criteri di gruppo che sono state definite dall'amministratore di Active Directory.

Quando si configurano oggetti Criteri di gruppo, considerare gli avvisi seguenti:

  • Dopo aver configurato DirectAccess per l'utilizzo di oggetti Criteri di gruppo specifico, né configurarlo per l'utilizzo di diversi oggetti Criteri di gruppo.

  • Utilizzare la procedura seguente per eseguire il backup tutti remoto oggetti Criteri di gruppo accesso prima di eseguire i cmdlet di DirectAccess:

    Backup e ripristino configurazione di accesso remoto.

  • Se si usano automaticamente o manualmente configurati oggetti Criteri di gruppo, è necessario aggiungere un criterio per il rilevamento dei collegamenti lenti se i client usano 3G. Il percorso per criteri: rilevamento collegamento lento Criteri di gruppo configurazione è:

    Computer configuration/criteri/modelli amministrativi/sistema/criteri di gruppo.

  • Se le autorizzazioni corrette per collegare oggetti Criteri di gruppo non esiste, viene emesso un avviso. L'operazione di accesso remoto continua, ma il collegamento non verrà eseguita. Se viene emesso questo avviso, verranno creati i collegamenti non essere automaticamente, anche se le autorizzazioni sono state aggiunte. L'amministratore deve invece creare i collegamenti manualmente.

Creati automaticamente oggetti Criteri di gruppo

Tenere presente quanto segue quando si utilizza automaticamente creati oggetti Criteri di gruppo:

Creati automaticamente oggetti Criteri di gruppo vengono applicati secondo il percorso e destinazione collegamento, come indicato di seguito:

  • Per l'oggetto Criteri di gruppo del server DirectAccess, il percorso e destinazione collegamento puntano al dominio che contiene il server di accesso remoto.

  • Quando vengono creati oggetti Criteri di gruppo del server applicazioni e client, il percorso è impostato su un singolo dominio. Il nome oggetto Criteri di gruppo viene cercato in ogni dominio e il dominio è compilato con le impostazioni di DirectAccess, se presente.

  • La destinazione del collegamento è impostata nella radice del dominio in cui è stato creato l'oggetto Criteri di gruppo. Viene creato un oggetto Criteri di gruppo per ogni dominio contenente i computer client o server applicazioni e l'oggetto Criteri di gruppo viene collegato alla radice del rispettivo dominio.

Quando si usano creati automaticamente oggetti Criteri di gruppo per applicare le impostazioni di DirectAccess, l'amministratore del server Accesso remoto richiede le autorizzazioni seguenti:

  • Autorizzazioni per creare oggetti Criteri di gruppo per ogni dominio.

  • Autorizzazioni per collegare a tutte le radici del dominio client selezionate.

  • Autorizzazioni per collegare le radici del dominio oggetto Criteri di gruppo.

  • Autorizzazioni di sicurezza per creare, modificare, eliminare e modificare oggetti Criteri di gruppo.

  • Oggetto Criteri di gruppo autorizzazioni di lettura per ogni dominio richiesto. Non è richiesta l'autorizzazione, ma è consigliabile perché consente di accesso remoto verificare che non esistano oggetti Criteri di gruppo con nomi duplicati quando vengono creati oggetti Criteri di gruppo.

Creare manualmente oggetti Criteri di gruppo

Tenere presente quanto segue quando si utilizza manualmente creati oggetti Criteri di gruppo:

  • Oggetti Criteri di gruppo devono essere presenti prima di eseguire la configurazione guidata accesso remoto.

  • Per applicare le impostazioni di DirectAccess, l'amministratore del server Accesso remoto richiede le autorizzazioni di sicurezza completo per creare, modificare, eliminare e modificare oggetti Criteri di gruppo creati manualmente.

  • Viene eseguita una ricerca per un collegamento a oggetto Criteri di gruppo nell'intero dominio. Se l'oggetto Criteri di gruppo non è collegato nel dominio, verrà automaticamente creato un collegamento nel dominio radice. Se le autorizzazioni necessarie per creare il collegamento non sono disponibili, viene emesso un avviso.

Ripristino da un oggetto Criteri di gruppo eliminato

Se un oggetto Criteri di gruppo in un server di accesso remoto, client o server applicazioni è stato eliminato per errore, verrà visualizzato il messaggio di errore seguente: oggetto Criteri di gruppo non è possibile trovare.

Se è disponibile un backup, è possibile ripristinare l'oggetto Criteri di gruppo dal backup. Se non è disponibile alcun backup, è necessario rimuovere le impostazioni di configurazione e configurarli nuovamente.

Per rimuovere le impostazioni di configurazione
  1. Eseguire il cmdlet di Windows PowerShell Uninstall-RemoteAccess.

  2. Apri Gestione accesso remoto.

  3. Vedrai un messaggio di errore che oggetto Criteri di gruppo non viene trovato. Fare clic su rimuovere impostazioni di configurazione. Al termine, verrà ripristinato il server a uno stato non configurato e sarà possibile riconfigurare le impostazioni.

© 2017 Microsoft