Maybaygiare.org

Blog Network

Al usar Microsoft AD administrado en firewalls

Los controladores de dominio operados por Servicio administrado para Microsoft Active Directory exponen una serie de servicios, incluidos LDAP, DNS, Kerberos y RPC. Según los casos de uso,es posible que las máquinas virtuales (VM) implementadas en Google Cloud, así como las máquinas que se ejecutan en las instalaciones, necesiten acceso a estos servicios para aprovechar ActiveDirectory.

Para reducir la superficie de ataque de los controladores de dominio y las máquinas virtuales, debe utilizar los firewalls para rechazar cualquier comunicación de red que no sea estrictamente necesaria.En este artículo se describe cómo configurar el cortafuegos para acomodar común ActiveDirectory, casos de uso, mientras que rechazando otras comunicaciones de red.

Inicio de sesión versus autenticación

Aunque los términos inicio de sesión y autenticación a menudo se usan indistintamente,tienen diferentes significados en el contexto de la seguridad de Windows. Logondescribe el proceso que se produce en el sistema al que un usuario está accediendo to.In por el contrario, la autenticación la realiza el equipo en el que reside la cuenta del usuario.

Cuando se utiliza una cuenta local para iniciar sesión en un equipo, el equipo de destino gestiona tanto el inicio de sesión como la autenticación. En un entorno de Directoryenvironment activo, es más común usar un usuario de dominio para iniciar sesión. En ese caso, el inicio de sesión lo gestiona la máquina de destino, mientras que la autenticación la realiza un controlador de dominio.

Para autenticarse, un cliente puede usar eitherKerberos o NTLM .Una vez que un cliente se autentica, la máquina de destino necesita procesar el inicio de sesión.Dependiendo del tipo de logon solicitado por el cliente, esto puede requerir interacción adicional con controladores de dominio que utilicen protocolos como Kerberos, NTLM,LDAP ,RPC o SMB .

Debido a que los inicios de sesión de autenticación y procesamiento requieren protocolos diferentes, es útil distinguir entre los dos conceptos al identificar la configuración de rightfirewall.

Casos de uso comunes

En las siguientes secciones se describen casos de uso comunes para acceder a Microsoft AD administrado y se muestran las reglas de firewall que debe configurar para cada caso de uso.

Si no tiene previsto integrar Managed Microsoft AD con un Directorio Activo local, solo necesita leer la primera sección de este artículo,acceder a Managed Microsoft AD desde su VPC. Si tiene la intención de crear una relación de confianza entre Microsoft AD administrado y un ActiveDirectory local, se aplicará el artículo completo.

Puede usar registros de reglas de firewall para analizar si se requieren puertos adicionales. Dado que la regla de denegación de entrada implementada tiene deshabilitado el registro, primero debe crear una regla de firewall personalizada de baja prioridad que deniegue todo el tráfico de entrada, pero que tenga habilitado el registro de firewall. Con esta regla en su lugar, cualquier intento de conexión fallido hace que se publique una entrada de registro en Stackdriver. Como las reglas de firewall pueden producir un volumen significativo de registros, considere deshabilitar el registro de firewall de nuevo una vez que haya completado el análisis.

Acceder a Microsoft AD administrado desde su VPC

Cuando utiliza la red predeterminada para implementar Microsoft AD administrado, no se requiere ninguna configuración adicional para permitir que las máquinas virtuales de la VPC accedan a Active Directory.

Si ha personalizado la configuración de la VPC o las reglas de firewall, debe asegurarse de que la configuración del firewall siga permitiendo la comunicación con Microsoft AD administrado. En las siguientes secciones se describen las reglas de firewall que podría necesitar crear.

Resolución de nombres de dominio

Cuando una máquina virtual intenta resolver un nombre DNS, no consulta directamente a un controlador de dominio. En su lugar, la consulta DNS se envía al servidor de metadatos, que es el servidor DNS predeterminado configurado para máquinas virtuales de Compute Engine. A continuación, el servidor de metadatos reenvía la consulta a una zona de reenvío de DNS privado en la nube creada por Microsoft AD administrado. Esta zona de reenvío reenvía la consulta al controlador de dominio apropiado.

Resolución de nombre de dominio

No es necesario configurar ninguna regla de firewall para habilitar este caso de uso.La comunicación a DNS en la nube (1) siempre se permite para las máquinas virtuales en una VPC y permisos de anuncios administrados de Microsoft para solicitudes DNS reservadas desde DNS en la nube DNS en la nube(2) de forma predeterminada.

Autenticarse en una máquina virtual mediante Kerberos

Un usuario que ha iniciado sesión en una máquina virtual puede requerir acceso a un servicio proporcionado por una máquina virtual diferente. Por ejemplo, un usuario puede intentar abrir una conexión RDP,acceder a un recurso compartido de archivos o acceder a un recurso HTTP que requiera autenticación.

Para permitir que un usuario se autentique en la máquina virtual del servidor mediante Kerberos, la máquina virtual del cliente debe obtener primero un ticket de Kerberos apropiado de uno de los controladores de AD de Microsoft administrados.

Autenticación en una máquina virtual mediante Kerberos

Para permitir que las máquinas virtuales se autentiquen en otra mediante Kerberos, las reglas de firewall deben permitir la siguiente comunicación:

Action From To Protocols
1 Allow Client VM Managed Microsoft AD subnet Kerberos (UDP/88, TCP/88)
LDAP (UDP/389, TCP/389)
2 Allow Client VM Server VM Protocol used to access VM, such as HTTP (TCP/80, TCP/443) or RDP (TCP/3389)
3 Allow Server VM Managed Microsoft AD subnet See processing logons.

Autenticarse en una máquina virtual mediante NTLM

Aunque Windowsprefers Kerberos sobre NTLM en la mayoría de los casos, es posible que ocasionalmente los clientes necesiten recurrir al uso de NTLM forauthentication. NTLM depende de la autenticación pasante y, por lo tanto, requiere que el servidor se comunique con uno de los controladores de dominio AD de Microsoft administrados para autenticar al usuario.

Autenticación en una máquina virtual mediante NTLM

Para permitir que las máquinas virtuales autentiquen otras máquinas virtuales mediante NTLM, las reglas de firewall deben permitir la siguiente comunicación:

Acción De A Protocolos
1 Permitir VM cliente VM servidor Protocolo utilizado para acceder a VM, como HTTP (TCP/IP 80, TCP/443) o RDP (TCP/3389)
2 Permitir Máquina virtual de cliente Subred AD administrada de Microsoft Consulte procesamiento de inicios de sesión.

Inicio de sesión de unión y procesamiento de dominios

Para funcionar como miembro de dominio y procesar inicios de sesión de usuarios, una máquina debe poder interactuar con Active Directory. El conjunto exacto de protocolos utilizados depende del tipo de inicio de sesión que soliciten los clientes individuales. Para soportar todos los escenarios comunes, debe permitir la siguiente combinación de protocolos.

Action From To Protocols
1 Allow Server VM Managed Microsoft AD subnet Kerberos (UDP/88, TCP/88)
NTP (UDP/123)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
SMB (UDP/445, TCP/445)
LDAP GC (TCP/3268)

Additionally, depending on your exact use case, you might also want to permitthe los siguientes protocolos:

Acción De A Protocolos
1 Permitir Máquina virtual de servidor Subred de anuncios administrada de Microsoft Cambio de contraseña de Kerberos (UDP/464, TCP/464)
LDAP seguro (TCP/636, TCP/3269)

Administrar Microsoft AD administrado

Debe usar vmpara administrar Microsoft AD administrado unido a un dominio. Para utilizar herramientas como Active DirectoryAdministrative Center en esta máquina virtual, la máquina virtual también debe poder acceder a los servicios Web de Active Directory expuestos por los controladores de dominio AD administrados de Microsoft.

Acción De A Protocolos
1 Permitir Admin VM Subred AD administrada de Microsoft Servicios Web de anuncios (TCP/9389)

Conexión de Microsoft AD administrado a un Active Directory local

Para conectar Microsoft AD administrado a un Active Directory local, debe crear una relación de confianza entre los bosques. Además, debe habilitar la resolución de nombres de Google Cloud y su entorno local.

Creación y verificación de confianza

Para crear y verificar una confianza de bosque, los controladores de dominios adicionales de Microsoft administrados y los controladores de dominio raíz de su bosque local deben poder comunicarse bidireccionalmente.

Creación y verificación de confianza

Para habilitar la creación y verificación de confianza, configure su cortafuegos local para permitir el tráfico de entrada y salida que coincida con estas características:

Action From To Protocols
1 Allow On-premises AD Managed Microsoft AD DNS (UDP/53, TCP/53)
Kerberos (UDP/88, TCP/88)
Kerberos password change (UDP/464, TCP/464)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
SMB (UDP/445, TCP/445)
2 Allow Managed Microsoft AD On-premises AD DNS (UDP/53, TCP/53)
Kerberos (UDP/88, TCP/88)
Kerberos password change (UDP/464, TCP/464)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
SMB (UDP/445, TCP/445)

Microsoft AD administrado está preconfigurado para permitir que el tráfico coincida con estas características, por lo que no es necesario configurar reglas de firewall adicionales onGoogle Cloud.

Resolver nombres DNS de Google Cloud desde locales

Existen dos formas de permitir que las máquinas locales resuelvan nombres DNS en Microsoft AD administrado: delegación de DNS y reenvío de DNS condicional.

Delegación de DNS

El dominio DNS utilizado por Microsoft AD administrado puede ser un subdominio del dominio DNS utilizado en las instalaciones. Por ejemplo, puede usar cloud.example.com Microsoft AD administrado durante el uso example.com en las instalaciones. Para permitir que los clientes locales resuelvan los nombres DNS de los recursos de Google Cloud, puede configurar la delegación de actualizaciones.

Al usar la delegación de DNS, intenta resolver el nombre DNS del recurso en la nube de aGoogle primero consultando un servidor DNS local. A continuación, el servidor DNSS redirige el cliente a DNS en la nube, que a su vez reenvía la solicitud a uno de los controladores de dominio administrados de Microsoft AD.

Delegación de DNS

Exponer DNS en la nube a redes locales requiere crear y directiva de servidor entrante.Esto creará una dirección IP del reenviador de entrada que forma parte de su VPC.

Para usar la dirección del reenviador desde las instalaciones, configure su muro de separación en las instalaciones para permitir el tráfico de salida que coincida con las características que se indican a continuación.

Action From To Protocols
1 Allow On-premises AD Managed Microsoft AD DNS (UDP/53, TCP/53)
Kerberos (UDP/88, TCP/88)
Kerberos password change (UDP/464, TCP/464)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
SMB (UDP/445, TCP/445)
2 Allow Managed Microsoft AD On-premises AD DNS (UDP/53, TCP/53)
Kerberos (UDP/88, TCP/88)
Kerberos password change (UDP/464, TCP/464)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
SMB (UDP/445, TCP/445)

Reenvío de DNS condicional

Es posible que el dominio DNS utilizado por Microsoft AD administrado no sea un subdominio del DNS dominio utilizado en las instalaciones. Por ejemplo, puede usarcloud.example.com forManaged Microsoft AD mientras usa corp.example.local en las instalaciones.

En situaciones en las que los dominios DNS no están relacionados, puede configurar DNSforwarding condicional en su DNS de Active Directory local. Todas las consultas que coincidan con el nombre DNS utilizado por Microsoft AD administrado se redirigirán a DNS en la nube.

Reenvío de DNS condicional

Para usar el reenvío de DNS condicional, debe configurar la directiva aDNS que habilita el reenvío de DNS entrante primero. Para usar la dirección del reenviador resultante desde las instalaciones, configure su firewall local para permitir el tráfico de salida que coincida con las características siguientes.

Acción De A Protocolos
1 Permitir ANUNCIO local Dirección IP de reenvío de DNS DNS (UDP/53, TCP/53)

En el lado de Google Cloud, cree una regla de firewall para interrumpir el tráfico de entrada que coincida con estos criterios.

No es necesario configurar ninguna regla de firewall para habilitar la comunicación desde el reenviador de DNS a DNS en la nube (2).

Resolver nombres DNS locales desde Google Cloud

Microsoft AD administrado utiliza el reenvío de DNS condicional para resolver nombres DNS en su bosque local. Para permitir que los clientes que se ejecutan en Google Cloud también resuelvan nombres DNS administrados por un Active Directory local, puede crear una zona de reenvío privada con DNS en la nube que reenvía consultas a controladores de dominio locales.

Resolución de nombres DNS locales

Para habilitar la resolución de nombres DNS locales desde Google Cloud, configure su firewall local para permitir el tráfico de entrada según la tabla siguiente.

Acción/th> De Para Protocolos
1 Permite Administrado de Microsoft ANUNCIO instalaciones AD DNS (UDP/53, TCP/53)
2 Permite Cloud DNS (35.199.192.0/19) ANUNCIO local DNS (UDP/53, TCP/53)

Google Cloud permite el tráfico de salida correspondiente por defecto.

Acceso a los recursos administrados de Microsoft AD desde las instalaciones

Si el bosque administrado de Microsoft AD está configurado para confiar en su bosque local,es posible que desee que los usuarios y máquinas locales puedan acceder a los recursos del bosque administrado de Microsoft AD.

Autenticarse en una máquina virtual local mediante Kerberos

Un usuario que ha iniciado sesión en una máquina local puede requerir acceso a un servicio proporcionado por una máquina virtual que se ejecuta en Google Cloud y es miembro de un bosque de anuncios de Microsoft administrado. Por ejemplo, un usuario puede intentar abrir una conexión RDP, acceder a un recurso compartido de archivos o acceder a un recurso HTTP que requiera autenticación.

Para permitir que los usuarios se autentiquen en la máquina virtual del servidor mediante Kerberos, la máquina cliente debe obtener un ticket de Kerberos adecuado. Esto requiere comunicarse con uno de los controladores de dominio locales, así como con uno de los controladores de dominio administrados de Microsoft AD.

Autenticación en una máquina virtual local mediante Kerberos

Para habilitar la autenticación de máquinas virtuales locales mediante Kerberos, configure su firewall local para permitir el siguiente tráfico de salida.

Action From To Protocols
1 Allow Client machine (on-premises) Managed Microsoft AD subnet LDAP (UDP/389, TCP/389)
Kerberos (UDP/88, TCP/88)
2 Allow Client machine (on-premises) Server VM (GCP) Protocol used by application, such as HTTP (TCP/80, TCP/443) or RDP (TCP/3389)
3 Allow Server VM Managed Microsoft AD subnet See processing logons.

En el lado de Google Cloud, cree reglas de firewall para interrumpir el tráfico de entrada para (1) y (2). El tráfico de salida a Microsoft AD(3) administrado está permitido de forma predeterminada.

Autenticación en una máquina virtual local mediante NTLM

Cuando se utiliza NTLM para autenticar a un usuario desde un bosque de Directoryforest Activo local a una máquina virtual de servidor unida a un bosque de Microsoft AD Administrado, los controladores de dominio de Microsoft AD administrados deben comunicarse con los controladores de dominio locales.

Autenticación en una máquina virtual local mediante NTLM

Para habilitar la autenticación de máquinas virtuales locales mediante NTLM, configure su firewall local para permitir el tráfico de entrada y salida de la siguiente manera.

Acción De A Protocolos
1 Permitir Máquina cliente (local) Máquina virtual de servidor (Google Cloud) Protocolo utilizado por la aplicación, como HTTP (TCP/80, TCP/443) o RDP (TCP/3389)
2 Permitir Máquina virtual de servidor Subred AD administrada de Microsoft Consulte Procesamiento de inicios de sesión.
3 Permitir Subred de ANUNCIOS administrada de Microsoft ANUNCIO local LDAP (UDP/389, TCP/389)
SMB (UDP/445, TCP/445)

En el lado de Google Cloud, cree reglas de cortafuegos para interrumpir el tráfico de entrada para (1). El tráfico de salida para (2) y (3) está permitido por defecto.

Procesamiento de inicios de sesión para usuarios del bosque local

Para procesar un inicio de sesión para un usuario del bosque local, una máquina virtual debe poder interactuar con Active Directory local. El conjunto exacto de protocolos utilizados depende del tipo de registro que el cliente solicite. Para admitir todos los escenarios comunes, configure su firewall local para permitir el tráfico de entrada que coincida con estas características.

Acción De A Protocolos
1 Permitir Máquina virtual de servidor (Google Cloud) Subred de anuncios local Kerberos (UDP/88, TCP/88)
NTP (UDP/123)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
SMB (UDP/445, TCP/445)
LDAP GC (TCP/3268)

Dependiendo de su caso de uso exacto, también puede permitir los siguientes protocolos.

  • Cambio de contraseña de Kerberos (UDP/464, TCP/464)
  • LDAP seguro (TCP/636, TCP/3269)

En el lado de Microsoft AD administrado, el tráfico de salida correspondiente está permitido de forma predeterminada.

En máquinas virtuales administrativas, es posible que no tenga previsto permitir inicios de sesión de usuarios del bosque local. Sin embargo, una actividad que es probable que tenga que realizar en máquinas virtuales administrativas es administrar las membresías de grupo. Siempre que utilice el selector de objetos para hacer referencia a un usuario o grupo de su bosque local, el selector de objetos requerirá acceso a los controladores de dominio locales. Para que funcione, la máquina virtual administrativa requiere el mismo acceso a los controladores de dominio de Active Directory en sus instalaciones que para procesar los inicios de sesión de los usuarios del bosque local.

Acceso a los recursos locales de Active Directory desde Google Cloud

Si el bosque local está configurado para confiar en el bosque administrado de Microsoft AD,es posible que desee que los usuarios del bosque administrado de Microsoft AD puedan acceder a los recursos locales.

Autenticarse en una máquina virtual local mediante Kerberos

Un usuario que ha iniciado sesión en una máquina virtual que se ejecuta en Google Cloud y que es miembro del bosque de anuncios administrado de Microsoft puede requerir acceso a un servicio proporcionado por una máquina local que es miembro del bosque local.Por ejemplo, el usuario puede intentar abrir una conexión RDP, acceder a un archivo compartido o acceder a un recurso HTTP que requiera autenticación.

Para permitir que el usuario se autentique en la máquina local usando Kerberos, el VM debe obtener un ticket de Kerberos apropiado. Esto requiere comunicarse primero con uno de los controladores AD administrados de Microsoft y, a continuación, con los controladores de dominio locales.

Autenticación en una máquina virtual local mediante Kerberos

Para habilitar la autenticación de máquinas virtuales locales mediante Kerberos, configure su firewall local para permitir el tráfico de entrada que coincida con las características siguientes.

Action From To Protocols
1 Allow Client VM (Google Cloud) Managed Microsoft AD subnet Kerberos (UDP/88, TCP/88)
LDAP (UDP/389, TCP/389)
Implied by processing logons
2 Allow Client VM (Google Cloud) On-premises AD Kerberos (UDP/88, TCP/88)
LDAP (UDP/389, TCP/389)
3 Allow Client VM (Google Cloud) Server machine (on-premises) Protocol used by aplicación, como HTTP (TCP/80, TCP / 443) o RDP (TCP/3389)

En el lado de Google Cloud, el tráfico de salida correspondiente está permitido de forma predeterminada.

Autenticación en una máquina virtual local mediante NTLM

Cuando se utiliza NTLM para autenticar a un usuario desde el bosque AD administrado de Microsoft a una máquina servidor que está unida a su bosque local, los controladores de dominio locales deben poder comunicarse con los controladores de dominio AD administrados de Microsoft:

Autenticación en una máquina virtual local mediante NTLM

Para habilitar la autenticación de máquinas virtuales locales mediante Kerberos, configure su firewall local para permitir el tráfico de entrada y salida que coincida con estas características.

Acción De A Protocolos
1 Permitir VM cliente (Google Cloud) Máquina servidor (local) Protocolo utilizado por la aplicación por ejemplo, HTTP (TCP/80, TCP/443) o RDP (TCP/3389)
2 Permitir AD local Subred AD administrada de Microsoft LDAP (UDP/389, TCP/389)
SMB (UDP/445, TCP/445)

En el lado de Google Cloud, el tráfico de salida para (1) y el tráfico de entrada para(2) está permitido por predeterminado.

Procesamiento de inicios de sesión para usuarios del bosque AD administrado de Microsoft

Para procesar un inicio de sesión para un usuario del bosque AD administrado de Microsoft, una máquina de ejecución local debe poder interactuar con los controladores de dominios complementarios administrados de Microsoft. El conjunto exacto de protocolos utilizados depende del tipo de logon que el cliente solicite. Para soportar todos los escenarios comunes, debe permitir la siguiente combinación de protocolos.

Acción De Para Protocolos
1 Permite máquina Servidor (local) Administrado de Microsoft ANUNCIO de subred Kerberos (UDP/88, TCP/88)
NTP (UDP/123)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
SMB (UDP/445, TCP/445)
LDAP GC (TCP/3268)

Dependiendo de su exacto de casos de uso, también puede ser que desee para permitir las siguientes opciones protocolos.

  • Cambio de contraseña de Kerberos (UDP/464, TCP/464)
  • LDAP seguro (TCP/636, TCP/3269)

Asegúrese de que los cortafuegos locales permitan el tráfico de salida que coincida con estas características. No es necesario configurar ninguna regla de firewall en Google Cloud para habilitar el tráfico de entrada correspondiente a Microsoft AD administrado.

En máquinas administrativas, es posible que no planee permitir inicios de sesión de usuarios del bosque de anuncios de Microsoft administrado. Una actividad que probablemente tenga que realizar en máquinas administrativas es administrar membresías de grupo. Siempre que utilice el selector de objetos para hacer referencia a un usuario o grupo del Microsoft AdForest administrado, el selector de objetos requerirá acceso a los controladores de dominios complementarios administrados de Microsoft. Para que esto funcione, la máquina administrativa requiere el mismo acceso a los controladores de dominio de Microsoft AD administrados que para procesar los inicios de sesión de los usuarios del bosque de Microsoft AD administrado.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.