Federa Google Cloud con Active Directory: Introducción

Este artículo es la primera parte de una serie de varias partes en las que se analiza cómo extender una solución existente de administración de identidades basada en Active Directory a Google Cloud. En él se describe cómo establecer mecanismos coherentes de autenticación y autorización en un entorno de procesamiento híbrido. Si bien el artículo se enfoca en el uso de Cloud Identity, parte del debate se aplica a G Suite.

La serie consta de estas partes:

Los departamentos de TI de las empresas a menudo dependen de Active Directory para administrar las cuentas de usuario y controlar el acceso a las aplicaciones y los recursos de procesamiento. Esto hace que Active Directory sea un pilar principal de su panorama de TI y su infraestructura local.

Cuando extiendes el panorama de TI existente a Google Cloud como parte de una estrategia híbrida, quieres mantener un único punto en el que administres las identidades. Tener una única solución de administración de identidades minimiza el esfuerzo administrativo y ayuda a garantizar que los usuarios y las aplicaciones puedan autenticarse de forma segura en un entorno híbrido.

En este artículo, se comparan las estructuras lógicas de Active Directory y GCP, y se analizan las formas en las que puedes mapear cuentas de Active Directory a cuentas de usuarios y grupos en GCP para implementar la federación. Al final del artículo, hay un diagrama de flujo que te ayudará a determinar el mejor enfoque para la asignación entre Active Directory y GCP en tu situación.

En este artículo, se supone que estás familiarizado con Active Directory.

Implementa la federación

Google Cloud usa las identidades de Google para la autenticación y administración de acceso. Para poder acceder a cualquier recurso de Google Cloud, un empleado debe tener una identidad de Google. El mantenimiento manual de las identidades de Google para cada empleado sería engorroso siendo que todos los empleados ya tienen una cuenta en Active Directory. Mediante la federación de identidades de usuario entre Active Directory y Google Cloud, puedes automatizar el mantenimiento de las Cuentas de Google y vincular su ciclo de vida con las cuentas de Active Directory. La federación ayuda a garantizar lo siguiente:

  • Active Directory sigue siendo la única fuente de información para la administración de identidades.
  • Se crea una Cuenta de Google de forma automática para todas las cuentas de usuario en Active Directory o un subconjunto seleccionado.
  • Si una cuenta se inhabilita o se borra de Active Directory, la Cuenta de Google correspondiente también se suspende o se borra. Por el contrario, suspender o borrar una Cuenta de Google no genera ningún efecto en Active Directory, ya que la Cuenta de Google se volverá a crear de forma automática durante la sincronización siguiente.
  • Active Directory controla la autenticación de usuario, por lo que no necesitas sincronizar contraseñas con Google Cloud.

Del lado de Google, puedes usar Cloud Identity para configurar un directorio de cuenta de usuario privado en el que puedes crear y administrar Cuentas de Google. La federación de Active Directory con Cloud Identity se divide en dos partes:

Federación de Active Directory con Cloud Identity

  • Sincronización de cuentas: Las cuentas de usuario y los grupos relevantes se sincronizan de forma periódica de Active Directory a Cloud Identity. Con este proceso, se garantiza que cuando crees una cuenta nueva en Active Directory puedas hacer referencia a ella en Google Cloud, incluso antes de que el usuario asociado acceda por primera vez. Este proceso también garantiza que los retiros de cuentas se propaguen.

    La sincronización es unidireccional, lo que significa que los cambios en Active Directory se repiten en Cloud Identity, pero no al revés. Además, la sincronización no incluye contraseñas. En una configuración federada, Active Directory es el único sistema que administra estas credenciales.

  • Inicio de sesión único: Cada vez que un usuario necesita autenticarse en Google Cloud, Cloud Identity delega la autenticación a Active Directory mediante el protocolo de lenguaje de marcado para confirmación de seguridad (SAML). Esta delegación garantiza que solo Active Directory administre las credenciales de los usuarios y que se apliquen todas las políticas o los mecanismos de autenticación de varios factores (MFA) correspondientes. Sin embargo, para que un inicio de sesión tenga éxito, la cuenta respectiva debe sincronizarse antes.

Para implementar la federación, puedes usar las siguientes herramientas:

  • Google Cloud Directory Sync es una herramienta gratuita que proporciona Google para implementar el proceso de sincronización. Cloud Directory Sync se comunica con Cloud Identity a través de la capa de conexión segura (SSL) y, por lo general, se ejecuta en el entorno de procesamiento existente.
  • Microsoft proporciona los Servicios de federación de Active Directory (AD FS) como parte de Windows Server. Con AD FS, puedes usar Active Directory para la autenticación federada. AD FS por lo general se ejecuta dentro del entorno de procesamiento existente.

Debido a que las API de Cloud Identity están disponibles de forma pública y SAML es un estándar abierto, hay muchas herramientas disponibles para implementar la federación. En este artículo, el enfoque se da en el uso de Cloud Directory Sync y AD FS.

Estructura lógica de Active Directory

En una infraestructura de Active Directory, el componente de nivel superior es el bosque. El bosque sirve como contenedor para uno o más dominios y su nombre deriva del dominio raíz del bosque. Los dominios en un bosque de Active Directory confían entre sí, lo que permite que los usuarios autenticados en un dominio accedan a los recursos de otro dominio. A menos que estén conectados mediante relaciones de confianza entre sí, los bosques separados no confían unos en otros de forma predeterminada y los usuarios que se autentican en un bosque no pueden acceder a recursos que se encuentren en otro.

Infraestructura de Active Directory

Los dominios de Active Directory son contenedores para administrar recursos y se los considera límites administrativos. Tener varios dominios en un bosque es una forma de simplificar la administración o aplicar una estructura adicional, pero los dominios en un bosque no representan límites de seguridad.

Estructura lógica de Google Cloud

En Google Cloud, debes administrar recursos en organizaciones, que puedes segmentar mediante carpetas y proyectos. Las organizaciones, carpetas y proyectos, por lo tanto, tienen un propósito similar a los dominios de Active Directory.

Active Directory trata las cuentas de usuario como recursos, por lo que la administración y la autenticación de cuentas de usuario están vinculadas a los dominios. Por el contrario, Google Cloud no administra las cuentas de usuario de una organización, excepto las cuentas de servicio. En cambio, Google Cloud depende de Cloud Identity o G Suite para administrar las cuentas de usuario.

Con Cloud Identity, puedes crear y administrar directorios privados para cuentas de usuario y grupos. Cada uno de estos directorios se administra de forma independiente y puede, por ejemplo, diferir en los métodos de autenticación que permiten o las políticas de contraseña que aplican. En Cloud Identity, los directorios se conocen como cuentas de Cloud Identity y se identifican por nombres de dominio.

Infraestructura de identidad de GCP

De manera similar a cómo un bosque y un dominio raíz de bosque siempre se crean de forma conjunta en Active Directory, una cuenta de Cloud Identity siempre se crea en paralelo con una organización de Google Cloud. Además, así como un dominio raíz de bosque y un bosque comparten el mismo nombre y no se pueden desconectar uno del otro, la cuenta de Cloud Identity y la organización de Google Cloud comparten el mismo nombre y están vinculadas entre sí. Sin embargo, una organización de Google Cloud puede hacer referencia a usuarios y grupos de cuentas de Cloud Identity adicionales.

Integra Active Directory y Google Cloud

A pesar de ciertas similitudes entre la estructura lógica de Active Directory y Google Cloud, no existe ningún mapeo entre las dos estructuras que funcione de igual manera en todas las situaciones. En su lugar, el enfoque correcto para integrar los dos sistemas y mapear la estructura depende de varios factores:

  • Cómo asignar dominios y bosques a las cuentas de Cloud Identity
  • Cómo asignar dominios DNS
  • Cómo asignar cuentas de usuario
  • Cómo asignar grupos

Las secciones siguientes analizan cada uno de estos factores.

Asigna bosques

A menudo se usa más de un dominio de Active Directory para administrar las identidades y el acceso en toda la empresa, sobre todo en las organizaciones más grandes. Cuando planeas federar Active Directory y Google Cloud, el primer factor que debes considerar es la topología de la infraestructura de Active Directory.

Un bosque, un dominio

Un bosque, un dominio

Cuando un bosque incluye solo un dominio, puedes mapear todo el bosque de Active Directory a una cuenta de Cloud Identity. Esta cuenta proporciona la base para una sola organización de Google Cloud que puedes usar a fin de administrar tus recursos de Google Cloud.

En un entorno de un solo dominio, los controladores de dominio y los servidores de catálogo global proporcionan acceso a todos los objetos que se administran en Active Directory. En la mayoría de los casos, puedes ejecutar una instancia única de Cloud Directory Sync a fin de sincronizar cuentas de usuarios y grupos en Google Cloud y mantener una sola instancia o flota de AD FS para administrar el inicio de sesión único.

Un bosque, varios dominios

Un bosque, varios dominios

Cuando un bosque contiene varios dominios de Active Directory, puedes organizarlos en uno o más árboles de dominios. En ambos casos, puedes mapear todo el bosque a una sola cuenta de Cloud Identity. Esta cuenta proporciona la base para una sola organización de Google Cloud que puedes usar a fin de administrar tus recursos de Google Cloud.

En un entorno de múltiples dominios, existe una diferencia entre la información que se puede recuperar de un controlador de dominio y la que se puede consultar desde un servidor de catálogo global. Mientras que los controladores de dominio solo entregan datos de su dominio local, los servidores de catálogo global proporcionan acceso a la información de todos los dominios del bosque. Cabe destacar que los datos que entregan los servidores de catálogo global son parciales y carecen de ciertos atributos de LDAP. Esta limitación puede afectar la forma en que configuras Cloud Directory Sync para sincronizar grupos.

Según cómo planees mapear grupos, federar un bosque de varios dominios con Google Cloud requiere una o más instancias de Cloud Directory Sync, pero solo se necesita una instancia o flota de AD FS para manejar el inicio de sesión único.

Varios bosques con relación de confianza entre sí

Varios bosques con relación de confianza entre sí

En organizaciones más grandes, es común tener más de un bosque de Active Directory, a menudo como resultado de una fusión o adquisición. Puedes combinar estos bosques con un fondo común bidireccional para que los usuarios puedan compartir y acceder a los recursos a través de los límites de un solo bosque.

Si todos los bosques tienen una relación de confianza bidireccional con otro bosque, puedes mapear todo el entorno a una sola cuenta de Cloud Identity. Esta cuenta proporciona la base para una organización de Google Cloud individual que puedes usar a fin de administrar tus recursos de Google Cloud.

Aunque los servidores de catálogo global proporcionan acceso a los datos desde varios dominios, su alcance está limitado a un solo bosque. Por lo tanto, en un entorno de varios bosques, debes consultar varios controladores de dominio o servidores de catálogo global para obtener, por ejemplo, una lista completa de cuentas de usuario. Como resultado de esta limitación, la federación de un entorno de varios bosques con Google Cloud requiere al menos una instancia de Cloud Directory Sync por bosque. Las relaciones de confianza entre bosques permiten que la autenticación de usuarios funcione a través de límites de bosques, por lo que una sola instancia o flota de AD FS es suficiente para manejar el inicio de sesión único.

Si tu entorno abarca varios bosques sin una relación de confianza entre ellos, pero todos los dominios de Active Directory relevantes para la federación con Google Cloud están conectados a través de relaciones de confianza externas, se aplican las mismas consideraciones.

Varios bosques sin una relación de confianza entre sí

Varios bosques sin una relación de confianza entre sí

En el entorno ilustrado aquí, no es posible autenticar o acceder a los recursos a través de los límites de los bosques. Tampoco es posible que una sola instancia o flota de AD FS maneje las solicitudes de inicio de sesión único para usuarios de todos los bosques.

Por lo tanto, no es posible asignar bosques múltiples que carezcan de fondos comunes entre bosques a una sola cuenta de Cloud Identity. En su lugar, cada bosque debe mapearse a una cuenta de Cloud Identity separada, lo que implica ejecutar al menos una instancia de Cloud Directory Sync y un servidor o flota de AD FS por bosque.

En Google Cloud, se crea una organización distinta para cada cuenta de Cloud Identity. En la mayoría de los casos, no es necesario mantener múltiples organizaciones separadas. Puedes seleccionar una de las organizaciones y asociarla con las otras cuentas de Cloud Identity, lo que crea una organización que está federada con múltiples bosques de Active Directory. Las otras organizaciones quedan sin uso.

Asigna dominios DNS

El DNS cumple una función vital en Active Directory y en Cloud Identity. El segundo factor que debes considerar cuando planeas federar Active Directory y Google Cloud es cómo compartir o mapear dominios DNS entre Active Directory y Google Cloud.

Uso de dominios DNS en Active Directory

En un bosque de Active Directory, los dominios DNS se usan en varios lugares:

  • Dominios DNS de Active Directory: Cada dominio de Active Directory corresponde a un dominio DNS. Este dominio puede ser global, como corp.example.com, o puede ser un nombre de dominio local como corp.local o corp.internal.
  • Dominios de intercambio de correo (MX): Las direcciones de correo electrónico usan un dominio DNS. En algunos casos, este dominio es el mismo que el dominio DNS de Active Directory, pero en muchos casos se usa un dominio diferente, a menudo más corto, como example.com. Lo ideal es que las cuentas de usuario en Active Directory tengan la dirección de correo electrónico asociada con el atributo opcional mail.
  • Dominios de sufijo UPN: Estos dominios se usan para Nombres principales de usuario (UPN). De forma predeterminada, el dominio DNS de Active Directory del dominio de la cuenta se usa para compilar un UPN. Por lo tanto, para un usuario john en el dominio corp.example.com, el UPN predeterminado es john@corp.example.com. Sin embargo, puedes configurar un bosque para que use dominios DNS adicionales como sufijos UPN que no corresponden a los dominios DNS de Active Directory ni a los dominios MX. Los UPN son opcionales y se almacenan en el campo userPrincipalName de la cuenta de usuario.
  • Dominios de extremos: Por lo general, a los servidores públicos como los servidores de AD FS se les asigna un nombre de DNS, como login.external.example.com. El dominio que se usa para estos fines puede superponerse con el dominio MX, el sufijo UPN o el dominio DNS de Active Directory, o puede ser un dominio diferente.

Uso de dominios DNS en Google Cloud

El Acceso con Google, en el que se basa Google Cloud para la autenticación, usa direcciones de correo electrónico a fin de identificar a los usuarios. El uso de direcciones de correo electrónico garantiza que sean únicas a nivel global y, también, permite que Google Cloud les envíe mensajes de notificación.

El Acceso con Google determina el directorio o el proveedor de identidad que se usará para autenticar a un usuario en función de la parte del dominio de las direcciones de correo electrónico, después del símbolo @. Para una dirección de correo electrónico en la que se usa el dominio gmail.com, por ejemplo, el Acceso con Google usa el directorio de cuentas de usuario de Gmail a fin de realizar la autenticación.

Uso de dominios DNS en GCP

Cuando te registras en una cuenta de G Suite o Cloud Identity, lo que haces es crear un directorio privado que Google Identity Platform puede usar para la autenticación. De la misma manera que el directorio de Gmail está asociado con el dominio gmail.com, las cuentas de G Suite y Cloud Identity deben estar asociadas a un dominio personalizado. Se usan tres tipos diferentes de dominios:

  • Dominio principal: Identifica el directorio de Cloud Identity y también se usa como el nombre de la organización en Google Cloud. Cuando te registras en Cloud Identity, debes especificar este nombre de dominio.
  • Dominio secundario: Junto con el dominio principal, puedes asociar dominios secundarios adicionales con un directorio de Cloud Identity. Cada cuenta en el directorio se asocia al dominio principal o a uno de los dominios secundarios. Por lo tanto, dos cuentas, johndoe@example.com y johndoe@secondary.example.com, se consideran cuentas separadas si example.com es el dominio principal y secondary.example.com el dominio secundario.
  • Dominio de alias: un dominio de alias es una alternativa para el dominio principal. Es decir, johndoe@example.com y johndoe@alias.example.com hacen referencia a la misma cuenta si alias.example.com se configura como un dominio de alias. Un dominio de alias solo puede proporcionar un nombre alternativo para el dominio principal; no es posible agregar dominios de alias para dominios secundarios.

Todos los dominios deben cumplir los siguientes requisitos:

  • Deben ser nombres de dominio DNS globales válidos. No se permiten los nombres de dominio locales, como corp.local o corp.internal, que por lo general se usan en Active Directory. Durante la configuración, es posible que necesites acceso de administrador a las zonas DNS respectivas para verificar la propiedad del dominio.
  • Un dominio, como example.com, solo puede hacer referencia a un directorio único. Sin embargo, puedes usar diferentes subdominios, como subdomain.example.com, para hacer referencia a directorios diferentes.
  • Los dominios principales y secundarios deben tener un registro MX válido. De esta manera, los mensajes enviados a las direcciones de correo electrónico que se forman con este nombre de dominio se pueden entregar de forma correcta.

Para habilitar la sincronización entre los directorios, se requiere cierta asignación entre los dominios de Active Directory y los que usa Cloud Identity. Determinar la asignación correcta depende de cómo uses Active Directory y requiere un análisis más detallado de cómo se identifican las cuentas de usuario en un bosque de Active Directory y cómo se pueden asignar a Cloud Identity.

Mapea cuentas de usuario

El tercer factor que debes considerar cuando planificas la federación de Active Directory y Google Cloud es cómo mapear cuentas de usuario entre Active Directory y Cloud Identity.

Identifica cuentas de usuario en Active Directory

De forma interna, Active Directory usa dos ID para identificar de manera única las cuentas de usuario:

  • objectGUID: Este ID global único se genera cuando se crea un usuario y nunca cambia.
  • objectSID: El SID, o identificador de seguridad, se usa para todas las verificaciones de acceso. Si bien este ID es único y estable dentro de un dominio, es posible que a una cuenta se le asigne un SID nuevo cuando se traslade a un dominio diferente en el bosque.

Ninguno de estos ID es significativo para los usuarios, por lo que Active Directory ofrece dos formas sencillas de identificar las cuentas de usuario:

  • UPN (userPrincipalName): La forma preferida de identificar una cuenta de usuario es mediante UPN. Los UPN siguen el formato RFC 822 de las direcciones de correo electrónico y se crean mediante la combinación del nombre de usuario con un dominio de sufijo UPN, como en johndoe@corp.example.com. A pesar de ser la forma preferida de identificar cuentas de usuario, los UPN son opcionales, por lo que algunas cuentas de usuario en el bosque de Active Directory pueden carecer de UPN.

    Aunque se recomienda que los UPN sean direcciones de correo electrónico válidas, Active Directory no aplica esta práctica.

  • Nombre de inicio de sesión anterior a Windows 2000 (sAMAccountName): Este nombre combina el nombre de dominio NetBIOS y el nombre de usuario mediante el formato domain\user, como en corp\johndoe. Aunque estos nombres se consideran heredados, todavía suelen usarse y son el único identificador obligatorio de una cuenta de usuario.

En particular, Active Directory no usa la dirección de correo electrónico del usuario (mail) para identificar a los usuarios. En consecuencia, este campo no es obligatorio ni debe ser único en un bosque.

Todos estos identificadores se pueden cambiar en cualquier momento.

Asigna identidades de cuenta

Asignar las cuentas de Active Directory a las de Cloud Identity requiere dos datos para cada cuenta de usuario:

  • Un ID único y estable que puedes usar durante la sincronización para rastrear qué cuenta de Active Directory corresponde a qué cuenta de Cloud Identity. Del lado de AD, objectGUID es adecuado para este fin.
  • Una dirección de correo electrónico en la que la parte del dominio corresponde a un dominio principal, secundario o de alias de Cloud Identity. Debido a que esta dirección de correo electrónico se usará en todo Google Cloud, asegúrate de que la dirección sea significativa. Derivar una dirección a partir de objectGUID no es práctico como lo son otras direcciones de correo electrónico generadas de forma automática.

En una cuenta de usuario de Active Directory, dos campos son candidatos para proporcionar una dirección de correo electrónico de Cloud Identity: userPrincipalName y mail.

Mapea por nombre principal del usuario

Usar el campo userPrincipalName requiere que se cumplan dos criterios para todas las cuentas sujetas a la sincronización:

  • Los UPN deben ser direcciones de correo electrónico válidas. Todos los dominios que se usan como dominios de sufijo UPN también deben ser dominios MX y deben configurarse de forma que un correo electrónico que se envía al UPN de un usuario le llegue a la carpeta Recibidos.
  • Las asignaciones de UPN deben estar completas. Todas las cuentas de usuario sujetas a la sincronización deben tener un UPN asignado. El siguiente comando de PowerShell puede ayudarte a encontrar cuentas que carecen de UPN:

    Get-ADUser -LDAPFilter "(!userPrincipalName=*)"

Si se cumplen estos dos criterios, puedes asignar UPN de forma segura a las direcciones de correo electrónico de Cloud Identity. Puedes usar uno de los dominios de sufijo UPN como dominio principal en Cloud Identity y agregar cualquier otro como dominio secundario.

Si no se cumple uno de los criterios, aún puedes mapear UPN a las direcciones de correo electrónico de Cloud Identity, pero se aplican las siguientes advertencias:

  • Si los UPN no son direcciones de correo electrónico válidas, es posible que los usuarios no reciban los correos electrónicos de notificación que envía Google Cloud, lo que puede hacer que se pierda información importante.
  • Las cuentas sin UPN se ignorarán durante la sincronización.
  • Puedes configurar la sincronización para reemplazar el dominio de sufijo UPN por un dominio diferente. Sin embargo, este enfoque puede crear duplicados cuando usas múltiples dominios de sufijo UPN en un bosque, ya que todos serán reemplazados por un solo dominio. En caso de duplicados, solo puede sincronizarse una cuenta.

Una de las ventajas principales de usar UPN para asignar usuarios es que se garantiza que las UPN sean únicas en un bosque y usen un conjunto de dominios seleccionados, lo que ayuda a evitar posibles problemas de sincronización.

Mapea por dirección de correo electrónico

Usar el campo mail requiere que se cumplan los siguientes criterios para todas las cuentas sujetas a sincronización:

  • Los mapeos de correo electrónico deben estar completos. Todas las cuentas de usuario sujetas a la sincronización deben tener el campo mail propagado. El siguiente comando de PowerShell puede ayudarte a encontrar cuentas para las cuales este campo no está propagado:

    Get-ADUser -LDAPFilter "(!mail=*)"
  • Las direcciones de correo electrónico deben usar un conjunto de dominios seleccionados que te pertenezcan. Si algunas de tus cuentas usan direcciones de correo electrónico que hacen referencia a empresas asociadas o proveedores de correo electrónico de consumidor, esas direcciones no se pueden usar.

  • Todas las direcciones de correo electrónico deben ser únicas en todo el bosque. Debido a que Active Directory no aplica esta regla, es posible que tengas que implementar verificaciones o políticas personalizadas.

Si todas las cuentas relevantes cumplen con estos criterios, puedes identificar todos los dominios que usan estas direcciones de correo electrónico y usarlos como dominios principales y secundarios en Cloud Identity.

Si no se cumple alguno de los criterios, aún puedes asignar direcciones de correo electrónico a direcciones de correo electrónico de Cloud Identity, pero se deben tener en cuenta estas advertencias:

  • Durante la sincronización, las cuentas sin direcciones de correo electrónico y aquellas con direcciones que usan dominios no asociados con el directorio de Cloud Identity se ignorarán.
  • Cuando dos cuentas comparten la misma dirección de correo electrónico, solo se sincronizará una de ellas.
  • Puedes configurar la sincronización para reemplazar el dominio de las direcciones de correo electrónico por uno diferente. Este proceso puede crear duplicados, en cuyo caso solo se sincronizará una cuenta.

Mapea grupos

El cuarto factor que debes considerar cuando planeas federar Active Directory y Google Cloud es si deseas sincronizar los grupos entre Active Directory y Google Cloud y cómo mapearlos.

Por lo general, en Google Cloud, los grupos se usan como una forma de administrar el acceso de manera eficiente en todos los proyectos. En lugar de asignar usuarios individuales a las funciones de Cloud Identity and Access Management (Cloud IAM) en cada proyecto, debes definir un conjunto de grupos que modelan funciones comunes en tu organización y, luego, mapearlos a un conjunto de funciones de Cloud IAM. Si modificas la membresía de los grupos, puedes controlar el acceso de los usuarios a un conjunto de recursos completo.

Active Directory distingue dos tipos de grupos: los de distribución y los de seguridad. Los grupos de distribución se usan para administrar las listas de correo electrónico. La sincronización de grupos de distribución es relevante cuando se migra de Microsoft Exchange a G Suite, para que Cloud Directory Sync pueda manejar los grupos de distribución regulares y dinámicos. Sin embargo, los grupos de distribución no son una preocupación en la administración de identidades y accesos de Google Cloud. Por lo tanto, esta discusión se enfoca solo en grupos de seguridad.

El mapeo de grupos de seguridad entre Active Directory y Google Cloud es opcional. Una vez que las cuentas de usuario se federan, puedes crear y administrar grupos directamente en Cloud Identity. Esto significa que Active Directory permanece como el sistema central de la administración de identidades, pero no de la administración de accesos. A fin de mantener Active Directory como el sistema central para la administración de identidades y la administración de accesos, recomendamos que sincronices los grupos de seguridad desde Active Directory en lugar de administrarlos en Cloud Identity. Con este enfoque, puedes configurar Cloud IAM para usar membresías de grupo en Active Directory a fin de controlar quién tiene acceso a los recursos en Google Cloud.

Grupos de seguridad en Active Directory

Los grupos de seguridad tienen una función fundamental en la seguridad de Windows y la administración de accesos de Active Directory. Hay tres tipos diferentes de grupos de Active Directory que facilitan esta función: grupos locales de dominio, grupos globales y grupos universales.

Grupos de seguridad en AD

Grupos locales de dominio
Estos grupos son relevantes solo dentro del permiso de un único dominio y no se puede hacer referencia a ellos en otros dominios. Debido a que su lista de miembros no necesita replicarse en todo el bosque, los grupos locales de dominio son los más flexibles con respecto a los tipos de miembros que pueden incluir.
Grupos globales
Estos grupos se muestran a otros dominios y se les puede hacer referencia en ellos. Sin embargo, su lista de miembros no se repite. Esta limitación restringe los tipos de miembros que estos grupos pueden incluir. Estos grupos solo pueden incluir cuentas de usuario y otros grupos globales del mismo dominio.
Grupos universales
Estos grupos, junto con sus listas de miembros, se replican en todo el bosque. Por lo tanto, se les puede hacer referencia en otros dominios, y pueden incluir cuentas de usuario y otros grupos universales, además de grupos globales de todos los dominios.

Si tu bosque de Active Directory contiene un solo dominio, puedes sincronizar los tres tipos de grupos de seguridad mediante Cloud Directory Sync. Si tu bosque de Active Directory usa más de un dominio, el tipo de un grupo determina si se puede sincronizar con Cloud Identity y de qué manera.

Debido a que los grupos locales de dominio y los globales no se repiten por completo en todo un bosque, los servidores de catálogo global contienen información incompleta sobre ellos. Aunque esta limitación es deliberada y ayuda a acelerar la replicación de directorios, es un obstáculo cuando se desea sincronizar estos grupos con Cloud Identity. De manera específica, si configuras Cloud Directory Sync para usar un servidor de catálogo global como fuente, la herramienta podrá encontrar grupos de todos los dominios del bosque. Pero solo los grupos que están en el mismo dominio que el servidor de catálogo global contienen una lista de membresía y son adecuados para la replicación. Para sincronizar los grupos locales de domino o globales en un bosque de varios dominios, debes ejecutar una instancia separada de Cloud Directory Sync por dominio.

Debido a que los grupos universales se repiten por completo en todo el bosque, no tienen esta restricción. Una sola instancia de Cloud Directory Sync puede sincronizar grupos universales de varios dominios.

Antes de concluir que necesitas instancias múltiples de Cloud Directory Sync para sincronizar varios dominios de Active Directory con Cloud Identity, ten en cuenta que quizás no todos los grupos deban estar sincronizados. Por este motivo, vale la pena observar cómo se usan por lo general los diferentes tipos de grupos de seguridad en todo tu bosque de Active Directory.

Uso de grupos de seguridad en Active Directory

Grupos de recursos

Windows usa un modelo de acceso basado en listas de control de acceso (LCA). Cada recurso, como un archivo o un objeto LDAP, tiene una LCA asociada que controla qué usuarios tienen acceso a él. Los recursos y las LCA son muy detallados, por lo que hay muchos de ellos. A fin de simplificar el mantenimiento de las LCA, es común crear grupos de recursos para agrupar recursos que se usan y acceden con frecuencia. Debes agregar el grupo de recursos a todas las LCA afectadas una sola vez; luego, debes administrar el acceso adicional mediante modificaciones en la membresía del grupo de recursos, no en las LCA.

Los recursos que se agrupan de esta manera, por lo general, residen en un solo dominio. En consecuencia, un grupo de recursos también tiende a referenciarse en un solo dominio, ya sea en las LCA o en otros grupos de recursos. Debido a que la mayoría de los grupos de recursos son locales, por lo general, se implementan mediante grupos locales de dominio en Active Directory.

Grupos de funciones y de organizaciones

Los grupos de recursos ayudan a simplificar la administración de accesos, pero en un entorno grande es posible que debas agregar un nuevo usuario a una gran cantidad de grupos de recursos. Por este motivo, los grupos de recursos suelen complementarse con grupos de funciones o grupos de organizaciones.

Los grupos de funciones agregan los permisos que requiere una función específica en la organización. Un grupo de funciones denominado Lector de la documentación de ingeniería, por ejemplo, puede dar a los miembros acceso de solo lectura a toda la documentación de ingeniería. En la práctica, esto se implementaría mediante la creación de un grupo de funciones que sea miembro de todos los grupos de recursos que se usan para controlar el acceso a diversos tipos de documentación.

De manera similar, los grupos de organizaciones agregan los permisos que requieren los departamentos dentro de una organización. Por ejemplo, un grupo de organizaciones llamado Ingeniería podría otorgar acceso a todos los recursos que los miembros del departamento de Ingeniería suelen necesitar.

En términos técnicos, no hay diferencia entre los grupos de funciones y los de recursos, y ambos suelen usarse en conjunto. Sin embargo, a diferencia de los grupos de recursos, los grupos de funciones y de organizaciones pueden tener relevancia más allá de los límites de un dominio. Para permitir que los grupos de recursos en otros dominios hagan referencia a estos grupos, los grupos de funciones y de organizaciones por lo general se implementan mediante grupos globales, que están restringidos a miembros de un solo dominio, y, a veces, se complementan con grupos universales, que admiten miembros de diferentes dominios.

En el siguiente diagrama, se muestra un patrón de anidación que se usa por lo general en entornos de Active Directory de varios dominios.

Patrón de anidación que se usa en entornos AD de varios dominios

Grupos en Cloud Identity

En Cloud Identity, hay un solo tipo de grupo, que se comporta de manera similar a los grupos universales en Active Directory. Es decir, los grupos no se limitan al alcance de la cuenta de Cloud Identity en la que se definieron. En cambio, los grupos pueden incluir cuentas de usuario de diferentes cuentas de Cloud Identity. Estos grupos se pueden referenciar y anidar en otras cuentas de Cloud Identity, y pueden usarse en cualquier organización de Google Cloud.

A diferencia de los grupos de Active Directory, a los miembros de un grupo de Cloud Identity no se les concede de forma implícita el permiso para almacenar en lista otros miembros del mismo grupo. En su lugar, para consultar la membresía de un grupo, por lo general, se requiere una autorización explícita.

Uso de grupos en Google Cloud

Google Cloud usa un modelo de acceso basado en funciones en lugar de uno basado en LCA. Las funciones se aplican a todos los recursos de un cierto tipo que se encuentran dentro de un permiso determinado. Por ejemplo, la función de desarrollador de Kubernetes Engine tiene acceso completo a los objetos de la API de Kubernetes dentro de todos los clústeres en un proyecto determinado. Debido a la naturaleza de las funciones, no hay mucha necesidad de mantener los grupos de recursos en Google Cloud, y rara vez es necesario sincronizarlos con Google Cloud.

Los grupos de funciones y de organizaciones son tan relevantes en Google Cloud como en Active Directory, ya que facilitan la administración de acceso para una gran cantidad de usuarios. La sincronización de grupos de organizaciones y funciones ayuda a mantener Active Directory como el lugar principal para administrar el acceso.

Sincronización de grupos de funciones y de organizaciones

Si implementas de forma coherente grupos de recursos como grupos locales de dominio y grupos de funciones y de organizaciones como grupos globales o universales, puedes usar el tipo de grupo para asegurarte de que solo los grupos de funciones y de organizaciones estén sincronizados.

La necesidad de ejecutar una sola instancia de Cloud Directory Sync por bosque de varios dominios o de múltiples instancias depende de si usas grupos globales. Si implementas todos tus grupos de funciones y de organizaciones con grupos universales, una única instancia de Cloud Directory Sync es suficiente; de lo contrario, necesitarás una por dominio.

Asigna identidades de grupo

Asignar grupos de seguridad de Active Directory a grupos de Cloud Identity requiere un identificador común. En Cloud Identity, este identificador debe ser una dirección de correo electrónico en la cual la parte del dominio corresponda a un dominio principal, secundario o de alias de Cloud Identity. Esta dirección de correo electrónico debe ser legible porque se usará en todo Google Cloud. No es necesario que corresponda a un buzón.

En Active Directory, los grupos se identifican por su nombre común (cn) o por un nombre de inicio de sesión anterior a Windows 2000 (sAMAccountName). Al igual que las cuentas de usuario, los grupos también pueden tener una dirección de correo electrónico (mail), pero son un atributo opcional para los grupos, y Active Directory no verifica que sean únicas.

Tienes dos opciones para mapear identidades de grupo entre Active Directory y Cloud Identity.

Mapea por nombre común

La ventaja de usar el nombre común (cn) es que su disponibilidad está garantizada, además de que es único dentro de una unidad organizativa. Sin embargo, el nombre común no es una dirección de correo electrónico, por lo que necesita que se agregue un sufijo @[DOMAIN] para convertirse en una.

Puedes configurar Cloud Directory Sync para que se encargue de forma automática de agregar un sufijo al nombre del grupo. Debido a que Active Directory garantiza que los nombres de grupo y de cuenta de usuario no entren en conflicto, es improbable que una dirección de correo electrónico que se derive de esta manera cause algún problema.

Si tu bosque de Active Directory contiene más de un solo dominio, se aplican las siguientes advertencias:

  • Si dos grupos en diferentes dominios comparten un nombre común, la dirección de correo electrónico derivada entrará en conflicto, y esto hará que un grupo se ignore durante la sincronización.
  • Solo puedes sincronizar grupos de los dominios de un solo bosque. Si sincronizas grupos de varios bosques con instancias separadas de Cloud Directory Sync, las direcciones de correo electrónico que derivan del nombre común no reflejan a qué bosque corresponden. Esta ambigüedad hará que una instancia de Cloud Directory Sync borre cualquier grupo que otra haya creado antes a partir de un bosque diferente.
  • No puedes asignar grupos por nombre común si usas la sustitución de dominio para asignar cuentas de usuario.

Mapea por dirección de correo electrónico

Usar la dirección de correo electrónico (mail) a fin de mapear identidades de grupo significa que debes cumplir los mismos criterios que cuando la usas para mapear identidades de cuenta:

  • Los mapeos de correo electrónico deben estar completos. Aunque es común que los grupos de distribución tengan una dirección de correo electrónico, los grupos de seguridad a menudo carecen de este atributo. Para usar la dirección de correo electrónico a fin de mapear identidades, los grupos de seguridad sujetos a sincronización deben tener el campo mail propagado. El siguiente comando de PowerShell puede ayudarte a encontrar cuentas para las cuales este campo no está propagado:

    Get-ADGroup -LDAPFilter "(!mail=*)"
  • Las direcciones de correo electrónico deben usar un conjunto seleccionado de dominios que te pertenezcan. Si algunas de tus cuentas usan direcciones de correo electrónico que hacen referencia a empresas asociadas o proveedores de correo electrónico de consumidor, no puedes usar esas direcciones.

  • Todas las cuentas de correo electrónico deben ser únicas en todo el bosque. Debido a que Active Directory no aplica esta regla, es posible que tengas que implementar verificaciones o políticas personalizadas.

Si todos los grupos relevantes cumplen con estos criterios, puedes identificar todas las direcciones de correo electrónico que usan estos dominios y garantizar que la lista de dominios DNS registrados en Cloud Identity los abarque.

Si no se cumple uno de los criterios, aún puedes asignar UPN a las direcciones de correo electrónico de Cloud Identity, con las siguientes advertencias:

  • Los grupos sin direcciones de correo electrónico se ignorarán durante la sincronización, al igual que las direcciones de correo electrónico que usan dominios que no están asociados con el directorio de Cloud Identity.
  • Cuando dos grupos comparten la misma dirección de correo electrónico, solo uno de ellos se sincronizará.

No se admite la asignación de grupos por dirección de correo electrónico si tu bosque de Active Directory contiene más de un solo dominio y usas la sustitución de dominios para asignar cuentas de usuario.

Asigna unidades organizativas

La mayoría de los dominios de Active Directory hacen un uso extensivo de las unidades organizativas para agrupar y organizar los recursos de forma jerárquica, controlar el acceso y aplicar las políticas.

En Google Cloud, las carpetas y los proyectos tienen un propósito similar, aunque los tipos de recursos que se administran dentro de una organización de Google Cloud son muy diferentes de los que se administran en Active Directory. Como resultado, una jerarquía de carpetas de Google Cloud adecuada para una empresa suele diferir de forma significativa de la estructura de las unidades organizativas en Active Directory. Por lo tanto, el mapeo automático de unidades organizativas a carpetas y proyectos no suele ser práctico y Cloud Directory Sync no lo admite.

Sin relación con las carpetas, Cloud Identity admite el concepto de unidades organizativas. Las unidades organizativas se crean para agrupar y organizar las cuentas de usuario, de manera similar a Active Directory. Sin embargo, a diferencia de Active Directory, se aplican solo a cuentas de usuario, no a grupos.

Cloud Directory Sync ofrece la opción de sincronizar las unidades organizativas de Active Directory con las de Cloud Identity. En una configuración en la que Cloud Identity solo se usa para extender la administración de identidades de Active Directory a Google Cloud, en general, no es necesario mapear unidades organizativas.

Elige el mapeo correcto

Como se mencionó al comienzo de este artículo, no existe una única manera ideal de mapear las estructuras de Active Directory y Google Cloud. A fin de ayudarte a elegir el mapeo correcto para tu caso, en los siguientes gráficos de decisión, se resumen los criterios analizados en las secciones anteriores.

Primero, consulta el siguiente cuadro para identificar cuántas cuentas de Cloud Identity, instancias de Cloud Directory Sync y flotas o instancias de AD FS necesitas.

Gráfico de decisión para determinar la cantidad de flotas o instancias necesarias

Luego, consulta el segundo cuadro para identificar los dominios que debes configurar en tu cuenta de Cloud Identity.

Gráfico de decisión para identificar los dominios que se deben configurar en Cloud Identity

Próximos pasos