En este artículo, se describe cómo configurar Cloud Identity o Google Workspace a fin de usar Microsoft Entra ID (antes Azure AD) como IdP y fuente para las identidades.
Además, se compara la estructura lógica de Microsoft Entra ID y la estructura que usan Cloud Identity y Google Workspace y se describe cómo puedes asignar grupos de usuarios, dominios, usuarios y grupos de Microsoft Entra ID.
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 Microsoft Entra ID. Si se federan las identidades de los usuarios 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 Microsoft Entra ID.
La configuración de la federación entre Microsoft Entra ID y Cloud Identity o Google Workspace implica dos partes:
Aprovisionamiento de usuarios: los grupos y usuarios relevantes se sincronizan de forma periódica desde Microsoft Entra ID hasta Cloud Identity o Google Workspace. Este proceso garantiza que, cuando creas un nuevo usuario en Microsoft Entra ID o sincronizas un usuario nuevo de Active Directory con Microsoft Entra ID, también esté disponible en Google Cloud para que se le pueda hacer referencia 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 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: Cuando un usuario necesita autenticarse, Google Cloud delega la autenticación a Microsoft Entra ID mediante el protocolo de lenguaje de marcado para confirmaciones de seguridad (SAML). Según la configuración de Microsoft Entra ID, este podría realizar una de las siguientes acciones:
- Realizar la autenticación de forma autónoma
- Usar autenticación de paso o sincronización de hash de contraseña
- Delegar la autenticación a un servidor de AD FS local
Hacer que Cloud Identity o Google Workspace delegue la autenticación a Microsoft Entra ID evita tener que sincronizar las contraseñas con Google Cloud y, también, garantiza que las políticas o los mecanismos de autenticación de varios factores (MFA) aplicables que hayas configurado en Microsoft Entra ID o AD FS se apliquen de forma forzosa.
Estructura lógica de Microsoft Entra ID
Cuando usas Azure, se usa una o más instancias de Microsoft Entra ID (también conocidas como directorios). Las instancias de Microsoft Entra ID son una estructura de nivel superior. Son consideradas límites administrativos y sirven como contenedores para usuarios, grupos, recursos y grupos de recursos.
Todo usuario de Microsoft Entra ID tiene, al menos, un dominio DNS asociado. Este dominio DNS se refleja en los nombres de usuario (también conocidos como Nombres de usuario principales o UPN), que toman la forma dename@domain, en el que domain es uno de los dominios DNS asociados con el usuario correspondiente.
Una empresa puede conservar varios usuarios de Microsoft Entra ID. Las razones comunes para tener múltiples instancias incluyen distinguir entre diferentes partes de la organización, separar los recursos de producción de los recursos de desarrollo y prueba y usar instancias separadas para integrar varios bosques de un Active Directory local.
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. Sin embargo, a excepción de las cuentas de servicio, las organizaciones no se usan para administrar usuarios ni grupos, lo que las diferencia de los inquilinos de Microsoft Entra ID.
Para administrar usuarios y grupos, Google Cloud depende de Cloud Identity o Google Workspace. 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 Microsoft Entra ID y Google Cloud
A pesar de ciertas similitudes entre las estructuras lógicas de Microsoft Entra ID y Google Cloud, no existe ninguna asignación 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 asignar la estructura depende de los varios factores que se detallan a continuación:
- Cómo mapear usuarios de Microsoft Entra ID a cuentas de Cloud Identity o Google Workspace
- Cómo mapear dominios DNS
- Cómo mapear usuarios
- Cómo mapear grupos
En las secciones siguientes, se analizan cada uno de estos factores.
Google Cloud interactúa solo con Microsoft Entra ID, no con el Active Directory local. Por lo tanto, la forma en que asignaste los bosques y dominios de tu Active Directory local a Microsoft Entra ID no es importante.
Asignación de instancias de Microsoft Entra ID
Inquilino único
Si usas un usuario único de Microsoft Entra ID, puedes asignarlo a una cuenta individual de Cloud Identity o de Google Workspace y configurar la federación entre ambos. Esta cuenta de Cloud Identity o Google Workspace, proporciona la base para una organización de Google Cloud individual que puedes usar para administrar todos los recursos de Google Cloud.
Varios usuarios
En organizaciones más grandes, suele haber más de una instancia de Microsoft Entra ID. Se pueden usar varios inquilinos para diferenciar entre entornos de prueba y de producción o entre distintas partes de una organización.
Aunque es posible aprovisionar usuarios y grupos de más de un usuario de Microsoft Entra ID a una sola cuenta de Cloud Identity o Google Workspace, en la actualidad no es posible configurar el inicio de sesión único, de manera que funcione para los usuarios de varios grupos de Microsoft Entra ID. Si usas varios usuarios de Microsoft Entra ID, deberás crear una cuenta de Cloud Identity o Google Workspace independiente para cada usuario y configurar la federación entre cada par.
En Google Cloud, se crea una organización distinta para cada cuenta de Cloud Identity o Google Workspace. Debido a que Google Cloud permite organizar los recursos mediante proyectos y carpetas dentro de una sola organización, tener más de una organización no suele ser práctico. Sin embargo, puedes seleccionar una de las organizaciones y asociarla a las otras cuentas de Cloud Identity o Google Workspace, lo que crea en efecto una organización federada con múltiples bosques de Active Directory. Las otras organizaciones quedan sin uso.
Usuarios externos
Con B2B de Microsoft Entra ID, puedes agregar usuarios externos como invitados a tu instancia de Microsoft Entra ID. Se crea un usuario nuevo para cada invitado y Microsoft Entra ID asigna un UPN a estos usuarios invitados de forma automática. El UPN que genera Microsoft Entra ID usa un prefijo derivado de la dirección de correo electrónico del invitado, combinado con el dominio inicial del inquilino: 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 mapear el UPN de los usuarios invitados a las direcciones de correo electrónico en Cloud Identity o Google Workspace, ya que
onmicrosoft.comes un dominio que no se puede agregar ni verificar en Cloud Identity o Google Workspace. Por lo tanto, debes mapear usuarios mediante un atributo que no sea el UPN. - Si se suspende a un usuario invitado en su grupo principal, el usuario correspondiente en Cloud Identity o Google Workspace puede seguir activo, y podría no estar revocado de forma correcta el acceso a los recursos de Google Cloud.
Una forma mejor de tratar con los usuarios invitados que se originan en un inquilino de Microsoft Entra ID diferente es crear varias cuentas de Cloud Identity o Google Workspace como se describe en la sección anterior, cada una federada con un inquilino de Microsoft Entra ID diferente. Para obtener más información, consulta:Aprovisionamiento de usuarios de B2B con Microsoft Entra ID y inicio de sesión único
Si quieres otorgar acceso a ciertos recursos de Google Cloud a un usuario externo, no es necesario que este tenga una cuenta de usuario en Cloud Identity o Google Workspace. A menos que esté restringido por una política, también puedes agregar al usuario externo directamente como miembro de la organización, las carpetas o los proyectos respectivos, siempre que el usuario tenga una identidad de Google.
Mapea dominios DNS
El DNS tiene una función fundamental tanto en Microsoft Entra ID como en Cloud Identity y Google Workspace. El segundo factor que se debe tener en cuenta cuando se planifica la federación de Microsoft Entra ID y Google Cloud es cómo compartir o mapear dominios DNS entre Microsoft Entra ID y Google Cloud.
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. Usar 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 la cuenta 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.comyjohndoe@secondary.example.com, se consideran usuarios separados siexample.comes el dominio principal ysecondary.example.comes un dominio secundario. - Dominio de alias: nombre alternativo para otro dominio.
Es decir,
johndoe@example.comyjohndoe@alias.example.comhacen referencia al mismo usuario sialias.example.comestá configurado como un dominio de alias paraexample.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, comosubdomain.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.
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 grupos de usuarios de Microsoft Entra ID y asociar nombres de usuario con grupos. Sin embargo, debes tener en cuenta dos diferencias notables:
Dominios iniciales: Cuando creas una instancia de Microsoft Entra ID, la instancia está asociada con un dominio inicial, que es un subdominio de
onmicrosoft.com. Este dominio es diferente de cualquier nombre de dominio personalizado en el que puedas registrarte porque no tienes la propiedad del dominio ni acceso administrativo a la zona DNS respectiva.Cloud Identity no tiene un equivalente al dominio inicial y, en su lugar, requiere que tengas la propiedad de todos los dominios que asocias a una cuenta de Cloud Identity. Este requisito implica que no puedes registrar un subdominio de
onmicrosoft.comcomo dominio de Cloud Identity.Dominios usados en identificadores de usuario: Microsoft Entra ID distingue entre las MOERA (direcciones de enrutamiento de correo electrónico en línea de Microsoft) y los UPN de las direcciones de correo electrónico. Ambos siguen un formato RFC 822 (
user@domain), pero tienen diferentes propósitos: mientras que los UPN sirven para identificar a los usuarios y se usan en el formulario de inicio de sesión, solo las MOERA se usan a fin de entregar el correo electrónico.El sufijo de dominio que usan los UPN debe coincidir con uno de los dominios registrados del inquilino de Microsoft Entra ID; este requisito no se aplica a las direcciones de correo electrónico.
Cloud Identity y Google Workspace no dependen del concepto de un UPN y, en su lugar, usan la dirección de correo electrónico de un usuario como identificador. En consecuencia, el dominio que usa la dirección de correo electrónico debe coincidir con uno de los dominios registrados de la cuenta de Cloud Identity o Google Workspace.
Un usuario de Microsoft Entra ID y una cuenta de Cloud Identity o de 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.
Debes tener en cuenta las dos diferencias descritas antes para tu asignación de dominio con respecto a cómo planeas asignar usuarios entre Microsoft Entra ID y Cloud Identity o Google Workspace.
Mapeo de usuarios
El tercer factor que debes considerar cuando planificas la federación de Microsoft Entra ID y Google Cloud es cómo mapear usuarios entre Microsoft Entra ID y Cloud Identity o Google Workspace.
El mapeo exitoso de usuarios de Microsoft Entra ID a usuarios de Cloud Identity o 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 Microsoft Entra ID corresponde a qué usuario de Cloud Identity o Google Workspace.
- Una dirección de correo electrónico en la que la parte del dominio corresponde a un dominio principal, secundario o de alias de Cloud Identity. Esta dirección de correo electrónico debe ser legible porque se usará en todo Google Cloud.
De forma interna, Microsoft Entra ID identifica a los usuarios por ObjectId, que es un ID único a nivel global generado al azar. Aunque este ID es estable y, por lo tanto, cumple con el primer requisito, no es legible 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 electrónico.
Si el usuario ingresa una dirección de correo electrónico que pertenece a una cuenta de Cloud Identity o Google Workspace con una configuración de inicio de sesión único con Microsoft Entra ID, el usuario es redireccionado a la pantalla de inicio de sesión de Microsoft Entra ID.
Microsoft Entra ID usa UPN para identificar a los usuarios, no direcciones de correo electrónico, por lo que la pantalla de inicio de sesión solicita al usuario que proporcione un UPN.
Si la instancia de Microsoft Entra ID está configurada a fin de usar AD FS para el inicio de sesión, otro redireccionamiento llevará al usuario a la pantalla de inicio de sesión de AD FS. AD FS puede identificar a los usuarios por su 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 electrónico usada para Cloud Identity o Google Workspace, el UPN que usa Microsoft Entra ID y el UPN que usa Active Directory son distintos, la secuencia de pantallas de inicio de sesión puede resultar confusa para los usuarios finales. Por el contrario, si los tres identificadores son iguales, como en las capturas de pantalla de ejemplo (johndoe@example.com), los usuarios no estarán expuestos a las diferencias técnicas entre los UPN y direcciones de correo electrónico, lo que minimiza la posible confusión de los usuarios.
Mapea por UPN
Desde la perspectiva de la experiencia del usuario, el mapeo de UPN de Microsoft Entra ID a direcciones de correo electrónico de Cloud Identity o Google Workspace podría considerarse la mejor opción. Otro beneficio de basarse en los UPN es que Microsoft Entra ID garantiza la exclusividad para evitar el riesgo de conflictos de nombres.
Sin embargo, para asignar los UPN de Microsoft Entra ID a las direcciones de correo electrónico de Cloud Identity, debes cumplir estos requisitos:
- Los UPN de Microsoft Entra ID deben ser direcciones de correo electrónico válidas para que cualquier correo electrónico de notificación que envíe Google Cloud se entregue de forma correcta al buzón del usuario. Si este no es el caso, es posible que puedas configurar direcciones de correo electrónico de alias para garantizar que el usuario reciba este correo electrónico.
- Los UPN de todos los usuarios pertinentes en Microsoft Entra ID deben usar un dominio personalizado como sufijo (
user@custom-domain). Los UPN que usan el dominio inicial de Microsoft Entra ID (user@tenant.onmicrosoft.com) no se pueden asignar a direcciones de correo electrónico de Cloud Identity porque el dominio inicial no es de tu propiedad, sino de Microsoft. - Todos los dominios personalizados que Microsoft Entra ID usa para los UPN deben registrarse también en Cloud Identity. Este requisito implica que debes tener acceso a las zonas DNS correspondientes para realizar la validación del dominio.
Si quieres evitar la anulación de los registros DNS
TXTexistentes que puedas haber creado para verificar la propiedad del dominio en Microsoft Entra ID, puedes usar un registroCNAMEa fin de verificar la propiedad del dominio en Cloud Identity.
Mapea usuarios por dirección de correo electrónico
Si no puedes asignar los UPN de Microsoft Entra ID a Cloud Identity o a las direcciones de correo electrónico de Google Workspace, puedes asignar usuarios por dirección de correo electrónico.
Cuando especificas una dirección de correo electrónico en Active Directory, se almacena en el atributo mail del objeto user respectivo, y Microsoft Entra ID Connect sincronizará el valor con el atributo Mail en Microsoft Entra ID. Microsoft Entra ID también hace que el atributo esté disponible para el aprovisionamiento de usuarios a fin de que puedas mapearlo a la dirección de correo electrónico en Cloud Identity o cloudid_name_short.
Cabe destacar que el atributo Mail de Microsoft Entra ID en la actualidad no aparece en el portal de Azure y solo se puede ver y editar a través de API o PowerShell. Aunque la interfaz de usuario te permite especificar una dirección de correo electrónico y una dirección de correo electrónico alternativa, ninguno de estos valores se almacena en el atributo Mail, por lo que no se pueden usar para el aprovisionamiento de Cloud Identity o cloudid_name_short.
Como resultado, mapear los usuarios de una dirección de correo electrónico es práctico solo cuando realizas la mayor parte de la creación y edición de usuarios en Active Directory, no en Microsoft Entra ID.
La asignación de usuarios por dirección de correo electrónico requiere que cumplas los siguientes requisitos adicionales:
- Las asignaciones de correo electrónico deben estar completas. Todos los usuarios sujetos a la sincronización deben tener asignada una dirección de correo electrónico. Este podría no ser el caso, en especial 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 electrónico en el atributoMailde Microsoft Entra ID se ignoran en silencio durante la sincronización. - Las direcciones de correo electrónico deben ser exclusivas en la instancia. Aunque Active Directory no verifica la exclusividad durante la creación del usuario, Microsoft Entra ID Connect detecta las colisiones de forma predeterminada, lo que puede provocar que falle la sincronización de los usuarios afectados.
- Los dominios que usan las direcciones de correo electrónico no necesitan estar registrados en Microsoft Entra ID, pero sí en Cloud Identity o en Google Workspace. Este requisito implica que debes tener acceso a las zonas DNS respectivas para realizar la validación del dominio, y se descarta el uso de direcciones de correo electrónico con dominios que no sean de tu propiedad (como
gmail.com).
Mapeo del ciclo de vida del usuario
Después de definir 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 deseas aprovisionar. Consulta las prácticas recomendadas sobre la asignación de conjuntos de identidades para obtener orientación sobre cómo tomar esta decisión.
Si no quieres aprovisionar a todos los usuarios de tu inquilino de Microsoft Entra ID, puedes habilitar el aprovisionamiento para un subconjunto de usuarios mediante las asignaciones de usuarios o los filtros de alcance.
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 realizará Microsoft Entra ID en Cloud Identity o Google Workspace.
| Aprovisionamiento habilitado para el usuario de Microsoft Entra ID | Estado del usuario en Cloud Identity/Google Workspace | Acción realizada en Microsoft Entra ID | Acción realizada en Cloud Identity/Google Workspace |
|---|---|---|---|
| No | No existe | Habilitar aprovisionamiento | Crear usuario nuevo (*) |
| No | Existe (activo) | Habilitar aprovisionamiento | Actualizar usuario existente |
| No | Existe (suspendido) | Habilitar aprovisionamiento | Actualizar usuario existente, mantener suspendido |
| Sí | Existe | Modificar usuario | Actualizar usuario existente |
| Sí | Existe | Cambiar el nombre de UPN o la dirección de correo electrónico | Cambiar la dirección de correo electrónico principal, mantener la dirección anterior como alias |
| Sí | Existe | Inhabilitar aprovisionamiento | Mantener usuario como está |
| Sí | Existe | Borrar usuario de forma no definitiva | Suspender usuario |
| Sí | Existe | Borrar usuario de forma permanente | Suspender usuario, agregar prefijo del_ a dirección de correo electrónico |
(*) Si existe una cuenta personal con la misma dirección de correo electrónico, dicha cuenta se expulsa.
Mapea grupos
El cuarto factor que debes considerar cuando planeas federar Microsoft Entra ID y Google Cloud es si deseas sincronizar los grupos entre Microsoft Entra ID y Google Cloud y cómo asignarlos.
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 los roles de IAM en cada proyecto, debes definir un conjunto de grupos que modelen funciones comunes en la organización. Luego, debes asignar esos grupos a un conjunto de funciones de IAM. Si modificas la membresía de los grupos, puedes controlar el acceso de los usuarios a un conjunto de recursos completo.
La asignación de grupos entre Microsoft Entra ID y Google Cloud es opcional. Una vez que configures el aprovisionamiento de usuarios, puedes crear y administrar grupos de directamente en Cloud Identity o Google Workspace, lo que significa que Active Directory o Microsoft Entra ID continúa como el sistema central para la administración de identidades, pero no para la administración de accesos a Google Cloud.
A fin de mantener Active Directory o Microsoft Entra ID como el sistema central de administración de identidades y accesos, se recomienda sincronizar los grupos de Microsoft Entra ID, en lugar de administrarlos en Cloud Identity o Google Workspace. Con este enfoque, puedes configurar IAM a fin de que puedas usar membresías de grupos en Active Directory o Microsoft Entra ID para controlar quién tiene acceso a los recursos en Google Cloud.
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 y 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 los 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.
Cuando trabajas con grupos en IAM, a menudo necesitas especificar grupos por dirección de correo electrónico, en lugar de por el nombre. Por lo tanto, es mejor que los grupos tengan un nombre significativo y, además, una dirección de correo electrónico significativa y reconocible.
Grupos en Microsoft Entra ID
Microsoft Entra ID admite varios tipos de grupos, y cada uno se adapta a diferentes casos prácticos. Los grupos tienen alcance de una sola instancia y se identifican con un ID de objeto, que es un ID exclusivo global generado de forma aleatoria. Los grupos se pueden anidar y pueden contener usuarios de la misma instancia o usuarios invitados desde otras instancias mediante Azure B2B. Microsoft Entra ID también admite grupos dinámicos, cuyos miembros se determinan de forma automática 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 grupos de interés principal, si el grupo está habilitado para correo y si está habilitado para seguridad:
- Se puede usar un grupo habilitado para seguridad a fin de administrar el acceso a los recursos en Microsoft Entra ID. Por lo tanto, cualquier grupo habilitado para seguridad tiene posible relevancia en el contexto de Google Cloud.
- Un grupo habilitado para correo tiene una dirección de correo electrónico, que es relevante porque Cloud Identity y Google Workspace requieren que los grupos se identifiquen con una dirección de correo electrónico.
En Microsoft Entra ID, puedes crear grupos de tipo Seguridad o de tipo Office 365 (a veces llamados grupos unificados). Cuando se sincronizan grupos desde un Active Directory local o si se usa el tipo de Office 365, también puedes crear grupos del tipo Lista de distribución.
En la tabla siguiente, se resumen las diferencias entre estos diferentes tipos de grupos con respecto a la habilitación para correo o seguridad, y cómo se asignan a los tipos de grupos de Active Directory, si se teniendo en cuenta una 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 | Habilitado para seguridad |
|---|---|---|---|---|
| Microsoft Entra ID | - | Grupo de Office 365 | Siempre | Opcional |
| Microsoft Entra ID | - | Grupo de Seguridad | Opcional | Siempre |
| local | Grupo de Seguridad (con correo electrónico) | Grupo de Seguridad | Sí | Sí |
| local | Grupo de Seguridad (sin correo electrónico) | Grupo de Seguridad | No | Sí |
| local | Lista de distribución (con correo electrónico) | Lista de distribución | Sí | No |
| local | Lista de distribución (sin correo electrónico) | (ignorado por Microsoft Entra ID Connect) |
A diferencia de lo que ocurre con los usuarios, Microsoft Entra ID requiere que las direcciones de correo electrónico asignadas a grupos usen un dominio que se haya registrado como dominio personalizado en Microsoft Entra ID. Este requisito da como resultado el siguiente comportamiento predeterminado:
- Si un grupo en Active Directory usa una dirección de correo electrónico con un dominio que ya se registró en Microsoft Entra ID, la dirección de correo electrónico se mantiene intacta durante la sincronización con Microsoft Entra ID.
- Si un grupo en Active Directory usa una dirección de correo electrónico que no se registró en Microsoft Entra ID, se genera de forma automática una nueva dirección de correo electrónico durante la sincronización. Esta dirección de correo electrónico usa el dominio predeterminado de la instancia. Si en tu instancia se usa el dominio inicial como dominio predeterminado, la dirección de correo electrónico resultante tendrá la forma
[name]@[tenant].onmicrosoft.com. - Si creas un grupo de Office 365 en Microsoft Entra ID, también se genera de forma automática una dirección de correo electrónico que usa el dominio predeterminado de la instancia.
Mapea identidades de grupo
El mapeo exitoso de grupos de Microsoft Entra ID a grupos de Cloud Identity o Google Workspace requiere un identificador común, que debe ser una dirección de correo electrónico. En el lado de Microsoft Entra ID, este requisito te deja dos opciones:
- Puedes usar la dirección de correo electrónico de un grupo en Microsoft Entra ID y mapearla a una dirección de correo electrónico de Cloud Identity o Google Workspace.
- Puedes derivar una dirección de correo electrónico del nombre del grupo en Microsoft Entra ID y mapear la dirección resultante a una dirección de correo electrónico en Cloud Identity o Google Workspace.
Mapea por dirección de correo electrónico
La asignación de grupos por dirección de correo electrónico es la opción más obvia, pero requiere que cumplas con varios requisitos:
- Todos los grupos sujetos a sincronización deben tener una dirección de correo electrónico. En la práctica, esto significa que solo puedes sincronizar grupos habilitados para correo. Los grupos que no tienen una dirección de correo electrónico se ignoran durante el aprovisionamiento.
- Las direcciones de correo electrónico deben ser exclusivas en la instancia. Debido a que Microsoft Entra ID no aplica la exclusividad, es posible que debas implementar políticas o verificaciones personalizadas.
- Los dominios en los que se usan las direcciones de correo electrónico deben estar registrados en Microsoft Entra ID y en Google Workspace/Cloud Identity. Los grupos con direcciones de correo electrónico que usan dominios no registrados en Cloud Identity o Google Workspace, incluido el dominio
tenant.onmicrosoft.com, no se sincronizarán.
Si todos los grupos relevantes cumplen con estos criterios, debes identificar los dominios que se usan en estas direcciones de correo electrónico y asegurarte de que estén cubiertos en la lista de dominios DNS registrados en Cloud Identity o Google Workspace.
Mapea por nombre
Cumplir con los criterios necesarios para asignar grupos por dirección de correo electrónico puede ser difícil, en especial si muchos de los grupos de seguridad que deseas aprovisionar en Cloud Identity o en Google Workspace no están habilitados para correo. En este caso, podría ser mejor derivar de forma automática una dirección de correo electrónico a partir del nombre visible del grupo.
Derivar una dirección de correo electrónico presenta dos desafíos:
- Una dirección de correo electrónico derivada del nombre de un grupo puede entrar en conflicto con la dirección de correo electrónico de un usuario.
- Microsoft Entra ID no aplica la exclusividad para los nombres de grupos. Si varios grupos en tu instancia de Microsoft Entra ID comparten el mismo nombre, las direcciones de correo electrónico derivadas de este nombre entrarán en conflicto, lo que hará que solo un grupo se sincronice con éxito.
Puedes superar el primer desafío si usas un dominio para la dirección de correo electrónico generada que sea diferente de cualquiera de los dominios que usan los usuarios. Por ejemplo, si todos los usuarios usan direcciones de correo electrónico con example.com como dominio, podrías usar groups.example.com para todos los grupos. El registro de subdominios en Cloud Identity o Google Workspace no requiere verificación del dominio, por lo que no es necesario que exista la zona DNS groups.example.com.
Puedes superar el segundo desafío, la duplicación de los nombres de grupo, solo de forma técnica mediante la derivación de la dirección de correo electrónico del grupo a partir del ID de objeto. Debido a que los nombres de grupo 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.
Mapeo del ciclo de vida del grupo
Después de definir 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 deseas aprovisionar. Al igual que con los usuarios, puedes habilitar el aprovisionamiento para un subconjunto de grupos mediante asignaciones de grupos o filtros de alcance.
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 realizará Microsoft Entra ID en Cloud Identity o Google Workspace.
| Aprovisionamiento habilitado para el grupo de Microsoft Entra ID | Estado del grupo en Cloud Identity/Google Workspace | Acción realizada en Microsoft Entra ID | Acción realizada en Cloud Identity/Google Workspace |
|---|---|---|---|
| No | No existe | Habilitar aprovisionamiento | Crear grupo nuevo |
| No | Existe | Habilitar aprovisionamiento | Agregar miembro, conservar todos los miembros existentes |
| Sí | Existe | Cambiar nombre del grupo | Cambiar nombre del grupo |
| Sí | Existe | Modificar descripción | Actualizar descripción |
| Sí | Existe | Agregar miembro | Agregar miembro, conservar todos los miembros existentes |
| Sí | Existe | Quitar miembro | Quitar miembro |
| Sí | Existe | Inhabilitar aprovisionamiento | Mantener grupo como está (incluidos los miembros) |
| Sí | Existe | Borrar grupo | Mantener grupo como está (incluidos los miembros) |
¿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.
- Obtén información sobre la configuración del aprovisionamiento y el inicio de sesión único entre Microsoft Entra ID y Cloud Identity.
- Consulta las prácticas recomendadas para administrar cuentas de administrador avanzado.