Los controladores de dominio gestionados por el servicio gestionado de Microsoft Active Directory exponen varios servicios, como LDAP, DNS, Kerberos y RPC. En función de tus casos prácticos, es posible que las máquinas virtuales implementadas en Google Cloud, así como las máquinas que se ejecutan de forma local, necesiten acceder a estos servicios para aprovechar las ventajas de Active Directory.
Para reducir la superficie de ataque de los controladores de dominio y las VMs, debes usar cortafuegos para denegar cualquier comunicación de red que no sea estrictamente necesaria. En este artículo se describe cómo configurar cortafuegos para adaptarse a los casos prácticos habituales de Active Directory y, al mismo tiempo, impedir otras comunicaciones de red.
Inicio de sesión frente a autenticación
Aunque los términos "inicio de sesión" y "autenticación" se suelen usar indistintamente, tienen significados diferentes en el contexto de la seguridad de Windows. Inicio de sesión: describe el proceso que se produce en el sistema al que accede un usuario. Por el contrario, la autenticación la realiza el ordenador en el que se encuentra la cuenta del usuario.
Cuando usas 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 Active Directory, es más habitual usar un usuario del 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 Kerberos o NTLM . Una vez que un cliente se autentica, el equipo de destino debe procesar el inicio de sesión. En función del tipo de inicio de sesión que haya solicitado el cliente, puede que sea necesario interactuar más con los controladores de dominio mediante protocolos como Kerberos, NTLM, LDAP, RPC o SMB .
Como la autenticación y el procesamiento de los inicios de sesión requieren protocolos diferentes, es útil distinguir entre ambos conceptos a la hora de identificar la configuración de firewall adecuada.
Casos prácticos habituales
En las siguientes secciones se describen casos prácticos habituales para acceder a Microsoft AD gestionado y se indica qué reglas de firewall debe configurar en cada caso.
Si no tienes previsto integrar Managed Microsoft AD con un Active Directory local, solo tienes que leer la primera sección de este artículo, Acceder a Managed Microsoft AD desde tu VPC. Si tienes intención de crear una relación de confianza entre Managed Microsoft AD y un Active Directory local, se aplica todo el artículo.
Puedes usar los registros de reglas de cortafuegos para analizar si se necesitan puertos adicionales. Como la regla de denegación implícita de entrada tiene el registro inhabilitado, primero debes crear una regla de cortafuegos personalizada de baja prioridad que deniegue todo el tráfico de entrada, pero que tenga habilitado el registro de cortafuegos. Con esta regla, cualquier intento de conexión fallido provoca que se publique una entrada de registro en Stackdriver. Como las reglas de cortafuegos pueden generar un volumen significativo de registros, te recomendamos que vuelvas a inhabilitar el registro de cortafuegos una vez que hayas completado el análisis.
Acceder a Microsoft AD gestionado desde tu VPC
Si usas la red predeterminada para implementar Managed Microsoft AD, no es necesario realizar ninguna configuración adicional para que las VMs de la VPC accedan a Active Directory.
Si has personalizado la configuración de tu VPC o las reglas de cortafuegos, debes asegurarte de que la configuración del cortafuegos siga permitiendo la comunicación con Managed Microsoft AD. En las siguientes secciones se describen las reglas de cortafuegos que puede que tengas que crear.
Resolución de nombres de dominio
Cuando una VM intenta resolver un nombre de DNS, no consulta directamente 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 las VMs de Compute Engine. A continuación, el servidor de metadatos reenvía la consulta a una zona de reenvío de DNS privada de Cloud DNS creada por Managed Microsoft AD. A continuación, esta zona de reenvío reenvía la consulta al controlador de dominio adecuado.
No es necesario que configure ninguna regla de cortafuegos para habilitar este caso práctico. La comunicación con Cloud DNS siempre está permitida para las VMs de una VPC y Managed Microsoft AD permite de forma predeterminada las solicitudes DNS reenviadas desde Cloud DNS .
Autenticarse en una VM mediante Kerberos
Un usuario que haya iniciado sesión en una máquina virtual puede necesitar acceso a un servicio proporcionado por otra máquina virtual. 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 VM del servidor mediante Kerberos, la VM del cliente debe obtener primero un ticket de Kerberos adecuado de uno de los controladores de Microsoft AD gestionado.
Para que las VMs puedan autenticarse entre sí mediante Kerberos, las reglas del cortafuegos deben permitir la siguiente comunicación:
| Acción | De | Para | Protocolos | |
|---|---|---|---|---|
| 1 | Permitir | VM de cliente | Subred de Microsoft AD gestionado |
Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) |
| 2 | Permitir | VM de cliente | VM de servidor | Protocolo usado para acceder a la VM, como HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 3 | Permitir | VM de servidor | Subred de Microsoft AD gestionado | Consulta Procesar inicios de sesión. |
Autenticarse en una VM mediante NTLM
Aunque Windows prefiere Kerberos a NTLM en la mayoría de los casos, es posible que los clientes tengan que recurrir a NTLM para la autenticación en ocasiones. NTLM se basa en la autenticación de acceso directo y, por lo tanto, requiere que el servidor se comunique con uno de los controladores de dominio de Microsoft AD gestionados para autenticar al usuario.
Para que las VMs puedan autenticar otras VMs mediante NTLM, las reglas del cortafuegos deben permitir la siguiente comunicación:
| Acción | De | Para | Protocolos | |
|---|---|---|---|---|
| 1 | Permitir | VM de cliente | VM de servidor | Protocolo usado para acceder a la VM, como HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 2 | Permitir | VM de cliente | Subred de Microsoft AD gestionado | Consulta Procesar inicios de sesión. |
Unión a un dominio y procesamiento de inicios de sesión
Para funcionar como miembro de un dominio y procesar los inicios de sesión de los usuarios, un equipo 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 admitir todos los casos habituales, debes permitir la siguiente combinación de protocolos.
| Acción | De | Para | Protocolos | |
|---|---|---|---|---|
| 1 | Permitir | VM de servidor | Subred de Microsoft AD gestionado |
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) |
Además, en función de tu caso práctico concreto, también puedes permitir los siguientes protocolos:
| Acción | De | Para | Protocolos | |
|---|---|---|---|---|
| 1 | Permitir | VM de servidor | Subred de Microsoft AD gestionado |
Cambio de contraseña de Kerberos (UDP/464, TCP/464) LDAP seguro (TCP/636, TCP/3269) |
Administrar Microsoft AD gestionado
Para gestionar Microsoft AD gestionado, debes usar una VM unida a un dominio. Para usar herramientas como el Centro de administración de Active Directory en esta VM, la VM también debe poder acceder a los servicios web de Active Directory expuestos por los controladores de dominio de Managed Microsoft AD.
| Acción | De | Para | Protocolos | |
|---|---|---|---|---|
| 1 | Permitir | VM de administrador | Subred de Microsoft AD gestionado | Servicios web de AD (TCP/9389) |
Conectar Microsoft AD gestionado a un Active Directory local
Para conectar Managed Microsoft AD a un Active Directory local, debes crear una relación de confianza entre bosques. Además, debes habilitar la resolución de nombres DNS entre Google Cloud y tu entorno local.
Creación y verificación de la confianza
Para crear y verificar una confianza entre bosques, los controladores de dominio de Microsoft AD gestionado y los controladores de dominio raíz de tu bosque local deben poder comunicarse bidireccionalmente.
Para habilitar la creación y la verificación de la confianza, configure su cortafuegos local para permitir el tráfico de entrada y salida que coincida con estas características:
| Acción | De | Para | Protocolos | |
|---|---|---|---|---|
| 1 | Permitir | AD on-premise | Microsoft AD gestionado |
DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Cambio de contraseña de Kerberos (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
| 2 | Permitir | Microsoft AD gestionado | AD on-premise |
DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Cambio de contraseña de Kerberos (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
Microsoft AD gestionado está preconfigurado para permitir el tráfico que coincida con estas características, por lo que no es necesario que configure reglas de cortafuegos adicionales enGoogle Cloud.
Resolver nombres de DNS desde el entorno local Google Cloud
Hay dos formas de permitir que las máquinas on-premise resuelvan nombres DNS en Managed Microsoft AD: la delegación de DNS y el reenvío de DNS condicional.
Delegación de DNS
El dominio DNS que utiliza el servicio gestionado de Microsoft AD puede ser un subdominio del dominio DNS que se utiliza en las instalaciones. Por ejemplo, puedes usar cloud.example.com para Microsoft AD gestionado y 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 DNS.
Cuando se usa la delegación de DNS, los intentos de resolver el nombre de DNS de un recursoGoogle Cloud primero consultan un servidor DNS local. A continuación, el servidor DNS redirige al cliente a Cloud DNS, que a su vez reenvía la solicitud a uno de tus controladores de dominio de Microsoft AD gestionado.
Para exponer Cloud DNS a redes on-premise, debes crear una política de servidor entrante. Se creará una dirección IP de reenvío entrante que formará parte de tu VPC.
Para usar la dirección de reenvío desde las instalaciones locales, configura tu cortafuegos local para permitir el tráfico de salida que coincida con las características que se indican a continuación.
| Acción | De | Para | Protocolos | |
|---|---|---|---|---|
| 1 | Permitir | AD on-premise | Microsoft AD gestionado |
DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Cambio de contraseña de Kerberos (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
| 2 | Permitir | Microsoft AD gestionado | AD on-premise |
DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Cambio de contraseña de Kerberos (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
Reenvío condicional de DNS
Es posible que el dominio DNS que usa Managed Microsoft AD no sea un subdominio del dominio DNS que se usa en las instalaciones. Por ejemplo, puede usar cloud.example.com para Microsoft AD gestionado mientras usa corp.example.local en las instalaciones.
En los casos en los que los dominios DNS no estén relacionados, puedes configurar el reenvío condicional de DNS en tu DNS de Active Directory local. Todas las consultas que coincidan con el nombre de DNS utilizado por el servicio gestionado de Microsoft AD se reenviarán a Cloud DNS.
Para usar el reenvío de DNS condicional, primero debes configurar una política de DNS que habilite el reenvío de DNS entrante. Para usar la dirección de reenvío resultante desde las instalaciones locales, configura tu cortafuegos local para permitir el tráfico de salida que coincida con las características que se indican a continuación.
| Acción | De | Para | Protocolos | |
|---|---|---|---|---|
| 1 | Permitir | AD on-premise | Dirección IP de reenvío de DNS | DNS (UDP/53, TCP/53) |
En el lado Google Cloud , crea una regla de cortafuegos para permitir el tráfico de entrada que cumpla estos criterios.
No es necesario configurar ninguna regla de cortafuegos para habilitar la comunicación del reenviador de DNS a Cloud DNS (2).
Resolver nombres de DNS on-premise desde Google Cloud
El servicio gestionado de Microsoft AD usa el reenvío condicional de DNS para resolver nombres de DNS en tu bosque local. Para permitir que los clientes que se ejecutan en Google Cloud resuelvan nombres de DNS gestionados por un Active Directory local, puedes crear una zona de reenvío privada en Cloud DNS que reenvíe las consultas a los controladores de dominio locales.
Para habilitar la resolución de nombres de DNS on-premise desde Google Cloud, configura tu cortafuegos on-premise para permitir el tráfico entrante según la siguiente tabla.
| Acción | De | Para | Protocolos | |
|---|---|---|---|---|
| 1 | Permitir | Microsoft AD gestionado | AD on-premise | DNS (UDP/53, TCP/53) |
| 2 | Permitir | Cloud DNS (35.199.192.0/19) | AD on-premise | DNS (UDP/53, TCP/53) |
Google Cloud permite el tráfico de salida correspondiente de forma predeterminada.
Acceder a recursos de Microsoft AD gestionado desde un entorno local
Si el bosque de Microsoft AD gestionado está configurado para confiar en tu bosque local, puede que quieras que los usuarios y las máquinas locales puedan acceder a los recursos del bosque de Microsoft AD gestionado.
Autenticarse en una VM desde un entorno local mediante Kerberos
Un usuario que haya iniciado sesión en un equipo local puede necesitar acceso a un servicio proporcionado por una máquina virtual que se ejecute en Google Cloud y sea miembro de un bosque de Microsoft AD gestionado. 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 VM del servidor mediante Kerberos, el equipo cliente debe obtener un ticket de Kerberos adecuado. Para ello, es necesario comunicarse con uno de los controladores de dominio locales, así como con uno de los controladores de dominio de Microsoft AD gestionado.
Para permitir que las VMs locales se autentiquen mediante Kerberos, configura tu cortafuegos local para que permita el siguiente tráfico de salida.
| Acción | De | Para | Protocolos | |
|---|---|---|---|---|
| 1 | Permitir | Equipo cliente (local) | Subred de Microsoft AD gestionado |
LDAP (UDP/389, TCP/389) Kerberos (UDP/88, TCP/88) |
| 2 | Permitir | Equipo 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) |
| 3 | Permitir | VM de servidor | Subred de Microsoft AD gestionado | Consulta Procesar inicios de sesión. |
En el lado de Google Cloud , crea reglas de cortafuegos para permitir el tráfico de entrada de (1) y (2). El tráfico de salida a Microsoft AD gestionado (3) está permitido de forma predeterminada.
Autenticarse en una VM desde un entorno local mediante NTLM
Cuando se usa NTLM para autenticar a un usuario de un bosque de Active Directory local en una VM de servidor unida a un bosque de Microsoft AD gestionado, los controladores de dominio de Microsoft AD gestionado deben comunicarse con los controladores de dominio locales.
Para permitir que las VMs locales se autentiquen mediante NTLM, configura tu cortafuegos local para que permita el tráfico de entrada y salida de la siguiente manera.
| Acción | De | Para | Protocolos | |
|---|---|---|---|---|
| 1 | Permitir | Equipo cliente (local) | VM del servidor (Google Cloud) | Protocolo utilizado por la aplicación, como HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 2 | Permitir | VM de servidor | Subred de Microsoft AD gestionado | Consulta Procesar inicios de sesión. |
| 3 | Permitir | Subred de Microsoft AD gestionado | AD on-premise |
LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
En el lado de Google Cloud , crea reglas de cortafuegos para permitir el tráfico de entrada de (1). El tráfico de salida de (2) y (3) está permitido de forma predeterminada.
Procesar los inicios de sesión de los usuarios del bosque local
Para procesar el inicio de sesión de un usuario del bosque local, una máquina virtual debe poder interactuar con Active Directory local. El conjunto exacto de protocolos que se usan depende del tipo de inicio de sesión que haya solicitado el cliente. Para admitir todos los casos habituales, configure su cortafuegos local para permitir el tráfico de entrada que coincida con estas características.
| Acción | De | Para | Protocolos | |
|---|---|---|---|---|
| 1 | Permitir | VM del servidor (Google Cloud) | Subred de AD 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) |
En función de tu caso práctico concreto, también puedes permitir los siguientes protocolos.
- Cambio de contraseña de Kerberos (UDP/464 y TCP/464)
- LDAP seguro (TCP/636 y TCP/3269)
En el lado de Microsoft AD gestionado, el tráfico de salida correspondiente está permitido de forma predeterminada.
En las VMs administrativas, puede que no tengas previsto permitir los inicios de sesión de los usuarios del bosque local. Sin embargo, una de las actividades que probablemente tengas que realizar en las VMs administrativas es gestionar las pertenencias a grupos. Cada vez que uses el selector de objetos para hacer referencia a un usuario o grupo de tu bosque local, el selector de objetos requerirá acceso a los controladores de dominio locales. Para que esto funcione, la máquina virtual administrativa requiere el mismo acceso a los controladores de dominio de Active Directory locales que para procesar los inicios de sesión de los usuarios del bosque local.
Acceder a recursos de Active Directory locales desde Google Cloud
Si tu bosque local está configurado para confiar en el bosque de Microsoft AD gestionado, es posible que quieras que los usuarios del bosque de Microsoft AD gestionado puedan acceder a los recursos locales.
Autenticarse en una máquina virtual local mediante Kerberos
Un usuario que haya iniciado sesión en una máquina virtual que se ejecute en Google Cloud y que sea miembro del bosque de Microsoft AD gestionado puede necesitar acceso a un servicio proporcionado por una máquina local que sea miembro de tu bosque local. Por ejemplo, el 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 el usuario se autentique en la máquina local mediante Kerberos, la máquina virtual debe obtener un ticket de Kerberos adecuado. Para ello, primero debe comunicarse con uno de los controladores de Microsoft AD gestionado y, después, con los controladores de dominio locales.
Para permitir que las máquinas virtuales on-premise se autentiquen mediante Kerberos, configura tu cortafuegos on-premise para que permita el tráfico entrante que coincida con las características que se indican a continuación.
| Acción | De | Para | Protocolos | |
|---|---|---|---|---|
| 1 | Permitir | VM de cliente (Google Cloud) | Subred de Microsoft AD gestionado |
Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) Implícito en procesar inicios de sesión |
| 2 | Permitir | VM de cliente (Google Cloud) | AD on-premise |
Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) |
| 3 | Permitir | VM de cliente (Google Cloud) | Servidor (local) | Protocolo utilizado por la aplicación, como HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
En el lado Google Cloud , el tráfico de salida correspondiente está permitido de forma predeterminada.
Autenticarse en una VM on-premise mediante NTLM
Cuando se usa NTLM para autenticar a un usuario del bosque de Microsoft AD gestionado en un servidor que está unido a tu bosque local, los controladores de dominio locales deben poder comunicarse con los controladores de dominio de Microsoft AD gestionado:
Para permitir que las máquinas virtuales on-premise se autentiquen mediante Kerberos, configura tu cortafuegos on-premise para que permita el tráfico entrante y saliente que coincida con estas características.
| Acción | De | Para | Protocolos | |
|---|---|---|---|---|
| 1 | Permitir | VM de cliente (Google Cloud) | Servidor (local) | Protocolo utilizado por la aplicación. Por ejemplo, HTTP (TCP/80, TCP/443) o RDP (TCP/3389). |
| 2 | Permitir | AD on-premise | Subred de Microsoft AD gestionado |
LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
En el lado de Google Cloud , el tráfico de salida de (1) y el tráfico de entrada de (2) están permitidos de forma predeterminada.
Procesar los inicios de sesión de los usuarios del bosque de Microsoft AD gestionado
Para procesar el inicio de sesión de un usuario del bosque de Managed Microsoft AD, un equipo que se ejecute de forma local debe poder interactuar con los controladores de dominio de Managed Microsoft AD. El conjunto exacto de protocolos utilizados depende del tipo de inicio de sesión que haya solicitado el cliente. Para admitir todos los casos prácticos habituales, debes permitir la siguiente combinación de protocolos.
| Acción | De | Para | Protocolos | |
|---|---|---|---|---|
| 1 | Permitir | Servidor (local) | Subred de Microsoft AD gestionado |
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) |
En función de tu caso práctico concreto, también puedes permitir los siguientes protocolos.
- Cambio de contraseña de Kerberos (UDP/464 y TCP/464)
- LDAP seguro (TCP/636 y TCP/3269)
Asegúrate de que tus cortafuegos locales permitan el tráfico de salida que coincida con estas características. No es necesario que configure ninguna regla de cortafuegos enGoogle Cloud para habilitar el tráfico de entrada correspondiente a Microsoft AD gestionado.
En los equipos administrativos, puede que no tengas previsto permitir el inicio de sesión de los usuarios del bosque de Microsoft AD gestionado. Una de las actividades que probablemente tengas que realizar en las máquinas administrativas es gestionar la pertenencia a grupos. Siempre que uses el selector de objetos para hacer referencia a un usuario o un grupo del bosque de Managed Microsoft AD, el selector de objetos requerirá acceso a los controladores de dominio de Managed Microsoft AD. Para que esto funcione, el equipo administrativo requiere el mismo acceso a los controladores de dominio de Microsoft AD gestionado que para procesar los inicios de sesión de los usuarios del bosque de Microsoft AD gestionado.