Configurar firewalls para o Microsoft AD gerenciado

Os controladores de domínio operados pelo serviço gerenciado para o Microsoft Active Directory expõem vários serviços, incluindo LDAP, DNS, Kerberos e RPC. Dependendo dos casos de uso, as máquinas virtuais (VMs) implantadas no Google Cloud, bem como as máquinas em execução no local, podem precisar de acesso a esses serviços para aproveitar o Active Directory.

Para reduzir a superfície de ataque de controladores de domínio e VMs, use firewalls para proibir qualquer comunicação de rede que não seja estritamente necessária. Neste artigo, descrevemos como configurar firewalls para acomodar casos de uso comuns do Active Directory e impedir outras comunicações de rede.

Comparação entre logon e autenticação

Os termos logon e autenticação geralmente são usados como sinônimos, mas têm diferentes significados no contexto da segurança do Windows. O Logon descreve o processo que ocorre no sistema ao qual um usuário está recebendo acesso. Por outro lado, a autenticação é executada pelo computador em que reside a conta do usuário.

Quando você usa uma conta local para fazer login em uma máquina, tanto o logon como a autenticação são processados pela máquina de destino. Em um ambiente do Active Directory, é mais comum usar um usuário de domínio para fazer login. Nesse caso, o logon é processado pela máquina de destino, enquanto a autenticação é realizada por um controlador de domínio.

Para autenticar, um cliente pode usar o Kerberos ou o NTLM . Depois que um cliente é autenticado, a máquina de destino precisa processar o logon. Dependendo do tipo de logon solicitado pelo cliente, isso pode exigir interações adicionais com controladores de domínio usando protocolos como Kerberos, NTLM, LDAP, RPC ou SMB .

Como a autenticação e o processamento de logons exigem protocolos diferentes, é útil distinguir entre os dois conceitos ao identificar a configuração de firewall correta.

Casos de uso comuns

Nas seções a seguir, descrevemos casos de uso comuns para acessar o Managed Microsoft AD e mostramos quais regras de firewall é necessário configurar para cada caso de uso.

Se você não planeja integrar o Managed Microsoft AD a um Active Directory local, leia a primeira seção deste artigo, Como acessar o Managed Microsoft AD em sua VPC. Se você pretende criar uma relação de confiança entre o Managed Microsoft AD e um Active Directory local, o artigo inteiro será útil.

Use registros de regras de firewall para analisar se outras portas podem ser necessárias. Como a regra de negação de entrada implícita tem o registro desativado, primeiro crie uma regra de firewall personalizada de baixa prioridade que negue todo o tráfego de entrada, mas tenha o registro de firewall ativado. Com essa regra, qualquer tentativa de conexão com falha faz com que uma entrada de registro seja publicada no Stackdriver. Como as regras de firewall podem produzir um volume significativo de registros, considere desabilitar o registro de firewall novamente depois de concluir sua análise.

Como acessar o Managed Microsoft AD do VPC

Quando você usa a rede padrão para implantar o Managed Microsoft AD, nenhuma outra configuração é necessária para ativar as VMs no VPC para acessar o Active Directory.

Se você personalizou a configuração VPC ou as regras de firewall, verifique se a configuração do firewall ainda permite a comunicação com o Managed Microsoft AD. Nas seções a seguir, descrevemos as regras de firewall que pode ser necessário criar.

Resolução de nomes de domínio

Quando uma VM tenta resolver um nome DNS, ela não consulta diretamente um controlador de domínio. Em vez disso, a consulta DNS é enviada para o servidor de metadados, que é o servidor DNS padrão configurado para as VMs do Compute Engine. Em seguida, o servidor de metadados encaminha a consulta para uma zona de encaminhamento de DNS privada do Cloud DNS criada pelo Microsoft AD gerenciado. Em seguida, essa zona de encaminhamento encaminha a consulta para o controlador de domínio apropriado.

Não é preciso configurar regras de firewall para ativar esse caso de uso. A comunicação com o Cloud DNS é sempre permitida para VMs em uma VPC. O Microsoft AD gerenciado permite solicitações de DNS encaminhadas do Cloud DNS por padrão.

Como autenticar em uma VM usando Kerberos

Um usuário que fez login em uma VM pode exigir acesso a um serviço fornecido por uma VM diferente. Por exemplo, um usuário pode tentar abrir uma conexão RDP, acessar um compartilhamento de arquivos ou acessar um recurso HTTP que requer autenticação.

Para permitir que um usuário faça autenticação na VM do servidor usando o Kerberos, a VM do cliente precisa primeiro conseguir um ticket Kerberos apropriado de um dos controladores do Managed Microsoft AD.

Para permitir que as VMs façam autenticação em outra usando o Kerberos, a comunicação a seguir precisa ser permitida pelas regras de firewall:

Ação De Para Protocolos
1 Permitir VM do cliente Sub-rede do Managed Microsoft AD Kerberos (UDP/88, TCP/88)
LDAP (UDP/389, TCP/389)
2 Permitir VM do cliente VM do servidor Protocolo usado para acessar a VM, como HTTP (TCP/80, TCP/443) ou RDP (TCP/3389)
3 Permitir VM do servidor Sub-rede do Managed Microsoft AD Veja como processar logons.

Como autenticar-se em uma VM usando NTLM

Embora o Windows prefira o Kerberos em vez do NTLM na maioria dos casos, os clientes podem ocasionalmente precisar voltar a usar o NTLM para autenticação. O NTLM depende da autenticação de passagem e, portanto, exige que o servidor se comunique com um dos controladores de domínio do Managed Microsoft AD para autenticar o usuário.

Para permitir que as VMs autentiquem outras VMs usando NTLM, a comunicação a seguir precisa ser permitida pelas regras de firewall:

Ação De Para Protocolos
1 Permitir VM do cliente VM do servidor Protocolo usado para acessar a VM, como HTTP (TCP/80, TCP/443) ou RDP (TCP/3389)
2 Permitir VM do cliente Sub-rede do Managed Microsoft AD Veja como processar logons.

Ingresso no domínio e processamento de logons

Para operar como um membro do domínio e processar logons de usuários, uma máquina precisa ser capaz de interagir com o Active Directory. O conjunto exato de protocolos usados depende do tipo de logon que os clientes individuais solicitam. Para oferecer suporte a todos os cenários comuns, é necessário permitir a combinação de protocolos a seguir.

Ação De Para Protocolos
1 Permitir VM do servidor Sub-rede do Managed Microsoft AD Kerberos (UDP/88, TCP/88)
NTP (UDP/123)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
PME (UDP/445, TCP/445)
GC LDAP (TCP/3268)

Além disso, dependendo do seu caso de uso exato, convém também permitir os protocolos a seguir:

Ação De Para Protocolos
1 Permitir VM do servidor Sub-rede do Managed Microsoft AD Mudança de senha do Kerberos (UDP/464, TCP/464)
LDAP seguro (TCP/636, TCP/3269)

Como administrar o Managed Microsoft AD

Use uma VM ingressada no domínio para gerenciar o Managed Microsoft AD. Para usar ferramentas como o Centro Administrativo do Active Directory nesta VM, ela também precisa ser capaz de acessar os Serviços Web do Active Directory expostos pelos controladores de domínio do Managed Microsoft AD.

Ação De Para Protocolos
1 Permitir VM do administrador Sub-rede do Managed Microsoft AD Serviços da Web do AD (TCP/9389)

Como conectar o Managed Microsoft AD a um Active Directory local

Para conectar o Microsoft AD Managed a um Active Directory local, é necessário criar uma relação de confiança entre florestas. Além disso, ative a resolução de nomes DNS entre o Google Cloud e seu ambiente local.

Criação e verificação de relação de confiança

Para criar e verificar uma relação de confiança de floresta, os controladores de domínio do Managed Microsoft AD e os controladores de domínio raiz da floresta local precisam poder se comunicar bidirecionalmente.

Para habilitar a criação e a verificação de relação de confiança, configure o firewall local para permitir o tráfego de entrada e saída que corresponda a essas características:

Ação De Para Protocolos
1 Permitir AD local Managed Microsoft AD DNS (UDP/53, TCP/53)
Kerberos (UDP/88, TCP/88)
Alteração de senha do Kerberos (UDP/464, TCP/464)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
PME (UDP/445, TCP/464)
2 Permitir Managed Microsoft AD AD local DNS (UDP/53, TCP/53)
Kerberos (UDP/88, TCP/88)
Alteração de senha do Kerberos (UDP/464, TCP/464)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
PME (UDP/445, TCP/464)

O Managed Microsoft AD é pré-configurado para permitir o tráfego correspondente a essas características, portanto, você não precisa configurar outras regras de firewall no Google Cloud.

Como resolver nomes DNS do Google Cloud no local

Há duas maneiras de permitir que máquinas locais resolvam nomes de DNS no Microsoft AD gerenciado: delegação de DNS e encaminhamento de DNS condicional.

Delegação de DNS

O domínio DNS usado pelo Microsoft AD gerenciado pode ser um subdomínio do domínio DNS usado no local. Por exemplo, use cloud.example.com para o Microsoft AD gerenciado enquanto usa example.com no local. Para permitir que os clientes locais resolvam os nomes DNS dos recursos do Google Cloud, configure a delegação de DNS.

Ao usar a delegação de DNS, as tentativas de resolver o nome DNS de um recurso do Google Cloud primeiro consultam um servidor DNS local. O servidor DNS então redireciona o cliente para o Cloud DNS, que, por sua vez, encaminha a solicitação para um dos controladores de domínio do Microsoft AD gerenciado.

A exposição do Cloud DNS a redes locais requer a criação e política de servidor de entrada. Isso criará um endereço IP de encaminhador de entrada que faz parte da VPC.

Para usar o endereço do encaminhador no local, configure o firewall local para permitir o tráfego de saída correspondente às características abaixo.

Ação De Para Protocolos
1 Permitir AD local Managed Microsoft AD DNS (UDP/53, TCP/53)
Kerberos (UDP/88, TCP/88)
Alteração de senha do Kerberos (UDP/464, TCP/464)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
PME (UDP/445, TCP/464)
2 Permitir Managed Microsoft AD AD local DNS (UDP/53, TCP/53)
Kerberos (UDP/88, TCP/88)
Alteração de senha do Kerberos (UDP/464, TCP/464)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
PME (UDP/445, TCP/464)

Encaminhamento de DNS condicional

O domínio DNS usado pelo Microsoft AD gerenciado pode não ser um subdomínio do domínio DNS usado no local. Por exemplo, use cloud.example.com para o Microsoft AD gerenciado enquanto usa corp.example.local no local.

Nos cenários em que os domínios DNS não são relacionados, configure o encaminhamento de DNS condicional no DNS do Active Directory local. Todas as consultas que correspondem ao nome DNS usado pelo Managed Microsoft AD serão encaminhadas para o Cloud DNS.

Para usar o encaminhamento de DNS condicional, configure uma política de DNS que permita o encaminhamento de DNS de entrada primeiro. Para usar o endereço do encaminhador resultante no local, configure o firewall local para permitir o tráfego de saída correspondente às características abaixo.

Ação De Para Protocolos
1 Permitir AD local Endereço IP de encaminhamento de DNS DNS (UDP/53, TCP/53)

No Google Cloud, crie uma regra de firewall para permitir o tráfego de entrada correspondente a esses critérios.

Não é preciso configurar regras de firewall para ativar a comunicação do encaminhador de DNS para o Cloud DNS (2).

Como resolver nomes DNS locais no Google Cloud

O Manged Microsoft AD usa o encaminhamento de DNS condicional para resolver nomes DNS em sua floresta local. Para também permitir que clientes em execução no Google Cloud resolvam nomes DNS gerenciados por um Active Directory local, crie uma zona de encaminhamento privado no Cloud DNS que encaminha consultas aos controladores de domínio locais.

Para ativar a resolução de nomes DNS locais do Google Cloud, configure o firewall local para permitir o tráfego de entrada de acordo com a tabela a seguir.

Ação De Para Protocolos
1 Permitir Managed Microsoft AD AD local DNS (UDP/53, TCP/53)
2 Permitir Cloud DNS (35.199.192.0/19) AD local DNS (UDP/53, TCP/53)

O Google Cloud permite o tráfego de saída correspondente por padrão.

Como acessar recursos do Managed Microsoft AD no local

Se a floresta do Managed Microsoft AD estiver configurada para confiar na floresta local, convém que os usuários e máquinas locais acessem recursos na floresta do Managed Microsoft AD.

Como autenticar-se em uma VM no local usando o Kerberos

Um usuário que fez login em uma máquina local pode exigir acesso a um serviço fornecido por uma VM executada no Google Cloud e que é membro de uma floresta do Microsoft AD gerenciado. Por exemplo, um usuário pode tentar abrir uma conexão RDP, acessar um compartilhamento de arquivos ou acessar um recurso HTTP que requer autenticação.

Para permitir que os usuários se autentiquem na VM do servidor usando o Kerberos, a máquina cliente precisa conseguir um tíquete Kerberos apropriado. Isso requer a comunicação com um dos controladores de domínio local, bem como com um dos controladores de domínio do Managed Microsoft AD.

Para permitir que as VMs locais se autentiquem usando o Kerberos, configure seu firewall local para permitir o tráfego de saída a seguir.

Ação De Para Protocolos
1 Permitir Máquina do cliente (no local) Sub-rede do Managed Microsoft AD LDAP (UDP/389, TCP/389)
Kerberos (UDP/88, TCP/88)
2 Permitir Máquina do cliente (no local) VM de servidor (Google Cloud) Protocolo usado pelo aplicativo, como HTTP (TCP/80, TCP/443) ou RDP (TCP/3389)
3 Permitir VM do servidor Sub-rede do Managed Microsoft AD Veja como processar logons.

No Google Cloud, crie regras de firewall para permitir tráfego de entrada para (1) e (2). O tráfego de saída para o Microsoft AD gerenciado (3) é permitido por padrão.

Como autenticar-se em uma VM no local usando NTML

Ao usar o NTLM para autenticar um usuário de uma floresta do Active Directory local para uma VM de servidor associada a uma floresta do Managed Microsoft AD, os controladores de domínio do Managed Microsoft AD precisam se comunicar com os controladores de domínio locais.

Para permitir que VMs locais sejam autenticadas usando o NTLM, configure seu firewall local para permitir o tráfego de entrada e saída da seguinte maneira.

Ação De Para Protocolos
1 Permitir Máquina do cliente (no local) VM de servidor (Google Cloud) Protocolo usado pelo aplicativo, como HTTP (TCP/80, TCP/443) ou RDP (TCP/3389)
2 Permitir VM do servidor Sub-rede do Managed Microsoft AD Veja como processar logons.
3 Permitir Sub-rede do Managed Microsoft AD AD local LDAP (UDP/389, TCP/389)
PME (UDP/445, TCP/445)

No Google Cloud, crie regras de firewall para permitir tráfego de entrada para (1). O tráfego de saída para (2) e (3) é permitido por padrão.

Como processar logons para usuários da floresta local

Para processar um logon de um usuário da floresta local, uma VM precisa ser capaz de interagir com o Active Directory local. O conjunto exato de protocolos usados depende do tipo de logon solicitado pelo cliente. Para oferecer suporte a todos os cenários comuns, configure o firewall local para permitir o tráfego de entrada que corresponda a essas características.

Ação De Para Protocolos
1 Permitir VM de servidor (Google Cloud) Sub-rede AD local Kerberos (UDP/88, TCP/88)
NTP (UDP/123)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
PME (UDP/445, TCP/445)
GC LDAP (TCP/3268)

Dependendo do seu caso de uso exato, convém também permitir os protocolos a seguir.

  • Alteração de senha do Kerberos (UDP/464, TCP/464)
  • LDAP seguro (TCP/636, TCP/3269)

No lado do Managed Microsoft AD, o tráfego de saída correspondente é permitido por padrão.

Em VMs administrativas, pode ser que você não planeje permitir logons de usuários da floresta local. Uma atividade que você provavelmente precisa executar em VMs administrativas está gerenciando as associações ao grupo. Sempre que você usar o seletor de objetos para se referir a um usuário ou grupo ao formar sua floresta local, o seletor de objetos exigirá acesso aos controladores de domínio locais. Para que isso funcione, a VM administrativa requer o mesmo acesso aos controladores de domínio do Active Directory no local, assim como exigiria para processar logons para os usuários da floresta local.

Como acessar recursos locais do Active Directory no Google Cloud

Se sua floresta local estiver configurada para confiar na floresta do Managed Microsoft AD, convém que os usuários da floresta do Managed Microsoft AD possam acessar recursos locais.

Como autenticar-se em uma VM local usando Kerberos

Um usuário que tenha feito login em uma VM em execução no Google Cloud e que seja membro da floresta do Microsoft AD gerenciado pode exigir acesso a um serviço fornecido por uma máquina local que seja membro de sua floresta local. Por exemplo, o usuário pode tentar abrir uma conexão RDP, acessar um compartilhamento de arquivos ou acessar um recurso HTTP que requer autenticação.

Para permitir que o usuário se autentique na máquina local usando o Kerberos, a VM precisa ter um tíquete Kerberos apropriado. Isso requer a comunicação com um dos controladores do Managed Microsoft AD e, em seguida, com os controladores de domínio locais.

Para permitir que VMs locais sejam autenticadas usando o Kerberos, configure seu firewall local para permitir o tráfego de entrada que corresponda às características abaixo.

Ação De Para Protocolos
1 Permitir VM do cliente (Google Cloud) Sub-rede do Managed Microsoft AD Kerberos (UDP/88, TCP/88)
LDAP (UDP/389, TCP/389)
Implícito por processamento de logons
2 Permitir VM do cliente (Google Cloud) AD local Kerberos (UDP/88, TCP/88)
LDAP (UDP/389, TCP/389)
3 Permitir VM do cliente (Google Cloud) Máquina do servidor (local) Protocolo usado pelo aplicativo, como HTTP (TCP/80, TCP/443) ou RDP (TCP/3389)

No Google Cloud, o tráfego de saída correspondente é permitido por padrão.

Como autenticar-se em uma VM local usando NTLM

Ao usar o NTLM para autenticar um usuário da floresta do Managed Microsoft AD em uma máquina de servidor associada à sua floresta local, os controladores de domínio locais precisam poder se comunicar com os controladores de domínio do Managed Microsoft AD:

Para permitir que VMs locais sejam autenticadas usando o Kerberos, configure seu firewall local para permitir o tráfego de entrada e saída correspondente a essas características.

Ação De Para Protocolos
1 Permitir VM do cliente (Google Cloud) Máquina do servidor (local) Protocolo usado pelo aplicativo, por exemplo, HTTP (TCP/80, TCP/443) ou RDP (TCP/3389)
2 Permitir AD local Sub-rede do Managed Microsoft AD LDAP (UDP/389, TCP/389)
PME (UDP/445, TCP/445)

No lado do Google Cloud, o tráfego de saída para (1) e o tráfego de entrada para (2) é permitido por padrão.

Como processar logons para usuários da floresta do Managed Microsoft AD

Para processar um logon para um usuário da floresta do Managed Microsoft AD, uma máquina em execução no local precisa interagir com os controladores de domínio do Managed Microsoft AD. O conjunto exato de protocolos usados depende do tipo de logon solicitado pelo cliente. Para oferecer suporte a todos os cenários comuns, é necessário permitir a combinação de protocolos a seguir.

Ação De Para Protocolos
1 Permitir Máquina do servidor (local) Sub-rede do Managed Microsoft AD Kerberos (UDP/88, TCP/88)
NTP (UDP/123)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
PME (UDP/445, TCP/445)
GC LDAP (TCP/3268)

Dependendo do seu caso de uso exato, convém também permitir os protocolos a seguir.

  • Alteração de senha do Kerberos (UDP/464, TCP/464)
  • LDAP seguro (TCP/636, TCP/3269)

Verifique se os firewalls locais permitem o tráfego de saída que corresponde a essas características. Não é preciso configurar regras de firewall no Google Cloud para ativar o tráfego de entrada correspondente no Microsoft AD gerenciado.

Em máquinas administrativas, pode ser que você não planeje permitir logons de usuários da floresta do Microsoft AD gerenciado. Uma atividade que você provavelmente precisa realizar em máquinas administrativas é gerenciar as associações aos grupos. Sempre que você usar o seletor de objetos para referenciar um usuário ou grupo da floresta do Microsoft AD gerenciado, o seletor de objetos exigirá o acesso aos controladores de domínio do Microsoft AD gerenciado. Para que isso funcione, a máquina administrativa requer o mesmo acesso aos controladores de domínio do Microsoft AD gerenciado da mesma forma que exigiria para o processamento de logons de usuários da floresta do Microsoft AD gerenciado.