Federación de Google Cloud Platform con Active Directory: introducción

Este artículo es el primero de una serie de varias partes que explica cómo extender una solución de administración de identidades basada en Active Directory a Google Cloud Platform (GCP). En él se describe cómo establecer mecanismos coherentes de autenticación y autorización en un entorno de computación híbrido. Si bien el artículo se enfoca en el uso de Cloud Identity, parte de la discusión se aplica a G Suite.

La serie consta de las siguientes partes:

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

Cuando extiendes tu panorama de TI existente a GCP como parte de una estrategia híbrida, debes mantener un punto único 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 manera segura en un entorno híbrido.

En este artículo, se comparan las estructuras lógicas de Active Directory y GCP y se explican las formas en que puedes asignar 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

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

  • Active Directory es la única fuente de información para la administración de identidades.
  • Se crea una cuenta de usuario de Google de forma automática a todas las cuentas de usuario en Active Directory o a un subconjunto seleccionado.
  • Si una cuenta se inhabilita o se borra en 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 tiene ningún efecto en Active Directory, ya que la Cuenta de Google se volverá a crear de forma automática durante la siguiente sincronización.
  • Active Directory maneja la autenticación del usuario, por lo que no es necesario sincronizar las contraseñas con GCP.

En el 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:

Federa 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. Este proceso garantiza que, cuando creas una cuenta nueva en Active Directory, esta se pueda referenciar en GCP 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: Siempre que un usuario necesite autenticarse en GCP, 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 Google Identity Platform a través de capas de conexión segura (SSL) y, por lo general, se ejecuta en el entorno de computación 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 computación existente.

Debido a que las API de Google Identity Platform están disponibles de forma pública y SAML es un estándar abierto, hay muchas herramientas disponibles para implementar la federación. Este artículo se enfoca 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 deriva su nombre de su dominio raíz. 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 fondos comunes, los bosques separados no confían entre sí de manera 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 consideran 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 GCP

En GCP, administras los recursos en organizaciones, que puedes segmentar aún más 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 autenticación está vinculada a los dominios. Por el contrario, GCP no administra las cuentas de usuario en una organización, excepto las cuentas de servicio. En su lugar, GCP se basa en 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 GCP. Además, así como un dominio raíz de bosque y un bosque comparten el mismo nombre y no se pueden separar uno del otro, la cuenta de Cloud Identity y la organización de GCP comparten el mismo nombre y están vinculadas entre sí. Sin embargo, una organización de GCP puede hacer referencia a usuarios y grupos de otras cuentas de Cloud Identity.

Integra Active Directory y GCP

A pesar de ciertas similitudes entre las estructuras lógicas de Active Directory y de GCP, no existe una asignación única entre las dos estructuras que funcione igual de bien en todas las situaciones. En su lugar, el enfoque correcto para integrar los dos sistemas y asignar 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 planificas la federación de Active Directory y GCP, el primer factor que debes considerar es la topología de tu infraestructura de Active Directory.

Un bosque, un dominio

Un bosque, un dominio

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

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 sola instancia de Cloud Directory Sync para sincronizar las cuentas de usuario y los grupos con GCP, y mantener una sola instancia o flota de AD FS a fin de manejar 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 asignar todo el bosque a una sola cuenta de Cloud Identity. Esta cuenta proporciona la base para una sola organización de GCP que puedes usar a fin de administrar tus recursos de GCP.

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. Sin embargo, los datos que entregan los servidores de catálogo global son parciales y carecen de ciertos atributos LDAP. Esta limitación puede afectar la forma en que configuras Cloud Directory Sync para sincronizar grupos.

Según cómo planifiques la asignación de grupos, la federación de un bosque de dominios múltiples con GCP requiere una o más instancias de Cloud Directory Sync, pero solo una única instancia o flota de AD FS para manejar el inicio de sesión único.

Varios bosques con fondo común

Varios bosques con fondo común

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 un fondo bidireccional con otro bosque, puedes asignar todo el entorno a una sola cuenta de Cloud Identity. Esta cuenta proporciona la base para una sola organización de GCP que puedes usar a fin de administrar tus recursos de GCP.

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

Si tu entorno abarca bosques múltiples sin un fondo común, pero todos los dominios de Active Directory relevantes para la federación con GCP están conectados a través de fondos externos, se aplican las mismas consideraciones.

Varios bosques sin un fondo común

Varios bosques sin un fondo común

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 asignarse 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 GCP, se crea una organización separada 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 tener en cuenta cuando planificas la federación de Active Directory y GCP es cómo compartir o asignar dominios DNS entre ambos.

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 con el fin de crear 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: A los servidores públicos, como los de AD FS, por lo general, se les asigna un nombre DNS, por ejemplo, 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 GCP

Google Identity Platform, en la que se basa GCP para la autenticación, usa las direcciones de correo electrónico a fin de identificar a los usuarios. Usar direcciones de correo electrónico garantiza que sean únicas a nivel global y también permite que GCP les envíe mensajes de notificación.

Google Identity Platform determina el directorio o el proveedor de identidad que se usa para autenticar a un usuario en función de la parte de las direcciones de correo electrónico que corresponde al dominio, la cual se encuentra luego del símbolo @. Para una dirección de correo electrónico que usa el dominio gmail.com, por ejemplo, Google Identity Platform usa el directorio de cuentas de usuarios 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, en esencia creas un directorio privado que Google Identity Platform puede usar para la autenticación. De la misma manera en que el directorio de Gmail se asocia con el dominio gmail.com, las cuentas de G Suite y Cloud Identity deben asociarse con un dominio personalizado. Se usan tres tipos diferentes de dominios:

  • Dominio principal: este dominio identifica el directorio de Cloud Identity y también se usa como el nombre de la organización en GCP. 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 con el dominio principal o uno de los dominios secundarios. Por lo tanto, dos cuentas como johndoe@example.com y johndoe@secondary.example.com se consideran cuentas separadas si example.com es el dominio principal de un directorio y secondary.example.com es 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. Los nombres de dominio locales, como corp.local o corp.internal, que se usan por lo general en Active Directory, no están permitidos. 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 referirse 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.

Asigna cuentas de usuario

El tercer factor que debes considerar cuando planificas la federación de Active Directory y GCP es cómo asignar 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 único global 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 tu bosque de Active Directory pueden carecer de UPN.

    Aunque se recomienda que las UPN sean direcciones de correo electrónico válidas, Active Directory no hace cumplir 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 identificarlo. 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. En el lado de AD, el 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 usa en todo GCP, debes asegurarte de que 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, hay dos campos que pueden proporcionar una dirección de correo electrónico de Cloud Identity: userPrincipalName y mail.

Asigna 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 asignar 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 GCP, lo que puede hacer que pierdan 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.

Asigna 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:

  • Las asignaciones de correo electrónico deben estar completas. Todas las cuentas de usuario sujetas 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-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 uno de los criterios, aún puedes asignar UPN a las direcciones de correo electrónico de Cloud Identity, con las siguientes 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.

Asigna grupos

El cuarto factor que debes considerar cuando planificas la federación de Active Directory y GCP es la sincronización de los grupos entre Active Directory y GCP y cómo asignarlos.

En GCP, los grupos se usan, por lo general, 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 asignarlos 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, por lo que Cloud Directory Sync puede manejar grupos de distribución regulares y dinámicos. Sin embargo, los grupos de distribución no son un problema en la administración de identidades y accesos para GCP. Por lo tanto, esta discusión se enfoca solo en grupos de seguridad.

La asignación de grupos de seguridad entre Active Directory y GCP es opcional. Una vez que las cuentas de usuario se federan, puedes crear y administrar grupos de forma directa 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 de forma que pueda usar las membresías de grupo en Active Directory para controlar quién tiene acceso a determinados recursos en GCP.

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 alcance de un único dominio y no se los puede referenciar en otros dominios. Debido a que su lista de miembros no necesita repetirse 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 pueden referenciar 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 repiten en todo el bosque. Por lo tanto, pueden referenciarse 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. En específico, si configuras Cloud Directory Sync para usar un servidor de catálogo global como fuente, la herramienta podrá encontrar grupos de todos los dominios en todo el bosque. Sin embargo, solo los grupos que están en el mismo dominio que el servidor de catálogo global contendrán una lista de membresías y serán 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.

El siguiente diagrama muestra un patrón de anidación que se usa por lo general en entornos de Active Directory de dominios múltiples.

Patrón de anidación usado en entornos AD de dominios múltiples

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 su lugar, los grupos pueden incluir cuentas de usuario de diferentes cuentas de Cloud Identity. Estos grupos admiten la referencia y la anidación en otras cuentas de Cloud Identity, y se pueden usar en cualquier organización de GCP.

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 los otros miembros del mismo grupo. En su lugar, consultar la membresía de un grupo por lo general requiere una autorización explícita.

Uso de grupos en GCP

GCP 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 alcance 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 GCP y rara vez es necesario sincronizarlos.

Los grupos de funciones y los de organizaciones son tan relevantes en GCP como en Active Directory, ya que facilitan la administración del acceso para una gran cantidad de usuarios. La sincronización de funciones y grupos de organizaciones 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 sistemática 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 GCP. 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 y Active Directory no verifica que sean únicas.

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

Asigna por nombre común

La ventaja de usar el nombre común (cn) es que su disponibilidad está garantizada, además de que es única dentro de una unidad organizativa. Sin embargo, el nombre común no es una dirección de correo electrónico, por lo que necesita un sufijo @[DOMAIN] adjunto 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, esto hará que un grupo se ignore durante la sincronización.
  • Solo puedes sincronizar grupos a partir de dominios de un solo bosque. Si sincronizas grupos de bosques múltiples mediante instancias separadas de Cloud Directory Sync, las direcciones de correo electrónico derivadas 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.

Asigna por dirección de correo electrónico

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

  • Las asignaciones de correo electrónico deben estar completas. 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 identificar 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 todos los dominios que usan estas direcciones de correo electrónico y garantizar que los abarque la lista de dominios DNS registrados en Cloud Identity.

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 GCP, las carpetas y los proyectos tienen un propósito similar, aunque los tipos de recursos que se administran dentro de una organización de GCP son muy diferentes de los que se administran en Active Directory. Como resultado, una jerarquía de carpetas de GCP adecuada para una empresa tiende a diferir mucho de la estructura de las unidades organizativas en Active Directory. Por lo tanto, la asignación automática de unidades organizativas a carpetas y proyectos no suele ser práctica y Cloud Directory Sync no la 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 se usa solo para extender la administración de identidades de Active Directory a GCP, por lo general, no es necesario asignar unidades organizativas.

Elige la asignación correcta

Como se señaló al principio de este artículo, no existe una única manera ideal de asignar las estructuras de Active Directory y GCP. A fin de ayudarte a elegir la asignación correcta para tu situación, los siguientes grafos de decisión 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 necesitarás.

Grafo de decisión para determinar el número de flotas o instancias necesarias

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

Grafo de decisión para identificar los dominios que se deben configurar en Cloud Identity

Pasos siguientes

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…