Etapa 1: Planejar a infraestrutura avançada do DirectAccess

A primeira etapa do planejamento de uma implantação avançada do DirectAccess em um único servidor é planejar a infraestrutura necessária para a implantação. Este tópico descreve as etapas de planejamento de infraestrutura. Essas tarefas de planejamento não precisam ser concluídas em uma ordem específica.

1.1 Planejar topologia e configurações de rede

Esta secção explica como planear a sua rede, incluindo:

• 1.1.1 Planejar adaptadores de rede e endereçamento IP

• 1.1.2 Planejar a conectividade da intranet IPv6

• 1.1.3 Plano de tunelamento de força

1.1.1 Planejar adaptadores de rede e endereçamento IP

1. Identifique a topologia do adaptador de rede que você deseja usar. O DirectAccess pode ser configurado usando uma das seguintes topologias:

   • Dois adaptadores de rede. O servidor DirectAccess pode ser instalado na borda com um adaptador de rede conectado à Internet e o outro à rede interna, ou pode ser 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.

   • Um adaptador de rede. O servidor DirectAccess é 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 tecnologias de transição IPv6 para encapsular o tráfego IPv6 na Internet IPv4 (usando 6to4, Teredo ou IP-HTTPS) e na intranet somente IPv4 (usando 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 endereços necessários de acordo com a tabela a seguir. Para implantações que usam um único adaptador de rede e são configuradas atrás de um dispositivo NAT, configure seus endereços IP usando apenas a coluna Adaptador de rede interno .

   Description	Adaptador de rede externo	Adaptador de rede interno	Requisitos de roteamento
   Internet IPv4 e intranet IPv4	Configure dois endereços IPv4 públicos consecutivos estáticos com as máscaras de sub-rede apropriadas (necessário apenas para Teredo). Configure também o endereço IPv4 do gateway padrão do firewall da Internet ou do roteador do provedor de serviços de Internet (ISP) local. Observação: O servidor DirectAccess requer dois endereços IPv4 públicos consecutivos para que possa atuar como um servidor Teredo e os clientes baseados no Windows possam usar o servidor DirectAccess para detetar o tipo de dispositivo NAT que eles estão atrás.	Configure o seguinte: - Um endereço de intranet IPv4 com a máscara de sub-rede apropriada. - O sufixo DNS específico da conexão do namespace da intranet. Um servidor DNS também deve ser configurado na interface interna. Atenção: Não configure um gateway padrão em nenhuma interface de intranet.	Para configurar o servidor DirectAccess 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 o comando route add -p 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 DirectAccess.
   Internet IPv6 e intranet IPv6	Configure o seguinte: - Use a configuração de endereço que é fornecida pelo seu ISP. - Use o comando Route Print para garantir que existe uma rota IPv6 padrão e que está apontando 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 descritas na RFC 4191 e 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 router ISP garante que a rota IPv6 predefinida ativa do servidor DirectAccess aponte para a Internet IPv6. Como o servidor DirectAccess é 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 voltada para a Internet do servidor DirectAccess.	Configure o seguinte: - Se você não estiver usando os níveis de preferência padrão, você pode configurar suas interfaces de intranet usando o seguinte comandonetsh interface ipv6 set InterfaceIndex ignoredefaultroutes=enabled. 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 índice de interface de suas interfaces de intranet usando o seguinte comando: netsh interface ipv6 show interface.	Se você tiver uma intranet IPv6, para configurar o servidor DirectAccess 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 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 DirectAccess.
   Internet IPv4 e intranet IPv6	O servidor DirectAccess encaminha o tráfego da rota IPv6 padrão através do adaptador Microsoft 6to4 para um relé 6to4 na Internet IPv4. Você pode configurar um servidor DirectAccess para o endereço IPv4 do adaptador Microsoft 6to4 usando o seguinte comando: 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 transição 6to4 para se conectar à intranet. Se lhe for atribuído 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 DirectAccess tiver apenas um adaptador de rede.
   • Os computadores cliente IPv6 nativos podem se conectar ao servidor DirectAccess por IPv6 nativo e nenhuma tecnologia de transição é necessária.

1.1.2 Planejar a conectividade da intranet IPv6

Para gerenciar clientes DirectAccess remotos, o IPv6 é necessário. O IPv6 permite que os servidores de gerenciamento DirectAccess se conectem a clientes DirectAccess localizados na Internet para fins de gerenciamento remoto.

1.1.3 Plano de tunelamento de força

Com o IPv6 e a NRPT (Name Resolution Policy Table), por padrão, os clientes DirectAccess separam o tráfego da intranet e da Internet da seguinte maneira:

• As consultas de nomes DNS para FQDNs (nomes de domínio totalmente qualificados) da intranet, bem como todo o tráfego, são trocados através dos túneis criados com o servidor DirectAccess ou diretamente com os servidores da intranet. O tráfego da intranet dos clientes DirectAccess é o tráfego IPv6.

• As consultas de nome DNS para FQDNs que correspondem a regras de isenção ou não correspondem ao namespace da intranet e todo o tráfego para servidores da Internet são trocadas pela interface física conectada à Internet. O tráfego da Internet dos clientes DirectAccess é normalmente tráfego IPv4.

Por outro lado, por padrão, algumas implementações de rede virtual privada (VPN) de acesso remoto, incluindo o cliente VPN, enviam todo o tráfego da intranet e da Internet pela conexão VPN de acesso remoto. O tráfego ligado à Internet é roteado pelo servidor VPN para servidores proxy Web IPv4 da intranet para acesso aos recursos IPv4 da Internet. É possível separar o tráfego da intranet e da Internet para clientes VPN de acesso remoto usando o túnel dividido. Isso envolve a configuração da tabela de roteamento IP (Internet Protocol) em clientes VPN para que o tráfego para locais da intranet seja enviado pela conexão VPN e o tráfego para todos os outros locais seja enviado usando a interface física conectada à Internet.

Você pode configurar os clientes DirectAccess para enviar todo o tráfego através dos túneis para o servidor DirectAccess com tunelamento forçado. Quando o túnel de força é configurado, os clientes DirectAccess detetam que estão na Internet e removem sua rota padrão IPv4. Com exceção do tráfego de sub-rede local, todo o tráfego enviado pelo cliente DirectAccess é tráfego IPv6 que passa por túneis para o servidor DirectAccess.

Habilitar o tunelamento de força tem as seguintes consequências:

• Os clientes DirectAccess utilizam apenas o Protocolo Internet sobre o Protocolo de Transferência de Hipertexto Seguro (IP-HTTPS) para obter conectividade IPv6 com o servidor DirectAccess através da Internet IPv4.

• Os únicos locais que um cliente DirectAccess pode alcançar por padrão com tráfego IPv4 são aqueles em sua sub-rede local. Todo o outro tráfego enviado por aplicativos e serviços em execução no cliente DirectAccess é tráfego IPv6, que é enviado pela conexão DirectAccess. Portanto, os aplicativos somente IPv4 no cliente DirectAccess não podem ser usados para acessar recursos da Internet, exceto aqueles na sub-rede local.

1.2 Planejar requisitos de firewall

Se o servidor DirectAccess 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 DirectAccess estiver na Internet IPv4:

• Teredo traffic - Protocolo de Datagrama de Utilizador (UDP), porta de destino 3544 de entrada e porta de origem 3544 de saída.

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

• Porta de destino do Protocolo de Controlo IP-HTTPS-Transmission (TCP) porta 443 e porta de origem TCP 443 para saída.

• Se você estiver implantando o Acesso Remoto com um único adaptador de rede e instalando o servidor de local de rede no servidor DirectAccess, a porta TCP 62000 também deverá ser isenta.

  Note

  Essa isenção está no servidor DirectAccess e todas as outras isenções estão no firewall de borda.

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 DirectAccess. Para IP-HTTPS, as exceções precisam ser aplicadas no endereço registrado no servidor DNS público.

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

• ID do Protocolo IP 50

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

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

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

• ISATAP-Protocol 41 entrada e saída

• TCP/UDP para todo o tráfego IPv4 e IPv6

• ICMP para todo o tráfego IPv4 e IPv6 (ao usar somente Teredo)

1.3 Planejar requisitos de certificado

Há três cenários que exigem certificados quando você implanta um único servidor DirectAccess:

• Etapa 1: Planejar a infraestrutura avançada do DirectAccess
  • 1.1 Planejar topologia e configurações de rede
    • 1.1.1 Planejar adaptadores de rede e endereçamento IP
    • 1.1.2 Planejar a conectividade da intranet IPv6
    • 1.1.3 Plano de tunelamento de força
  • 1.2 Planejar requisitos de firewall
  • 1.3 Planejar requisitos de certificado
    • 1.3.1 Planejar certificados de computador para autenticação IPsec
    • 1.3.2 Planejar certificados para IP-HTTPS
    • 1.3.3 Planear certificados de websites para o servidor de localização de rede
  • 1.4 Planejar requisitos de DNS
    • 1.4.1 Planejar os requisitos do servidor DNS
    • 1.4.2 Planear a resolução de nomes locais
  • 1.5 Planear o servidor de localização de rede
    • 1.5.1 Planejar certificados para o servidor de local de rede
    • 1.5.2 Planeie o DNS para o servidor de localização da rede
  • 1.6 Planejar servidores de gerenciamento
  • 1.7 Planear os Serviços de Domínio do Active Directory
    • 1.7.1 Planejar a autenticação do cliente
    • 1.7.2 Planejar vários domínios
  • 1.8 Planejar objetos de diretiva de grupo
    • 1.8.1 Configurar GPOs criados automaticamente
    • 1.8.2 Configurar GPOs criados manualmente
    • 1.8.3 Gerenciar GPOs em um ambiente de controlador de vários domínios
    • 1.8.4 Gerenciar GPOs de Acesso Remoto com permissões limitadas
    • 1.8.5 Recuperar de um GPO excluído
  • Próximos passos

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

1.3.1 Planejar certificados de computador para autenticação IPsec

Se você estiver usando a autenticação IPsec baseada em certificado, o servidor DirectAccess e os clientes deverão obter um certificado de computador. A maneira mais simples de instalar os certificados é configurar o registro automático baseado em Diretiva de Grupo 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 avançado de chave (EKU) de Autenticação de Cliente.

• O certificado do cliente e o certificado do servidor devem ser encadeados para o mesmo certificado raiz. Esse certificado raiz deve ser selecionado nas definições de configuração do DirectAccess.

1.3.2 Planejar certificados para IP-HTTPS

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

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

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

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

• Para o campo Uso Avançado de Chaves, 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.

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

Se você planeja usar IP-HTTPS em uma porta não padrão, execute as seguintes etapas no servidor DirectAccess:

1. Remova a vinculação de certificado existente para 0.0.0.0:443 e substitua-a por uma vinculação de certificado para a porta escolhida. Para fins deste exemplo, a porta 44500 é usada. Antes de excluir a vinculação do certificado, mostre e copie o appid.

   1. Para excluir a vinculação de certificado, digite:

      netsh http delete ssl ipport=0.0.0.0:443
      

   2. Para adicionar a nova vinculação de certificado, digite:

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

2. Para modificar o URL do IP-HTTPS no servidor, digite:

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

   Net stop iphlpsvc & net start iphlpsvc
   

3. Altere a reserva de URL para kdcproxy.

   1. Para excluir a reserva de URL existente, digite:

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

   2. Para adicionar uma nova reserva de URL, digite:

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

4. Adicione a configuração para fazer kppsvc ouvir na porta não padrão. Para adicionar a entrada do Registro, digite:

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

5. Para reiniciar o serviço kdcproxy no controlador de domínio, digite:

   net stop kpssvc & net start kpssvc
   

Para usar IP-HTTPS em uma porta não padrão, execute as seguintes etapas no controlador de domínio:

1. Modifique a configuração IP-HTTPS no GPO do cliente.

   1. Abra o editor de Diretiva de Grupo.

   2. Navegue até Configuração do computador=>Políticas=>Modelos administrativos=> Rede=>Configurações TCPIP =>Tecnologias de transição IPv6.

   3. Abra a configuração de estado IP-HTTPS e altere a URL para https://< nome do servidor DirectAccess (por exemplo, server.contoso.com)>:44500/IPHTTPS.

   4. Clique em Aplicar.

2. Modifique as configurações do cliente proxy Kerberos no GPO do cliente.

   1. No editor de Diretiva de Grupo, navegue até Configuração do computador=>Políticas=>Modelos Administrativos=> Sistema=>Kerberos => Especifique os servidores proxy KDC para clientes Kerberos.

   2. Abra a configuração de estado IPHTTPS e altere a URL para https://< nome do servidor DirectAccess (por exemplo, server.contoso.com)>:44500/IPHTTPS.

   3. Clique em Aplicar.

3. Modifique as configurações de diretiva IPsec do cliente para usar ComputerKerb e UserKerb.

   1. No editor de Diretiva de Grupo, navegue até Configuração do computador=>Políticas=> Configurações do Windows=> Configurações de segurança=> Firewall do Windows com segurança avançada.

   2. Clique em Regras de segurança de conexão e, em seguida, clique duas vezes em Regra IPsec.

   3. Na guia Autenticação , clique em Avançado.

   4. Para Auth1: remova o método de autenticação existente e substitua-o por ComputerKerb. Para Auth2: remova o método de autenticação existente e substitua-o por UserKerb.

   5. Clique em Aplicar e, em seguida, em OK.

Para concluir o processo manual de uso de uma porta IP-HTTPS não padrão, execute gpupdate /force nos computadores cliente e no servidor DirectAccess.

1.3.3 Planejar certificados de site para o servidor de local de rede

Ao planejar o site do servidor de local de rede, considere o seguinte:

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

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

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

• Se, posteriormente, você estiver planejando configurar uma implantação multissite ou de cluster, o nome do certificado não deverá corresponder ao nome interno de nenhum servidor DirectAccess que será adicionado à implantação.

  Note

  Verifique se os certificados para IP-HTTPS e o servidor de local de rede têm um Nome do Assunto. Se o certificado não tiver um Nome da Entidade, mas tiver um Nome Alternativo, não será aceite pelo Assistente de Acesso Remoto.

1.4 Planejar requisitos de DNS

Esta seção explica os requisitos de DNS para solicitações de cliente DirectAccess e servidores de infraestrutura em uma implantação de Acesso Remoto. Inclui as seguintes subsecções:

• 1.4.1 Planejar os requisitos do servidor DNS

• 1.4.2 Planear a resolução de nomes locais

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 (ou corporativa). Os clientes DirectAccess tentam se conectar ao servidor de local de rede DirectAccess para determinar se estão localizados na Internet ou na rede interna.

• Se a conexão for bem-sucedida, os clientes serão identificados como localizados na rede interna, 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 localizados na Internet e os clientes 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 usem 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 DNS64 ou um servidor DNS na rede interna for especificado para a entrada, a consulta será enviada para resolução de nomes usando o servidor especificado. Se existir uma correspondência, mas nenhum servidor DNS for especificado, isso indica uma regra de isenção e a resolução normal de nomes é aplicada.

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

• 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 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. 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 DirectAccess e os endereços IPv6 que correspondem ao endereço DNS64. Em redes corporativas somente IPv6, os servidores DNS da intranet são configurados no servidor DirectAccess. Por exemplo, se o servidor DirectAccess 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 servidor

  O servidor DirectAccess 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 estejam usando servidores DNS públicos.

• Verificação da revogação de CRL

  O DirectAccess usa a verificação de revogação de certificados para a conexão IP-HTTPS entre clientes DirectAccess e o servidor DirectAccess e para a conexão baseada em HTTPS entre o cliente DirectAccess e o servidor de local de rede. Em ambos os casos, os clientes DirectAccess devem ser capazes de resolver e acessar o local do ponto de distribuição da CRL.

• ISATAP

  O ISATAP permite que computadores corporativos adquiram um endereço IPv6 e encapsula pacotes IPv6 em um cabeçalho IPv4. Ele é usado pelo servidor DirectAccess para fornecer conectividade IPv6 para hosts ISATAP em uma intranet. Em um ambiente de rede IPv6 não nativo, o servidor DirectAccess se configura automaticamente como um roteador ISATAP.

  Como o ISATAP não é mais suportado no DirectAccess, você deve garantir que seus servidores DNS estejam configurados para não responder às consultas ISATAP. Por predefinição, o serviço Servidor DNS bloqueia a resolução de nomes para o nome ISATAP através da Lista de Bloqueios de Consultas Globais de DNS. Não remova o nome ISATAP da Lista de Bloqueios de Consulta Global.

• Verificadores de conectividade

  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-Deve ser resolvido para o endereço IPv4 interno do servidor DirectAccess ou para o endereço IPv6 em um ambiente somente IPv6.

  • directaccess-corpconnectivityhost-Deve resolver para o endereço do host local (loopback). Os seguintes registros de recursos de host (A) e (AAAA) devem ser criados: um registro de recurso de host (A) com valor 127.0.0.1 e um registro de recurso de host (AAAA) com valor construído a partir do prefixo NAT64 com os últimos 32 bits como 127.0.0.1. O prefixo NAT64 pode ser recuperado executando o comando get-netnattransitionconfiguration do Windows PowerShell.

    Note

    Isso é válido somente em um ambiente somente IPv4. Num ambiente IPv4 e IPv6, ou num ambiente apenas IPv6, apenas um registo de recurso de anfitrião (AAAA) deve ser criado 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.

1.4.1 Planejar os requisitos do servidor DNS

A seguir estão os requisitos para DNS quando você implanta o DirectAccess.

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

  Note

  Não é recomendável usar servidores DNS que estejam executando o Windows Server 2003 ao implantar o DirectAccess. Embora os servidores DNS do Windows Server 2003 ofereçam suporte a registros IPv6, o Windows Server 2003 não é mais suportado pela Microsoft. Além disso, você não deve implantar o DirectAccess se os controladores de domínio estiverem executando o Windows Server 2003 devido a um problema com o Serviço de Replicação de Arquivos. Para obter mais informações, consulte Configurações sem suporte do DirectAccess.

• Use 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 deve atualizar manualmente as entradas nesses servidores.

• O FQDN para seus pontos de distribuição de CRL acessíveis pela Internet deve ser resolúvel 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 DirectAccess, você deverá garantir que o crld.contoso.com FQDN possa ser resolvido usando servidores DNS da Internet.

1.4.2 Planejar a resolução de nomes locais

Ao planejar a resolução de nomes locais, considere os seguintes problemas:

NRPT

Poderá ter de criar regras NRPT adicionais nos seguintes casos:

• Se você precisar adicionar mais sufixos DNS para seu namespace da intranet.

• Se o nome de domínio totalmente qualificado (FQDN) dos pontos de distribuição da CRL for baseado 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 e usará os endereços dos servidores proxy da Web para permitir as solicitações de entrada. Nesse caso, adicione uma regra de isenção para o FQDN do site externo e especifique que a regra use seu servidor proxy da Web da intranet em vez dos endereços IPv6 dos servidores DNS da intranet.

  Por exemplo, se você estiver testando um site externo chamado test.contoso.com, esse nome não poderá ser resolvido por meio de servidores DNS da Internet, mas o servidor proxy da Web da Contoso saberá como resolver o nome e 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 acessá-lo 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 de rótulo único

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.

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:

• Implante 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 WINS que está usando apenas computername. O cliente pensa que está a emitir um registo de recurso de host DNS (A) regular, mas na realidade trata-se de um pedido NetBIOS. Para obter mais informações, consulte Gerenciando uma zona de pesquisa direta.

• Adicione um sufixo DNS, como dns.zone1.corp.contoso.com, à diretiva de domínio padrão do GPO.

Split-brain DNS

O conceito de 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. Para cada nome que corresponde a um recurso para o qual você deseja que os clientes DirectAccess alcancem a versão da Internet, você deve adicionar o FQDN correspondente como uma regra de isenção à NRPT para seus clientes DirectAccess.

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 alternativos, que não sejam duplicados dos nomes usados na Internet, e instrua os usuários a usar o nome alternativo quando estiverem na Intranet. Por exemplo, configure o nome www.internal.contoso.com alternativo para o nome www.contoso.cominterno .

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 de nomes 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 a organização.

Comportamento de resolução de nomes locais para clientes do DirectAccess

Se um nome não puder ser resolvido com o DNS, para resolver o nome na sub-rede local, o serviço Cliente DNS no Windows Server 2012 R2 , Windows Server 2012 , Windows Server 2008 R2 , Windows 8 e Windows 7 pode usar a resolução de nome local, com os protocolos LLMNR (Link-Local Multicast Name Resolution) e NetBIOS sobre TCP/IP.

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 locais para nomes de servidores de intranet e o computador está conectado a uma sub-rede compartilhada na Internet, usuários mal-intencionados podem capturar mensagens LLMNR e NetBIOS sobre TCP/IP para determinar nomes de servidores de intranet. Na página DNS do Assistente de Configuração do Servidor de Infraestrutura, você configura 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:

• Use a resolução de nome local se o nome não existir no DNS. Esta opção é a mais segura porque o cliente DirectAccess executa a resolução de nomes locais apenas 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 estão inacessíveis.

• Use a resolução de nome local 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 através da resolução de nomes locais.

1.5 Planear o servidor de localização 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 DirectAccess ou em outro servidor em sua organização. Se você hospedar o servidor de local de rede no servidor DirectAccess, o site será criado automaticamente quando você instalar a função de servidor Acesso Remoto. Se você hospedar o servidor de local de rede em outro servidor em sua organização executando um sistema operacional Windows, deverá certificar-se de que o IIS (Serviços de Informações da Internet) está instalado nesse servidor e se o site foi criado. O DirectAccess não define configurações em um servidor de local de rede remoto.

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

• É um site com um certificado de servidor HTTPS.

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

• O site do servidor de localização de rede deve ter alta disponibilidade para computadores na rede interna.

• O servidor de local de rede não deve estar acessível a computadores cliente DirectAccess na Internet.

• O certificado do servidor deve ser verificado em relação a uma CRL.

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

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

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

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

3. No 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.

1.5.2 Planejar o DNS para o servidor de local 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.

1.6 Planejar servidores de gerenciamento

Os clientes DirectAccess iniciam comunicações 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 entrar em contato com controladores de domínio para autenticação 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 deteção automática de controladores de domínio é realizada para todos os domínios na mesma floresta que os servidores DirectAccess e os computadores cliente.

• Servidores do Microsoft Endpoint Configuration Manager - A descoberta automática de servidores do Configuration Manager é executada para todos os domínios na mesma floresta que o servidor DirectAccess e os computadores cliente.

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 o cmdlet do Windows PowerShell Get-DAMgmtServer -Type Todos. Se o controlador de domínio ou os servidores do Configuration Manager forem modificados, clicar em Atualizar Servidores de Gerenciamento no console de Gerenciamento de Acesso Remoto atualizará a lista de servidores de gerenciamento.

Requisitos do servidor de gerenciamento

• Os servidores de gerenciamento devem estar acessíveis pelo primeiro túnel (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 atribuído pelo ISATAP.

1.7 Planejar os Serviços de Domínio Ative Directory

Esta seção explica como o DirectAccess usa os Serviços de Domínio Ative Directory (AD DS) e inclui as seguintes subseções:

• 1.7.1 Planejar a autenticação do cliente

• 1.7.2 Planejar vários domínios

O DirectAccess usa o AD DS e os GPOs (Objetos de Política de Grupo) do Ative Directory da seguinte maneira:

• Authentication

  O AD DS é usado para autenticação. O túnel de infraestrutura usa a autenticação NTLMv2 para a conta de computador que está se conectando ao servidor DirectAccess e a conta deve estar listada em um domínio do Ative Directory. O túnel da intranet usa a autenticação Kerberos para o usuário criar o segundo túnel.

• Objetos de Diretiva de Grupo

  O DirectAccess reúne definições de configuração em GPOs que são aplicadas a servidores, clientes e servidores de aplicativos internos do DirectAccess.

• Grupos de segurança

  O DirectAccess usa grupos de segurança para reunir e identificar computadores cliente DirectAccess. Os GPOs são aplicados ao grupo de segurança exigido.

• Políticas IPsec estendidas

  O DirectAccess pode usar autenticação e criptografia IPsec entre clientes e o servidor DirectAccess. Você pode estender a autenticação e a criptografia IPsec do cliente para os servidores de aplicativos internos especificados. Para fazer isso, adicione os servidores de aplicativos necessários em um grupo de segurança.

Requisitos do AD DS

Ao planejar o AD DS para uma implantação do DirectAccess, considere os seguintes requisitos:

• Pelo menos um controlador de domínio deve ser instalado com o sistema operacional Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2 ou Windows Server 2008.

  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 DirectAccess), você deverá impedir que o servidor DirectAccess o alcance adicionando filtros de pacotes no controlador de domínio para impedir a conectividade com o endereço IP do adaptador de Internet.

• O servidor DirectAccess deve ser um membro do domínio.

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

  • Qualquer domínio que esteja na mesma floresta que o servidor DirectAccess.

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

  • Qualquer domínio em uma floresta que tenha uma relação de confiança bidirecional com a floresta à qual o domínio do DirectAccess pertence.

1.7.1 Planejar a autenticação do cliente

O DirectAccess permite que você escolha entre usar certificados para autenticação de computador IPsec ou usar um proxy Kerberos interno que autentica usando nomes de usuário e senhas.

Ao optar por usar as credenciais do AD DS para autenticação, o DirectAccess utiliza um túnel de segurança que emprega Kerberos de Máquina para a primeira autenticação e Kerberos de Utilizador para a segunda autenticação. Ao usar esse modo para 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 outros servidores na rede interna.

Ao optar 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 Configuração de Acesso Remoto configura as regras de segurança de conexão do Firewall do Windows com Segurança Avançada que especificam o uso dos seguintes tipos de credenciais ao negociar as associações de segurança IPsec para os túneis para o servidor DirectAccess:

• O túnel de infraestrutura usa as credenciais Kerberos de computador para a primeira autenticação e as credenciais de usuário Kerberos para a segunda autenticação.

• O túnel da intranet utiliza credenciais de certificado de computador para a primeira autenticação e o Kerberos do utilizador para a segunda autenticação.

Quando o DirectAccess opta por permitir o acesso a clientes que executam o Windows 7 ou em uma implantação multissite, ele usa dois túneis de segurança. O Assistente de Configuração de Acesso Remoto configura as regras de segurança de conexão do Firewall do Windows com Segurança Avançada que especificam o uso dos seguintes tipos de credenciais ao negociar as associações de segurança IPsec para os túneis para o servidor DirectAccess:

• O túnel de infraestrutura usa credenciais de certificado de computador para a primeira autenticação e NTLMv2 para a segunda autenticação. As credenciais NTLMv2 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 utiliza credenciais de certificado de computador para a primeira autenticação e o Kerberos do utilizador para a segunda autenticação.

1.7.2 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. Isso é feito automaticamente se os domínios estiverem na mesma floresta.

Sempre que possível, sufixos comuns de nome de domínio devem ser adicionados à NRPT (Tabela de Políticas de Resolução de Nomes) 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, mas os domínios que não estão na mesma raiz devem ser adicionados manualmente.

Se o WINS (Windows Internet Name Service) for implantado em um ambiente de vários domínios, você deverá implantar uma zona de pesquisa direta do WINS no DNS. Para obter mais informações, consulte Nomes de rótulo único na seção 1.4.2 Planejar a resolução de nomes locais anteriormente neste documento.

1.8 Planejar objetos de diretiva de grupo

Esta seção explica a função dos GPOs (Objetos de Diretiva de Grupo) em sua infraestrutura de Acesso Remoto e inclui as seguintes subseções:

• 1.8.1 Configurar GPOs criados automaticamente

• 1.8.2 Configurar GPOs criados manualmente

• 1.8.3 Gerenciar GPOs em um ambiente de controlador de vários domínios

• 1.8.4 Gerenciar GPOs de Acesso Remoto com permissões limitadas

• 1.8.5 Recuperar de um GPO excluído

As configurações do DirectAccess definidas quando você configura o Acesso Remoto são coletadas em GPOs. Os seguintes tipos de GPOs são preenchidos com configurações do DirectAccess e 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 do 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 configurado como um servidor DirectAccess em sua implantação. Ele também contém regras de segurança de conexão do Firewall do Windows com Segurança Avançada.

• GPO de servidores de aplicações

  Esse GPO contém configurações para servidores de aplicativos selecionados aos quais você opcionalmente estende a autenticação e a criptografia de clientes DirectAccess. Se a autenticação e a criptografia não forem estendidas, esse GPO não será usado.

Os GPOs podem ser configurados de duas maneiras:

• Automaticamente-Você pode especificar que eles são criados automaticamente. Um nome padrão é especificado para cada GPO.

• Manualmente-Você pode usar GPOs que foram predefinidos pelo administrador do Ative Directory.

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 redes 3G. O caminho para Política: Configurar a deteção de link lento da Diretiva de Grupo é: Configuração do computador/Políticas/Modelos administrativos/Sistema/Diretiva de grupo.

Se as permissões corretas (listadas nas seções a seguir) 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 quando as permissões forem adicionadas posteriormente. Em vez disso, o administrador precisa criar os links manualmente.

1.8.1 Configurar GPOs criados automaticamente

Considere o seguinte ao usar GPOs criados automaticamente.

Os GPOs criados automaticamente são aplicados de acordo com o parâmetro de destino de local e link, da seguinte maneira:

• Para o GPO do servidor DirectAccess, o parâmetro location e o parâmetro link apontam para o domínio que contém o servidor DirectAccess.

• Quando GPOs de cliente e servidor de aplicativos são criados, o local é definido como um único domínio no qual o GPO será criado. O nome do GPO é pesquisado em cada domínio e preenchido com as definições do DirectAccess, caso exista. 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.

Quando você usa GPOs criados automaticamente para aplicar as configurações do DirectAccess, o administrador de Acesso Remoto requer as seguintes permissões:

• GPO criar permissões para cada domínio

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

• Permissões de ligação para as raízes de domínios do GPO do servidor

Além disso, as seguintes permissões são necessárias:

• Para os GPOs, são necessárias as permissões de segurança de Criar, Editar, Excluir e Modificar.

• Recomendamos que o administrador de Acesso Remoto tenha permissões de Leitura de GPO para cada domínio necessário. Esta funcionalidade permite que o Acesso Remoto verifique se não existem GPOs com nomes duplicados quando se criam GPOs.

1.8.2 Configurar 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 de Acesso Remoto requer permissões completas de GPO (Editar, Excluir, Modificar permissões de segurança) nos GPOs criados manualmente.

• É feita uma busca em todo o domínio para encontrar um link para o GPO. 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.

1.8.3 Gerenciar GPOs em um ambiente de controlador de vários domínios

Cada GPO é gerenciado por um controlador de domínio específico, da seguinte maneira:

• O GPO do servidor é gerenciado por um dos controladores de domínio no site do Ative Directory associado ao servidor. Se os controladores de domínio nesse site forem somente leitura, o GPO do servidor será gerido pelo controlador de domínio com capacidade de escrita mais próximo do servidor DirectAccess.

• Os GPOs do cliente e do servidor de aplicações são geridos pelo controlador de domínio que está a funcionar como controlador de domínio primário (PDC).

Se quiser modificar manualmente as configurações de GPO, considere o seguinte:

• Para o GPO do servidor, para identificar qual controlador de domínio está associado ao servidor DirectAccess, em um prompt de comando elevado no servidor DirectAccess, execute nltest /dsgetdc: /writable.

• Por padrão, quando se fazem alterações com cmdlets de rede do Windows PowerShell ou se fazem alterações no console de Gestão de Políticas de Grupo, é utilizado o controlador de domínio que está a agir como o PDC (controlador de domínio primário).

Além disso, se você modificar as configurações em um controlador de domínio que não seja o controlador de domínio associado ao servidor DirectAccess (para o GPO do servidor) ou ao PDC (para GPOs do cliente e do servidor de aplicativos), considere o seguinte:

• Antes de modificar as configurações, verifique se o controlador de domínio está replicado com um GPO de data up-toe efetue uma cópia de segurança das configurações do GPO. Para obter mais informações, consulte Fazer backup e restaurar a configuração de acesso remoto. Se o GPO não for atualizado, poderão ocorrer conflitos de mesclagem durante a replicação, o que pode resultar em uma configuração de Acesso Remoto corrompida.

• Depois de modificar as configurações, você deve aguardar a replicação das alterações para os controladores de domínio associados aos GPOs. Não faça alterações adicionais com o uso do console de Gestão de Acesso Remoto ou dos cmdlets de PowerShell de Acesso Remoto até que a replicação esteja concluída. Se um GPO for editado em dois controladores de domínio antes da conclusão da replicação, poderão ocorrer conflitos de mesclagem, o que pode resultar em uma configuração de Acesso Remoto corrompida.

Como alternativa, você pode alterar a configuração padrão usando a caixa de diálogo Alterar Controlador de Domínio no console de Gerenciamento de Diretiva de Grupo ou usando o cmdlet Open-NetGPO do Windows PowerShell, para que as alterações usem o controlador de domínio especificado.

• Para fazer isso no console de Gerenciamento de Diretiva de Grupo, clique com o botão direito do mouse no contêiner de domínio ou sites e clique em Alterar Controlador de Domínio.

• Para fazer isso no Windows PowerShell, especifique o parâmetro DomainController para o cmdlet Open-NetGPO . Por exemplo, para habilitar os perfis privados e públicos no Firewall do Windows em um GPO chamado domínio1\DA_Server_GPO _Europe usando um controlador de domínio chamado europe-dc.corp.contoso.com, digite o seguinte:

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

1.8.4 Gerenciar GPOs de Acesso Remoto com permissões limitadas

Para gerenciar uma implantação de Acesso Remoto, o administrador de Acesso Remoto requer permissões completas de GPO (permissões de Leitura, Edição, Exclusão e Modificação de segurança) nos GPOs usados na implantação. Isso ocorre porque o console de Gerenciamento de Acesso Remoto e os módulos do PowerShell de Acesso Remoto leem a configuração e a gravam nos GPOs de Acesso Remoto (ou seja, GPOs de cliente, servidor e servidor de aplicativos).

Em muitas organizações, o administrador de domínio responsável pelas operações de GPO não é a mesma pessoa que o administrador de Acesso Remoto responsável pela configuração do Acesso Remoto. Essas organizações podem ter políticas que restringem o administrador de Acesso Remoto de ter permissões totais em GPOs no domínio. O administrador do domínio também pode ser obrigado a revisar a configuração da diretiva antes de aplicá-la a qualquer computador no domínio.

Para acomodar esses requisitos, o administrador do domínio deve criar duas cópias de cada GPO: preparo e produção. O administrador de Acesso Remoto recebe permissões totais nos GPOs de preparação. O administrador de Acesso Remoto especifica os GPOs de preparo no console de Gestão de Acesso Remoto e nos cmdlets do Windows PowerShell, como sendo os GPOs utilizados para a implementação do Acesso Remoto. Isso permite que o administrador de Acesso Remoto leia e modifique a configuração de Acesso Remoto como e quando necessário.

O administrador de domínio deve certificar-se de que os GPOs de preparo não estão vinculados a nenhum escopo de gerenciamento no domínio e que o administrador de Acesso Remoto não tem permissões de link de GPO no domínio. Isso garante que as alterações feitas pelo administrador de Acesso Remoto nos GPOs de preparação não tenham qualquer efeito nos computadores do domínio.

O administrador de domínio vincula os GPOs de produção ao escopo de gerenciamento necessário e aplica a filtragem de segurança apropriada. Isso garante que as alterações nesses GPOs sejam aplicadas aos computadores no domínio (computadores cliente, servidores DirectAccess e servidores de aplicativos). O administrador de Acesso Remoto não tem permissões nos GPOs de produção.

Quando são feitas alterações nos GPOs de teste, o administrador do domínio pode revisar a configuração de políticas nesses GPOs para garantir que ela atenda aos requisitos de segurança da organização. Em seguida, o administrador do domínio exporta as configurações dos GPOs de preparo usando o recurso de backup e importa as configurações para os GPOs de produção correspondentes, que serão aplicados aos computadores no domínio.

O diagrama a seguir mostra essa configuração.

1.8.5 Recuperar de um GPO eliminado

Se um cliente, servidor DirectAccess ou GPO do servidor de aplicativos tiver sido excluído acidentalmente e não houver backup disponível, você deverá remover as definições de configuração e reconfigurá-las. Se um backup estiver disponível, você poderá restaurar o GPO a partir do backup.

O console de Gerenciamento de Acesso Remoto exibirá a seguinte mensagem de erro: GPO (nome do GPO) não pode ser encontrado. Para remover as definições de configuração, execute as seguintes etapas:

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

2. Abra o console de 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.

Próximos passos

• Etapa 2: Planejar implantações do DirectAccess