Federa Google Cloud con Azure Active Directory

En este artículo, se describe cómo puedes extender una solución existente de administración de identidades basada en Microsoft Azure Active Directory a Google Cloud para establecer mecanismos de autenticación y autorización coherentes en un entorno de computación híbrido.

Introducción

La administración de las cuentas de usuario y el control de acceso a las aplicaciones y a los recursos informáticos es una responsabilidad clave de los departamentos de TI empresariales. En el pasado, las empresas solían depender de forma exclusiva de un Active Directory (AD) local, lo que lo convertía en una pieza fundamental de su panorama de TI y su infraestructura local.

En la actualidad, las empresas suelen usar una combinación de Active Directory local y Azure Active Directory (Azure AD) para administrar la autenticación y la autorización. Aunque un Active Directory local se podría usar a fin de administrar recursos locales y, también, podría considerarse como el sistema de registro de administración de cuentas de usuario y grupos, Azure AD a menudo se usa con el propósito de administrar la autenticación y autorización de implementaciones basadas en la nube.

En este artículo, se describe cómo extender tu solución existente de administración de identidades basadas en Active Directory y Azure AD a Google Cloud mediante Cloud Identity. Aunque parte del contenido también se aplica a G Suite, el artículo se enfoca en Cloud Identity.

En el artículo, se da por sentado que tienes conocimientos de Active Directory y Azure AD.

Federa Active Directory, Azure AD y Google Cloud

Google Cloud usa las identidades de Google para la autenticación y la administración de acceso. Para acceder a cualquier recurso de Google Cloud, un empleado debe tener una identidad de Google. Mantener de forma manual las identidades de Google para cada empleado sería engorroso si todos los empleados ya tienen una cuenta en Active Directory o Azure AD. Si se federan las identidades de los usuarios entre Cloud Identity y tu sistema de administración de identidades, puedes automatizar el mantenimiento de las Cuentas de Google y vincular su ciclo de vida a las cuentas existentes.

Si ya usas Active Directory y Azure AD, tienes dos opciones para integrar Google Cloud:

  1. Puedes federar Active Directory directamente con Cloud Identity mediante Google Cloud Directory Sync y Active Directory Federation Services (AD FS):

    Google Cloud Directory Sync

    Aunque este enfoque te brinda un control detallado sobre el contenido y el método de sincronización entre Active Directory y Cloud Identity, no se aprovecha Azure AD. Además, se requiere que ejecutes Google Cloud Directory Sync y AD FS en tu entorno de computación.

    Para obtener más información sobre este enfoque, consulta una guía aparte.

  2. Puedes federar Cloud Identity con Azure AD. Azure AD podría estar federado con uno o más bosques locales de Active Directory:

    Federa Cloud Identity con Azure AD

    Una ventaja de este enfoque es que no necesitas instalar ningún software adicional en tu entorno local. Los mecanismos de autenticación que admite Azure AD (incluidas la autenticación de paso y la sincronización de hash de contraseña) también se pueden usar para Google Cloud.

El resto de este artículo se centra en el segundo enfoque.

La federación de Azure AD con Cloud Identity garantiza lo siguiente:

  • Active Directory y Azure AD permanecen como la única fuente de verdad para la administración de identidades.
  • Para todas las cuentas de usuario que están en Azure AD o en un subconjunto seleccionado, se crea de forma automática una Cuenta de Google.
  • Si una cuenta se inhabilita o se borra de Azure AD, la Cuenta de Google correspondiente también se suspenderá o se borrará. Por el contrario, suspender o borrar una Cuenta de Google no genera ningún efecto en Active Directory, porque la Cuenta de Google se vuelve a crear de forma automática durante la siguiente sincronización.
  • Azure AD controla la autenticación de usuario, por lo que no necesitas sincronizar contraseñas con Google Cloud.

La configuración de la federación entre Azure AD y Cloud Identity implica dos partes:

  • Aprovisionamiento de cuentas: Las cuentas de usuario y grupos relevantes se sincronizan de forma periódica desde Azure AD hasta Cloud Identity. Este proceso garantiza que, cuando creas una cuenta en Azure AD o sincronizas una cuenta nueva de Active Directory con Azure AD, 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 los retiros de cuentas se propaguen.

    El aprovisionamiento funciona en un solo sentido, lo que significa que los cambios en Azure AD se replican en Cloud Identity, 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 en Google Cloud, Cloud Identity delega la autenticación a Azure AD mediante el protocolo de Lenguaje de marcado para confirmación de seguridad (SAML). Según su configuración, Azure AD podría realizar una de las acciones siguientes:

    • 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 delegue la autenticación a Azure AD evita tener que sincronizar las contraseñas con Google Cloud y, también, garantiza que se apliquen los mecanismos de autenticación de varios factores (MFA) o las políticas aplicables que configuraste en Azure AD o AD FS.

Estructura lógica de Azure AD

Cuando usas Azure, se usa una o más instancias de Azure AD (también conocidas como directorios). Las instancias de Azure AD son una estructura de nivel superior. Son consideradas límites administrativos y sirven como contenedores para usuarios, grupos, recursos y grupos de recursos.

Cada instancia de Azure AD tiene, al menos, un dominio DNS asociado. Este dominio DNS se refleja en los nombres de usuario (también conocidos como Nombres principales de usuario o UPN), que toman la forma de [name]@[domain], en la que [domain] es uno de los dominios DNS asociados a la instancia respectiva.

Estructura lógica de Azure AD

Una empresa puede mantener múltiples instancias de Azure AD. 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 cuentas de usuario ni grupos, lo que las diferencia de las instancias de Azure AD.

Para administrar usuarios y grupos, Google Cloud se basa en las cuentas de Cloud Identity (o cuentas de G Suite, que están fuera del alcance de este documento).

Estructura lógica de GCP

Con Cloud Identity, puedes crear y administrar directorios privados para cuentas de usuario y grupos. Cada directorio privado se administra de forma independiente y puede diferir, por ejemplo, en qué métodos de autenticación permiten o qué políticas de contraseñas aplican. En Cloud Identity, los directorios se conocen como cuentas de Cloud Identity y se identifican por nombres de dominio.

Cuando creas una cuenta de Cloud Identity, se crea una organización de Google Cloud de forma automática y se la asocia con la cuenta de Cloud Identity. La cuenta de Cloud Identity 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.

Integra Azure AD y Google Cloud

A pesar de ciertas similitudes entre las estructuras lógicas de Azure AD 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 diversos factores que se detallan a continuación:

  • Cómo asignar instancias de Azure AD a cuentas de Cloud Identity
  • Cómo asignar dominios DNS
  • Cómo asignar cuentas de usuario
  • Cómo asignar grupos

Las secciones siguientes analizan cada uno de estos factores.

Google Cloud interactúa solo con Azure AD, no con Active Directory local. Por lo tanto, la forma en que asignaste los bosques y dominios de tu Active Directory local a Azure AD no es importante.

Asignación de instancias de Azure AD

Instancia única

Si usas una instancia única de Azure AD, puedes asignarla a una cuenta individual de Cloud Identity y configurar la federación entre ambas. Esta cuenta de Cloud Identity proporciona la base para una organización de Google Cloud individual que puedes usar a fin de administrar todos los recursos de Google Cloud.

Asigna una instancia a una sola cuenta de Cloud Identity

Instancia múltiple

En organizaciones más grandes, suele haber más de una instancia de Azure AD. Se pueden usar instancias múltiples 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 una instancia de Azure AD a una sola cuenta de Cloud Identity, en la actualidad no es posible configurar el inicio de sesión único de manera que funcione para los usuarios de varias instancias de Azure AD. Si usas varias instancias de Azure AD, deberás crear una cuenta distinta de Cloud Identity para cada una de ellas y configurar la federación entre cada par.

En Google Cloud, se crea una organización distinta para cada cuenta de Cloud Identity. 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. Así, se crea en efecto una organización federada con múltiples bosques de Active Directory. Las otras organizaciones quedan sin usar.

Organización federada con múltiples bosques de Active Directory

Usuarios externos

Con B2B de Azure AD, puedes agregar usuarios externos como invitados a tu instancia de Azure AD. Se crea un usuario nuevo para cada invitado y Azure AD asigna un UPN a estos usuarios invitados de forma automática. El UPN que genera Azure AD usa un prefijo derivado de la dirección de correo electrónico del invitado, combinado con el dominio inicial de la instancia: [prefix]#EXT#@[tenant].onmicrosoft.com.

El aprovisionamiento de usuarios invitados de Azure AD a Cloud Identity está sujeto a ciertas limitaciones:

  • No puedes asignar el UPN de los usuarios invitados a las direcciones de correo electrónico en Cloud Identity, ya que onmicrosoft.com es un dominio que no se puede agregar ni verificar en Cloud Identity. Por lo tanto, debes asignar cuentas de usuario mediante un atributo que no sea UPN.
  • Si se suspende a un usuario en su instancia principal, el usuario correspondiente en Cloud Identity puede mantenerse activo, y podría no estar revocado el acceso a los recursos de Google Cloud de forma correcta.

Una forma mejor de tratar con los usuarios invitados que se originan en una instancia de Azure AD diferente es crear varias cuentas de Cloud Identity como se describe en la sección anterior, cada una federada con una instancia de Azure AD diferente.

Para otorgar a un usuario externo acceso a ciertos recursos de Google Cloud, no es obligatorio que el usuario tenga una cuenta en Cloud Identity. A menos que la política lo restrinja, también puedes agregar al usuario externo directamente como miembro a los respectivos proyectos, carpetas o a la organización, siempre que el usuario tenga una Cuenta de Google.

Asigna dominios DNS

El DNS tiene una función fundamental en Azure AD y en Cloud Identity. El segundo factor que se debe tener en cuenta cuando se planifica la federación de Azure AD y Google Cloud es cómo compartir o asignar dominios DNS entre Active Directory y Google Cloud.

Uso de dominios DNS en Google Cloud

Google Identity Platform, que Google Cloud necesita para la autenticación, usa direcciones de correo electrónico a fin de identificar 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.

Google Identity Platform determina el directorio de la cuenta o el proveedor de identidad que se usará para autenticar a un usuario en función de la parte del dominio de las direcciones de correo electrónico, después del símbolo @. Para una dirección de correo electrónico que usa el dominio gmail.com, por ejemplo, Google Identity Platform usa el directorio de cuentas de usuario de Gmail a fin de realizar la autenticación.

Uso de dominios DNS en GCP

Cuando te registras para obtener una cuenta de G Suite y Cloud Identity, se crea un directorio privado que Google Identity Platform puede usar para la autenticación. De la misma manera que el directorio de Gmail se asocia al dominio gmail.com, las cuentas de G Suite y Cloud Identity se deben asociar a un dominio personalizado. Para esto, se usan tres tipos diferentes de dominios:

  • Dominio principal: Este dominio identifica la cuenta de Cloud Identity y se usa como el nombre de la organización en Google Cloud. Cuando te registras en Cloud Identity, debes especificar este nombre de dominio.
  • Dominio secundario: Junto con el dominio principal, puedes asociar otros dominios secundarios con un directorio de Cloud Identity. Cada cuenta en el directorio se asocia al dominio principal o a uno de los dominios secundarios. Dos cuentas, johndoe@example.com y johndoe@secondary.example.com, se consideran cuentas distintas si example.com es el dominio principal y secondary.example.com es el dominio secundario de un directorio.
  • Dominio de alias: Un dominio de alias es una alternativa para el dominio principal. Es decir, johndoe@example.com y johndoe@alias.example.com hacen referencia a la misma cuenta si alias.example.com se configura como un dominio de alias. Un dominio de alias solo puede proporcionar un nombre alternativo para el dominio principal; no es posible agregar dominios de alias a dominios secundarios.

Todos los dominios deben cumplir los requisitos siguientes:

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

Uso de dominios DNS en Azure AD

La forma en que Cloud Identity usa DNS es similar a cómo Azure AD se basa en DNS para distinguir las instancias de Azure AD y asociar los nombres de usuario a ellas. Sin embargo, debes tener en cuenta dos diferencias importantes:

  1. Dominios iniciales: Cuando creas una instancia de Azure AD, esta se asocia a 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.com como dominio de Cloud Identity.

  2. Dominios usados en identificadores de usuario: Azure AD 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 de tu instancia de Azure AD; este requisito no se aplica a las direcciones de correo electrónico.

    Cloud Identity no se basa en el concepto de UPN y, en su lugar, usa la dirección de correo electrónico del 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.

Azure AD y Cloud Identity pueden usar los mismos dominios DNS. Debes tener en cuenta las dos diferencias descritas antes para tu asignación de dominio con respecto a cómo planeas asignar cuentas de usuario entre Azure AD y Cloud Identity.

Asigna cuentas de usuario

El tercer factor que debes considerar cuando planificas la federación de Active Directory y Google Cloud es cómo asignar cuentas de usuario entre Azure AD y Cloud Identity.

La asignación correcta de cuentas de Azure AD a cuentas de Cloud Identity requiere dos datos para cada cuenta:

  1. Un ID único y estable que puedes usar durante la sincronización para realizar un seguimiento de qué cuenta de Azure AD corresponde a qué cuenta de Cloud Identity.
  2. 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, Azure AD 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 asignar usuarios, las únicas opciones prácticas son asignar por UPN o por dirección de correo electrónico.

Asigna cuentas de usuario 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 configurada para usar el inicio de sesión único con Azure AD, el usuario es redireccionado a la pantalla de inicio de sesión de Azure AD.

Azure AD 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.

Pantalla de inicio de sesión que solicita un UPN

Si la instancia de Azure AD 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).

Pantalla de inicio de sesión de AD FS

Si la dirección de correo electrónico usada para Cloud Identity, el UPN que usa Azure AD 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.

Asigna por UPN

Desde la perspectiva de la experiencia del usuario, la asignación de UPN de Azure AD a direcciones de correo electrónico de Cloud Identity podría considerarse la mejor opción. Otro beneficio de basarse en los UPN es que Azure AD garantiza la exclusividad para evitar el riesgo de conflictos de nombres.

Sin embargo, para asignar los UPN de Azure AD a las direcciones de correo electrónico de Cloud Identity, debes cumplir estos requisitos:

  • Los UPN de Azure AD 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 relevantes en Azure AD deben usar un dominio personalizado como sufijo ([user]@[custom-domain]). Los UPN que usan el dominio inicial de Azure AD ([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 Azure AD 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 anular los registros DNS TXT existentes que puedas haber creado para verificar la propiedad del dominio en Azure AD, puedes usar un registro CNAME a fin de verificar la propiedad del dominio en Cloud Identity.

Para Cloud Identity, no importa si los UPN de Active Directory y Azure AD son equivalentes. Sin embargo, si usas AD FS, los usuarios tendrán una mejor experiencia si el UPN de Active Directory es el mismo que el de Azure AD.

Asigna usuarios por dirección de correo electrónico

Si no puedes asignar UPN de Azure AD a direcciones de correo electrónico de Cloud Identity, puedes asignar cuentas 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 Azure AD Connect sincronizará el valor con el atributo Mail en Azure AD. Azure AD también hace que el atributo esté disponible para el aprovisionamiento de usuarios a fin de que puedas asignarlo a la dirección de correo electrónico en Cloud Identity.

Cabe destacar que el atributo Mail de Azure AD 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. Como resultado, asignar los usuarios de una dirección de correo electrónico es práctico solo cuando realizas la mayor parte de tu creación y edición de usuarios en Active Directory, no en Azure AD.

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. A todas las cuentas de usuario que están sujetas a la sincronización se les debe asignar 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 mail es un atributo de usuario opcional de Active Directory. Los usuarios que no tienen una dirección de correo electrónico en el atributo Mail de Azure AD se ignoran en silencio durante la sincronización.
  • Las direcciones de correo electrónico deben ser exclusivas en toda la instancia de Azure AD. Aunque Active Directory no verifica la exclusividad durante la creación de la cuenta, Azure AD Connect detecta las colisiones de manera predeterminada, lo que puede provocar que falle la sincronización de las cuentas de usuario afectadas.
  • Los dominios que usan las direcciones de correo electrónico no necesitan estar registrados en Azure AD, pero deben estar registrados en Cloud Identity. 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).

Asigna grupos

El cuarto factor que debes tener en cuenta cuando planeas la federación de Active Directory y Google Cloud es si se sincronizan los grupos entre Active Directory y Google Cloud y cómo se asignarán.

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 funciones de Cloud Identity and Access Management (Cloud IAM) en cada proyecto, debes definir un conjunto de grupos que modelen funciones comunes en tu organización. Luego, debes asignar esos grupos a un conjunto de funciones de Cloud IAM. Si modificas la membresía de los grupos, puedes controlar el acceso de los usuarios a un conjunto de recursos completo.

La asignación de grupos entre Azure AD y Google Cloud es opcional. Después de que se federan las cuentas de usuario, puedes crear y administrar grupos de forma directa en Cloud Identity, lo que implica que Active Directory o Azure AD continúen como el sistema central de la administración de identidades, pero no de la administración de acceso a Google Cloud.

A fin de mantener Active Directory o Azure AD como el sistema central de administración de identidades y acceso, recomendamos que sincronices los grupos de Azure AD, en lugar de administrarlos en Cloud Identity. Con este enfoque, puedes configurar Cloud IAM a fin de que puedas usar membresías de grupos en Active Directory o Azure AD para controlar quién tiene acceso a los recursos en Google Cloud.

Grupos en Cloud Identity

En Cloud Identity, hay un solo tipo de grupo. Los grupos en Cloud Identity no se limitan al alcance de la cuenta de Cloud Identity en la que se definieron. En su lugar, pueden incluir cuentas de usuario de diferentes cuentas de Cloud Identity, se pueden referenciar y anidar en otras cuentas de Cloud Identity y pueden usarse en cualquier organización de Google Cloud.

Al igual que con las cuentas de usuario, Cloud Identity identifica 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 Cloud 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 Azure AD

Azure AD 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. Azure AD 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 Azure AD a Cloud Identity, 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 Azure AD. 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 requiere que los grupos se identifiquen con una dirección de correo electrónico.

En Azure AD, 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 Azure AD Connect:

Fuente Tipo de grupo de Active Directory Tipo de grupo de Azure AD Habilitado para correo Habilitado para seguridad
Azure AD - Grupo de Office 365 Siempre Opcional
Azure AD - Grupo de Seguridad Opcional Siempre
local Grupo de Seguridad (con correo electrónico) Grupo de Seguridad
local Grupo de Seguridad (sin correo electrónico) Grupo de Seguridad No
local Lista de distribución (con correo electrónico) Lista de distribución No
local Lista de distribución (sin correo electrónico) (Azure AD Connect la ignora)

A diferencia de lo que ocurre con los usuarios, Azure AD requiere que las direcciones de correo electrónico asignadas a grupos usen un dominio que se haya registrado como dominio personalizado en Azure AD. 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 Azure AD, la dirección de correo electrónico se mantiene intacta durante la sincronización con Azure AD.
  • Si un grupo en Active Directory usa una dirección de correo electrónico que no se registró en Azure AD, 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 Azure AD, también se genera de forma automática una dirección de correo electrónico que usa el dominio predeterminado de la instancia.

Asigna identidades de grupo

La asignación correcta de los grupos de Azure AD a los grupos de Cloud Identity requiere un identificador común, y Cloud Identity requiere que este identificador sea una dirección de correo electrónico. En el lado de Azure AD, este requisito te deja dos opciones:

  • Puedes usar la dirección de correo electrónico de un grupo en Azure AD y asignarla a una dirección de correo electrónico de Cloud Identity.
  • Puedes derivar una dirección de correo electrónico del nombre del grupo en Azure AD y asignar la dirección resultante a una dirección de correo electrónico en Cloud Identity.

Asigna 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 Azure AD no aplica la exclusividad, es posible que debas implementar políticas o verificaciones personalizadas.
  • Los dominios que usan las direcciones de correo electrónico deben estar registrados en Azure AD y en Cloud Identity. Los grupos con direcciones de correo electrónico que usan dominios no registrados en Cloud Identity, incluido el dominio [tenant].onmicrosoft.com, no se sincronizarán.

Si todos los grupos relevantes cumplen estos criterios, debes identificar todos los dominios que se usan en estas direcciones de correo electrónico y asegurarte de que estén en la lista de dominios DNS registrados en Cloud Identity.

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

  1. 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.
  2. Azure AD no aplica la exclusividad para los nombres de grupos. Si varios grupos en tu instancia de Azure AD 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 tus 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 no requiere verificación de 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 algo crípticos y difíciles de usar, es mejor identificar y cambiar el nombre de los grupos duplicados en Azure AD antes de configurar el aprovisionamiento en Cloud Identity.

Administra el ciclo de vida de las cuentas de usuario

Identificar la asignación correcta entre instancias, dominios, usuarios y grupos te permite automatizar la administración de cuentas de usuario y grupos en Cloud Identity. Sin embargo, ¿para qué cuentas de usuario y grupos debes aprovisionar y habilitar el inicio de sesión único?

Integración

Según cómo planees usar Google Cloud, todos los usuarios que tengan una cuenta en Azure AD o que reciban una cuenta nueva también pueden obtener el permiso para usar Google Cloud. Lo más probable es que solo un subconjunto de tus usuarios deba tener acceso a Google Cloud. Por lo tanto, es importante distinguir entre cuatro conjuntos de cuentas de usuario en Azure AD:

  • Cuentas en Azure AD indica la cantidad total de cuentas en Azure AD.
  • Cuentas aprovisionadas en Cloud Identity indica el subconjunto de cuentas de Azure AD que se asignaron para el aprovisionamiento en Cloud Identity.
  • Cuentas habilitadas para SSO indica el subconjunto de cuentas de Azure AD que se asignaron para el inicio de sesión único.
  • Cuentas con acceso a Cloud IAM es el subconjunto de cuentas de Azure AD aprovisionadas en Cloud Identity que tienen acceso a cualquier recurso en Google Cloud.

A fin de poder usar los recursos de Google Cloud, se debe aprovisionar una cuenta en Cloud Identity, habilitarla para SSO y otorgarle acceso en Cloud IAM.

Una cuenta que se aprovisionó en Cloud Identity y se habilitó para SSO, pero que aún no tiene acceso a Cloud IAM, no podrá usar Google Cloud, aunque es posible que pueda usar otras herramientas de Google, como Data Studio.

Una cuenta que se aprovisionó en Cloud Identity, pero que no se habilitó para SSO, no le sirve al usuario porque no puede usarse a fin de iniciar sesión. Sin embargo, la existencia de la cuenta en Cloud Identity impide que el usuario use su dirección de correo electrónico corporativa para registrarse en una cuenta personal en YouTube, Búsqueda de Google o en otros sitios de Google. Permitir que los empleados usen cuentas personales con fines empresariales puede ser riesgoso, ya que tu empresa no controla la cuenta, su ciclo de vida ni su seguridad, por lo que bloquear el registro podría ser útil.

Habilitar una cuenta para SSO sin aprovisionarla en Cloud Identity es útil cuando se migran cuentas personales existentes a Cloud Identity. Más allá de una migración, no hay motivos para habilitar SSO en una cuenta que no se aprovisiona en Cloud Identity.

Aprovisiona y habilita SSO para todas las cuentas

Si se tiene en cuenta la interacción de estos cuatro conjuntos de usuarios, el enfoque más directo es aprovisionar todas las cuentas de Azure AD en Cloud Identity y habilitar SSO para todas las cuentas, pero solo otorgar acceso a recursos a un subconjunto relevante de usuarios:

Aprovisiona y habilita SSO para todas las cuentas

En organizaciones más grandes, se recomienda otorgar permisos basados en grupos, no en individuos. Los grupos que usas para este propósito pueden ser grupos creados en Cloud Identity o grupos aprovisionados desde Azure AD.

Si decides usar Cloud Identity a fin de crear y administrar los grupos para controlar el acceso a los recursos de Google Cloud, este enfoque tiene la ventaja de que todas las cuentas de usuario estarán disponibles con facilidad en Cloud Identity cuando decidas otorgar acceso a un grupo a más usuarios. De lo contrario, otorgar a un usuario acceso a Google Cloud podría requerir que primero realices cambios en Azure AD, esperes hasta que la cuenta de usuario se sincronice y, luego, ejecutes otras acciones en Cloud Identity.

Aprovisiona y habilita SSO para el conjunto de cuentas más pequeño

Aprovisionar todas las cuentas de Azure AD en Cloud Identity y habilitar SSO para ellas implica que todos los usuarios pueden acceder a herramientas que no son de Google Cloud, como Data Studio, que puede parecer innecesario. Un enfoque alternativo es aprovisionar solo el conjunto de cuentas más pequeño posible en Cloud Identity. Lo ideal es que este conjunto solo abarque las cuentas que también tienen acceso en Cloud IAM.

Aprovisiona y habilita SSO para el conjunto de cuentas más pequeño

Si usas grupos para administrar el acceso, pero decides administrar estos grupos en Azure AD, en lugar de Cloud Identity, puedes asegurarte de que solo se aprovisionen las cuentas relevantes si usas los mismos grupos para controlar la asignación a la app empresarial respectiva. Como alternativa, puedes aproximar el conjunto de cuentas que podrían requerir acceso a Google Cloud mediante la creación de un grupo dinámico en Azure AD.

Una desventaja de este enfoque es que los usuarios cuyas cuentas no se aprovisionaron aun así pueden registrarse para obtener una cuenta personal con su dirección de correo electrónico corporativa.

Aprovisiona a todos los usuarios y habilita SSO para el conjunto de cuentas más pequeño

Puedes solucionar el inconveniente del enfoque anterior si aprovisionas todas las cuentas en Cloud Identity, pero habilitas SSO solo para aquellos usuarios a los que también planeas otorgar acceso en Cloud IAM.

Aprovisiona a todos los usuarios y habilita SSO para el conjunto de cuentas más pequeño

Este enfoque impide la creación de cuentas personales y evita que más usuarios de lo necesario puedan iniciar sesión en los servicios de Google.

Desvinculación

Conceder a los usuarios acceso a Google Cloud cuando lo necesitan es tan importante como revocar ese acceso cuando se van o cambian de función. Cuando se borra un usuario de Azure AD, fallarán los intentos de inicio de sesión único posteriores para ese usuario. Además, se suspenderá la cuenta de usuario correspondiente en Cloud Identity.

Del mismo modo, si quitas a un usuario de un grupo que se sincroniza con Cloud Identity, eso se reflejará en Cloud Identity, lo que causará que el usuario pierda todos los permisos asociados al grupo.

Próximos pasos