Federar Google Cloud con Active Directory

Last reviewed 2024-06-26 UTC

En este documento se describe cómo configurar Cloud Identity o Google Workspace para usar Active Directory como proveedor de identidades y fuente autorizada.

En este 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. El documento también incluye un diagrama de flujo que te ayuda a determinar el mejor enfoque de asignación para tu situación.

En este documento se da por supuesto que conoces Active Directory.

Implementar la federación

Google Cloud usa identidades de Google para la autenticación y la gestión de accesos. Mantener manualmente las identidades de Google de cada empleado puede añadir una sobrecarga de gestión innecesaria si todos los empleados ya tienen una cuenta en Active Directory. Al federar las identidades de los usuarios entre Google Cloud y tu sistema de gestión de identidades, puedes automatizar el mantenimiento de las identidades de Google y vincular su ciclo de vida a los usuarios de Active Directory.

Para configurar la federación entre Active Directory y Cloud Identity o Google Workspace, se necesitan dos elementos:

• Aprovisionamiento de usuarios: los usuarios y grupos pertinentes se sincronizan periódicamente de Active Directory a Cloud Identity o Google Workspace. De esta forma, cuando creas un usuario en Active Directory, se puede hacer referencia a él Google Cloud incluso antes de que el usuario asociado haya iniciado sesión por primera vez. Este proceso también asegura que las eliminaciones de usuarios se propaguen.

  El aprovisionamiento funciona en una sola dirección, 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 sigue siendo el único sistema que gestiona estas credenciales.

• Inicio de sesión único: cada vez que un usuario necesita autenticarse, Google Cloud delega la autenticación en Active Directory mediante el protocolo de lenguaje de marcado para confirmaciones de seguridad (SAML). Esta delegación asegura que solo Active Directory gestione las credenciales de los usuarios y que se apliquen las políticas o los mecanismos de autenticación multifactor (MFA) correspondientes. Sin embargo, para que el inicio de sesión se realice correctamente, el usuario correspondiente debe haber recibido acceso previamente.

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

• Google Cloud Directory Sync (GCDS) es una herramienta gratuita proporcionada por Google que implementa el proceso de sincronización. GCDS se comunica con Google Cloud a través de la capa de conexión segura (SSL) y suele ejecutarse en el entorno informático actual.
• Microsoft proporciona 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 suele ejecutarse en el entorno informático existente.

Como las APIs de Google Cloud están disponibles públicamente 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 actúa como contenedor de uno o varios dominios y recibe su nombre del dominio raíz del bosque. Los dominios de 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 los bosques estén conectados mediante relaciones de confianza entre bosques, los bosques independientes no confían entre sí de forma predeterminada y los usuarios autenticados en un bosque no pueden acceder a los recursos de otro bosque.

Los dominios de Active Directory son contenedores para gestionar 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 de un bosque no representan límites de seguridad.

Estructura lógica de Google Cloud

En Google Cloud, las organizaciones sirven como contenedores de todos los recursos y se pueden segmentar aún más mediante carpetas y proyectos. Por lo tanto, las organizaciones, las carpetas y los proyectos tienen un propósito similar al de los dominios de Active Directory.

Active Directory trata a los usuarios como recursos, por lo que la gestión de usuarios y la autenticación están vinculadas a los dominios. Por el contrario, Google Cloud no gestiona usuarios de una organización, excepto las cuentas de servicio. En su lugar, Google Cloud se basa en Cloud Identity o Google Workspace para gestionar a los usuarios.

Una cuenta de Cloud Identity o de Google Workspace sirve como 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 los grupos, así como definir cómo se puede realizar la autenticación.

Cuando creas una cuenta de Cloud Identity o Google Workspace, se crea automáticamente una organización. Google Cloud La cuenta de Cloud Identity o Google Workspace y la Google Cloud organización asociada tienen el mismo nombre y están vinculadas entre sí. Sin embargo, una organización puede hacer referencia a usuarios y grupos de otras cuentas de Cloud Identity o Google Workspace. Google Cloud

Integrar Active Directory y Google Cloud

A pesar de las similitudes entre la estructura lógica de Active Directory y Google Cloud, no hay un único mapeo entre las dos estructuras que funcione igual de bien en todos los casos. En su lugar, el enfoque adecuado para integrar los dos sistemas y asignar la estructura depende de varios factores:

• Cómo asignar dominios y bosques a cuentas de Cloud Identity o Google Workspace
• Cómo asignar dominios DNS
• Cómo mapear usuarios
• Cómo asignar grupos

En las siguientes secciones se analiza cada uno de estos factores.

Mapa de bosques

Sobre todo en las organizaciones más grandes, a menudo se usa más de un dominio de Active Directory para gestionar las identidades y el acceso en toda la empresa. Cuando vayas a federar Active Directory y Google Cloud, el primer factor que debes tener en cuenta es la topología de tu infraestructura de Active Directory.

Un único bosque y un único dominio

Si un bosque incluye un solo dominio, puedes asignar todo el bosque de Active Directory a una sola cuenta de Cloud Identity o Google Workspace. Esta cuenta proporciona la base para una única Google Cloud organización que puedes usar para gestionar tus Google Cloud recursos.

En un entorno de un solo dominio, los controladores de dominio y los servidores de catálogo global proporcionan acceso a todos los objetos gestionados en Active Directory. En la mayoría de los casos, puedes ejecutar una sola instancia de GCDS para sincronizar cuentas de usuario y grupos con Google Cloud, así como para mantener una sola instancia o flota de AD FS para gestionar el inicio de sesión único.

Un único bosque con varios dominios

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

En un entorno de varios dominios, hay 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 proporcionan datos de su dominio local, los servidores de catálogo global proporcionan acceso a la información de todos los dominios del bosque. Es importante destacar que los datos que proporcionan los servidores de catálogo global son parciales y carecen de determinados atributos LDAP. Esta limitación puede afectar a la forma en que configures GCDS para sincronizar grupos.

En función de cómo tengas previsto asignar los grupos, la federación de un bosque de varios dominios con Google Cloud requiere una o varias instancias de GCDS, pero solo una instancia o flota de AD FS para gestionar el inicio de sesión único.

Varios bosques con una relación de confianza entre bosques

En las organizaciones más grandes, no es raro tener más de un bosque de Active Directory, a menudo como resultado de una fusión o adquisición. Puedes combinar estos bosques mediante una confianza bidireccional entre bosques para que los usuarios puedan compartir recursos y acceder a ellos entre los límites de un solo bosque.

Si todos los bosques tienen una relación de confianza bidireccional con otro bosque, puedes asignar todo el entorno a una sola cuenta de Cloud Identity o de Google Workspace. Esta cuenta proporciona la base de una única organizaciónGoogle Cloud que puedes usar para gestionar tus recursos Google Cloud.

Aunque los servidores de catálogo global proporcionan acceso a datos de varios dominios, su ámbito se limita 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, para federar un entorno de varios bosques con Google Cloud , se necesita al menos una instancia de GCDS por bosque. Las relaciones de confianza entre bosques permiten que la autenticación de usuarios funcione entre los límites de los bosques, por lo que basta con una sola instancia o flota de AD FS para gestionar 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 Cloudestán conectados mediante relaciones de confianza externas, se aplican las mismas consideraciones.

Varios bosques sin confianza entre bosques

En el entorno que se muestra en esta ilustración, no es posible autenticar ni acceder a recursos entre los límites del bosque. Tampoco es posible que una sola instancia o flota de AD FS gestione las solicitudes de inicio de sesión único de los usuarios de todos los bosques.

Por lo tanto, no es posible asignar varios bosques que no tengan relaciones de confianza 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 de Google Workspace independiente, lo que implica ejecutar al menos una instancia de GCDS y un servidor o una flota de AD FS por bosque.

En Google Cloud, se crea una organización independiente para cada cuenta de Cloud Identity o Google Workspace. En la mayoría de los casos, no es necesario que mantengas varias organizaciones independientes. Puede seleccionar una de las organizaciones y asociarla con las otras cuentas de Cloud Identity o Google Workspace. De esta forma, se creará una organización federada con varios bosques de Active Directory. Las demás organizaciones no se utilizan.

Asignar dominios DNS

El DNS desempeña un papel fundamental tanto en Active Directory como en Cloud Identity y Google Workspace. El segundo factor que debes tener en cuenta al planificar la federación de Active Directory y Google Cloud es cómo compartir o asignar 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 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 asociada al atributo mail opcional.
• Dominios de sufijo de UPN: estos dominios se usan para los nombres principales de usuario (UPN). De forma predeterminada, se usa el dominio DNS de Active Directory del dominio del usuario para crear un UPN. Por lo tanto, el UPN predeterminado del usuario john del dominio corp.example.com es [e-mail]. Sin embargo, puedes configurar un bosque para que use dominios DNS adicionales como sufijos de UPN que no correspondan a dominios DNS de Active Directory ni a dominios MX. Los UPNs son opcionales y se almacenan en el campo userPrincipalName del usuario.
• Dominios de endpoint: a los servidores públicos, como los servidores de AD FS, se les suele asignar un nombre DNS, como login.external.example.com. El dominio que se usa para estos fines puede coincidir con el dominio MX, el sufijo UPN o el dominio DNS de Active Directory, o bien puede ser un dominio completamente diferente.

Uso de dominios DNS en Google Cloud

Inicio de sesión con Google, que Google Cloud usa para la autenticación, utiliza direcciones de correo para identificar a los usuarios. Al usar direcciones de correo electrónico, no solo se garantiza que sean únicas en todo el mundo, sino que también se permite a Google Cloud enviar mensajes de notificación a las direcciones.

El inicio de sesión de Google determina el directorio o el proveedor de identidades que se va a usar para autenticar a un usuario en función de la parte del dominio de las direcciones de correo, que sigue el @. Por ejemplo, para una dirección de correo que usa el dominio gmail.com, el inicio de sesión con Google usa el directorio de usuarios de Gmail para la autenticación.

Cuando te registras en una cuenta de Google Workspace o de Cloud Identity, creas un directorio privado que Inicio de sesión puede usar para la autenticación. Del mismo modo que el directorio de Gmail está asociado al dominio gmail.com, las cuentas de Google Workspace y Cloud Identity deben asociarse a un dominio personalizado. Se usan tres tipos de dominios:

• Dominio principal: este dominio identifica la cuenta de Cloud Identity o Google Workspace y se usa como nombre de la organización en Google Cloud. Al registrarte en Cloud Identity o Google Workspace, debes especificar este nombre de dominio.
• Dominio secundario: además del dominio principal, puedes asociar otros dominios secundarios a una cuenta de Cloud Identity o Google Workspace. Cada usuario del directorio está asociado al dominio principal o a uno de los dominios secundarios. Dos usuarios, [e-mail] y [e-mail], se consideran usuarios independientes si example.com es el dominio principal y secondary.example.com es un dominio secundario.
• Alias de dominio: es un nombre alternativo de otro dominio. Es decir, [e-mail] y [e-mail] hacen referencia al mismo usuario si alias.example.com se configura como un dominio de alias de example.com.

Todos los dominios deben cumplir los siguientes requisitos:

• Deben ser nombres de dominio DNS globales válidos. Durante la configuración, es posible que necesites acceso de administrador a las zonas DNS correspondientes para verificar la propiedad del dominio.
• Un dominio, como example.com, solo puede hacer referencia a un directorio. Sin embargo, puedes usar subdominios diferentes, como subdomain.example.com, para hacer referencia a directorios distintos.
• Los dominios principales y secundarios deben tener un registro MX válido para que los mensajes enviados a direcciones de correo formadas con este nombre de dominio se puedan entregar correctamente.

Para habilitar la sincronización entre los directorios, es necesario asignar los dominios de Active Directory a los dominios que usan Cloud Identity o Google Workspace. Para determinar la asignación correcta, debes analizar cómo usas Active Directory y cómo se identifican los usuarios en un bosque de Active Directory, así como cómo se pueden asignar a Cloud Identity o Google Workspace.

Map users (Asignar usuarios)

El tercer factor que debes tener en cuenta al planificar la federación de Active Directory yGoogle Cloud es cómo asociar usuarios entre Active Directory y Cloud Identity o Google Workspace.

Identificar usuarios en Active Directory

Internamente, Active Directory usa dos identificadores para identificar a los usuarios de forma única:

• objectGUID: este ID único global se genera cuando se crea un usuario y nunca cambia.
• objectSID: El SID; es decir, el identificador de seguridad, se usa en todas las comprobaciones de acceso. Aunque este ID es único y estable en un dominio, es posible que, al moverlo a otro dominio del bosque, se le asigne un SID nuevo.

Ninguno de estos IDs es significativo para los usuarios, por lo que Active Directory ofrece dos formas sencillas de identificar a los usuarios:

• UPN (userPrincipalName): es la forma preferida de identificar a un usuario. Los UPNs siguen el formato RFC 822 de las direcciones de correo electrónico y se crean combinando el nombre de usuario con un dominio de sufijo de UPN, como en [e-mail]. Aunque es la forma preferida de identificar a los usuarios, los UPNs son opcionales, por lo que es posible que algunos usuarios de tu bosque de Active Directory no tengan un UPN.

  Aunque se considera una práctica recomendada que los UPNs 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 de NetBIOS y el nombre de usuario con el formato domain<var>user, como en corp\johndoe. Aunque estos nombres se consideran antiguos, se siguen usando con frecuencia y son el único identificador obligatorio de un usuario.

Es importante destacar que Active Directory no usa la dirección de correo del usuario (mail) para identificar a los usuarios. Por lo tanto, este campo no es obligatorio ni tiene que ser único en un bosque.

Todos estos identificadores se pueden cambiar en cualquier momento.

Asignar identidades de usuario

Para asignar usuarios de Active Directory a usuarios de Cloud Identity o Google Workspace, se necesitan dos datos de cada usuario:

• Un ID único y estable que puedes usar durante la sincronización para hacer un seguimiento de qué usuario de Active Directory corresponde a qué usuario de Cloud Identity o Google Workspace. En el lado de los anuncios, el objectGUID es perfecto para este propósito.
• Una dirección de correo cuyo dominio corresponde a un dominio principal, secundario o alias de tu cuenta de Cloud Identity o Google Workspace. Como esta dirección de correo se usará en todo el proceso, asegúrate de que sea significativa. Google CloudObtener una dirección a partir del objectGUID no es práctico, al igual que otras direcciones de correo generadas automáticamente.

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

Asignación por nombre principal de usuario

Para usar el campo userPrincipalName, se deben cumplir dos criterios para todos los usuarios sujetos a sincronización:

• Los nombres principales de usuario (UPNs) deben ser direcciones de correo válidas. Todos los dominios que se usen como dominios de sufijo de UPN también deben ser dominios MX y deben configurarse de forma que los correos que se envíen al UPN de un usuario se entreguen en su bandeja de entrada.

• Las asignaciones de UPN deben estar completas. Todos los usuarios que estén sujetos a la sincronización deben tener asignado un UPN. El siguiente comando de PowerShell puede ayudarte a encontrar usuarios que no tengan un UPN:

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

Si se cumplen estos dos criterios, puedes asignar de forma segura los UPNs a direcciones de correo de Cloud Identity o de Google Workspace. Puedes usar uno de los dominios de sufijo de UPN como dominio principal en Cloud Identity o Google Workspace y añadir cualquier otro dominio de sufijo de UPN como dominio secundario.

Si no se cumple uno de los criterios, puedes asignar UPNs a direcciones de correo de Cloud Identity o Google Workspace, pero se aplican las siguientes advertencias:

• Si los UPNs no son direcciones de correo válidas, es posible que los usuarios no reciban los correos de notificación que envía Google Cloud, lo que podría provocar que se pierdan información importante.
• Los usuarios sin UPN se ignoran durante la sincronización.
• Puedes configurar la sincronización para que sustituya el dominio del sufijo UPN por otro dominio. Si usas varios dominios de sufijo UPN en un bosque, este enfoque puede crear duplicados, ya que todos los dominios de sufijo UPN se sustituirán por un único dominio. En caso de que haya duplicados, solo se puede sincronizar un usuario.

Una de las principales ventajas de usar UPNs para mapear usuarios es que se garantiza que los UPNs son únicos en todo un bosque y que usan un conjunto de dominios seleccionado, lo que ayuda a evitar posibles problemas de sincronización.

Asignar por dirección de correo electrónico

Para usar el campo mail, todos los usuarios que estén sujetos a la sincronización deben cumplir los siguientes criterios:

• Las tareas por correo electrónico deben estar completas. Todos los usuarios que estén sujetos a la sincronización deben tener el campo mail rellenado. El siguiente comando de PowerShell puede ayudarte a encontrar usuarios para los que este campo no se ha rellenado:

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

• Las direcciones de correo deben usar un conjunto de dominios seleccionados, todos ellos de tu propiedad. Si algunos de tus usuarios utilizan direcciones de correo que hacen referencia a empresas colaboradoras o proveedores de correo para consumidores, esas direcciones no se podrán usar.

• Todas las direcciones de correo deben ser únicas en todo el bosque. Como Active Directory no exige la unicidad, es posible que tengas que implementar comprobaciones o políticas personalizadas.

Si todos los usuarios pertinentes cumplen estos criterios, puedes identificar todos los dominios que utilizan estas direcciones de correo y usarlos como dominios principales y secundarios en Cloud Identity o Google Workspace.

Si no se cumple uno de los criterios, puedes seguir asignando direcciones de correo a direcciones de correo de Cloud Identity o Google Workspace, pero debes tener en cuenta lo siguiente:

• Durante la sincronización, se ignorarán los usuarios sin dirección de correo electrónico, así como los usuarios con direcciones de correo electrónico que utilicen dominios que no estén asociados a la cuenta de Cloud Identity o Google Workspace.
• Cuando dos usuarios comparten la misma dirección de correo electrónico, solo se sincronizará uno de ellos.
• Puedes configurar la sincronización para sustituir el dominio de las direcciones de correo electrónico por otro. Este proceso puede crear duplicados, en cuyo caso solo se sincronizará un usuario.

Asignar grupos

El cuarto factor que debes tener en cuenta al planificar la federación de Active Directory y Google Cloud es si quieres sincronizar los grupos entre Active Directory y Google Cloud y cómo asignarlos.

En Google Cloud, los grupos se suelen usar para gestionar el acceso de manera eficiente en los proyectos. En lugar de asignar usuarios individuales a roles de gestión de identidades y accesos en cada proyecto, define un conjunto de grupos que modelen roles comunes en tu organización y, a continuación, asigna esos grupos a un conjunto de roles de gestión de identidades y accesos. Si modificas la pertenencia a los grupos, puedes controlar el acceso de los usuarios a todo un conjunto de recursos.

Active Directory distingue entre dos tipos de grupos: grupos de distribución y grupos de seguridad. Los grupos de distribución se usan para gestionar listas de correo. La sincronización de grupos de distribución es importante cuando migras de Microsoft Exchange a Google Workspace, por lo que GCDS puede gestionar grupos de distribución normales y dinámicos. Los grupos de distribución no son un problema en la gestión de identidades y accesos de Google Cloud, por lo que esta sección se centra exclusivamente en los grupos de seguridad.

La asignación de grupos entre Active Directory y Google Cloud es opcional. Una vez que hayas configurado el aprovisionamiento de usuarios, podrás crear y gestionar grupos directamente en Cloud Identity o Google Workspace. Esto significa que Active Directory seguirá siendo el sistema central para la gestión de identidades, pero no para la gestión de accesos. Para mantener Active Directory como sistema central de gestión de identidades y de acceso, te recomendamos que sincronices los grupos de seguridad de Active Directory en lugar de gestionarlos en Cloud Identity o Google Workspace. Con este método, puedes configurar IAM para usar las pertenencias a grupos de Active Directory y controlar quién tiene acceso a determinados recursos de Google Cloud.

Grupos de seguridad en Active Directory

Los grupos de seguridad desempeñan un papel fundamental en la seguridad de Windows y en la gestión del acceso a Active Directory. Este rol se facilita mediante tres tipos diferentes de grupos de Active Directory: grupos locales de dominio, grupos globales y grupos universales.

Grupos locales de dominio

Estos grupos solo son relevantes en el ámbito de un único dominio y no se pueden hacer referencia a ellos en otros dominios. Dado que no es necesario replicar su lista de miembros en todo el bosque, los grupos locales de dominio son los más flexibles en cuanto a los tipos de miembros que pueden incluir.

Grupos globales

Estos grupos se muestran y se pueden consultar en otros dominios. Sin embargo, su lista de miembros no se replica. Esta limitación restringe los tipos de miembros que pueden incluir estos grupos. 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 pueden hacer referencias a ellos en otros dominios y pueden incluir no solo usuarios y otros grupos universales, sino también grupos globales de todos los dominios.

Si tu bosque de Active Directory solo contiene un 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 cómo se puede hacer.

Como los grupos locales y globales de dominio no se replican completamente en 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, supone un obstáculo si quieres sincronizar estos grupos con Cloud Identity o Google Workspace. En concreto, si configuras GCDS para que use un servidor de catálogo global como fuente, la herramienta podrá encontrar grupos de todos los dominios del bosque. Sin embargo, solo los grupos que estén en el mismo dominio que el servidor del catálogo global contendrán una lista de miembros y serán aptos para la replicación. Para sincronizar grupos locales o globales de dominio en un bosque de varios dominios, debes ejecutar una instancia de GCDS independiente por dominio.

Como los grupos universales se replican 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 varias instancias de GCDS para sincronizar varios dominios de Active Directory con Cloud Identity o Google Workspace, ten en cuenta que es posible que no sea necesario sincronizar todos los grupos. Por este motivo, merece la pena analizar cómo se suelen usar los distintos tipos de grupos de seguridad en 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 utilizan 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 listas de control de acceso son muy detallados, por lo que hay muchos. Para simplificar el mantenimiento de las listas de control de acceso, es habitual crear grupos de recursos para agrupar los recursos que se usan y a los que se accede con frecuencia. Añade el grupo de recursos a todas las listas de control de acceso afectadas una vez y gestiona el acceso posterior modificando la pertenencia al grupo de recursos, no las listas de control de acceso.

Los recursos que se agrupan de esta forma suelen residir en un solo dominio. Por lo tanto, un grupo de recursos también tiende a referenciarse solo en un dominio, ya sea en las LCA o en otros grupos de recursos. Como la mayoría de los grupos de recursos son locales, suelen implementarse mediante grupos locales de dominio en Active Directory.

Grupos de roles y organizaciones

Los grupos de recursos ayudan a simplificar la gestión del acceso, pero en un entorno grande, es posible que tengas que añadir un nuevo usuario a un gran número de grupos de recursos. Por este motivo, los grupos de recursos se suelen complementar con grupos de roles o grupos de organización.

Los grupos de roles agregan los permisos que requiere un rol específico en la organización. Por ejemplo, un grupo de roles llamado "Lector de documentación de ingeniería" podría dar a los miembros acceso de solo lectura a toda la documentación de ingeniería. En la práctica, esto se implementaría creando un grupo de roles y haciéndolo miembro de todos los grupos de recursos que se utilicen para controlar el acceso a varios tipos de documentación.

Del mismo modo, los grupos de organizaciones agregan los permisos que necesitan los departamentos de una organización. Por ejemplo, un grupo de una organización llamado Ingeniería puede conceder acceso a todos los recursos que suelen necesitar los miembros del departamento de Ingeniería.

Técnicamente, no hay ninguna diferencia entre los grupos de roles y los grupos de recursos, y ambos se suelen usar conjuntamente. Sin embargo, a diferencia de los grupos de recursos, los grupos de roles y de organizaciones pueden tener relevancia más allá de los límites de un dominio. Para permitir que los grupos de recursos de otros dominios hagan referencia a estos grupos, los grupos de roles y de organizaciones suelen implementarse mediante grupos globales, que se limitan a los miembros de un solo dominio, y a veces se complementan con grupos universales, que permiten miembros de diferentes dominios.

En el siguiente diagrama se muestra un patrón de anidación que se suele usar en entornos de Active Directory con varios dominios.

Grupos en Cloud Identity y Google Workspace

En Cloud Identity y Google Workspace, solo hay un tipo de grupo. Los grupos de Cloud Identity y Google Workspace no se limitan al ámbito 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, se pueden hacer referencias a ellos y anidarlos en otras cuentas, y se pueden usar en cualquier Google Cloud organización.

Al igual que con los usuarios, Cloud Identity y Google Workspace identifican los grupos por su dirección de correo electrónico. La dirección de correo no tiene que corresponder a un buzón real, pero debe usar uno de los dominios registrados en la cuenta de Cloud Identity correspondiente.

A diferencia de los grupos de Active Directory, los miembros de un grupo de Cloud Identity o de Google Workspace no tienen permiso implícito para ver la lista de otros miembros del mismo grupo. En su lugar, para consultar la pertenencia a un grupo, generalmente se necesita una autorización explícita.

Uso de grupos en Google Cloud

Google Cloud usa un modelo de acceso basado en roles en lugar de un modelo de acceso basado en listas de control de acceso. Los roles se aplican a todos los recursos de un tipo determinado que se incluyan en un ámbito concreto. Por ejemplo, el rol de desarrollador de Kubernetes Engine tiene acceso completo a los objetos de la API de Kubernetes en todos los clústeres de un proyecto determinado. Debido a la naturaleza de los roles, no es necesario mantener grupos de recursos en Google Cloudy rara vez es necesario sincronizar grupos de recursos con Google Cloud.

Los grupos de roles y los grupos de organizaciones son igual de importantes en Google Cloudque en Active Directory, ya que facilitan la gestión del acceso de un gran número de usuarios. Sincronizar los roles y los grupos de organizaciones ayuda a mantener Active Directory como el lugar principal para gestionar el acceso.

Si implementas grupos de recursos de forma coherente como grupos locales de dominio y grupos de roles y de organización como grupos globales o universales, puedes usar el tipo de grupo para asegurarte de que solo se sincronicen los grupos de roles y de organización.

La cuestión de si es suficiente con ejecutar una sola instancia de GCDS por bosque multidominio o si necesitas varias instancias de GCDS se convierte en la cuestión de si utilizas grupos globales. Si implementas todos tus roles y grupos de organización mediante grupos universales, será suficiente con una sola instancia de GCDS. De lo contrario, necesitarás una instancia de GCDS por dominio.

Asignar identidades de grupo

Para asignar grupos de seguridad de Active Directory a grupos de Cloud Identity o Google Workspace, se necesita un identificador común. En Cloud Identity y Google Workspace, este identificador debe ser una dirección de correo cuyo dominio corresponda al dominio principal, secundario o alias de la cuenta de Cloud Identity o Google Workspace. Como esta dirección de correo se usará en todo el documento, Google Cloud debe ser legible. No es necesario que la dirección de correo se corresponda con 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 las direcciones de correo electrónico son un atributo opcional para los grupos y Active Directory no verifica la singularidad.

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

Asignar por nombre común

La ventaja de usar el nombre común (cn) es que está disponible y, al menos en una unidad organizativa, es único. Sin embargo, el nombre común no es una dirección de correo electrónico, por lo que necesita que se le añada el sufijo @DOMAIN para convertirse en una dirección de correo electrónico.

Puedes configurar GCDS para que añada automáticamente un sufijo al nombre del grupo. Como Active Directory se asegura de que los nombres de grupo y los nombres de usuario no entren en conflicto, es poco probable que una dirección de correo derivada de esta forma cause conflictos.

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

• Si dos grupos de dominios diferentes comparten un nombre común, la dirección de correo derivada entrará en conflicto, lo que provocará que se ignore uno de los grupos durante la sincronización.
• Solo puedes sincronizar grupos de dominios de un único bosque. Si sincronizas grupos de varios bosques mediante instancias independientes de GCDS, las direcciones de correo derivadas del nombre común no reflejan a qué bosque corresponden. Esta ambigüedad hará que una instancia de GCDS elimine cualquier grupo que se haya creado previamente desde otro bosque con otra instancia de GCDS.
• No puedes asignar grupos por nombre común si utilizas la sustitución de dominio para asignar usuarios.

Asignar por dirección de correo electrónico

Si usas la dirección de correo (mail) para mapear identidades de grupo, debes cumplir los mismos criterios que cuando usas la dirección de correo para mapear usuarios:

• Las tareas por correo electrónico deben estar completas. Aunque es habitual que los grupos de distribución tengan una dirección de correo, los grupos de seguridad suelen carecer de este atributo. Para usar la dirección de correo electrónico en el mapeado de identidades, los grupos de seguridad que estén sujetos a la sincronización deben tener el campo mail rellenado. El siguiente comando de PowerShell puede ayudarte a encontrar cuentas en las que este campo no se ha rellenado:

  Get-ADGroup -LDAPFilter "(!mail=*)"

• Las direcciones de correo deben usar un conjunto de dominios seleccionados, todos ellos de tu propiedad. Si algunos de tus usuarios utilizan direcciones de correo que hacen referencia a empresas colaboradoras o a proveedores de correo para consumidores, no podrás usar esas direcciones.

• Todas las direcciones de correo deben ser únicas en todo el bosque. Como Active Directory no exige la unicidad, es posible que tengas que implementar comprobaciones o políticas personalizadas.

Si todos los grupos pertinentes cumplen estos criterios, puedes identificar todos los dominios que usan estas direcciones de correo y asegurarte de que la lista de dominios DNS registrados en Cloud Identity o Google Workspace incluya estos dominios.

Si no se cumple uno de los criterios, puedes asignar UPNs a direcciones de correo de Cloud Identity o Google Workspace, con las siguientes advertencias:

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

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

Asignar unidades organizativas

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

En Google Cloud, las carpetas y los proyectos tienen un propósito similar, aunque los tipos de recursos que se gestionan en una Google Cloud organización son muy diferentes de los recursos que se gestionan en Active Directory. Por lo tanto, la jerarquía de carpetas adecuada para una empresa suele ser muy diferente de la estructura de las unidades organizativas de Active Directory. Google CloudPor lo tanto, rara vez es práctico asignar automáticamente unidades organizativas a carpetas y proyectos, y GCDS no admite esta opción.

Aparte de las carpetas, Cloud Identity y Google Workspace admiten el concepto de unidades organizativas. Las unidades organizativas se crean para agrupar y organizar a los usuarios, de forma 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 unidades organizativas de Active Directory con Cloud Identity o Google Workspace. En una configuración en la que Cloud Identity solo se usa para ampliar la gestión de identidades de Active Directory a Google Cloud, normalmente no es necesario asignar unidades organizativas.

Elegir la asignación adecuada

Como se indica al principio de este documento, no hay una única forma de asignar las estructuras de Active Directory y Google Cloud. Para ayudarte a elegir la asignación adecuada para tu situación, los siguientes gráficos de decisión resumen los criterios que se han tratado en las secciones anteriores.

Primero, consulta el siguiente gráfico para identificar cuántas cuentas de Cloud Identity o Google Workspace, instancias de GCDS e instancias o flotas de AD FS necesitarás.

A continuación, consulta el segundo gráfico para identificar los dominios que debes configurar en tu cuenta de Cloud Identity o Google Workspace.

Siguientes pasos

• Consulta las prácticas recomendadas para planificar cuentas y organizaciones y las prácticas recomendadas para federar Google Cloud con un proveedor de identidades externo.
• Configura GCDS para sincronizar 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 gestionar las cuentas de superadministrador.