Etapa 1: Planejar a infraestrutura de Acesso Remoto

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Observação

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

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

Tarefa	Descrição
Planejar a topologia de rede e as configurações do servidor	Decida onde colocar o servidor de Acesso Remoto (na borda ou por trás de um firewall ou de um dispositivo NAT [Conversão de Endereços de Rede]) e planeje o roteamento e o endereçamento IP.
Planejar requisitos de firewall	Planejar como permitir a passagem do Acesso Remoto através de firewalls de borda.
Planejar requisitos de certificado	Decida se você usará o protocolo Kerberos ou certificados para autenticação do cliente e planeje seus certificados de site. O IP-HTTPS é um protocolo de transição usado por clientes do DirectAccess para tráfego IPv6 de túnel em redes IPv4. Decida entre autenticar o IP-HTTPS para o servidor usando um certificado emitido por uma AC (autoridade de certificação) ou um certificado autoassinado emitido automaticamente pelo servidor de Acesso Remoto.
Planejar os requisitos de DNS	Planeje as configurações do DNS (Serviço de Nomes de Domínio) para o servidor de Acesso Remoto, os servidores de infraestrutura, as opções de resolução de nome local e a conectividade do cliente.
Planejar a configuração do servidor de local de rede	Decida onde colocar o site do servidor de local de rede na organização (no servidor de Acesso Remoto ou em um servidor alternativo) e planeje os requisitos de certificado caso o servido de local de rede fique localizado no servidor de Acesso Remoto. Observação: o servidor de local de rede é usado por clientes do DirectAccess para determinar se eles estão localizados na rede interna.
Planejar as configurações dos servidores de gerenciamento	Plano para servidores de gerenciamento (como servidores de atualização) que são utilizados durante o gerenciamento de cliente remoto. Observação: os administradores podem gerenciar remotamente os computadores cliente do DirectAccess localizados fora da rede corporativa usando a Internet.
Planejar os requisitos do Active Directory	Planeje os controladores de domínio, os requisitos do Active Directory, a autenticação de cliente e a estrutura com vários domínios.
Planejar a criação do Objeto de Política de Grupo	Decida quais GPOs são necessários na organização e como criar e editá-los.

Planejar topologia e configurações de rede

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

Planejar adaptadores de rede e endereçamento IP

1. Identifique a topologia de adaptador de rede que 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 outro à rede interna.

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

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

2. Identificar os requisitos de endereçamento IP:

   O DirectAccess usa IPv6 com IPsec para criar uma conexão segura entre os computadores cliente do DirectAccess e a rede interna corporativa. Contudo, o DirectAccess não precisa necessariamente de uma conectividade IPv6 com a Internet ou suporte IPv6 nativo em redes internas. Em vez disso, ele configura e usa automaticamente tecnologias de transição IPv6 para criar um túnel de tráfego IPv6 pela Internet IPv4 (6to4, Teredo ou IP-HTTPS) e pela Intranet somente IPv4 (NAT64 ou ISATAP). Para uma visão geral dessas tecnologias de transição, confira os seguintes recursos:

   • Tecnologias de transição IPv6

   • Especificação do protocolo de túnel IP-HTTPS

3. Configure os adaptadores e endereçamento necessários conforme a tabela a seguir. Para implantações por trás de um dispositivo NAT usando um só adaptador de rede, configure os endereços IP usando apenas a coluna Adaptador de rede interno.

   Descrição	Adaptador de rede externa	Adaptador de rede interno1, acima	Requisitos de roteamento
   Internet IPv4 e intranet IPv4	Configure o seguinte: – Dois endereços IPv4 públicos, consecutivos e estáticos com as máscaras de sub-rede apropriadas (necessário somente para Teredo). – Um endereço IPv4 de gateway padrão do firewall da Internet para o roteador do ISP (provedor de serviços de Internet) local. Observação: o servidor de Acesso Remoto precisa de dois endereços IPv4 públicos e consecutivos para que possa atuar como um servidor Teredo e para que clientes Teredo baseados no Windows possam usar o servidor de Acesso Remoto para detectar o tipo de dispositivo NAT.	Configure o seguinte: – Um endereço da intranet IPv4 com a máscara de sub-rede apropriada. – Um sufixo DNS específico da conexão para o namespace da intranet. Um servidor DNS também deverá ser configurado na interface interna. Cuidado: não configure um gateway padrão em nenhuma interface da intranet.	Para configurar o servidor de Acesso Remoto para acessar todas as sub-redes na rede IPv4 interna, faça o seguinte: – Liste os espaços de endereço IPv4 para todos os locais em sua intranet. – Use os comandos route add -p ou netsh interface ipv4 add route para adicionar os espaços de endereços 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 configurada automaticamente pelo ISP. – Use o comando route print para garantir que haja uma rota IPv6 padrão que aponta para o roteador do ISP na tabela de roteamento de IPv6. – Determine se o ISP e os roteadores da intranet estão usando as preferências de roteador padrão descritas no RFC 4191 e se estão usando uma preferência padrão mais alta do que os roteadores da intranet local. Se as duas situações forem verdadeiras, nenhuma outra configuração para a rota padrão será necessária. A preferência mais alta para o roteador do ISP assegura 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, caso você tenha uma infraestrutura IPv6 nativa, a interface de Internet também poderá acessar os controladores de domínio na intranet. Nesse caso, adicione filtros de pacote ao controlador de domínio na rede de perímetro para evitar a conectividade com o endereço IPv6 da interface da Internet do servidor de Acesso Remoto.	Configure o seguinte: Se você não estiver usando os níveis de preferência padrão, configure as interfaces da intranet usando o comando netsh interface ipv6 set InterfaceIndex ignoredefaultroutes=enabled. Esse comando garante que as rotas padrão adicionais que apontam para os roteadores da intranet não sejam acrescentadas à tabela de roteamento de IPv6. É possível obter o InterfaceIndex das interfaces da intranet na exibição do comando netsh interface show interface.	Se você possui uma intranet IPv6, execute o seguinte procedimento para configurar o servidor de Acesso Remoto para chegar a todos os locais IPv6: – Liste os espaços de endereço IPv6 para todos os locais em sua intranet. – Use o comando netsh interface ipv6 add route 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 do Microsoft 6to4 para uma retransmissão 6to4 na Internet IPv4. Quando o IPv6 nativo não está 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 do Microsoft 6to4 na Internet IPv4: netsh interface ipv6 6to4 set relay name=<ipaddress> state=enabled.

   Observação

   • Se um endereço IPv4 público tiver sido atribuído a um cliente do DirectAccess, ele usará tecnologia de retransmissão 6to4 para se conectar à intranet. Se um endereço IPv4 privado for atribuído ao cliente, ele usará o Teredo. Se o cliente do DirectAccess não puder se conectar ao servidor do DirectAccess com 6to4 ou Teredo, ele usará IP-HTTPS.
   • Para usar o Teredo, você precisa configurar dois endereços IP consecutivos no adaptador de rede voltado para o exterior.
   • Você não poderá usar o Teredo se o servidor de Acesso Remoto tiver somente um adaptador de rede.
   • Os computadores cliente IPv6 nativos podem conectar-se ao servidor de Acesso Remoto pelo IPv6 nativo, sem a necessidade de tecnologia de transição.

Planejar requisitos do ISATAP

O ISATAP é necessário para o gerenciamento remoto de DirectAccessclients, para que os servidores de gerenciamento do DirectAccess possam se conectar aos clientes do DirectAccess localizados na Internet. O ISATAP não é necessário para dar suporte a conexões iniciadas pelos computadores cliente do DirectAccess para recursos IPv4 na rede corporativa. NAT64/DNS64 é usado para esta finalidade. Se sua implantação exigir o ISATAP, use a tabela a seguir para identificar os requisitos.

Cenário de implantação do ISATAP	Requisitos
Intranet IPv6 nativa existente (nenhum ISATAP é necessário)	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 assegurar que clientes DirectAccess sejam acessíveis da intranet, você precisará modificar o roteamento IPv6 para que o tráfego de rota padrão seja encaminhado ao servidor de Acesso Remoto. Se o espaço de endereço IPv6 da intranet usar um endereço diferente de um prefixo de endereço IPv6 de 48 bits, você precisará especificar o prefixo IPv6 da organização relevante durante a implantação. 2. Se você estiver conectado à Internet IPv6, configure o tráfego de rota padrão para que seja encaminhado ao servidor de Acesso Remoto. Em seguida, configure as rotas e conexões apropriadas no servidor de Acesso Remoto para que o tráfego de rota padrão seja encaminhado ao dispositivo conectado à Internet IPv6.
Implantação do ISATAP existente	Se você tiver uma infraestrutura ISATAP existente, durante a implantação, receberá um prompt solicitando o prefixo de 48 bits da organização, e o servidor de Acesso Remoto não configurará a si mesmo como um roteador ISATAP. Para assegurar que clientes DirectAccess sejam acessíveis da intranet, você precisará modificar a infraestrutura de roteamento IPv6 para que o tráfego de rota padrão seja encaminhado ao servidor de Acesso Remoto. Essa alteração precisa ser feita no roteador ISATAP existente para o qual os clientes da intranet já precisam estar encaminhando o tráfego padrão.
Nenhuma conectividade IPv6 existente	Quando o assistente de instalação do Acesso Remoto detecta 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 aos hosts ISATAP na intranet. (Um prefixo baseado em 6to4 será usado somente se o servidor tiver endereços públicos, caso contrário, o prefixo será gerado automaticamente de um intervalo de endereços local exclusivo.) Para usar o ISATAP, faça o seguinte: 1. Registre o nome ISATAP em um servidor DNS para cada domínio no qual você deseja habilitar a conectividade baseada em ISATAP, de modo que o nome ISATAP possa ser resolvido pelo servidor DNS interno para o endereço IPv4 interno do servidor de Acesso Remoto. 2. Por padrão, servidores DNS que executam o Windows Server 2012 , o Windows Server 2008 R2 , o Windows Server 2008 ou o Windows Server 2003 bloqueiam a resolução do nome ISATAP usando a lista de bloqueios de consulta global. Para habilitar o ISATAP, remova o nome ISATAP da lista de bloqueios. Para obter mais informações, consulte Remover o ISATAP da lista global de consultas não autorizadas do DNS. 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 em uma interface com túnel ISATAP 2. Uma rota de 64 bits que fornece conectividade aos outros hosts ISATAP na intranet 3. Uma rota IPv6 padrão que aponta para o servidor de Acesso Remoto. A rota padrão assegura que os hosts ISATAP da intranet possam acessar os 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 pelo ISATAP para se comunicar, caso o destino também seja um host ISATAP. Como o ISATAP usa apenas uma sub-rede de 64 bits para toda a intranet, a comunicação vai de um modelo IPv4 segmentado para um modelo de sub-rede única com IPv6. Isso pode afetar o comportamento do AD DS (Serviços de Domínio Active Directory) e de alguns aplicativos que dependem da configuração de Serviços e Sites do Active Directory. Por exemplo, se você usou o snap-in de Serviços e Sites do Active Directory para configurar sites, sub-redes baseadas em IPv4 e transportes entre sites para encaminhar solicitações para servidores nos sites, essa configuração não será usada pelos hosts ISATAP. Para configurar os Serviços e Sites do Active Directory para encaminhamento dentro de sites para hosts ISATAP, para cada objeto de sub-rede IPv4, você precisa configurar um objeto de sub-rede IPv6 equivalente, em que o prefixo de endereço IPv6 para a sub-rede expressa o mesmo intervalo de endereços do 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 de prefixo IPv6 correspondente com a fórmula 96 + IPv4PrefixLength. Para os endereços IPv6 de clientes DirectAccess, adicione o seguinte: Para clientes DirectAccess baseados em Teredo: uma sub-rede IPv6 para o intervalo 2001:0:WWXX:YYZZ::/64, em que WWXX:YYZZ é a versão hexadecimal com dois-pontos do primeiro endereço IPv4 voltado para a Internet do servidor de Acesso Remoto. . Para clientes DirectAccess baseados em IP-HTTPS: uma sub-rede IPv6 para o intervalo 2002:WWXX:YYZZ:8100::/56, em que WWXX:YYZZ é a versão hexadecimal com dois-pontos do primeiro endereço IPv4 (w.x.y.z) voltado para a Internet do servidor de Acesso Remoto. . Para clientes DirectAccess baseados em 6to4: uma série de prefixos IPv6 baseados em 6to4 que iniciam com 2002: e representam os prefixos de endereço IPv4 público e regional que são administrados pela IANA (Autoridade para Atribuição de Números da Internet) 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], em que WWXX:YYZZ é a versão hexadecimal com dois-pontos de w.x.y.z. Por exemplo, o intervalo 7.0.0.0/8 é administrado pelo ARIN (Registro Americano para Números da Internet) para a América do Norte. O prefixo baseado em 6to4 correspondente para esse intervalo de endereços IPv6 públicos é 2002:700::/24. Para obter informações sobre o espaço de endereço público IPv4, confira Registro de Espaço de Endereço IPv4 da IANA. .

Importante

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

Planejar requisitos de firewall

Se o servidor de Acesso Remoto estiver atrás de um firewall de borda, as seguintes exceções serão necessárias para o tráfego do 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 protocolo UDP 3544 de entrada e porta de origem UDP 3544 de saída.

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

  Observação

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

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

• Se você implantar o Acesso Remoto com um só adaptador de rede e instalar o servidor de local de rede no servidor de Acesso Remoto, a porta TCP 62000.

  Observação

  Esta exceção está no servidor do Acesso Remoto e todas as isenções anteriores estão no firewall de borda.

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

• Protocolo IP 50

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

• Tráfego ICMPv6 de entrada e saída (somente ao usar o Teredo).

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

• Para ISATAP: protocolo 41 de entrada e de 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

Existem três cenários que exigem certificados ao implantar apenas um servidor de Acesso Remoto.

• Autenticação IPsec: os requisitos de certificado para o IPsec incluem um certificado de computador usado pelos computadores cliente do DirectAccess ao estabelecerem a conexão IPsec com o servidor de Acesso Remoto e um certificado de computador usado pelos servidores de Acesso Remoto para estabelecer conexões IPsec com clientes do DirectAccess.

  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á por SSL, e o protocolo Kerberos usará o certificado configurado para IP-HTTPS. Alguns cenários empresariais (inclusive implantação em múltiplos sites e autenticação de cliente com senha única) exigem o uso da autenticação de certificado, e não da autenticação Kerberos.

• Servidor IP-HTTPS: quando você configurar o Acesso Remoto, o servidor de Acesso Remoto será configurado automaticamente para atuar como o ouvinte da Web IP-HTTPS. O site IP-HTTPS precisa de um certificado de site, e os computadores cliente também devem poder contatar o site da CRL (lista de certificados revogados) do certificado.

• Servidor de local de rede: o servidor de local de rede é um site usado para detectar se os computadores cliente estão localizados na rede corporativa. O servidor local da rede precisa de um certificado de site. Clientes do DirectAccess devem poder contatar o site da CRL para o certificado.

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

Autenticação IPsec	Servidor IP-HTTPS	Servidor de local da rede
Uma AC interna é necessária para emitir certificados de computador para o servidor e os clientes de Acesso Remoto para autenticação IPsec quando você não usa o protocolo Kerberos para autenticação.	AC interna: você pode usar uma AC interna para emitir o certificado IP-HTTPS, no entanto, verifique se o ponto de distribuição da CRL está disponível externamente.	AC interna: você pode usar uma AC interna para emitir o certificado do site do servidor de local de rede. Verifique se o ponto de distribuição de CRL está altamente disponível pela 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 da rede, mas não pode usar um certificado autoassinado em implantações com vários sites.
	AC pública: é recomendável usar uma AC pública para emitir o certificado IP-HTTPS; isso assegura 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 e os clientes do Acesso Remoto precisarão obter um certificado de computador. A maneira mais simples de instalar os certificados é usar uma Política 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 AC corporativa. Se você não tiver uma AC corporativa configurada na organização, consulte Serviços de Certificados do Active Directory.

Esse certificado possui os seguintes requisitos:

• O certificado deverá ter um EKU (uso estendido de chave) de autenticação do cliente.

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

Planejar certificados para IP-HTTPS

O servidor de Acesso Remoto age como um ouvinte do IP-HTTPS, e você deve instalar manualmente um certificado de site HTTPS no servidor. Leve em conta as seguintes considerações ao planejar:

• É recomendável usar uma AC pública, para que as CRLs estejam prontamente disponíveis.

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

• O nome comum do certificado deverá ser corresponder ao nome do site IP-HTTPS.

• No campo Uso Avançado de Chave, use o OID (identificador de objeto) da autenticação de servidor.

• No campo Pontos de Distribuição da Lista de Certificados Revogados, especifique um ponto de distribuição da CRL que seja acessível aos clientes do DirectAccess conectados à Internet.

  Observação

  Isso é necessário apenas 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.

• Os certificados IP-HTTPS podem ter curingas no nome.

Planejar certificados de site para o servidor de local da rede

Considere o seguinte ao planejar o site do servidor de local de rede:

• No campo Assunto, especifique o endereço IP da interface da intranet do servidor de local de rede do FQDN da URL de rede local.

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

• No campo Pontos de Distribuição da CRL, use um ponto de distribuição da CRL acessível pelos clientes DirectAccess conectados à intranet. Esse ponto de distribuição da CRL não deverá ser acessível de fora da rede interna.

Observação

Assegure-se de que os certificados IP-HTTPS e do servidor do local de rede tenham um nome da entidade. Se o certificado usar um nome alternativo, ele não será aceito pelo Assistente de Acesso Remoto.

Planejar os requisitos de DNS

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

Solicitações de cliente do DirectAccess

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

• Se a conexão for bem-sucedida, será determinado que os clientes estão 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. Clientes do DirectAccess usarão a NRPT (tabela de políticas de resolução de nomes) 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 realizar a resolução do nome, a NRPT é usada pelos clientes do 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 do DNs é agregado para criar um FQDN. Se a consulta DNS corresponder a uma entrada na NRPT, e DNS4 ou um servidor DNS de intranet for especificado para a entrada, a consulta será enviada para resolução de nome usando o servidor especificado. Se houver uma correspondência, mas nenhum servidor DNS tiver sido especificado, haverá uma regra de exceção e a resolução de nome normal será aplicada.

Quando um novo sufixo for adicionado à NRPT no console de Gerenciamento do Acesso Remoto, os servidores DNS padrão do sufixo poderão ser descobertos automaticamente clicando no botão Detectar. A detecção automática funciona da seguinte maneira:

• 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.

Servidores de infraestrutura

• Servidor de local de rede

  Os clientes DirectAccess tentam acessar o servidor de local de rede para determinar se estão em uma rede interna. Os clientes na rede interna precisam poder resolver o nome do servidor de local de rede e precisam ser impedidos de resolver o nome quando se encontrarem na Internet. Para garantir que isso ocorra, o FQDN do servidor do local de rede é adicionado, por padrão, a uma regra de exceção do NRPT. Quando você configurar o Acesso Remoto, as seguintes regras também serã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 correspondentes 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, é criada uma regra para o sufixo de DNS corp.contoso.com.

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

• Servidor IP-HTTPS

  O servidor de Acesso Remoto atua como um ouvinte do IP-HTTPS e usa o certificado do servidor para autenticar clientes IP-HTTPS. O nome IP-HTTPS precisa ser resolvível pelos clientes DirectAccess que usam servidores DNS públicos.

Verificadores de conectividade

O Acesso Remoto cria uma sonda da Web padrão usada pelos computadores cliente do DirectAccess para verificar a conectividade com a rede interna. Para garantir que a sonda funcione como esperado, os nomes a seguir devem ser registrados manualmente no DNS:

• directaccess-webprobehost deve ser resolvido para o endereço IPv4 interno do servidor de Acesso Remoto ou o endereço IPv6 em um ambiente somente com IPv6.

• directaccess-corpconnectivityhost deve ser resolvido para o endereço do host local (loopback). Você deve criar registros A e AAAA. O valor do registro A é 127.0.0.1 e o valor do registro AAAA é construído com base no prefixo NAT64 com os últimos 32 bits como 127.0.0.1. O prefixo NAT64 pode ser recuperando executando o cmdlet do Windows PowerShell Get-netnatTransitionConfiguration.

  Observação

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

Você pode criar verificadores de conectividade adicionais usando outros endereços da Web via HTTP ou PING. Uma entrada de DNS deverá existir para cada verificador de conectividade.

Requisitos de servidor DNS

• Para clientes DirectAccess, você precisa usar um servidor DNS executando o Windows Server 2012, o Windows Server 2008 R2, o Windows Server 2008, o Windows Server 2003 ou qualquer servidor DNS com suporte para IPv6.

• Use um servidor DNS com suporte para atualizações dinâmicas. Você pode usar servidores DNS sem suporte para atualizações dinâmicas, mas as entradas precisarão ser atualizadas manualmente.

• O FQDN para os pontos de distribuição da CRL precisa ser resolvível usando os 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 da CRL do certificado IP-HTTPS do servidor de Acesso Remoto, você precisará assegurar que o FQDN crl.contoso.com possa ser resolvido usando servidores DNS da Internet.

Planejar a resolução de nome local

Considere o seguinte ao planejar a resolução de nome local:

NRPT

Talvez seja necessário criar regras adicionais de NRPT (Tabela de Políticas de Resolução de Nomes) nas seguintes situações:

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

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

• Se você tiver um ambiente DNS com dupla personalidade, precisará adicionar regras de isenção para os nomes dos recursos cuja versão de Internet deve ser acessada pelos clientes do DirectAccess localizados na Internet, em vez da versão da intranet.

• Se você estiver redirecionando o tráfego para um site externo através dos servidores proxy Web, o site externo estará disponível somente na intranet. Ele usará os endereços dos servidores proxy 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 use seu servidor proxy 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 pelos servidores DNS da Internet, mas o servidor proxy Web da Contoso sabe como resolver o nome e como direcionar solicitações do site para o servidor Web externo. Para evitar que os usuários que não estiverem na intranet da Contoso acessem o site, o site externo permitirá solicitações somente do endereço da Internet IPv4 do proxy Web da Contoso. Portanto, os usuários da intranet podem acessar o site porque estão usando o proxy Web da Contoso, mas os usuários do DirectAccess não podem, pois não estão usando esse proxy. Com a configuração de uma regra de isenção de NRPT para test.contoso.com que usar o proxy Web da Contoso, as solicitações de página da Web para test.contoso.com serão roteadas para o servidor proxy Web da intranet na Internet IPv4.

Nomes de rótulo único

Nomes de rótulo únicos, 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 estiver configurada, os sufixos DNS na lista serão acrescentados ao nome de rótulo único. Por exemplo, quando um usuário em um computador que é membro do domínio corp.contoso.com digitar <https://paycheck> no navegador da Web, o FQDN construído como o nome será paycheck.corp.contoso.com. Por padrão, o sufixo agregado é baseado no sufixo DNS primário do computador cliente.

Observação

Em um cenário de namespace não contíguo (em que um ou mais computadores do domínio têm um sufixo DNS diferente do domínio do Active Directory do qual eles são membros), é necessário 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 Active Directory como o sufixo DNS primário do cliente. Certifique-se de adicionar o sufixo de DNS usado pelos clientes para a resolução de nome.

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

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

  Para saber mais, confira Gerenciando uma zona de pesquisa direta.

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

DNS com partição de rede

DNS com dupla personalidade se refere ao uso do mesmo domínio DNS para resolução de nomes da intranet e da Internet.

Para implantações de DNS com dupla personalidade, é necessário listar os FQDNs duplicados na Internet e na intranet, além de decidir quais recursos o cliente do DirectAccess deve acessar: a versão da intranet ou da Internet. Quando você deseja que os clientes DirectAccess acessem a versão da Internet, é necessário adicionar o FQDN correspondente como uma regra de isenção à NRPT de cada recurso.

Em um ambiente DNS de dupla personalidade, se você quiser que as duas versões do recurso estejam disponíveis, configure os recursos da intranet com nomes que não sejam duplicatas dos nomes usados na Internet. Em seguida, instrua os usuários a usarem 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 de DNS sem partição de rede, 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 da NRPT para corp.contoso.com roteia todas as consultas de nome DNS por recursos de intranet para servidores DNS da intranet. Consultas DNS por nomes com o sufixo contoso.com não correspondem à regra de namespace corp.contoso.com da intranet na NRPT e são enviadas aos servidores DNS da Internet. Com uma implantação de DNS com partição de rede, não é necessário fazer configurações adicionais na NRPT, pois não há duplicação dos FQDNs dos recursos da Internet e da intranet. Os clientes DirectAccess podem acessar os recursos da Internet e da intranet da organização.

Planejar o comportamento da resolução de nomes locais para clientes DirectAccess

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

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

• Suar a resolução de nomes locais se o nome não existir no DNS: esta opção é a mais segura, pois o cliente do DirectAccess executará a resolução de nomes locais somente para os nomes de servidor que não puderem 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 acessados ou se houver outros tipos de erros de DNS, não haverá uma perda dos nomes do servidor da intranet para a sub-rede por meio da resolução de nomes locais.

• Usar 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): esta opção é recomendada porque permite o uso da resolução de nomes locais em uma rede privada somente quando os servidores DNS da intranet estão inacessíveis.

• Usar a resolução de nomes locais para qualquer tipo de erro de resolução de 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 da rede é um site usado para detectar se os clientes DirectAccess encontram-se na rede corporativa. Clientes na rede corporativa não usam o DirectAccess para acessar recursos internos; eles se conectam diretamente.

O site do servidor de local de rede pode ser hospedado no servidor de Acesso Remoto ou em outro servidor da 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 executando um sistema operacional Windows, precisará garantir que o ISS (Serviços de Informações da Internet) esteja instalado neste servidor e que o site seja criado. O Acesso Remoto não define as configurações no servidor de local de rede.

Assegure-se de que o site do servidor de local de rede cumpra os seguintes requisitos:

• Tem um certificado do servidor HTTPS.

• Tem alta disponibilidade para computadores na rede interna.

• Não é acessível para computadores cliente do DirectAccess pela Internet.

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

• Os computadores cliente do DirectAccess devem confiar na AC que emitiu o certificado do servidor para o site do servidor do local de rede.

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

Planejar certificados para o servidor de local de rede

Ao obter o certificado do site para usar com o servidor de local de rede, considere o seguinte:

• No cmapo Assunto, especifique o endereço IP da interface da intranet do servidor de local de rede do FQDN da URL de rede local.

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

• O certificado do servidor de local de rede precisa ser verificado em relação a uma CRL (lista de certificados revogados). No campo Pontos de Distribuição da CRL, use um ponto de distribuição da CRL acessível pelos clientes DirectAccess conectados à intranet. Esse ponto de distribuição da CRL não deverá ser acessível de fora da rede interna.

Planejar o DNS para o servidor do local da rede

Os clientes DirectAccess tentam acessar o servidor de local de rede para determinar se estão em uma rede interna. Os clientes na rede interna devem poder resolver o nome do servidor de local de rede, mas não deverão resolver o nome quando se encontrarem na Internet. Para garantir que isso ocorra, o FQDN do servidor do local de rede é adicionado, por padrão, a uma regra de exceção da NRPT.

Planejar as configurações dos servidores de gerenciamento

Clientes DirectAccess iniciam comunicações com os servidores de gerenciamento que oferecem serviços como o Windows Update e atualizações de antivírus. Clientes DirectAccess também usam o protocolo Kerberos para autenticar nos controladores de domínio antes de acessarem a rede interna. Durante o gerenciamento dos clientes DirectAccess, os servidores de gerenciamento comunicam-se com os computadores cliente para realizar funções de gerenciamento como avaliações de inventário de software ou hardware. O Acesso Remoto pode descobrir alguns servidores de gerenciamento automaticamente, 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 detectados automaticamente na primeira fez que o DirectAccess é configurado. Os controladores de domínio detectados não são exibidos no console, mas as configurações podem ser recuperadas usando cmdlets do Windows PowerShell. Se os servidores do controlador de domínio ou do Configuration Manager forem modificados, clicar em Atualizar Servidores de Gerenciamento no console atualizará a lista de servidores de gerenciamento.

Requisitos do Management Server

• Os servidores de gerenciamento precisam ser acessíveis por meio do túnel da infraestrutura. Quando você configurar o Acesso Remoto, os servidores adicionados à lista de servidores de gerenciamento poderão ser automaticamente acessados por esse túnel.

• Os servidores de gerenciamento que iniciam conexões com os clientes DirectAccess precisam dar suporte completo a IPv6 com um endereço IPv6 nativo ou usando um endereço atribuído por ISATAP.

Planejar os requisitos do Active Directory

O Acesso Remoto usa o Active Directory da seguinte forma:

• Autenticação: o túnel da infraestrutura usa a autenticação NTLMv2 para a conta do computador que está se conectando ao servidor do Acesso Remoto, conta esta que deve estar em um domínio do Active Directory. O túnel da intranet usa a autenticação Kerberos para que o usuário crie o túnel da intranet.

• Objetos de Política de Grupo – a Acesso Remoto reúne as configurações em GPOs (Objetos de Política de Grupo), que são aplicados aos servidores, clientes e servidores de aplicativo interno do Acesso Remoto.

• Grupos de segurança: o Acesso Remoto usa grupos de segurança para coletar e identificar os computadores cliente do DirectAccess. Os GPOs são aplicados aos grupos de segurança necessários.

Ao planejar um ambiente do Active 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 (estando, portanto, acessível do adaptador de rede voltado para a Internet do servidor de Acesso Remoto), evite que o servidor de Acesso Remoto o acesse. Você precisa adicionar filtros de pacote no controlador de domínio para evitar 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 do 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.

Observação

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

Planejar autenticação de cliente

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

Autenticação Kerberos: quando você opta por usar credenciais do Active Directory para autenticação, o DirectAccess primeiro usa a autenticação Kerberos para o computador e, em seguida, usa a autenticação Kerberos para o usuário. Ao usar esse modo de autenticação, o DirectAccess usa um só túnel de segurança que fornece acesso ao servidor DNS, ao controlador de domínio e a outros servidores na rede interna.

Autenticação IPsec: quando você opta por usar a autenticação de dois fatores ou a Proteção de Acesso à Rede, o DirectAccess usa dois túneis de segurança. O Assistente de Instalação do Acesso Remoto configura regras de segurança de conexão no 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 as credenciais de certificado do computador para a primeira autenticação e credenciais do usuário (NTLMv2) para a segunda autenticação. As credenciais do usuário forçam o uso do AuthIP (protocolo Authenticated IP) e fornecem acesso a um servidor DNS e a um controlador de domínio antes que o cliente do DirectAccess possa usar credenciais Kerberos para o túnel da intranet.

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

Planejar múltiplos domínios

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

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

Quando possível, sufixos de nomes de domínio comuns devem ser adicionados à NRPT durante a implantação do Acesso Remoto. Por exemplo, se houvesse dois domínios, domain1.corp.contoso.com e domain2.corp.contoso.com, em vez de adicionar duas entradas na NRPT, você poderia adicionar uma entrada de sufixo de DNS comum, cujo sufixo de nome de domínio seria corp.contoso.com. Isso acontece automaticamente para domínios na mesma raiz. Domínios que não estão na mesma raiz precisam ser adicionados manualmente.

Planejar a criação do Objeto de Política de Grupo

Ao definir o Acesso Remoto, as configurações do DirectAccess são coletadas nos 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 do cliente, incluindo configurações de tecnologia de transição IPv6, entradas da NRPT e regras de segurança de conexão do Firewall do Windows com Segurança Avançada. O GPO é aplicado a grupos de segurança específicos para os computadores cliente.

• GPO do servidor do DirectAccess: este GPO contém as configurações do DirectAccess aplicadas a qualquer servidor configurado como um servidor de Acesso Remoto na implantação. Ele contém também as regras de segurança de conexão do Firewall do Windows com Segurança Avançada.

Observação

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

Você pode configurar GPOs automática ou manualmente.

Automaticamente: quando você especifica que os GPOs sejam criados automaticamente, um nome padrão é especificado para cada GPO.

Manualmente: usando GPOs predefinidos pelo administrador do Active Directory.

Ao configurar os GPOs, considere os seguintes avisos:

• Depois de o DirectAccess ser configurado para usar GPOs específicos, não poderá ser configurado para usar GPOs diferentes.

• Use o seguinte procedimento para fazer backup de todos os Objetos da Política de Grupo do Acesso Remoto antes de executar cmdlets do DirectAccess:

  Backup e restauração da configuração do Acesso Remoto.

• Seja em GPOs configurados automática ou manualmente, você precisará adicionar uma política para detecção de links lentos se os clientes usarem 3G. O caminho para Política: Configurar Política de Grupo de detecção de links lentos é:

  Configuração do Computador / Políticas / Modelos Administrativos / Sistema / Política de Grupo.

• Se as permissões corretas para vincular GPOs não existirem, um aviso será emitido. A operação do Acesso Remoto continuará, porém não ocorrerá a vinculação. Se o aviso for emitido, os links não serão criados automaticamente, mesmo se as permissões forem adicionadas posteriormente. Em vez disso, o administrador precisará criar os links manualmente.

GPOs criados automaticamente

Considere o seguinte ao usar GPOs criados automaticamente:

GPOs criados automaticamente são aplicados de acordo com o local e o destino do link, da seguinte maneira:

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

• Quando os GPOs do cliente e do servidor de aplicativos são criados, o local é definido como um único domínio. O nome do GPO é pesquisado em cada domínio e o domínio é preenchido nas configurações do DirectAccess, se houver.

• O destino do link é definido para 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 aplicativo, e o GPO é vinculado à raiz dos seus respectivos domínios.

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

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

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

• Permissões para vincular às raízes de domínio do GPO do 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 é obrigatória, mas é recomendada porque permite que o Acesso Remoto verifique se GPOs com nomes duplicados não existem quando os GPOs estão sendo criados.

GPOs criados manualmente

Leve em conta as seguintes considerações ao usar GPOs criados manualmente:

• Os GPOs devem existir antes de o Assistente de Instalação de Acesso Remoto ser executado.

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

• É feita uma pesquisa em busca de um link para o GPO em todo o domínio. Se o GPO não estiver vinculado ao domínio, um link é criado automaticamente na raiz do domínio. Se as permissões necessárias para criar o link não estiverem disponíveis, será emitido um aviso.

Recuperando 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: O GPO (nome do GPO) não pode ser encontrado.

Se um backup estiver disponível, você poderá usá-lo para restaurar o GPO. Se não houver um backup disponível, você precisará remover as definições de configuração e defini-las novamente.

Para remover definições de configuração

1. Execute o cmdlet Uninstall-RemoteAccess do Windows PowerShell.

2. Abra o Gerenciamento de Acesso Remoto.

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