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
- Casos de uso comunes
- Acceder a Microsoft AD administrado desde su VPC
- Resolución de nombres de dominio
- Autenticarse en una máquina virtual mediante Kerberos
- Autenticarse en una máquina virtual mediante NTLM
- Inicio de sesión de unión y procesamiento de dominios
- Administrar Microsoft AD administrado
- Conexión de Microsoft AD administrado a un Active Directory local
- Creación y verificación de confianza
- Resolver nombres DNS de Google Cloud desde locales
- Delegación de DNS
- Reenvío de DNS condicional
- Resolver nombres DNS locales desde Google Cloud
- Acceso a los recursos administrados de Microsoft AD desde las instalaciones
- Autenticarse en una máquina virtual local mediante Kerberos
- Autenticación en una máquina virtual local mediante NTLM
- Procesamiento de inicios de sesión para usuarios del bosque local
- Acceso a los recursos locales de Active Directory desde Google Cloud
- Autenticarse en una máquina virtual local mediante Kerberos
- Autenticación en una máquina virtual local mediante NTLM
- Procesamiento de inicios de sesión para usuarios del bosque AD administrado de Microsoft
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.