Etapa 1: Planejar a infraestrutura de acesso remoto

Note

O Windows Server 2016 combina o DirectAccess e o Serviço de Roteamento e Acesso Remoto (RRAS) em uma única função de Acesso Remoto.

Este tópico descreve as etapas para planejar uma infraestrutura que você pode usar para configurar um único servidor de Acesso Remoto para gerenciamento remoto de clientes DirectAccess. A tabela a seguir lista as etapas, mas essas tarefas de planejamento não precisam ser feitas em uma ordem específica.

Task	Description
Planejar topologia de rede e configurações de servidor	Decida onde colocar o servidor de Acesso Remoto (na borda ou atrás de um dispositivo NAT (Network Address Translation) ou firewall) e planeje o endereçamento e o roteamento IP.
Planejar requisitos de firewall	Planeje a permissão de Acesso Remoto por meio de firewalls de borda.
Planejar requisitos de certificado	Decida se você usará o protocolo Kerberos ou certificados para autenticação de cliente e planeje os certificados do seu site. IP-HTTPS é um protocolo de transição usado por clientes DirectAccess para encapsular o tráfego IPv6 em redes IPv4. Decida se deseja autenticar IP-HTTPS para o servidor usando um certificado emitido por uma autoridade de certificação (CA) ou usando um certificado autoassinado emitido automaticamente pelo servidor de Acesso Remoto.
Planejar requisitos de DNS	Planeje as configurações de DNS (Sistema de Nomes de Domínio) para o servidor de Acesso Remoto, servidores de infraestrutura, opções de resolução de nomes locais e conectividade de cliente.
Planejar a configuração do servidor de local de rede	Decida onde colocar o site do servidor de local de rede em sua organização (no servidor de Acesso Remoto ou em um servidor alternativo) e planeje os requisitos de certificado se o servidor de local de rede estiver localizado no servidor de Acesso Remoto. Note: The network location server is used by DirectAccess clients to determine whether they are located on the internal network.
Planejar configurações de servidores de gerenciamento	Planeje servidores de gerenciamento (como servidores de atualização) que são usados durante o gerenciamento remoto de clientes. Note: Administrators can remotely manage DirectAccess client computers that are located outside the corporate network by using the Internet.
Planejar requisitos do Ative Directory	Planeje seus controladores de domínio, seus requisitos do Ative Directory, autenticação de cliente e estrutura de vários domínios.
Planejar a criação de Objeto de Diretiva de Grupo	Decida quais GPOs são necessários em sua organização e como criar e editar os GPOs.

Planejar topologia e configurações de rede

Ao planejar sua rede, você precisa considerar a topologia do adaptador de rede, as configurações para endereçamento IP e os requisitos para ISATAP.

Planejar adaptadores de rede e endereçamento IP

1. Identifique a topologia do adaptador de rede que você deseja usar. O Acesso Remoto pode ser configurado com qualquer uma das seguintes topologias:

   • Com dois adaptadores de rede: O servidor de Acesso Remoto é instalado na borda com um adaptador de rede conectado à Internet e o outro à rede interna.

   • Com dois adaptadores de rede: O servidor de Acesso Remoto é instalado atrás de um dispositivo NAT, firewall ou roteador, com um adaptador de rede conectado a uma rede de perímetro e o outro à rede interna.

   • Com um adaptador de rede: O servidor de Acesso Remoto é instalado atrás de um dispositivo NAT e o único adaptador de rede está conectado à rede interna.

2. Identifique seus requisitos de endereçamento IP:

   O DirectAccess usa IPv6 com IPsec para criar uma conexão segura entre computadores cliente DirectAccess e a rede corporativa interna. No entanto, o DirectAccess não requer necessariamente conectividade com a Internet IPv6 ou suporte nativo a IPv6 em redes internas. Em vez disso, ele configura e usa automaticamente as tecnologias de transição IPv6 para encapsular o tráfego IPv6 na Internet IPv4 (6to4, Teredo ou IP-HTTPS) e na intranet somente IPv4 (NAT64 ou ISATAP). Para obter uma visão geral dessas tecnologias de transição, consulte os seguintes recursos:

   • Tecnologias de transição IPv6

   • IP-HTTPS Especificação do protocolo de tunelamento

3. Configure os adaptadores e o endereçamento necessários de acordo com a tabela a seguir. Para implementações que estejam atrás de um dispositivo NAT usando um único adaptador de rede, configure os seus endereços IP usando apenas a coluna Adaptador de rede interno.

   Description	Adaptador de rede externo	Internal network adapter1, above	Routing requirements
   Internet IPv4 e intranet IPv4	Configure o seguinte: - Dois endereços IPv4 públicos consecutivos estáticos com as máscaras de sub-rede apropriadas (necessário apenas para Teredo). - Um endereço IPv4 de gateway padrão para seu firewall de Internet ou roteador de provedor de serviços de Internet (ISP) local. Note: The Remote Access server requires two consecutive public IPv4 addresses so that it can act as a Teredo server and Windows-based Teredo clients can use the Remote Access server to detect the type of NAT device.	Configure o seguinte: - Um endereço de intranet IPv4 com a máscara de sub-rede apropriada. - Um sufixo DNS específico para a sua conexão no namespace da intranet. Um servidor DNS também deve ser configurado na interface interna. Caution: Do not configure a default gateway on any intranet interfaces.	Para configurar o servidor de Acesso Remoto para alcançar todas as sub-redes na rede IPv4 interna, faça o seguinte: - Liste os espaços de endereço IPv4 para todos os locais na sua intranet. - Use os route add -p comandos ou netsh interface ipv4 add route para adicionar os espaços de endereço IPv4 como rotas estáticas na tabela de roteamento IPv4 do servidor de Acesso Remoto.
   Internet IPv6 e intranet IPv6	Configure o seguinte: - Use a configuração de endereço autoconfigurada fornecida pelo seu ISP. - Use o route print comando para garantir que exista uma rota IPv6 padrão que aponte para o roteador ISP na tabela de roteamento IPv6. - Determine se o ISP e os roteadores da intranet estão usando as preferências padrão do roteador, conforme descrito na RFC 4191, e se eles estão usando uma preferência padrão mais alta do que os roteadores da intranet local. Se ambos forem verdadeiros, nenhuma outra configuração para a rota padrão será necessária. A preferência mais alta para o roteador ISP garante que a rota IPv6 padrão ativa do servidor de Acesso Remoto aponte para a Internet IPv6. Como o servidor de Acesso Remoto é um roteador IPv6, se você tiver uma infraestrutura IPv6 nativa, a interface da Internet também poderá alcançar os controladores de domínio na intranet. Nesse caso, adicione filtros de pacotes ao controlador de domínio na rede de perímetro que impeçam a conectividade com o endereço IPv6 da interface de Internet do servidor de Acesso Remoto.	Configure o seguinte: Se você não estiver usando níveis de preferência padrão, configure as interfaces da intranet usando o netsh interface ipv6 set InterfaceIndex ignoredefaultroutes=enabled comando. Este comando garante que rotas padrão adicionais que apontam para roteadores de intranet não serão adicionadas à tabela de roteamento IPv6. Você pode obter o InterfaceIndex de suas interfaces de intranet a partir da exibição do netsh interface show interface comando.	Se você tiver uma intranet IPv6, para configurar o servidor de Acesso Remoto para alcançar todos os locais IPv6, faça o seguinte: - Liste os espaços de endereço IPv6 para todos os locais na sua intranet. - Use o netsh interface ipv6 add route comando para adicionar os espaços de endereço IPv6 como rotas estáticas na tabela de roteamento IPv6 do servidor de Acesso Remoto.
   Internet IPv4 e intranet IPv6	O servidor de Acesso Remoto encaminha o tráfego de rota IPv6 padrão usando a interface do adaptador Microsoft 6to4 para uma retransmissão 6to4 na Internet IPv4. Quando o IPv6 nativo não é implantado na rede corporativa, você pode usar o seguinte comando para configurar um servidor de Acesso Remoto para o endereço IPv4 da retransmissão Microsoft 6to4 na Internet IPv4: netsh interface ipv6 6to4 set relay name=<ipaddress> state=enabled.

   Note

   • Se o cliente DirectAccess tiver recebido um endereço IPv4 público, ele usará a tecnologia de retransmissão 6to4 para se conectar à intranet. Se o cliente receber um endereço IPv4 privado, ele usará Teredo. Se o cliente DirectAccess não puder se conectar ao servidor DirectAccess com 6to4 ou Teredo, ele usará IP-HTTPS.
   • Para usar Teredo, você deve configurar dois endereços IP consecutivos no adaptador de rede externo.
   • Não é possível usar Teredo se o servidor de Acesso Remoto tiver apenas um adaptador de rede.
   • Os computadores cliente IPv6 nativos podem se conectar ao servidor de Acesso Remoto por IPv6 nativo e nenhuma tecnologia de transição é necessária.

Planejar os requisitos do ISATAP

O ISATAP é necessário para o gerenciamento remoto de clientes DirectAccess, para que os servidores de gerenciamento DirectAccess possam se conectar a clientes DirectAccess localizados na Internet. O ISATAP não é necessário para suportar conexões iniciadas por computadores cliente DirectAccess para recursos IPv4 na rede corporativa. NAT64/DNS64 é usado para este fim. Se sua implantação exigir ISATAP, use a tabela a seguir para identificar seus requisitos.

Cenário de implantação ISATAP	Requirements
Intranet IPv6 nativa existente (não é necessário ISATAP)	Com uma infraestrutura IPv6 nativa existente, você especifica o prefixo da organização durante a implantação do Acesso Remoto e o servidor de Acesso Remoto não se configura como um roteador ISATAP. Faça o seguinte: 1. Para garantir que os clientes DirectAccess sejam acessíveis a partir da intranet, você deve modificar o roteamento IPv6 para que o tráfego de rota padrão seja encaminhado para o servidor de Acesso Remoto. Se o espaço de endereçamento IPv6 da intranet usar um endereço diferente de um único prefixo de endereço IPv6 de 48 bits, você deverá especificar o prefixo IPv6 da organização relevante durante a implantação. 2. Se estiver atualmente ligado à Internet IPv6, tem de configurar o tráfego de rota predefinido para que seja reencaminhado para o servidor de Acesso Remoto e, em seguida, configurar as ligações e rotas adequadas no servidor de Acesso Remoto, para que o tráfego de rota predefinido seja reencaminhado para o dispositivo que está ligado à Internet IPv6.
Implantação ISATAP existente	Se você tiver uma infraestrutura ISATAP existente, durante a implantação será solicitado o prefixo de 48 bits da organização e o servidor de Acesso Remoto não se configurará como um roteador ISATAP. Para garantir que os clientes DirectAccess estejam acessíveis a partir da intranet, você deve modificar sua infraestrutura de roteamento IPv6 para que o tráfego de rota padrão seja encaminhado para o servidor de Acesso Remoto. Essa alteração precisa ser feita no roteador ISATAP existente para o qual os clientes da intranet já devem estar encaminhando o tráfego padrão.
Nenhuma conectividade IPv6 existente	Quando o assistente de configuração de Acesso Remoto deteta que o servidor não tem conectividade IPv6 nativa ou baseada em ISATAP, ele deriva automaticamente um prefixo de 48 bits baseado em 6to4 para a intranet e configura o servidor de Acesso Remoto como um roteador ISATAP para fornecer conectividade IPv6 a hosts ISATAP em toda a intranet. (Um prefixo baseado em 6to4 é usado somente se o servidor tiver endereços públicos, caso contrário, o prefixo será gerado automaticamente a partir de um intervalo de endereços local exclusivo.) Para usar o ISATAP, faça o seguinte: 1. Registe o nome ISATAP num servidor DNS para cada domínio no qual pretende ativar a conectividade baseada em ISATAP, para que o nome ISATAP possa ser resolvido pelo servidor DNS interno para o endereço IPv4 interno do servidor de Acesso Remoto. 2. Por predefinição, os servidores DNS com o Windows Server 2012, Windows Server 2008 R2, Windows Server 2008 ou Windows Server 2003 bloqueiam a resolução do nome ISATAP utilizando a lista de bloqueios de consulta global. Para habilitar o ISATAP, você deve remover o nome ISATAP da lista de bloqueios. Para obter mais informações, consulte Remover ISATAP da Lista de Bloqueios de Consultas Globais de DNS. Os hosts ISATAP baseados no Windows que podem resolver o nome ISATAP configuram automaticamente um endereço com o servidor de Acesso Remoto da seguinte maneira: 1. Um endereço IPv6 baseado em ISATAP numa interface de túnel ISATAP 2. Uma rota de 64 bits que fornece conectividade com os outros hosts ISATAP na intranet 3. Uma rota IPv6 padrão que aponta para o servidor de Acesso Remoto. A rota padrão garante que os hosts ISATAP da intranet possam alcançar clientes DirectAccess Quando seus hosts ISATAP baseados no Windows obtêm um endereço IPv6 baseado em ISATAP, eles começam a usar o tráfego encapsulado em ISATAP para se comunicar se o destino também for um host ISATAP. Como o ISATAP usa uma única sub-rede de 64 bits para toda a intranet, sua comunicação passa de um modelo de comunicação IPv4 segmentado para um único modelo de comunicação de sub-rede com IPv6. Isso pode afetar o comportamento de alguns Serviços de Domínio Ative Directory (AD DS) e aplicativos que dependem da configuração de Sites e Serviços do Ative Directory. Por exemplo, se você usou o snap-in Sites e Serviços do Ative Directory para configurar sites, sub-redes baseadas em IPv4 e transportes entre sites para encaminhar solicitações para servidores dentro de sites, essa configuração não será usada por hosts ISATAP. Para configurar Sites e Serviços do Ative Directory para encaminhamento dentro de sites para hosts ISATAP, para cada objeto de sub-rede IPv4, você deve configurar um objeto de sub-rede IPv6 equivalente, no qual o prefixo de endereço IPv6 para a sub-rede expressa o mesmo intervalo de endereços de host ISATAP que a sub-rede IPv4. Por exemplo, para a sub-rede IPv4 192.168.99.0/24 e o prefixo de endereço ISATAP de 64 bits 2002:836b:1:8000::/64, o prefixo de endereço IPv6 equivalente para o objeto de sub-rede IPv6 é 2002:836b:1:8000:0:5efe:192.168.99.0/120. Para um comprimento de prefixo IPv4 arbitrário (definido como 24 no exemplo), você pode determinar o comprimento do prefixo IPv6 correspondente a partir da fórmula 96 + IPv4PrefixLength. Para os endereços IPv6 dos clientes DirectAccess, adicione o seguinte: Para clientes DirectAccess baseados em Teredo: uma sub-rede IPv6 para o intervalo 2001:0:WWXX:YYZZ::/64, onde WWXX:YYZZ é a versão em hexadecimal com dois pontos do primeiro endereço IPv4 do servidor de Acesso Remoto voltado para a Internet. . Para clientes DirectAccess baseados em IP-HTTPS: Uma sub-rede IPv6 para o intervalo 2002:WWXX:YYZZ:8100::/56, na qual WWXX:YYZZ é a versão hexadecimal com dois-pontos do primeiro endereço IPv4 voltado para o exterior (w.x.y.z) do servidor de Acesso Remoto. . Para clientes DirectAccess baseados em 6to4: uma série de prefixos IPv6 baseados em 6to4 que começam em 2002: e representam os prefixos de endereço IPv4 públicos regionais administrados pela Internet Assigned Numbers Authority (IANA) e registros regionais. O prefixo baseado em 6to4 para um prefixo de endereço IPv4 público w.x.y.z/n é 2002:WWXX:YYZZ::/[16+n], no qual WWXX:YYZZ é a versão hexadecimal com separadores de dois pontos de w.x.y.z. Por exemplo, o intervalo 7.0.0.0/8 é administrado pelo American Registry for Internet Numbers (ARIN) para a América do Norte. O prefixo baseado em 6to4 correspondente para este intervalo de endereços IPv6 público é 2002:700::/24. Para obter informações sobre o espaço de endereçamento público IPv4, consulte IANA IPv4 Address Space Registry. .

Important

Verifique se você não tem endereços IP públicos na interface interna do servidor DirectAccess. Se tiver um endereço IP público na interface interna, a conectividade através do ISATAP poderá falhar.

Planejar requisitos de firewall

Se o servidor de Acesso Remoto estiver protegido por um firewall de borda, as seguintes exceções serão necessárias para o tráfego de Acesso Remoto quando o servidor de Acesso Remoto estiver na Internet IPv4:

• Para IP-HTTPS: porta de destino TCP (Transmission Control Protocol) 443 e porta de origem TCP 443 de saída.

• Para tráfego Teredo: porta de destino UDP (User Datagram Protocol) 3544 de entrada e porta de origem UDP 3544 de saída.

• Para tráfego 6to4: Protocolo IP 41 em entrada e saída.

  Note

  Para o tráfego Teredo e 6to4, essas exceções devem ser aplicadas para ambos os endereços IPv4 públicos consecutivos voltados para a Internet no servidor de Acesso Remoto.

  Por IP-HTTPS as exceções precisam ser aplicadas no endereço registrado no servidor DNS público.

• Se você estiver implantando o Acesso Remoto com um único adaptador de rede e instalando o servidor de local de rede no servidor de Acesso Remoto, porta TCP 62000.

  Note

  Essa isenção está no servidor de Acesso Remoto e as isenções anteriores estão no firewall de borda.

As seguintes exceções são necessárias para o tráfego de Acesso Remoto quando o servidor de Acesso Remoto está na Internet IPv6:

• Protocolo IP 50

• Porta de destino UDP 500 de entrada e porta de origem UDP 500 de saída.

• Entrada e saída de tráfego ICMPv6 (somente ao usar Teredo).

Quando estiver usando firewalls adicionais, aplique as seguintes exceções de firewall de rede interna para o tráfego de Acesso Remoto:

• Para ISATAP: Protocolo 41 de entrada e saída

• Para todo o tráfego IPv4/IPv6: TCP/UD

• Para Teredo: ICMP para todo o tráfego IPv4/IPv6

Planejar requisitos de certificado

Há três cenários que exigem certificados quando você implanta um único servidor de Acesso Remoto.

• IPsec authentication: Certificate requirements for IPsec include a computer certificate that is used by DirectAccess client computers when they establish the IPsec connection with the Remote Access server, and a computer certificate that is used by Remote Access servers to establish IPsec connections with DirectAccess clients.

  Para o DirectAccess no Windows Server 2012, o uso desses certificados IPsec não é obrigatório. Como alternativa, o servidor de Acesso Remoto pode atuar como um proxy para autenticação Kerberos sem exigir certificados. Se a autenticação Kerberos for usada, ela funcionará sobre SSL e o protocolo Kerberos usará o certificado que foi configurado para IP-HTTPS. Alguns cenários empresariais (incluindo implementação multissite e autenticação de cliente com senha única) exigem o uso de autenticação por certificado, e não autenticação Kerberos.

• IP-HTTPS server: When you configure Remote Access, the Remote Access server is automatically configured to act as the IP-HTTPS web listener. O site IP-HTTPS requer um certificado de site e os computadores clientes devem ser capazes de entrar em contato com o site da lista de revogação de certificados (CRL) para obter o certificado.

• Servidor de local de rede: o servidor de local de rede é um site usado para detetar se os computadores clientes estão localizados na rede corporativa. O servidor de localização de rede requer um certificado de website. Os clientes DirectAccess devem ser capazes de entrar em contato com o site da CRL para obter o certificado.

Os requisitos da autoridade de certificação (CA) para cada um desses cenários são resumidos na tabela a seguir.

IPsec authentication	IP-HTTPS server	Servidor de localização de rede
Uma autoridade de certificação interna é necessária para emitir certificados de computador para o servidor de Acesso Remoto e clientes para autenticação IPsec quando você não usa o protocolo Kerberos para autenticação.	CA interna: você pode usar uma autoridade de certificação interna para emitir o certificado de IP-HTTPS; no entanto, você deve certificar-se de que o ponto de distribuição CRL está disponível externamente.	CA interna: você pode usar uma autoridade de certificação interna para emitir o certificado de site do servidor de local de rede. Certifique-se de que o ponto de distribuição da CRL está altamente disponível na rede interna.
	Certificado autoassinado: você pode usar um certificado autoassinado para o servidor IP-HTTPS. Um certificado autoassinado não pode ser usado em uma implantação multissite.	Certificado autoassinado: Você pode usar um certificado autoassinado para o site do servidor de local de rede; no entanto, você não pode usar um certificado autoassinado em implantações multissite.
	CA pública: recomendamos que você use uma autoridade de certificação pública para emitir o certificado IP-HTTPS, isso garante que o ponto de distribuição da CRL esteja disponível externamente.

Planejar certificados de computador para autenticação IPsec

Se você estiver usando a autenticação IPsec baseada em certificado, o servidor de Acesso Remoto e os clientes deverão obter um certificado de computador. A maneira mais simples de instalar os certificados é usar a Diretiva de Grupo para configurar o registro automático para certificados de computador. Isso garante que todos os membros do domínio obtenham um certificado de uma autoridade de certificação corporativa. Se você não tiver uma autoridade de certificação corporativa configurada em sua organização, consulte Serviços de certificados do Ative Directory.

Este certificado tem os seguintes requisitos:

• O certificado deve ter um uso estendido de chave para autenticação de cliente (EKU).

• Os certificados de cliente e servidor devem estar relacionados ao mesmo certificado raiz. Esse certificado raiz deve ser selecionado nas definições de configuração do DirectAccess.

Planejar certificados para IP-HTTPS

O servidor de Acesso Remoto atua como um escutador IP-HTTPS e você deve instalar manualmente um certificado de servidor HTTPS no servidor. Considere o seguinte ao planejar:

• Recomenda-se o uso de uma autoridade de certificação pública, para que as CRLs estejam prontamente disponíveis.

• No campo assunto, especifique o endereço IPv4 do adaptador de Internet do servidor de Acesso Remoto ou o FQDN da URL de IP-HTTPS (o endereço ConnectTo). Se o servidor de Acesso Remoto estiver localizado atrás de um dispositivo NAT, o nome público ou endereço do dispositivo NAT deve ser especificado.

• O nome comum do certificado deve corresponder ao nome do site IP-HTTPS.

• Para o campo Uso Avançado de Chave, use o identificador de objeto de Autenticação do Servidor (OID).

• Para o campo Pontos de Distribuição de CRL, especifique um ponto de distribuição de CRL que seja acessível por clientes DirectAccess que estão conectados à Internet.

  Note

  Isso só é necessário para clientes que executam o Windows 7.

• O certificado IP-HTTPS deve ter uma chave privada.

• O certificado IP-HTTPS deve ser importado diretamente para o repositório pessoal.

• Certificados IP-HTTPS podem ter caracteres curinga no nome.

Planear certificados de site para o servidor de localização de rede

Considere o seguinte ao planear o site do servidor de localização de rede:

• In the Subject field, specify an IP address of the intranet interface of the network location server or the FQDN of the network location URL.

• Para o campo Uso Avançado de Chave , use o OID de Autenticação do Servidor.

• Para o campo Pontos de Distribuição de CRL , use um ponto de distribuição de CRL acessível por clientes DirectAccess conectados à intranet. Este ponto de distribuição de CRL não deve ser acessível a partir do exterior da rede interna.

Note

Certifique-se de que os certificados para IP-HTTPS e servidor de local de rede têm um nome de assunto. Se o certificado usar um nome alternativo, ele não será aceito pelo Assistente de Acesso Remoto.

Planejar requisitos de DNS

Esta seção explica os requisitos de DNS para clientes e servidores em uma implantação de Acesso Remoto.

Solicitações de cliente DirectAccess

O DNS é usado para resolver solicitações de computadores cliente DirectAccess que não estão localizados na rede interna. Os clientes DirectAccess tentam se conectar ao servidor de local de rede DirectAccess para determinar se estão localizados na Internet ou na rede corporativa.

• Se a conexão for bem-sucedida, os clientes serão determinados como estando na intranet, o DirectAccess não será usado e as solicitações do cliente serão resolvidas usando o servidor DNS configurado no adaptador de rede do computador cliente.

• Se a conexão não for bem-sucedida, presume-se que os clientes estejam na Internet. Os clientes DirectAccess usarão a tabela de política de resolução de nomes (NRPT) para determinar qual servidor DNS usar ao resolver solicitações de nome. Você pode especificar que os clientes devem usar o DirectAccess DNS64 para resolver nomes ou um servidor DNS interno alternativo.

Ao executar a resolução de nomes, a NRPT é usada por clientes DirectAccess para identificar como lidar com uma solicitação. Os clientes solicitam um FQDN ou um nome de rótulo único, como <https://internal>. Se um nome de rótulo único for solicitado, um sufixo DNS será anexado para criar um FQDN. Se a consulta DNS corresponder a uma entrada na NRPT e DNS4 ou se um servidor DNS da intranet for especificado para a entrada, a consulta será enviada para resolução de nomes usando o servidor especificado. Se houver uma correspondência, mas nenhum servidor DNS estiver especificado, uma regra de exceção e uma resolução de nomes normal serão aplicadas.

When a new suffix is added to the NRPT in the Remote Access Management console, the default DNS servers for the suffix can be automatically discovered by clicking the Detect button. A deteção automática funciona da seguinte forma:

• Se a rede corporativa for baseada em IPv4 ou usar IPv4 e IPv6, o endereço padrão será o endereço DNS64 do adaptador interno no servidor de Acesso Remoto.

• Se a rede corporativa for baseada em IPv6, o endereço padrão será o endereço IPv6 dos servidores DNS na rede corporativa.

Infrastructure servers

• Servidor de localização de rede

  Os clientes DirectAccess tentam acessar o servidor de local de rede para determinar se estão na rede interna. Os clientes na rede interna devem ser capazes de resolver o nome do servidor de local de rede e devem ser impedidos de resolver o nome quando estão localizados na Internet. Para garantir que isso ocorra, por padrão, o FQDN do servidor de local de rede é adicionado como uma regra de isenção ao NRPT. Além disso, quando você configura o Acesso Remoto, as seguintes regras são criadas automaticamente:

  • Uma regra de sufixo DNS para o domínio raiz ou o nome de domínio do servidor de Acesso Remoto e os endereços IPv6 que correspondem aos servidores DNS da intranet configurados no servidor de Acesso Remoto. Por exemplo, se o servidor de Acesso Remoto for membro do domínio corp.contoso.com, será criada uma regra para o sufixo DNS corp.contoso.com.

  • Uma regra de isenção para o FQDN do servidor de localização de rede. Por exemplo, se a URL do servidor de localização de rede for https://nls.corp.contoso.com, será criada uma regra de isenção para o FQDN nls.corp.contoso.com.

• IP-HTTPS server

  O servidor de Acesso Remoto atua como um ouvinte de IP-HTTPS e usa seu certificado de servidor para autenticar IP-HTTPS clientes. O nome IP-HTTPS deve ser resolúvel por clientes DirectAccess que usam servidores DNS públicos.

Connectivity verifiers

O acesso remoto cria uma sonda web padrão que é usada por computadores clientes do DirectAccess para verificar a ligação à rede interna. Para garantir que a sonda funcione conforme o esperado, os seguintes nomes devem ser registrados manualmente no DNS:

• directaccess-webprobehost should resolve to the internal IPv4 address of the Remote Access server, or to the IPv6 address in an IPv6-only environment.

• directaccess-corpconnectivityhost should resolve to the local host (loopback) address. Você deve criar registros A e AAAA. O valor do registro A é 127.0.0.1 e o valor do registro AAAA é construído a partir do prefixo NAT64 com os últimos 32 bits como 127.0.0.1. The NAT64 prefix can be retrieved by running the Get-netnatTransitionConfiguration Windows PowerShell cmdlet.

  Note

  Isso é válido apenas em ambientes somente IPv4. Em um ambiente IPv4 mais IPv6 ou somente IPv6, crie apenas um registro AAAA com o endereço IP de loopback ::1.

Você pode criar verificadores de conectividade adicionais usando outros endereços da Web por HTTP ou PING. Para cada verificador de conectividade, deve existir uma entrada DNS.

Requisitos do servidor DNS

• Para clientes DirectAccess, você deve usar um servidor DNS que execute o Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows Server 2003 ou qualquer servidor DNS que ofereça suporte a IPv6.

• Você deve usar um servidor DNS que ofereça suporte a atualizações dinâmicas. Você pode usar servidores DNS que não oferecem suporte a atualizações dinâmicas, mas as entradas devem ser atualizadas manualmente.

• O FQDN dos pontos de distribuição da CRL deve poder ser resolvido usando servidores DNS da Internet. Por exemplo, se a URL https://crl.contoso.com/crld/corp-DC1-CA.crl estiver no campo Pontos de Distribuição de CRL do certificado de IP-HTTPS do servidor de Acesso Remoto, você deverá garantir que o crld.contoso.com FQDN possa ser resolvido usando servidores DNS da Internet.

Planejar a resolução de nomes locais

Considere o seguinte quando estiver planejando a resolução de nomes locais:

NRPT

Pode ser necessário criar regras adicionais de tabela de política de resolução de nomes (NRPT) nas seguintes situações:

• Você precisa adicionar mais sufixos DNS para seu namespace da intranet.

• Se os FQDNs dos pontos de distribuição da CRL forem baseados no namespace da intranet, você deverá adicionar regras de isenção para os FQDNs dos pontos de distribuição da CRL.

• Se você tiver um ambiente DNS split-brain, deverá adicionar regras de isenção para os nomes dos recursos para os quais deseja que os clientes DirectAccess localizados na Internet acessem a versão da Internet, em vez da versão da intranet.

• Se você estiver redirecionando o tráfego para um site externo por meio de seus servidores proxy da Web da intranet, o site externo estará disponível somente na intranet. Ele usa os endereços de seus servidores proxy da Web para permitir as solicitações de entrada. Nessa situação, adicione uma regra de isenção para o FQDN do site externo e especifique que a regra usa o servidor proxy da Web da intranet em vez dos endereços IPv6 dos servidores DNS da intranet.

  Por exemplo, digamos que você esteja testando um site externo chamado test.contoso.com. Esse nome não pode ser resolvido por meio de servidores DNS da Internet, mas o servidor proxy da Web da Contoso sabe como resolver o nome e como direcionar solicitações para o site para o servidor Web externo. Para impedir que os usuários que não estão na intranet da Contoso acessem o site, o site externo permite solicitações somente do endereço IPv4 da Internet do proxy da Web da Contoso. Assim, os usuários da intranet podem acessar o site porque estão usando o proxy da Web da Contoso, mas os usuários do DirectAccess não podem porque não estão usando o proxy da Web da Contoso. ** Ao configurar uma regra de isenção NRPT para test.contoso.com que utiliza o proxy da Web da Contoso, as requisições de páginas web para test.contoso.com são direcionadas para o servidor proxy da Web da intranet através da Internet IPv4.

Nomes únicos de etiqueta

Nomes de rótulo único, como <https://paycheck>, às vezes são usados para servidores de intranet. Se um nome de rótulo único for solicitado e uma lista de pesquisa de sufixos DNS for configurada, os sufixos DNS na lista serão anexados ao nome de rótulo único. Por exemplo, quando um utilizador num computador que é membro do domínio corp.contoso.com digita <https://paycheck> no navegador da Web, o FQDN que é construído como o nome é paycheck.corp.contoso.com. Por padrão, o sufixo anexado é baseado no sufixo DNS primário do computador cliente.

Note

Em um cenário de espaço de nome separado (em que um ou mais computadores de domínio têm um sufixo DNS que não corresponde ao domínio do Ative Directory ao qual os computadores são membros), você deve garantir que a lista de pesquisa seja personalizada para incluir todos os sufixos necessários. Por padrão, o Assistente de Acesso Remoto configura o nome DNS do Ative Directory como o sufixo DNS primário no cliente. Certifique-se de adicionar o sufixo DNS que é usado pelos clientes para resolução de nomes.

Se vários domínios e o WINS (Windows Internet Name Service) forem implantados em sua organização e você estiver se conectando remotamente, os nomes únicos poderão ser resolvidos da seguinte maneira:

• Implantando uma zona de pesquisa direta WINS no DNS. Ao tentar resolver computername.dns.zone1.corp.contoso.com, a solicitação é direcionada para o servidor WINS que está usando apenas o nome do computador. O cliente pensa que está emitindo uma solicitação de registros DNS A regular, mas na verdade é uma solicitação NetBIOS.

  Para obter mais informações, consulte Gerenciando uma zona de pesquisa direta.

• Adicionando um sufixo DNS (por exemplo, dns.zone1.corp.contoso.com) ao GPO de domínio padrão.

Split-brain DNS

Split-brain DNS refere-se à utilização do mesmo domínio DNS para a resolução de nomes na Internet e na intranet.

Para implantações de DNS split-brain, deve-se listar os FQDNs duplicados na Internet e na intranet e decidir quais recursos o cliente DirectAccess deve alcançar: a intranet ou a versão da Internet. Quando desejar que os clientes DirectAccess alcancem a versão da Internet, você deve adicionar o FQDN correspondente como uma regra de isenção à NRPT para cada recurso.

Em um ambiente DNS split-brain, se você quiser que ambas as versões do recurso estejam disponíveis, configure os recursos da intranet com nomes que não dupliquem os nomes usados na Internet. Em seguida, instrua os usuários a usar o nome alternativo quando acessarem o recurso na intranet. Por exemplo, configure www.internal.contoso.com para o nome interno de www.contoso.com.

Em um ambiente DNS sem cérebro dividido, o namespace da Internet é diferente do namespace da intranet. Por exemplo, a Contoso Corporation usa contoso.com na Internet e corp.contoso.com na intranet. Como todos os recursos da intranet usam o sufixo DNS corp.contoso.com, a regra NRPT para corp.contoso.com roteia todas as consultas de nome DNS para recursos da intranet para servidores DNS da intranet. As consultas DNS para nomes com o sufixo contoso.com não correspondem à regra de namespace da intranet corp.contoso.com na NRPT e são enviadas para servidores DNS da Internet. Com uma implantação de DNS sem divisão cerebral, porque não há duplicação de FQDNs para recursos de intranet e Internet, não há nenhuma configuração adicional necessária para o NRPT. Os clientes DirectAccess podem acessar recursos da Internet e da intranet para sua organização.

Planeie o comportamento de resolução de nomes locais para clientes DirectAccess

Se um nome não puder ser resolvido com o DNS, o serviço Cliente DNS no Windows Server 2012, Windows 8, Windows Server 2008 R2 e Windows 7 poderá usar a resolução de nomes locais, com os protocolos LLMNR (Link-Local Multicast Name Resolution) e NetBIOS sobre TCP/IP, para resolver o nome na sub-rede local. A resolução de nomes locais é normalmente necessária para conectividade ponto a ponto quando o computador está localizado em redes privadas, como redes domésticas de sub-rede única.

Quando o serviço Cliente DNS executa a resolução de nomes de servidor de intranet e o computador está conectado a uma sub-rede compartilhada na Internet, usuários mal-intencionados podem capturar mensagens LLMNR e NetBIOS através de TCP/IP para determinar nomes de servidores de intranet. Na página DNS do Assistente de Configuração do Servidor de Infraestrutura, você pode configurar o comportamento de resolução de nomes locais com base nos tipos de respostas recebidas dos servidores DNS da intranet. As seguintes opções estão disponíveis:

• Usar resolução de nome local se o nome não existir no DNS: essa opção é a mais segura porque o cliente DirectAccess executa a resolução de nomes locais somente para nomes de servidor que não podem ser resolvidos pelos servidores DNS da intranet. Se os servidores DNS da intranet puderem ser acessados, os nomes dos servidores da intranet serão resolvidos. Se os servidores DNS da intranet não puderem ser alcançados ou se houver outros tipos de erros DNS, os nomes dos servidores da intranet não serão vazados para a sub-rede por meio da resolução de nomes locais.

• Use a resolução de nomes locais se o nome não existir no DNS ou se os servidores DNS estiverem inacessíveis quando o computador cliente estiver em uma rede privada (recomendado): essa opção é recomendada porque permite o uso da resolução de nomes locais em uma rede privada somente quando os servidores DNS da intranet estiverem inacessíveis.

• Usar resolução de nome local para qualquer tipo de erro de resolução DNS (menos seguro): Esta é a opção menos segura porque os nomes dos servidores de rede da intranet podem ser vazados para a sub-rede local por meio da resolução de nomes locais.

Planejar a configuração do servidor de local de rede

O servidor de local de rede é um site usado para detetar se os clientes DirectAccess estão localizados na rede corporativa. Os clientes na rede corporativa não usam o DirectAccess para acessar recursos internos; mas, em vez disso, eles se conectam diretamente.

O site do servidor de local de rede pode ser hospedado no servidor de Acesso Remoto ou em outro servidor em sua organização. Se você hospedar o servidor de local de rede no servidor de Acesso Remoto, o site será criado automaticamente quando você implantar o Acesso Remoto. Se você hospedar o servidor de local de rede em outro servidor que executa um sistema operacional Windows, deverá certificar-se de que o IIS (Serviços de Informações da Internet) esteja instalado nesse servidor e se o site seja criado. O Acesso Remoto não configura definições no servidor de localização de rede.

Verifique se o site do servidor de local de rede atende aos seguintes requisitos:

• Tem um certificado de servidor HTTPS.

• Tem alta disponibilidade para computadores na rede interna.

• Não está acessível a computadores cliente DirectAccess na Internet.

Além disso, considere os seguintes requisitos para clientes ao configurar o site do servidor de local de rede:

• Os computadores cliente DirectAccess devem confiar na autoridade de certificação que emitiu o certificado do servidor para o site do servidor de localização de rede.

• Os computadores cliente DirectAccess na rede interna devem ser capazes de resolver o nome do servidor de local de rede.

Planear certificados para o servidor de localização de rede

Ao obter o certificado de site a ser usado para o servidor de local de rede, considere o seguinte:

• In the Subject field, specify the IP address of the intranet interface of the network location server or the FQDN of the network location URL.

• Para o campo Uso Avançado de Chave , use o OID de Autenticação do Servidor.

• O certificado do servidor de local de rede deve ser verificado em relação a uma lista de revogação de certificados (CRL). Para o campo Pontos de Distribuição de CRL , use um ponto de distribuição de CRL acessível por clientes DirectAccess conectados à intranet. Este ponto de distribuição de CRL não deve ser acessível a partir do exterior da rede interna.

Configurar o DNS para o servidor de localização de rede

Os clientes DirectAccess tentam acessar o servidor de local de rede para determinar se estão na rede interna. Os clientes na rede interna devem ser capazes de resolver o nome do servidor de local de rede, mas devem ser impedidos de resolver o nome quando estão localizados na Internet. Para garantir que isso ocorra, por padrão, o FQDN do servidor de local de rede é adicionado como uma regra de isenção ao NRPT.

Planejar a configuração dos servidores de gerenciamento

Os clientes DirectAccess iniciam a comunicação com servidores de gerenciamento que fornecem serviços como o Windows Update e atualizações antivírus. Os clientes DirectAccess também usam o protocolo Kerberos para autenticar em controladores de domínio antes de acessarem a rede interna. Durante o gerenciamento remoto de clientes DirectAccess, os servidores de gerenciamento se comunicam com os computadores clientes para executar funções de gerenciamento, como avaliações de inventário de software ou hardware. O Acesso Remoto pode descobrir automaticamente alguns servidores de gerenciamento, incluindo:

• Controladores de domínio: a descoberta automática de controladores de domínio é executada para os domínios que contêm computadores cliente e para todos os domínios na mesma floresta que o servidor de Acesso Remoto.

• Servidores do Microsoft Endpoint Configuration Manager

Os controladores de domínio e os servidores do Configuration Manager são detetados automaticamente na primeira vez que o DirectAccess é configurado. Os controladores de domínio detetados não são exibidos no console, mas as configurações podem ser recuperadas usando cmdlets do Windows PowerShell. Se o controlador de domínio ou os servidores do Configuration Manager forem modificados, clicar em Atualizar Servidores de Gerenciamento no console atualizará a lista de servidores de gerenciamento.

Requisitos do servidor de gerenciamento

• Os servidores de gerenciamento devem estar acessíveis pelo túnel de infraestrutura. Quando você configura o Acesso Remoto, adicionar servidores à lista de servidores de gerenciamento os torna automaticamente acessíveis por esse túnel.

• Os servidores de gerenciamento que iniciam conexões com clientes DirectAccess devem oferecer suporte total ao IPv6, por meio de um endereço IPv6 nativo ou usando um endereço atribuído pelo ISATAP.

Planejar requisitos do Ative Directory

O Acesso Remoto usa o Ative Directory da seguinte maneira:

• Authentication: The infrastructure tunnel uses NTLMv2 authentication for the computer account that is connecting to the Remote Access server, and the account must be in an Active Directory domain. O túnel da intranet usa a autenticação Kerberos para o utilizador criar o túnel da intranet.

• Objetos de Diretiva de Grupo: o Acesso Remoto reúne definições de configuração em GPOs (Objetos de Diretiva de Grupo), que são aplicados a servidores, clientes e servidores de aplicativos internos de Acesso Remoto.

• Security groups: Remote Access uses security groups to gather and identify DirectAccess client computers. Os GPOs são aplicados aos grupos de segurança necessários.

Ao planejar um ambiente do Ative Directory para uma implantação de Acesso Remoto, considere os seguintes requisitos:

• Pelo menos um controlador de domínio está instalado no sistema operacional Windows Server 2012, Windows Server 2008 R2, Windows Server 2008 ou Windows Server 2003.

  Se o controlador de domínio estiver em uma rede de perímetro (e, portanto, acessível a partir do adaptador de rede voltado para a Internet do servidor de Acesso Remoto), impeça que o servidor de Acesso Remoto o alcance. Você precisa adicionar filtros de pacotes no controlador de domínio para impedir a conectividade com o endereço IP do adaptador de Internet.

• O servidor de Acesso Remoto deve ser um membro do domínio.

• Os clientes DirectAccess devem ser membros do domínio. Os clientes podem pertencer a:

  • Qualquer domínio na mesma floresta que o servidor de Acesso Remoto.

  • Qualquer domínio que tenha uma relação de confiança bidirecional com o domínio do servidor de Acesso Remoto.

  • Qualquer domínio em uma floresta que tenha uma relação de confiança bidirecional com a floresta do domínio do servidor de Acesso Remoto.

Note

• O servidor de Acesso Remoto não pode ser um controlador de domínio.
• O controlador de domínio do Ative Directory usado para Acesso Remoto não deve ser acessível a partir do adaptador de Internet externo do servidor de Acesso Remoto (o adaptador não deve estar no perfil de domínio do Firewall do Windows).

Planejar a autenticação do cliente

No Acesso Remoto no Windows Server 2012, você pode escolher entre usar a autenticação Kerberos interna, que usa nomes de usuário e senhas, ou usar certificados para autenticação de computador IPsec.

Kerberos authentication: When you choose to use Active Directory credentials for authentication, DirectAccess first uses Kerberos authentication for the computer, and then it uses Kerberos authentication for the user. Ao usar esse modo de autenticação, o DirectAccess usa um único túnel de segurança que fornece acesso ao servidor DNS, ao controlador de domínio e a qualquer outro servidor na rede interna

IPsec authentication: When you choose to use two-factor authentication or Network Access Protection, DirectAccess uses two security tunnels. O Assistente de Configuração de Acesso Remoto configura regras de segurança de ligação na Firewall do Windows com Segurança Avançada. Essas regras especificam as seguintes credenciais ao negociar a segurança IPsec para o servidor de Acesso Remoto:

• O túnel de infraestrutura usa credenciais de certificado de computador para a primeira autenticação e credenciais de usuário (NTLMv2) para a segunda autenticação. As credenciais de usuário forçam o uso do AuthIP (Authenticated Internet Protocol) e fornecem acesso a um servidor DNS e controlador de domínio antes que o cliente DirectAccess possa usar credenciais Kerberos para o túnel da intranet.

• O túnel da intranet usa credenciais de certificado de computador para a primeira autenticação e credenciais de usuário (Kerberos V5) para a segunda autenticação.

Planejar vários domínios

A lista de servidores de gerenciamento deve incluir controladores de domínio de todos os domínios que contêm grupos de segurança que incluem computadores cliente DirectAccess. Ele deve conter todos os domínios que contêm contas de usuário que podem usar computadores configurados como clientes DirectAccess. Isso garante que os usuários que não estão localizados no mesmo domínio que o computador cliente que estão usando sejam autenticados com um controlador de domínio no domínio do usuário.

Essa autenticação é automática se os domínios estiverem na mesma floresta. Se houver um grupo de segurança com computadores cliente ou servidores de aplicativos que estejam em florestas diferentes, os controladores de domínio dessas florestas não serão detetados automaticamente. As florestas também não são detetadas automaticamente. Você pode executar a tarefa Servidores de Gerenciamento de Atualização no Gerenciamento de Acesso Remoto para detetar esses controladores de domínio.

Sempre que possível, sufixos comuns de nome de domínio devem ser adicionados ao NRPT durante a implantação do Acesso Remoto. Por exemplo, se você tiver dois domínios, domain1.corp.contoso.com e domain2.corp.contoso.com, em vez de adicionar duas entradas à NRPT, poderá adicionar uma entrada de sufixo DNS comum, onde o sufixo de nome de domínio é corp.contoso.com. Isso acontece automaticamente para domínios na mesma raiz. Os domínios que não estão na mesma raiz devem ser adicionados manualmente.

Planear a criação de Objeto de Diretiva de Grupo

Quando você configura o Acesso Remoto, as configurações do DirectAccess são coletadas em GPOs (Objetos de Política de Grupo). Dois GPOs são preenchidos com configurações do DirectAccess e são distribuídos da seguinte maneira:

• GPO do cliente DirectAccess: este GPO contém configurações de cliente, incluindo configurações de tecnologia de transição IPv6, entradas NRPT e regras de segurança de conexão para o Firewall do Windows com Segurança Avançada. O GPO é aplicado aos grupos de segurança especificados para os computadores cliente.

• GPO do servidor DirectAccess: este GPO contém as definições de configuração do DirectAccess que são aplicadas a qualquer servidor que você configurou como um servidor de Acesso Remoto em sua implantação. Ele também contém regras de segurança de conexão para o Firewall do Windows com Segurança Avançada.

Note

A configuração de servidores de aplicativos não é suportada no gerenciamento remoto de clientes DirectAccess porque os clientes não podem acessar a rede interna do servidor DirectAccess onde os servidores de aplicativos residem. A etapa 4 na tela de configuração da Configuração de Acesso Remoto não está disponível para esse tipo de configuração.

Você pode configurar GPOs automaticamente ou manualmente.

Automatically: When you specify that GPOs are created automatically, a default name is specified for each GPO.

Manually: You can use GPOs that have been predefined by the Active Directory administrator.

Ao configurar seus GPOs, considere os seguintes avisos:

• Depois que o DirectAccess é configurado para usar GPOs específicos, ele não pode ser configurado para usar GPOs diferentes.

• Use o procedimento a seguir para fazer backup de todos os Objetos de Diretiva de Grupo de Acesso Remoto antes de executar cmdlets do DirectAccess:

  Faça backup e restaure a configuração de acesso remoto.

• Se você estiver usando GPOs configurados automática ou manualmente, precisará adicionar uma política para deteção de link lento se seus clientes usarem 3G. O caminho para Política: Configurar a deteção de ligação lenta nas Políticas de Grupo é:

  Configuração do computador/Políticas/Modelos administrativos/Sistema/Diretiva de grupo.

• Se as permissões corretas para vincular GPOs não existirem, um aviso será emitido. A operação de Acesso Remoto continuará, mas a vinculação não ocorrerá. Se esse aviso for emitido, os links não serão criados automaticamente, mesmo que as permissões sejam adicionadas posteriormente. Em vez disso, o administrador precisa criar os links manualmente.

GPOs criados automaticamente

Considere o seguinte ao usar GPOs criados automaticamente:

Os GPOS criados automaticamente são aplicados de acordo com o local e o destino do link, da seguinte forma:

• Para o GPO do servidor DirectAccess, a localização e o destino do link apontam para o domínio que contém o servidor de Acesso Remoto.

• Quando GPOs de cliente e servidor de aplicações são criados, o local é definido como um único domínio. Em cada domínio, procura-se o nome do GPO e, caso exista, o domínio é preenchido com as configurações do DirectAccess.

• O destino do link é definido como a raiz do domínio no qual o GPO foi criado. Um GPO é criado para cada domínio que contém computadores cliente ou servidores de aplicativos, e o GPO é vinculado à raiz de seu respetivo domínio.

Ao usar GPOs criados automaticamente para aplicar as configurações do DirectAccess, o administrador do servidor de Acesso Remoto requer as seguintes permissões:

• Permissões para criar GPOs para cada domínio.

• Permissões para vincular a todas as raízes de domínio do cliente selecionadas.

• Permissões para ligar às raízes de domínio do GPO no servidor.

• Permissões de segurança para criar, editar, excluir e modificar os GPOs.

• Permissões de leitura de GPO para cada domínio necessário. Essa permissão não é necessária, mas é recomendada porque permite que o Acesso Remoto verifique se GPOs com nomes duplicados não existem quando GPOs estão sendo criados.

GPOs criados manualmente

Considere o seguinte ao usar GPOs criados manualmente:

• Os GPOs devem existir antes de executar o Assistente de Configuração de Acesso Remoto.

• Para aplicar as configurações do DirectAccess, o administrador do servidor de Acesso Remoto requer permissões de segurança total para criar, editar, excluir e modificar os GPOs criados manualmente.

• Procura-se um link para o GPO em todo o domínio. Se o GPO não estiver vinculado no domínio, um link será criado automaticamente na raiz do domínio. Se as permissões necessárias para criar o link não estiverem disponíveis, um aviso será emitido.

Recuperar um GPO excluído

Se um GPO em um servidor, cliente ou servidor de aplicativos de Acesso Remoto tiver sido excluído por acidente, a seguinte mensagem de erro será exibida: GPO (nome do GPO) não pode ser encontrado.

Se um backup estiver disponível, você poderá restaurar o GPO a partir do backup. Se não houver backup disponível, você deverá remover as definições de configuração e configurá-las novamente.

Para remover definições de configuração

1. Run the Windows PowerShell cmdlet Uninstall-RemoteAccess.

2. Abra o Gerenciamento de Acesso Remoto.

3. Você verá uma mensagem de erro informando que o GPO não foi encontrado. Clique Remover configuração. Após a conclusão, o servidor será restaurado para um estado não configurado e você pode reconfigurar as configurações.