En este documento se describe cómo puedes configurar Cloud Identity o Google Workspace para usar Microsoft Entra ID (antes Azure AD) como proveedor de identidades y fuente de identidades.
En este documento se compara la estructura lógica de Microsoft Entra ID con la estructura que usan Cloud Identity y Google Workspace, y se describe cómo puedes asignar clientes, dominios, usuarios y grupos de Microsoft Entra ID.
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 cuando todos los empleados ya tienen una cuenta en Microsoft Entra ID. 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 Microsoft Entra ID.
Para configurar la federación entre Microsoft Entra ID y Cloud Identity o Google Workspace, se necesitan dos elementos:
Aprovisionamiento de usuarios: los usuarios y grupos pertinentes se sincronizan periódicamente desde Microsoft Entra ID con Cloud Identity o Google Workspace. De esta forma, cuando creas un usuario en Microsoft Entra ID o sincronizas un usuario nuevo de Active Directory con Microsoft Entra ID, también se pone a disposición en Google Cloud para que se pueda hacer referencia a él en 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 Microsoft Entra ID se replican en Google Cloud , pero no al revés. Además, el aprovisionamiento no incluye contraseñas.
Inicio de sesión único: cada vez que un usuario necesita autenticarse, Google Cloud delega la autenticación en Microsoft Entra ID mediante el lenguaje de marcado para confirmaciones de seguridad (SAML). En función de la configuración de Microsoft Entra ID, es posible que Microsoft Entra ID haga lo siguiente:
- Realizar la autenticación.
- Usa la autenticación de acceso directo o la sincronización de hash de contraseñas.
- Delegar la autenticación en un servidor AD FS local.
Si Cloud Identity o Google Workspace delegan la autenticación en Microsoft Entra ID, no solo se evita tener que sincronizar contraseñas conGoogle Cloud, sino que también se asegura que se apliquen las políticas o los mecanismos de autenticación multifactor (MFA) que hayas configurado en Microsoft Entra ID o AD FS.
Estructura lógica de Microsoft Entra ID
Cuando usas Azure, utilizas uno o varios clientes de Microsoft Entra ID (también denominados directorios). Los clientes de Microsoft Entra ID son una estructura de nivel superior. Se consideran límites administrativos y sirven como contenedores de usuarios, grupos, recursos y grupos de recursos.
Cada inquilino de Microsoft Entra ID tiene al menos un dominio DNS asociado. Este dominio DNS se refleja en los nombres de usuario (también denominados nombres principales de usuario o UPNs), que tienen el formato name@domain, donde domain es uno de los dominios DNS asociados al tenant correspondiente.
Una empresa puede mantener varios clientes de Microsoft Entra ID. Entre los motivos habituales para tener varios inquilinos se incluyen distinguir entre diferentes partes de la organización, separar los recursos de producción de los recursos de desarrollo y pruebas, y usar inquilinos independientes para integrar varios bosques de un Active Directory local.
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. Sin embargo, a excepción de las cuentas de servicio, las organizaciones no se usan para gestionar usuarios y grupos, lo que las diferencia de los inquilinos de Microsoft Entra ID.
Para gestionar usuarios y grupos, Google Cloud se basa en Cloud Identity o Google Workspace. 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 Microsoft Entra ID y Google Cloud
A pesar de las similitudes entre la estructura lógica de Microsoft Entra ID yGoogle Cloud, no hay una sola asignación 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 inquilinos de Microsoft Entra ID 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.
Google Cloud solo interactúa con Microsoft Entra ID, no con tu Active Directory local. Por lo tanto, la forma en que has asignado los bosques y dominios de tu Active Directory local a Microsoft Entra ID no es un problema grave.
Asignar clientes de Microsoft Entra ID
En las siguientes secciones se describe cómo asignar clientes de Microsoft Entra ID en estos casos:
Un solo cliente
Si solo usas un cliente de Microsoft Entra ID, puedes asignarlo a una sola cuenta de Cloud Identity o Google Workspace y configurar la federación entre ambos. Esta cuenta de Cloud Identity o Google Workspace proporciona la base para una sola Google Cloud organización que puedes usar para gestionar todos los Google Cloud recursos.
Varios clientes
En las organizaciones más grandes, no es raro tener más de un inquilino de Microsoft Entra ID. Se pueden usar varios arrendatarios para diferenciar entre entornos de prueba y de producción, o entre diferentes partes de una organización.
Es posible asignar varios clientes de Microsoft Entra ID a una sola cuenta de Cloud Identity o Google Workspace, así como configurar el aprovisionamiento de usuarios y el inicio de sesión único. Sin embargo, esta asignación de N:1 puede debilitar el aislamiento entre los clientes de Microsoft Entra ID. Si concedes permiso a varios clientes de Microsoft Entra ID para crear y modificar usuarios en una sola cuenta de Cloud Identity o Google Workspace, estos clientes pueden interferir entre sí y manipular los cambios de los demás.
Por lo general, una forma más adecuada de integrar varios clientes de Microsoft Entra ID es crear una cuenta de Cloud Identity o Google Workspace independiente para cada cliente y configurar la federación entre cada par.
En Google Cloud, se crea una organización independiente para cada cuenta de Cloud Identity o Google Workspace. ComoGoogle Cloud permite organizar los recursos mediante proyectos y carpetas en una sola organización, suele ser poco práctico tener más de una organización. Sin embargo, puedes seleccionar una de las organizaciones y asociarla con las otras cuentas de Cloud Identity o Google Workspace. De esta forma, crearás una organización federada con varios bosques de Active Directory. Las demás organizaciones no se utilizan.
Usuarios externos
Con Microsoft Entra ID B2B, puedes invitar a usuarios externos como invitados a tu cliente de Microsoft Entra ID. Se crea un usuario para cada invitado y Microsoft Entra ID asigna automáticamente un UPN a estos usuarios invitados. El UPN que genera Microsoft Entra ID usa un prefijo derivado de la dirección de correo del invitado, combinado con el dominio inicial del cliente: prefix#EXT#@tenant.onmicrosoft.com.
El aprovisionamiento de usuarios invitados de Microsoft Entra ID a Cloud Identity o Google Workspace está sujeto a ciertas limitaciones:
- No puedes asignar el UPN de los usuarios invitados a direcciones de correo en Cloud Identity o Google Workspace porque
onmicrosoft.comes un dominio que no se puede añadir ni verificar en Cloud Identity o Google Workspace. Por lo tanto, debes asignar usuarios mediante un atributo que no sea el UPN. - Si se suspende a un usuario invitado en su arrendatario principal, es posible que el usuario correspondiente de Cloud Identity o Google Workspace siga activo y que no se revoque correctamente el acceso a los recursos de Google Cloud .
Una forma mejor de gestionar a los usuarios invitados que proceden de un cliente de Microsoft Entra ID diferente es crear varias cuentas de Cloud Identity o Google Workspace, tal como se indica en la sección anterior. Cada una de ellas se federará con un cliente de Microsoft Entra ID diferente. Para obtener más información, consulta el artículo Aprovisionamiento de usuarios e inicio de sesión único de Microsoft Entra ID B2B.
Para conceder acceso a determinados recursos a un usuario externo, no es necesario que el usuario tenga una cuenta de usuario en Cloud Identity o Google Workspace. Google Cloud A menos que lo impida una política, también puedes añadir directamente al usuario externo como miembro de los proyectos, las carpetas o la organización correspondientes, siempre que tenga una identidad de Google.
Asignar dominios DNS
El DNS juega un papel fundamental tanto en Microsoft Entra ID como en Cloud Identity y Google Workspace. El segundo factor que debes tener en cuenta al planificar la federación de Microsoft Entra ID y Google Cloud es cómo puedes compartir o asignar dominios DNS entre Microsoft Entra ID y Google Cloud.
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 te aseguras de que sean únicas en todo el mundo, sino que también puedes Google Cloud enviar mensajes de notificación a esas 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. Cuando te registres 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,
johndoe@example.comyjohndoe@secondary.example.com, se consideran usuarios independientes siexample.comes el dominio principal ysecondary.example.comes un dominio secundario. - Alias de dominio: es un nombre alternativo de otro dominio.
Es decir,
johndoe@example.comyjohndoe@alias.example.comhacen referencia al mismo usuario sialias.example.comse configura como un dominio de alias deexample.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, comosubdomain.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.
Uso de dominios DNS en Microsoft Entra ID
La forma en que Cloud Identity y Google Workspace usan el DNS es similar a la forma en que Microsoft Entra ID se basa en el DNS para distinguir los clientes de Microsoft Entra ID y asociar nombres de usuario con clientes. Sin embargo, debes tener en cuenta dos diferencias importantes:
Dominios iniciales: cuando creas un inquilino de Microsoft Entra ID, el inquilino se asocia a un dominio inicial, que es un subdominio de
onmicrosoft.com. Este dominio es diferente de cualquier nombre de dominio personalizado que puedas registrar, ya que no eres el propietario del dominio ni tienes acceso administrativo a la zona DNS correspondiente.Cloud Identity no tiene un equivalente a un dominio inicial, sino que requiere que seas el propietario de todos los dominios que asocies a una cuenta de Cloud Identity. Esto significa que no puedes registrar un subdominio
onmicrosoft.comcomo dominio de Cloud Identity.Dominios usados en los identificadores de usuario: Microsoft Entra ID distingue entre las direcciones de correo MOERA (Microsoft Online Email Routing Addresses) y los UPNs. Ambos siguen el formato RFC 822 (
user@domain), pero tienen finalidades diferentes: mientras que los UPNs se usan para identificar a los usuarios y en el formulario de inicio de sesión, solo los MOERAs se usan para enviar correos.El sufijo de dominio que usan los UPNs debe coincidir con uno de los dominios registrados de tu cliente de Microsoft Entra ID. Este requisito no se aplica a las direcciones de correo electrónico.
Cloud Identity y Google Workspace no se basan en el concepto de UPN, sino que utilizan la dirección de correo de un usuario como identificador. Por lo tanto, el dominio utilizado por la dirección de correo debe coincidir con uno de los dominios registrados de la cuenta de Cloud Identity o Google Workspace.
Un cliente de Microsoft Entra ID y una cuenta de Cloud Identity o Google Workspace pueden usar los mismos dominios DNS. Si no es posible usar los mismos dominios, puedes configurar el aprovisionamiento de usuarios y el inicio de sesión único para sustituir los nombres de dominio.
Teniendo en cuenta las dos diferencias descritas anteriormente, debes basar tu asignación de dominio en cómo piensas asignar los usuarios entre Microsoft Entra ID y Cloud Identity o Google Workspace.
Map users (Asignar usuarios)
El tercer factor que debes tener en cuenta al planificar la federación de Microsoft Entra ID yGoogle Cloud es cómo asociar usuarios entre Microsoft Entra ID y Cloud Identity o Google Workspace.
Para asignar correctamente usuarios de Microsoft Entra ID 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 Microsoft Entra ID corresponde a qué usuario de Cloud Identity o Google Workspace.
- Una dirección de correo cuyo dominio corresponda a un dominio principal, secundario o alias de Cloud Identity. Como esta dirección de correo se usará en todo el proceso, Google Clouddebe ser legible.
Internamente, Microsoft Entra ID identifica a los usuarios por ObjectId, que es un ID único generado aleatoriamente a nivel global. Aunque este ID es estable y, por lo tanto, cumple el primer requisito, no tiene sentido para los humanos y no sigue el formato de una dirección de correo electrónico. Para mapear usuarios, las únicas opciones prácticas son mapear por UPN o por dirección de correo.
Si el usuario introduce una dirección de correo que pertenece a una cuenta de Cloud Identity o Google Workspace configurada para usar el inicio de sesión único con Microsoft Entra ID, se le redirigirá a la pantalla de inicio de sesión de Microsoft Entra ID.
Microsoft Entra ID usa UPNs, no direcciones de correo electrónico, para identificar a los usuarios, por lo que la pantalla de inicio de sesión pide al usuario que proporcione un UPN.
Si el cliente de Microsoft Entra ID está configurado para usar AD FS para el inicio de sesión, se redirigirá al usuario a la pantalla de inicio de sesión de AD FS. AD FS puede identificar a los usuarios por su nombre principal de usuario (UPN) de Active Directory o por su nombre de inicio de sesión anterior a Windows 2000 (domain\user).
Si la dirección de correo utilizada en Cloud Identity o Google Workspace, el UPN utilizado por Microsoft Entra ID y el UPN utilizado por Active Directory son diferentes, la secuencia de pantallas de inicio de sesión puede resultar confusa para los usuarios finales. Por el contrario, si los tres identificadores son los mismos que en las capturas de pantalla de ejemplo (johndoe@example.com), los usuarios no se verán afectados por las diferencias técnicas entre los UPNs y las direcciones de correo electrónico, lo que minimizará la confusión que puedan tener.
Mapa de UPN
Desde el punto de vista de la experiencia del usuario, asignar los UPNs de Microsoft Entra ID a direcciones de correo de Cloud Identity o Google Workspace puede considerarse la mejor opción. Otra ventaja de usar UPNs es que Microsoft Entra ID garantiza la singularidad, por lo que no tendrás que preocuparte por los conflictos de nombres.
Sin embargo, para asignar UPNs de Microsoft Entra ID a direcciones de correo de Cloud Identity, debes cumplir estos requisitos:
- Los UPNs de Microsoft Entra ID deben ser direcciones de correo válidas para que los correos de notificación que envíe Google Cloud se entreguen correctamente al buzón del usuario. Si aún no lo has hecho, puedes configurar direcciones de correo de alias para asegurarte de que el usuario reciba ese correo.
- Los UPNs de todos los usuarios pertinentes de Microsoft Entra ID deben usar un dominio personalizado como sufijo (
user@custom-domain). Los UPNs que usen el dominio inicial de Microsoft Entra ID (user@tenant.onmicrosoft.com) no se pueden asignar a direcciones de correo de Cloud Identity, ya que el dominio inicial no es de tu propiedad, sino de Microsoft. - Todos los dominios personalizados que use Microsoft Entra ID para los UPNs también deben registrarse en Cloud Identity. Esto significa que debes tener acceso a las zonas DNS correspondientes para poder validar el dominio.
Para evitar que se sobrescriban los registros DNS
TXTque hayas creado para verificar la propiedad del dominio en Microsoft Entra ID, puedes usar un registroCNAMEpara verificar la propiedad del dominio en Cloud Identity.
Asignar usuarios por dirección de correo electrónico
Si no puedes asignar los UPNs de Microsoft Entra ID a las direcciones de correo de Cloud Identity o Google Workspace, puedes asignar los usuarios por dirección de correo.
Cuando especificas una dirección de correo en Active Directory, se almacena en el atributo mail del objeto user correspondiente y Microsoft Entra ID Connect sincronizará el valor con el atributo Mail de Microsoft Entra ID. Microsoft Entra ID también hace que el atributo esté disponible para el aprovisionamiento de usuarios, de modo que puedas asignarlo a la dirección de correo en Cloud Identity o cloudid_name_short.
Es importante destacar que el atributo Mail de Microsoft Entra ID no se muestra en el portal de Azure y solo se puede ver y editar a través de APIs o PowerShell. Aunque la interfaz de usuario te permite especificar una dirección de correo y una dirección de correo alternativa, ninguno de estos valores se almacena en el atributo Mail, por lo que no se pueden usar para aprovisionar en Cloud Identity o cloudid_name_short.
Por lo tanto, asignar usuarios a una dirección de correo solo es práctico si la mayoría de las operaciones de creación y edición de usuarios se realizan en Active Directory, no en Microsoft Entra ID.
Para asignar usuarios por dirección de correo, debes cumplir los siguientes requisitos adicionales:
- Las tareas por correo electrónico deben estar completas. Se debe asignar una dirección de correo a todos los usuarios que estén sujetos a la sincronización. Esto puede ocurrir sobre todo cuando los usuarios se sincronizan desde un Active Directory local, ya que
mailes un atributo de usuario opcional en Active Directory. Los usuarios que no tienen una dirección de correo en el atributoMailde Microsoft Entra ID se ignoran de forma silenciosa durante la sincronización. - Las direcciones de correo electrónico deben ser únicas en todo el cliente de Microsoft Entra ID. Aunque Active Directory no comprueba la unicidad al crear usuarios, Microsoft Entra ID Connect detecta las colisiones de forma predeterminada, lo que puede provocar que falle la sincronización de los usuarios afectados.
- No es necesario registrar los dominios que usan las direcciones de correo en Microsoft Entra ID, pero sí en Cloud Identity o Google Workspace. Este requisito significa que debes tener acceso a las zonas DNS correspondientes para poder validar el dominio, y excluye el uso de direcciones de correo con dominios que no te pertenezcan (como
gmail.com).
Trazar el ciclo de vida del usuario
Una vez que hayas definido una asignación entre los usuarios de Microsoft Entra ID y los usuarios de Cloud Identity o Google Workspace, debes decidir qué conjunto de usuarios quieres aprovisionar. Consulta nuestras prácticas recomendadas para asignar conjuntos de identidades para tomar esta decisión.
Si no quieres aprovisionar a todos los usuarios de tu cliente de Microsoft Entra ID, puedes habilitar el aprovisionamiento para un subconjunto de usuarios mediante asignaciones de usuarios o filtros de ámbito.
En la siguiente tabla se resume el comportamiento predeterminado del aprovisionamiento de Microsoft Entra ID y se muestra cómo habilitar o inhabilitar el aprovisionamiento de un usuario controla las acciones que Microsoft Entra ID realizará en Cloud Identity o Google Workspace.
| Aprovisionamiento habilitado para el usuario de Microsoft Entra ID | Estado del usuario en Cloud Identity o Google Workspace | Acción realizada en Microsoft Entra ID | Acción realizada en Cloud Identity o Google Workspace |
|---|---|---|---|
| No | (no existe) | Habilitar el aprovisionamiento | Crear usuario (*) |
| No | Existe (activo) | Habilitar el aprovisionamiento | Actualizar usuario |
| No | Ya existe (suspendida) | Habilitar el aprovisionamiento | Actualizar usuario, mantener suspendido |
| Sí | Ya existe. | Modificar usuario | Actualizar usuario |
| Sí | Ya existe. | Cambiar el nombre de UPN o la dirección de correo | Cambiar la dirección de correo principal y conservar la anterior como alias |
| Sí | Ya existe. | Inhabilitar el aprovisionamiento | Suspender usuario |
| Sí | Ya existe. | Eliminar usuario de forma no definitiva | Suspender usuario |
(*) Si existe una cuenta de consumidor con la misma dirección de correo, se eliminará.
Asignar grupos
El cuarto factor que debes tener en cuenta al planificar la federación de Microsoft Entra ID y Google Cloud es si quieres sincronizar grupos entre Microsoft Entra ID 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 representen los roles habituales de tu organización. Después, asignas 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.
La asignación de grupos entre Microsoft Entra ID 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, lo que significa que Active Directory o Microsoft Entra ID seguirán siendo el sistema central para la gestión de identidades, pero no para la gestión de accesos. Google Cloud
Para mantener Active Directory o Microsoft Entra ID como sistema central de gestión de identidades y de acceso, te recomendamos que sincronices los grupos de Microsoft Entra ID 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 o Microsoft Entra ID y controlar quién tiene acceso a los recursos de Google Cloud.
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.
Cuando trabajas con grupos en IAM, a menudo tienes que especificar los grupos por su dirección de correo electrónico en lugar de por su nombre. Por lo tanto, es mejor que los grupos tengan no solo un nombre significativo, sino también una dirección de correo significativa y reconocible.
Grupos en Microsoft Entra ID
Microsoft Entra ID admite varios tipos de grupos, cada uno de ellos adaptado a diferentes casos prácticos. Los grupos se limitan a un solo arrendatario y se identifican mediante un ID de objeto, que es un ID único global generado de forma aleatoria. Los grupos se pueden anidar y pueden contener usuarios del mismo inquilino o usuarios invitados de otros inquilinos mediante Azure B2B. Microsoft Entra ID también admite grupos dinámicos, cuyos miembros se determinan automáticamente en función de una consulta.
En el contexto de la integración de Microsoft Entra ID con Cloud Identity o Google Workspace, hay dos propiedades de los grupos que son de interés principal: si un grupo tiene habilitado el correo y si tiene habilitada la seguridad.
- Un grupo habilitado para seguridad se puede usar para gestionar el acceso a recursos en Microsoft Entra ID. Por lo tanto, cualquier grupo con la seguridad habilitada puede ser relevante en el contexto de Google Cloud.
- Un grupo habilitado para correo tiene una dirección de correo electrónico, lo cual es importante porque Cloud Identity y Google Workspace requieren que los grupos se identifiquen mediante una dirección de correo electrónico.
En Microsoft Entra ID, puedes crear grupos de tipo Seguridad u Office 365 (a veces llamados grupos unificados). Cuando sincronizas grupos de un servicio Active Directory local o usas el tipo Office 365, también puedes crear grupos de tipo Lista de distribución.
En la siguiente tabla se resumen las diferencias entre estos tipos de grupos en cuanto a si están habilitados para correo o para seguridad, y cómo se asignan a los tipos de grupos de Active Directory, suponiendo que se utiliza la configuración predeterminada de Microsoft Entra ID Connect:
| Fuente | Tipo de grupo de Active Directory | Tipo de grupo de Microsoft Entra ID | Habilitado para correo | Con funciones de seguridad |
|---|---|---|---|---|
| ID de Microsoft Entra | - | Grupo de Office 365 | Siempre | Opcional |
| ID de Microsoft Entra | - | Grupo de seguridad | Opcional | Siempre |
| in situ | Grupo de seguridad (con correo electrónico) | Grupo de seguridad | Sí | Sí |
| in situ | Grupo de seguridad (sin correo electrónico) | Grupo de seguridad | No | Sí |
| in situ | Lista de distribución (con correo electrónico) | Lista de distribución | Sí | No |
| in situ | Lista de distribución (sin correo electrónico) | (ignorado por Microsoft Entra ID Connect) |
A diferencia de los usuarios, Microsoft Entra ID requiere que las direcciones de correo asignadas a los grupos usen un dominio que se haya registrado como dominio personalizado en Microsoft Entra ID. Este requisito da lugar al siguiente comportamiento predeterminado:
- Si un grupo de Active Directory usa una dirección de correo que utiliza un dominio que se ha registrado previamente en Microsoft Entra ID, la dirección de correo se mantiene correctamente durante la sincronización con Microsoft Entra ID.
- Si un grupo de Active Directory usa una dirección de correo que no se ha registrado en Microsoft Entra ID, Microsoft Entra ID generará automáticamente una nueva dirección de correo durante la sincronización. Esta dirección de correo usa el dominio predeterminado del arrendatario. Si tu arrendatario usa el dominio inicial como dominio predeterminado, la dirección de correo resultante tendrá el formato
[name]@[tenant].onmicrosoft.com. - Si creas un grupo de Office 365 en Microsoft Entra ID, Microsoft Entra ID también generará automáticamente una dirección de correo que use el dominio predeterminado del cliente.
Asignar identidades de grupo
Para asignar correctamente grupos de Microsoft Entra ID a grupos de Cloud Identity o Google Workspace, se necesita un identificador común, que debe ser una dirección de correo electrónico. Por parte de Microsoft Entra ID, este requisito te ofrece dos opciones:
- Puedes usar la dirección de correo de un grupo de Microsoft Entra ID y asignarla a una dirección de correo de Cloud Identity o Google Workspace.
- Puedes obtener una dirección de correo a partir del nombre del grupo en Microsoft Entra ID y asignar la dirección resultante a una dirección de correo en Cloud Identity o Google Workspace.
Asignar por dirección de correo electrónico
Asignar grupos por dirección de correo es la opción más evidente, pero requiere que cumplas varios requisitos:
- Todos los grupos que estén sujetos a la sincronización deben tener una dirección de correo. En la práctica, esto significa que solo puedes sincronizar grupos habilitados para correo. Los grupos que no tienen una dirección de correo se ignoran durante el aprovisionamiento.
- Las direcciones de correo electrónico deben ser únicas en todo el arrendatario. Como Microsoft Entra ID no exige que sean únicos, es posible que tengas que implementar comprobaciones o políticas personalizadas.
- Los dominios utilizados por las direcciones de correo deben registrarse tanto en Microsoft Entra ID como en Cloud Identity o Google Workspace. No se sincronizarán los grupos con direcciones de correo que usen dominios no registrados en Cloud Identity o Google Workspace, incluido el dominio
tenant.onmicrosoft.com.
Si todos los grupos pertinentes cumplen estos criterios, identifica los dominios que utilizan estas direcciones de correo y asegúrate de que la lista de dominios DNS registrados en Cloud Identity o Google Workspace incluya estos dominios.
Asignar por nombre
Cumplir los criterios necesarios para asignar grupos por dirección de correo puede ser complicado, sobre todo si muchos de los grupos de seguridad que quieres aprovisionar en Cloud Identity o Google Workspace no tienen habilitado el correo. En este caso, sería mejor derivar automáticamente una dirección de correo a partir del nombre visible del grupo.
Para obtener una dirección de correo, hay dos problemas:
- Una dirección de correo derivada del nombre de un grupo puede coincidir con la dirección de correo de un usuario.
- Microsoft Entra ID no exige que los nombres de los grupos sean únicos. Si varios grupos de su inquilino de Microsoft Entra ID comparten el mismo nombre, las direcciones de correo derivadas de este nombre entrarán en conflicto, lo que provocará que solo se sincronice un grupo correctamente.
Puedes superar el primer reto usando un dominio para la dirección de correo generada que sea diferente de cualquiera de los dominios utilizados por los usuarios. Por ejemplo, si todos tus usuarios utilizan direcciones de correo con example.com como dominio, puedes usar groups.example.com para todos los grupos. Para registrar subdominios en Cloud Identity o Google Workspace, no es necesario verificar el dominio, por lo que la zona DNS groups.example.com ni siquiera tiene que existir.
Solo puedes superar el segundo reto, los nombres de grupo duplicados, técnicamente derivando la dirección de correo del grupo del ID de objeto. Como los nombres de los grupos resultantes son bastante crípticos y difíciles de usar, es mejor identificar y cambiar el nombre de los grupos duplicados en Microsoft Entra ID antes de configurar el aprovisionamiento en Cloud Identity o Google Workspace.
Asigna el ciclo de vida del grupo
Una vez que hayas definido una asignación entre los grupos de Microsoft Entra ID y los grupos de Cloud Identity o Google Workspace, debes decidir qué conjunto de grupos quieres aprovisionar. Al igual que con los usuarios, puedes habilitar el aprovisionamiento para un subconjunto de grupos mediante asignaciones de grupos o filtros de ámbito.
En la siguiente tabla se resume el comportamiento predeterminado del aprovisionamiento de Microsoft Entra ID y se muestra cómo habilitar o inhabilitar el aprovisionamiento de un grupo controla las acciones que Microsoft Entra ID realizará en Cloud Identity o Google Workspace.
| Aprovisionamiento habilitado para el grupo de Microsoft Entra ID | Estado del grupo en Cloud Identity o Google Workspace | Acción realizada en Microsoft Entra ID | Acción realizada en Cloud Identity o Google Workspace |
|---|---|---|---|
| No | (no existe) | Habilitar el aprovisionamiento | Crear grupo |
| No | Ya existe. | Habilitar el aprovisionamiento | Añadir miembro y conservar todos los miembros actuales |
| Sí | Ya existe. | Cambiar el nombre del grupo | Cambiar el nombre del grupo |
| Sí | Ya existe. | Modificar descripción | Actualizar descripción |
| Sí | Ya existe. | Añadir miembro | Añadir miembro y conservar todos los miembros actuales |
| Sí | Ya existe. | Quitar miembro | Quitar miembro |
| Sí | Ya existe. | Inhabilitar el aprovisionamiento | El grupo se queda como está (incluidos los miembros) |
| Sí | Ya existe. | Eliminar grupo | El grupo se queda como está (incluidos los miembros) |
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.
- Consulta cómo configurar el aprovisionamiento y el inicio de sesión único entre Microsoft Entra ID y Cloud Identity.
- Consulta las prácticas recomendadas para gestionar cuentas de superadministrador.