Federa Google Cloud con Active Directory

En este documento, se describe cómo puedes configurar Cloud Identity o Google Workspace para usar Active Directory como IdP y fuente autorizada.

En el documento, se compara la estructura lógica de Active Directory con la estructura que usan Cloud Identity y Google Workspace y se describe cómo puedes asignar bosques, dominios, usuarios y grupos de Active Directory. En el documento, también se proporciona un diagrama de flujo que te ayuda a determinar el mejor enfoque de asignación para tu situación.

En este documento, 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. El mantenimiento manual de las identidades de Google para cada empleado puede agregar una sobrecarga de administración innecesaria cuando todos los empleados ya tienen una cuenta en Active Directory. Mediante la federación de identidades de usuario entre Google Cloud y tu sistema de administración de identidades existente, puedes automatizar el mantenimiento de las identidades de Google y vincular su ciclo de vida a los usuarios existentes en Active Directory.

La configuración de la federación entre Active Directory y Cloud Identity o Google Workspace implica dos partes:

• Aprovisionamiento de usuarios: Los grupos y usuarios relevantes se sincronizan de forma periódica de Active Directory a Cloud Identity o Google Workspace. Este proceso garantiza que cuando creas un usuario nuevo en Active Directory, se pueda hacer referencia a él en Google Cloud incluso antes de que el usuario asociado acceda por primera vez. Este proceso también garantiza que las eliminaciones de los usuarios se propaguen.

  El aprovisionamiento funciona en un solo sentido, lo que significa que los cambios en Active Directory se replican en Google Cloud, pero no al revés. Además, el aprovisionamiento no incluye contraseñas. En una configuración federada, Active Directory es el único sistema que administra estas credenciales.

• Inicio de sesión único: Cuando un usuario necesita autenticarse, Google Cloud delega la autenticación a Active Directory mediante el protocolo de lenguaje de marcado para confirmaciones 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 sea exitoso, el usuario correspondiente debe haberse aprovisionado antes.

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

• Google Cloud Directory Sync (GCDS) es una herramienta gratuita que proporciona Google para implementar el proceso de sincronización. GCDS se comunica con Google Cloud a través de la capa 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 APIs de Google Cloud están disponibles de forma pública y SAML es un estándar abierto, hay muchas herramientas disponibles para implementar la federación. Este documento se centra en el uso de GCDS 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.

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, las organizaciones sirven como contenedores para todos los recursos y pueden segmentarse 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 a los usuarios como recursos, por lo que la administración de usuarios y la autenticación están vinculadas a los dominios. Por el contrario, Google Cloud no administra usuarios en una organización, excepto las cuentas de servicio. En cambio, Google Cloud depende de Cloud Identity o Google Workspace para administrar usuarios.

Una cuenta de Cloud Identity o Google Workspace funciona como un directorio privado para usuarios y grupos. Como administrador de la cuenta, puedes controlar el ciclo de vida y la configuración de los usuarios y grupos, y definir cómo realizar la autenticación.

Cuando creas una cuenta de Cloud Identity o Google Workspace, se crea una organización de Google Cloud de forma automática. La cuenta de Cloud Identity o Google Workspace y la organización de Google Cloud asociada a ella 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 otras cuentas de Cloud Identity o Google Workspace.

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 o Google Workspace
• Cómo mapear dominios DNS
• Cómo mapear usuarios
• Cómo mapear 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

Cuando un bosque incluye solo un dominio, puedes mapear todo el bosque de Active Directory a una sola cuenta de Cloud Identity o Google Workspace. 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 GCDS para 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

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 o Google Workspace. 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 GCDS para sincronizar grupos.

Según cómo planees asignar grupos, federar un bosque de varios dominios con Google Cloud requiere una o más instancias de GCDS, 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í

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 o Google Workspace. 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 usuarios. Como resultado de esta limitación, la federación de un entorno de varios bosques con Google Cloud requiere al menos una instancia de GCDS 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 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 o Google Workspace. En su lugar, cada bosque debe asignarse a una cuenta de Cloud Identity o Google Workspace separada, lo que implica ejecutar al menos una instancia de GCDS 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 o Google Workspace. 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 o Google Workspace, 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 y Google Workspace. 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 los usuarios de 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 del usuario 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 del 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 según la parte del dominio de las direcciones de correo electrónico, que sigue a @. Para una dirección de correo electrónico que usa el dominio gmail.com, por ejemplo, el Acceso con Google usa el directorio de usuarios de Gmail para la autenticación.

Cuando te registras en una cuenta de Google Workspace o Cloud Identity, creas un directorio privado que el usuario puede usar para la autenticación. De la misma manera en que el directorio de Gmail se asocia al dominio gmail.com, Google Workspace y las cuentas de Cloud Identity se deben asociar a un dominio personalizado. Se usan tres tipos diferentes de dominios:

• Dominio principal: Identifica el directorio de Cloud Identity o Google Workspace y también se usa como el nombre de la organización en Google Cloud. Cuando te registras en Cloud Identity o Google Workspace, debes especificar este nombre de dominio.
• Dominio secundario: Junto con el dominio principal, puedes asociar otros dominios secundarios con una cuenta de Cloud Identity o de Google Workspace. Cada usuario en el directorio está asociado con el dominio principal o uno de los dominios secundarios. Dos usuarios, johndoe@example.com y johndoe@secondary.example.com, se consideran usuarios separados si example.com es el dominio principal y secondary.example.com es un dominio secundario.
• Dominio de alias: nombre alternativo para otro dominio. Es decir, johndoe@example.com y johndoe@alias.example.com hacen referencia al mismo usuario si alias.example.com está configurado como un dominio de alias para example.com.

Todos los dominios deben cumplir los requisitos siguientes:

• Deben ser nombres de dominio DNS globales válidos. 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 para que los mensajes enviados a las direcciones de correo electrónico que se forman con este nombre de dominio se puedan entregar de forma correcta.

Para habilitar la sincronización entre los directorios, se requiere cierto mapeo entre los dominios de Active Directory y los dominios que usa Cloud Identity o Google Workspace. Determinar el mapeo correcto depende de cómo uses Active Directory y requiere un análisis más detallado de cómo se identifican los usuarios en un bosque de Active Directory y cómo se pueden mapear a Cloud Identity o Google Workspace.

Asigna usuarios

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

Identifica usuarios en Active Directory

De manera interna, Active Directory usa dos identificadores para identificar de manera única a los usuarios:

• 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, cuando se mueva a un dominio diferente en el bosque, se le asigne un SID nuevo al usuario.

Ninguno de estos ID es significativo para los usuarios, por lo que Active Directory ofrece dos maneras fáciles de identificar a los usuarios:

• UPN (userPrincipalName): La forma preferida de identificar a un 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 usuarios, los UPN son opcionales, por lo que algunos usuarios de tu bosque de Active Directory pueden no tener un UPN.

  Aunque se recomienda que las 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<var>user, como en corp\johndoe. Aunque estos nombres se consideran heredados, todavía suelen usarse y son el único identificador obligatorio de un 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 usuario

Asignar usuarios de Active Directory a usuarios de Cloud Identity o de Google Workspace requiere dos datos para cada usuario:

• Un ID único y estable que puedes usar durante la sincronización para realizar un seguimiento de qué usuario de Active Directory corresponde a qué usuario en Cloud Identity o Google Workspace. 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 tu cuenta de Cloud Identity o Google Workspace. 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.

Para un usuario de Active Directory, hay dos campos que pueden proporcionar una dirección de correo electrónico de Cloud Identity o Google Workspace: userPrincipalName y mail.

Asigna por nombre principal de usuario

El uso del campo userPrincipalName requiere que se cumplan dos criterios para todos los usuarios sujetos a sincronización:

• Los nombres principales de usuario (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. Todos los usuarios sujetos a la sincronización deben tener un UPN asignado. El siguiente comando de PowerShell puede ayudarte a encontrar usuarios que no tienen un 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 o Google Workspace. Puedes usar uno de los dominios de sufijo UPN como dominio principal en Cloud Identity o Google Workspace y agregar cualquier otro dominio de sufijo UPN como dominios secundarios.

Si no se cumple uno de los criterios, aún puedes asignar UPN a las direcciones de correo electrónico de Cloud Identity o Google Workspace, con 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.
• Los usuarios sin UPN se ignoran 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 el caso de los duplicados, solo se puede sincronizar un único usuario.

Una de las ventajas principales de usar UPN para mapear 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.

Asignación por dirección de correo electrónico

El uso del campo mail requiere que se cumplan los siguientes criterios para todos los usuarios sujetos a sincronización:

• Las asignaciones de correo electrónico deben estar completas. Todos los usuarios sujetos a la sincronización deben tener el campo mail propagado. El siguiente comando de PowerShell puede ayudarte a encontrar usuarios para los 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 algunos de los usuarios usan direcciones de correo electrónico que hacen referencia a empresas asociadas o proveedores de correo electrónico personales, esas direcciones no se pueden usar.

• Todas las direcciones de correo electrónico deben ser únicas en 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 usuarios relevantes cumplen con estos criterios, puede identificar todos los dominios que usan estas direcciones de correo electrónico y usarlos como dominios principales y secundarios en Cloud Identity o Google Workspace.

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 o de Google Workspace, con las siguientes advertencias:

• Durante la sincronización, los usuarios sin direcciones de correo electrónico se ignorarán, al igual que las direcciones de correo electrónico que usan dominios no asociados con la cuenta de Cloud Identity o Google Workspace.
• Cuando dos usuarios comparten la misma dirección de correo electrónico, solo se sincroniza un usuario.
• 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á un usuario.

Asignar 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 roles de IAM en cada proyecto, debes definir un conjunto de grupos que modelen roles comunes en la organización y, luego, asignar esos grupos a un conjunto de roles de 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 Google Workspace, para que GCDS 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 que este debate se enfoca solo en grupos de seguridad.

El mapeo de grupos entre Active Directory y Google Cloud es opcional. Una vez configurado el aprovisionamiento de usuarios, puedes crear y administrar grupos de forma directa en Cloud Identity o Google Workspace, lo que 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 o Google Workspace. Con este enfoque, puedes configurar IAM para que puedas usar membresías de grupos en Active Directory a fin de controlar quiénes tienen acceso a ciertos 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 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 usuarios 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 puede hacer referencia a ellos en otros dominios y pueden incluir 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 GCDS. 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 o Google Workspace 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 o Google Workspace. De manera específica, si configuras GCDS 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 dominio o globales en un bosque de varios dominios, debes ejecutar una instancia separada de GCDS 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 GCDS puede sincronizar grupos universales de varios dominios.

Antes de concluir que necesitas instancias múltiples de GCDS para sincronizar varios dominios de Active Directory con Cloud Identity o Google Workspace, 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

En las siguientes secciones, se describen los tipos de grupos de seguridad que se usan 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.

Grupos en Cloud Identity y Google Workspace

En Cloud Identity y Google Workspace, solo hay un tipo de grupo. Los grupos en Cloud Identity y Google Workspace no se limitan al alcance de la cuenta de Cloud Identity o Google Workspace en la que se definieron. En su lugar, pueden incluir usuarios de diferentes cuentas de Cloud Identity o Google Workspace, admitir referencias de otras cuentas, anidarse en ellas y pueden usarse en cualquier organización de Google Cloud.

Al igual que con los usuarios, Cloud Identity y Google Workspace identifican grupos por dirección de correo electrónico. No es necesario que la dirección de correo electrónico corresponda a un buzón real, pero debe usar uno de los dominios registrados para la cuenta respectiva de Cloud Identity.

A diferencia de los grupos de Active Directory, a los miembros de un grupo de Cloud Identity o Google Workspace no se les concede de forma implícita el permiso para enumerar a 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 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.

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 GCDS por bosque de varios dominios o de múltiples instancias depende de si usas grupos globales. Si implementas todos tus grupos de roles y de organizaciones con grupos universales, una sola instancia de GCDS 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 o Google Workspace requiere un identificador común. En Cloud Identity y Google Workspace, 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 la cuenta de Cloud Identity o Google Workspace. 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 asignar identidades de grupo entre Active Directory y Cloud Identity o Google Workspace.

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 ú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 GCDS 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 grupos y usuarios no entren en conflicto, es poco probable que una dirección de correo electrónico derivada de este modo genere conflictos.

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 GCDS, 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 GCDS borre cualquier grupo que otra haya creado antes a partir de un bosque diferente.
• No puedes mapear grupos por nombre común si usas la sustitución de dominio para mapear usuarios.

Asignación 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 usuarios:

• 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 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 algunos de los usuarios usan direcciones de correo electrónico que hacen referencia a empresas asociadas o proveedores de correo electrónico personal, no puedes usar esas direcciones.

• Todas las direcciones de correo electrónico deben ser únicas en 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 o Google Workspace 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 o Google Workspace, con las siguientes advertencias:

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

El mapeo de grupos por dirección de correo electrónico no es compatible si tu bosque de Active Directory contiene más de un solo dominio y usas la sustitución de dominio para mapear usuarios.

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, la asignación automática de unidades organizativas a carpetas y proyectos no suele ser práctico y GCDS no lo admite.

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

GCDS ofrece la opción de sincronizar las unidades organizativas de Active Directory con Cloud Identity o Google Workspace. 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 la asignación correcta

Como se mencionó al comienzo de este documento, no existe una única manera ideal de asignar las estructuras de Active Directory y Google Cloud. A fin de ayudarte a elegir el mapeo correcto para tu caso, en los siguientes grafos 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 o Google Workspace, instancias de GCDS y flotas o instancias de AD FS necesitas.

Luego, consulta el segundo gráfico para identificar los dominios que deseas configurar en la cuenta de Cloud Identity o Google Workspace.

¿Qué sigue?

• Lee las prácticas recomendadas para planificar cuentas y organizaciones y las prácticas recomendadas para federar Google Cloud con un proveedor de identidad externo.
• Configura GCDS para sincronizar los usuarios y grupos de Active Directory con Cloud Identity.
• Configura el inicio de sesión único entre Active Directory y Google Cloud.
• Consulta las prácticas recomendadas para administrar cuentas de administrador avanzado.