Los controladores de dominio operados por el servicio administrado para Microsoft Active Directory exponen una serie de servicios, incluidos LDAP, DNS, Kerberos y RPC. Según sus casos prácticos, las máquinas virtuales (VM) implementadas en Google Cloud, así como las máquinas que se ejecutan en las instalaciones, pueden necesitar acceso a estos servicios para aprovechar Active Directory.
Para reducir la superficie de ataque de los controladores de dominio y las máquinas virtuales, debe usar firewalls para impedir el acceso a cualquier comunicación de red que no sea estrictamente necesaria. Este artículo describe cómo configurar los firewalls para acomodar los casos prácticos comunes de Active Directory y, al mismo tiempo, impedir el acceso a otras comunicaciones de red.
Inicio de sesión en comparación con la autenticación
Si bien los términos inicio de sesión y la autenticación a menudo se usan indistintamente, tienen diferentes significados en el contexto de la seguridad de Windows. Inicio de sesión describe el proceso que se lleva a cabo en el sistema al que un usuario obtiene acceso. Por el contrario, la autenticación la realiza la computadora en la que reside la cuenta del usuario.
Cuando usas una cuenta local para acceder a una máquina, la máquina de destino maneja el inicio de sesión y la autenticación. En un entorno de Active Directory, es más común usar un usuario de dominio para iniciar sesión. En ese caso, la máquina de destino se encarga del inicio de sesión, mientras que un controlador de dominio realiza la autenticación.
Para autenticar, un cliente puede usar Kerberos o NTLM. Una vez que un cliente se autentica, la máquina de destino debe procesar el inicio de sesión. Según el tipo de inicio de sesión que el cliente haya solicitado, puede que esto requiera interacción adicional con controladores de dominio mediante protocolos como Kerberos, NTLM, LDAP, RPC o SMB .
Debido a que la autenticación y el procesamiento de inicios de sesión requieren protocolos diferentes, es útil distinguir los dos conceptos para identificar la configuración correcta del firewall.
Casos prácticos habituales
Las siguientes secciones describen casos prácticos comunes para acceder a Microsoft AD administrado y muestran qué reglas de firewall debe configurar para cada caso práctico.
Si no planeas integrar Microsoft AD administrado con un Active Directory local, solo necesitas leer la primera sección de este artículo, Cómo acceder a Microsoft AD administrado desde tu VPC. Si pretendes crear una relación de confianza entre Microsoft AD administrado y un Active Directory local, se aplica todo el artículo.
Puedes usar los registros de reglas de firewall para analizar si es posible que se necesiten puertos adicionales. Debido a que la regla implícita de denegación de entrada tiene el registro inhabilitado, primero debes crear una regla de firewall personalizada de baja prioridad que rechace todo el tráfico de entrada, pero que tenga el registro de firewall habilitado. Con esta regla implementada, cualquier intento de conexión con errores hace que una entrada de registro se publique en Stackdriver. Como las reglas de firewall pueden producir un volumen significativo de registros, considera volver a inhabilitar el registro de firewall una vez que hayas completado tu análisis.
Accede a Microsoft AD administrado desde tu VPC
Cuando usas la red predeterminada para implementar Microsoft AD administrado, no se requiere más configuración para habilitar las VM en la VPC a fin de acceder a Active Directory.
Si personalizaste la configuración de VPC o las reglas de firewall, debes asegurarte de que la configuración de tu firewall permita la comunicación con Microsoft AD administrado. En las siguientes secciones, se describen las reglas de firewall que podrías 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 de DNS se envía al servidor de metadatos, que es el servidor de DNS predeterminado configurado para las VM de Compute Engine. Luego, el servidor de metadatos reenvía la consulta a una zona de reenvío de DNS privada de Cloud DNS creada por Microsoft AD administrado. Esta zona de reenvío reenvía la consulta al controlador de dominio adecuado.
No necesita configurar ninguna regla de firewall para habilitar este caso práctico. La comunicación a Cloud DNS siempre está permitida para máquinas virtuales en una VPC y Microsoft AD administrado permite solicitudes DNS reenviadas de Cloud DNS Cloud DNS de forma predeterminada.
Autentifica en una VM con Kerberos
Un usuario que accedió a una VM puede requerir acceso a un servicio proporcionado por una VM diferente. Por ejemplo, un usuario puede intentar abrir una conexión RDP, acceder a archivos compartidos o acceder a un recurso HTTP que requiere autenticación.
Para permitir que un usuario se autentique en la máquina virtual del servidor con Kerberos, la máquina virtual cliente debe obtener primero un ticket Kerberos apropiado de uno de los controladores de Microsoft AD administrado.
Para permitir que las máquinas virtuales se autentiquen en otra mediante Kerberos, las reglas de firewall deben permitir el acceso a la siguiente comunicación:
| Acción | De | A | Protocolos | |
|---|---|---|---|---|
| 1 | Allow | VM de cliente | Subred de Microsoft AD administrado |
Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) |
| 2 | Permitir | VM de cliente | VM del servidor | Protocolo que se usa para acceder a la VM, como HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 3 | Allow | VM del servidor | Subred de Microsoft AD administrado | Consulta cómo procesar inicios de sesión. |
Autentifica en una VM con NTLM
Si bien Windows opta a Kerberos sobre NTLM en la mayoría de los casos, es posible que a veces los clientes necesiten recurrir a NTLM para la autenticación. NTLM depende de la autenticación de paso y, por lo tanto, requiere que el servidor se comunique con uno de los controladores de dominio de Microsoft AD administrado para autenticar al usuario.
Para permitir que las máquinas virtuales autentiquen otras máquinas virtuales con NTLM, las reglas de firewall deben permitir el acceso a la siguiente comunicación:
| Acción | De | A | Protocolos | |
|---|---|---|---|---|
| 1 | Allow | VM de cliente | VM del servidor | Protocolo que se usa para acceder a la VM, como HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 2 | Permitir | VM de cliente | Subred de Microsoft AD administrado | Consulta cómo procesar inicios de sesión. |
Une dominios y procesa inicios de sesión
Para operar como miembro del dominio y procesar inicios de sesión de los usuarios, una máquina debe poder interactuar con Active Directory. El conjunto exacto de protocolos usados depende del tipo de inicio de sesión que solicitan los clientes individuales. Para admitir todas las situaciones comunes, debes permitir la siguiente combinación de protocolos.
| Acción | De | A | Protocolos | |
|---|---|---|---|---|
| 1 | Allow | VM del servidor | Subred de Microsoft AD administrado |
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, dependiendo de su caso práctico exacto, es posible que también desee permitir los siguientes protocolos:
| Acción | De | A | Protocolos | |
|---|---|---|---|---|
| 1 | Allow | VM del servidor | Subred de Microsoft AD administrado |
Cambio de contraseña de Kerberos (UDP/464, TCP/464) LDAP seguro (TCP/636, TCP/3269) |
Administra Microsoft AD administrado
Debe usar una VM unida al dominio para administrar Microsoft AD administrado. 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 Microsoft AD administrado.
| Acción | De | A | Protocolos | |
|---|---|---|---|---|
| 1 | Allow | VM de administrador | Subred de Microsoft AD administrado | Servicios web de AD (TCP/9389) |
Conecta Microsoft AD administrado a un Active Directory local
Para conectar Microsoft AD administrado a un Active Directory local, debes crear una relación de confianza entre los bosques. Además, debes habilitar la resolución de nombres de DNS entre Google Cloud y tu entorno local.
Creación y verificación de relación de confianza
Para crear y verificar una relación de confianza de bosque, los controladores de dominio de Microsoft AD administrado y los controladores de dominio raíz de su bosque local deben poder comunicarse bidireccionalmente.
Para habilitar la creación y verificación de la relación de confianza, configure su firewall local para permitir el ingreso y el tráfico de salida que coincida con estas características:
| Acción | De | A | Protocolos | |
|---|---|---|---|---|
| 1 | Allow | AD local | Microsoft AD administrado |
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) |
| 2 | Allow | Microsoft AD administrado | AD local |
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) |
Microsoft AD administrado está preconfigurado para permitir que el tráfico coincida con estas características, por lo que no necesitas configurar reglas de firewall adicionales en Google Cloud.
Resuelve nombres de Google Cloud DNS desde las instalaciones
Existen dos maneras de permitir que las máquinas locales resuelvan los nombres de DNS en Microsoft AD administrado: delegación de DNS y reenvío de DNS condicional.
Delegación de DNS
El dominio de DNS que usa Microsoft AD administrado puede ser un subdominio del dominio de DNS usado de forma local. Por ejemplo, puedes usar cloud.example.com para Microsoft AD administrado mientras usas example.com de manera local. Para permitir que los clientes locales resuelvan los nombres de DNS de los recursos de Google Cloud, puedes configurar la delegación de DNS.
Cuando se usa la delegación de DNS, los intentos de resolver el nombre de DNS de un recurso de Google Cloud primero consultan un servidor DNS local. Luego, el servidor DNS redirecciona al cliente a Cloud DNS, que, a su vez, reenvía la solicitud a uno de los controladores de dominio de Microsoft AD administrado.
Exponer Cloud DNS a redes locales requiere crear una política de servidor entrante. Esto creará una dirección IP de servidor de reenvío entrante que forma parte de su VPC.
Para usar la dirección del servidor re reenvío desde las instalaciones, configure su firewall local para permitir el tráfico de salida que coincida con las características a continuación.
| Acción | De | A | Protocolos | |
|---|---|---|---|---|
| 1 | Allow | AD local | Microsoft AD administrado |
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) |
| 2 | Allow | Microsoft AD administrado | AD local |
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) |
Reenvío de DNS condicional
El dominio de DNS que usa Microsoft AD administrado puede no ser un subdominio del dominio de DNS usado de forma local. Por ejemplo, puedes usar cloud.example.com para Microsoft AD administrado cuando usas corp.example.local de forma local.
En situaciones donde los dominios DNS no están relacionados, puede configurar el reenvío de DNS condicional en su DNS de Active Directory local. Todas las consultas que coincidan con el nombre DNS utilizado por Microsoft AD administrado se enviarán a Cloud DNS.
Para utilizar el reenvío de DNS condicional, primero debe configurar una política de DNS que permita el reenvío DNS entrante. Para usar la dirección del servidor re reenvío resultante desde las instalaciones, configure su firewall local para permitir el tráfico de salida que coincida con las características a continuación.
| Acción | De | A | Protocolos | |
|---|---|---|---|---|
| 1 | Allow | AD local | Dirección IP de reenvío de DNS | DNS (UDP/53, TCP/53) |
En Google Cloud, crea una regla de firewall para permitir el tráfico de entrada que cumpla con estos criterios.
No necesita configurar ninguna regla de firewall para habilitar la comunicación desde el servidor re reenvío DNS a Cloud DNS (2).
Resuelve nombres DNS locales en Google Cloud
Microsoft AD administrado usa reenvío de DNS condicional para resolver nombres de DNS en tu bosque local. Para permitir que los clientes que se ejecutan en Google Cloud resuelvan los nombres de DNS que administra un Active Directory local, puedes crear una zona de reenvío privada en el DNS de Cloud DNS que reenvía las consultas a los controladores de dominio 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 siguiente tabla.
| Acción | De | A | Protocolos | |
|---|---|---|---|---|
| 1 | Allow | Microsoft AD administrado | AD local | DNS (UDP/53, TCP/53) |
| 2 | Permitir | Cloud DNS (35.199.192.0/19) | AD local | DNS (UDP/53, TCP/53) |
Google Cloud permite el tráfico de salida correspondiente de forma predeterminada.
Accede a recursos de Microsoft AD administrado desde las instalaciones
Si el bosque de Microsoft AD administrado está configurado para confiar en su bosque local, es posible que desee que los usuarios y las máquinas locales puedan acceder a los recursos en el bosque de Microsoft AD administrado.
Autentifica en una VM desde las instalaciones con Kerberos
Un usuario que ha iniciado sesión en una máquina local puede requerir acceso a un servicio proporcionado por una VM que se ejecuta en Google Cloud y es miembro de un bosque de Microsoft AD administrado. Por ejemplo, un usuario puede intentar abrir una conexión RDP, acceder a archivos compartidos o acceder a un recurso HTTP que requiere autenticación.
Para permitir que los usuarios se autentiquen en la máquina virtual del servidor con Kerberos, la máquina del cliente debe obtener un ticket Kerberos adecuado. Esto requiere comunicarse con uno de los controladores de dominio locales, así como con uno de los controladores de dominio de Microsoft AD administrado.
Para permitir que las máquinas virtuales locales se autentiquen con Kerberos, configure su firewall local para permitir el siguiente tráfico de salida.
| Acción | De | A | Protocolos | |
|---|---|---|---|---|
| 1 | Permitir | Máquina cliente (local) | Subred de Microsoft AD administrado |
LDAP (UDP/389, TCP/389) Kerberos (UDP/88, TCP/88) |
| 2 | Allow | Máquina cliente (local) | VM del servidor (Google Cloud) | Protocolo que usa la aplicación, como HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 3 | Allow | VM del servidor | Subred de Microsoft AD administrado | Consulta cómo procesar inicios de sesión. |
En Google Cloud, crea reglas de firewall para permitir el tráfico de entrada para (1) y (2). El tráfico de salida a Microsoft AD administrado (3) está permitido por defecto.
Autentifica en una VM desde las instalaciones con NTLM
Cuando se utiliza NTLM para autenticar a un usuario de un bosque de Active Directory local en una VM del servidor unida a un bosque de Microsoft AD administrado, los controladores de dominio de Microsoft AD administrado deben comunicarse con los controladores de dominio local.
Para permitir que las máquinas virtuales locales se autentiquen con NTLM, configure su firewall local para permitir tráfico de salida y entrada de la siguiente manera.
| Acción | De | A | Protocolos | |
|---|---|---|---|---|
| 1 | Permitir | Máquina cliente (local) | VM del servidor (Google Cloud) | Protocolo que usa la aplicación, como HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 2 | Allow | VM del servidor | Subred de Microsoft AD administrado | Consulta cómo procesar inicios de sesión. |
| 3 | Permitir | Subred de Microsoft AD administrado | AD local |
LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
En Google Cloud, crea reglas de firewall para permitir el tráfico de entrada para (1). El tráfico de salida para (2) y (3) está permitido según la configuración predeterminada.
Procesa inicios de sesión para usuarios del bosque local
A fin de procesar un inicio de sesión para un usuario del bosque local, una VM debe poder interactuar con el Active Directory local. El conjunto exacto de protocolos usados depende del tipo de inicio de sesión que el cliente solicitó. A fin de admitir todas las situaciones comunes, configura tu firewall local para permitir el tráfico de entrada que coincida con estas características.
| Acción | De | A | 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) GC LDAP (TCP/3268) |
Dependiendo de su caso práctico exacto, es posible que también desee permitir los siguientes protocolos.
- Cambio de contraseña de Kerberos (UDP/464, TCP/464)
- LDAP seguro (TCP/636, TCP/3269)
En Microsoft AD administrado, el tráfico de salida correspondiente está permitido de forma predeterminada.
En las VM administrativas, es posible que no planifiques permitir inicios de sesión de los usuarios del bosque local. Sin embargo, una actividad que probablemente debas realizar en las VM administrativas es la administración de las membresías de grupo. Siempre que uses el selector de objetos para hacer referencia a un usuario o grupo en tu bosque local, el selector de objetos requerirá acceso a los controladores de dominio locales. Para que esto funcione, la VM administrativa requiere el mismo acceso a tus controladores de dominio locales de Active Directory que para procesar los inicios de sesión de los usuarios del bosque local.
Accede a recursos locales de Active Directory desde Google Cloud
Si su bosque local está configurado para confiar en el bosque administrado de Microsoft AD, es posible que desee que los usuarios del bosque de Microsoft AD administrado puedan acceder a los recursos locales.
Autentifica en una VM local con 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 Microsoft AD administrado puede requerir acceso a un servicio proporcionado por una máquina local que es miembro de su bosque local. Por ejemplo, el usuario podría intentar abrir una conexión RDP, acceder a archivos compartidos o acceder a un recurso HTTP que requiera autenticación.
Para permitir que el usuario se autentique en la máquina local con Kerberos, la VM debe obtener un ticket Kerberos apropiado. Esto requiere comunicarse primero con uno de los controladores de Microsoft AD administrado y, luego, con los controladores de dominio locales.
Para permitir que las máquinas virtuales locales se autentiquen con Kerberos, configure su firewall local para permitir el tráfico de entrada que coincida con las características a continuación.
| Acción | De | A | Protocolos | |
|---|---|---|---|---|
| 1 | Permitir | VM de cliente (Google Cloud) | Subred de Microsoft AD administrado |
Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) Implícito en el procesamiento de inicios de sesión |
| 2 | Permitir | VM de cliente (Google Cloud) | AD local |
Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) |
| 3 | Permitir | VM de cliente (Google Cloud) | Máquina del servidor (local) | Protocolo que usa la aplicación, como HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
En Google Cloud, el tráfico de salida correspondiente está permitido de forma predeterminada.
Autentifica en una VM local con NTLM
Cuando se utiliza NTLM para autenticar a un usuario del bosque de Microsoft AD administrado en una máquina servidor que está unida a su bosque local, los controladores de dominio locales deben poder comunicarse con los controladores de dominio de Microsoft AD administrado:
Para permitir que las máquinas virtuales locales se autentiquen con Kerberos, configure su firewall local para permitir el tráfico de salida y entrada que coincida con estas características.
| Acción | De | A | Protocolos | |
|---|---|---|---|---|
| 1 | Permitir | VM de cliente (Google Cloud) | Máquina del servidor (local) | Protocolo que usa la aplicación, por ejemplo HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 2 | Allow | AD local | Subred de Microsoft AD administrado |
LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
En Google Cloud, el tráfico de salida para (1) y el tráfico de entrada para (2) están permitidos de forma predeterminada .
Procesa inicios de sesión para usuarios del bosque de Microsoft AD administrado
A fin de procesar un inicio de sesión para un usuario del bosque de Microsoft AD administrado, una máquina que se ejecuta de manera local debe poder interactuar con los controladores de dominio de Microsoft AD administrado. El conjunto exacto de protocolos usados depende del tipo de inicio de sesión que el cliente solicitó. Para admitir todas las situaciones comunes, debes permitir la siguiente combinación de protocolos.
| Acción | De | A | Protocolos | |
|---|---|---|---|---|
| 1 | Allow | Máquina del servidor (local) | Subred de Microsoft AD administrado |
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 práctico exacto, es posible que también desee permitir los siguientes protocolos.
- Cambio de contraseña de Kerberos (UDP/464, TCP/464)
- LDAP seguro (TCP/636, TCP/3269)
Asegúrate de que tus firewalls locales permitan el tráfico de salida que coincida con estas características. No necesitas configurar ninguna regla de firewall en Google Cloud para habilitar el tráfico de entrada correspondiente a Microsoft AD administrado.
En las máquinas administrativas, es posible que no planifiques permitir accesos de los usuarios del bosque de Microsoft AD administrado. Una de las actividades que probablemente tengas que realizar en las máquinas administrativas es administrar las membresías de grupo. Cuando uses el selector de objetos para hacer referencia a un usuario o grupo desde el bosque de Microsoft AD administrado, el selector de objetos requerirá acceso a los controladores de dominio de Microsoft AD administrado. Para que esto funcione, la máquina administrativa requiere el mismo acceso a los controladores de dominio de Microsoft AD administrado que para procesar los inicios de sesión de los usuarios del bosque de Microsoft AD administrado.