Creación de cuentas de usuario y grupos en Azure Active Directory

La gestión de cuentas de usuario y grupos en Azure Active Directory y Azure AD B2C es una pieza clave para controlar quién puede acceder a qué recursos dentro de tu organización. Si trabajas con Microsoft Entra ID (el nuevo nombre de Azure AD), tarde o temprano tendrás que crear cuentas, invitar usuarios externos, organizar grupos y asignar permisos a aplicaciones.

En este artículo vamos a desgranar, con calma pero al grano, cómo funcionan los distintos tipos de cuentas (profesionales, invitadas y de consumidor) y cómo se relacionan con los grupos y las aplicaciones. Además, verás qué opciones tienes para automatizar tareas con PowerShell y Microsoft Graph, y cómo manejar asignaciones de roles de aplicación sin perderte entre tantos comandos y opciones.

Tipos de cuentas en Azure Active Directory y Azure AD B2C

En el ecosistema de Microsoft Entra ID, que engloba Microsoft Entra ID «clásico», la colaboración B2B y Azure AD B2C, existe un modelo de cuentas común que se reutiliza en estas tres soluciones. Entender bien cada tipo de cuenta es fundamental antes de ponerte a crear usuarios a lo loco.

Podemos diferenciar tres tipos principales de cuentas: cuentas profesionales (o de organización), cuentas invitadas y cuentas de consumidor. Cada una tiene sus capacidades, limitaciones y casos de uso típicos, tanto si trabajas con un inquilino empresarial como con un tenant B2C orientado a aplicaciones de clientes finales.

Este modelo compartido permite que la misma lógica de identidad y acceso funcione de forma coherente entre Entra ID, B2B y Azure AD B2C, de modo que la administración, los permisos y la colaboración entre organizaciones sea más sencilla, aunque a veces eso implique aprender un conjunto de conceptos que parecen muy similares entre sí.

Cuenta profesional (usuario interno de la organización)

La cuenta profesional es la típica cuenta de empleado de toda la vida: un usuario interno que pertenece a tu inquilino de Microsoft Entra ID y que puede acceder a recursos y aplicaciones de la organización. Si le concedes un rol de administrador, además podrá gestionar diferentes aspectos del directorio y de los servicios asociados.

Estas cuentas se crean de forma similar tanto en entornos de Entra ID «puro» como en inquilinos de Azure AD B2C que hacen uso de la misma infraestructura. La creación estándar de usuarios profesionales se realiza desde el portal de Azure, usando la opción “Nuevo usuario”, o bien mediante scripts y API si necesitas algo más automatizado.

A nivel de arquitectura, un usuario profesional siempre pertenece al inquilino donde se ha creado. Eso significa que su seguridad, sus políticas de acceso condicional y sus licencias dependen del tenant de origen, algo importante cuando combinas varios tenants o trabajas con escenarios de colaboración B2B.

Cuenta invitada (colaboración externa B2B)

La cuenta invitada se utiliza cuando quieres que alguien de fuera de tu organización entre en tu directorio para colaborar de forma controlada. Normalmente, estos usuarios proceden de otra organización con Microsoft Entra o tienen una cuenta Microsoft personal, y se integran a través de las capacidades de colaboración B2B.

Una cuenta de invitado no deja de ser un usuario que aparece en tu inquilino, pero con un tipo de relación diferente (Guest). Suelo usarse para compartir responsabilidades de administración limitadas, permitir acceso a determinadas aplicaciones o recursos, o colaborar en proyectos con proveedores y socios sin darles una cuenta interna completa.

La invitación se basa en un flujo de consentimiento: envías un correo con un vínculo de invitación y el usuario debe aceptarla para poder empezar a usar los recursos que le asignes. Si por lo que sea no dispone de bandeja de entrada para la dirección utilizada, puede ir directamente a una página de Microsoft con sus credenciales invitadas y canjear la invitación de forma manual, por ejemplo accediendo a una URL del estilo https://myapps.microsoft.com/B2CTENANTNAME.

Cuenta de consumidor en Azure AD B2C

La cuenta de consumidor está pensada para otra liga: usuarios finales de tus aplicaciones B2C, es decir, clientes, ciudadanos, estudiantes, etc. Este tipo de cuentas se usa para autenticarse en aplicaciones protegidas por Azure AD B2C, pero no otorga acceso a recursos internos de Azure como el portal de Azure o la administración del tenant.

Estas cuentas pueden ser locales (un usuario y contraseña gestionados por el propio B2C) o federadas con otros proveedores de identidad como Facebook o X. De esta manera puedes ofrecer a tus usuarios finales múltiples opciones de inicio de sesión, mientras centralizas el control del acceso en Azure AD B2C.

La creación de cuentas de consumidor puede realizarse de varias formas: a través de los flujos de usuario de registro/inicio de sesión integrados en tu aplicación, mediante Microsoft Graph API o desde el propio portal de Azure. Esto te da mucha flexibilidad: desde un registro autogestionado por el usuario hasta una migración o carga masiva de cuentas.

Creación y configuración de una cuenta profesional en Entra ID

Para dar de alta un nuevo empleado o usuario interno, lo normal es usar el portal de Azure. El proceso estándar empieza accediendo a Microsoft Entra ID y utilizando la opción “Nuevo usuario”, que es la forma gráfica más sencilla de poner en marcha una cuenta con todos sus datos básicos.

Durante esa creación inicial tienes que prestar atención a una serie de campos clave que condicionan cómo se comportará la cuenta: nombre, nombre de usuario, correo, perfil, grupos y rol de directorio. Definirlos bien desde el principio te evita muchos problemas administrativos posteriores.

El nombre y el nombre de usuario (UPN) son dos propiedades distintas. La propiedad “Name” suele incluir nombre y apellidos, mientras que el nombre de usuario es el identificador que la persona usará para autenticarse. Este UPN incluye el dominio completo y debe corresponderse con el dominio inicial del inquilino (por ejemplo, tu-dominio.onmicrosoft.com) o con un dominio personalizado verificado y no federado (por ejemplo, contoso.com).

Además, puedes habilitar el inicio de sesión con dirección de correo electrónico como credencial alternativa, siempre que sigas las restricciones establecidas: no se admiten ciertos caracteres especiales ni caracteres multibyte (como algunos alfabetos asiáticos) en el campo de correo que se usa para autenticación. Esto es relevante si trabajas con nombres internacionales o direcciones no estándar.

El apartado de perfil de usuario te permite completar datos adicionales, como nombre, apellidos, puesto o departamento. Aunque estos campos son opcionales, ayudan bastante a la hora de clasificar a los usuarios, aplicar filtros en listados o automatizar procesos basados en atributos. Y no te preocupes si no lo rellenas todo de primeras: el perfil se puede modificar después sin problema.

Por último, en el alta de una cuenta profesional puedes decidir si añadirla ya a uno o varios grupos existentes del inquilino. Esto te ahorra trabajo, porque si el grupo tiene permisos o licencias asociadas, el usuario heredará de golpe ese conjunto de accesos en lugar de tener que ir asignándolos uno a uno.

Elección del rol de directorio para la cuenta profesional

Cuando creas una cuenta profesional también debes definir el nivel de acceso que tendrá dentro del inquilino, lo que en Entra ID se gestiona mediante roles de directorio. No es lo mismo un usuario estándar que solo accede a sus aplicaciones de trabajo que un administrador global con control total.

Microsoft Entra ID ofrece una serie de roles integrados (built-in) con permisos ya predefinidos: administrador global, administrador de aplicaciones, administrador de usuarios, administrador de seguridad, etc. Es recomendable revisar la documentación oficial de “Roles integrados de Microsoft Entra” para ver qué capacidades incluye cada uno y no pasarse dando permisos.

La idea es aplicar el principio de privilegios mínimos: conceder solo el rol necesario para que la persona pueda realizar sus tareas. Por ejemplo, si alguien solo necesita gestionar aplicaciones, quizá encaje mejor un rol de administrador de aplicaciones en la nube que un rol de mayor alcance.

Actualización de perfiles y restablecimiento de contraseñas

Una vez creada la cuenta, es bastante habitual que haya cambios de puesto, movimientos entre departamentos o actualizaciones de datos de contacto. El perfil de usuario en Entra ID se puede editar en cualquier momento desde el portal, PowerShell o Microsoft Graph, adaptando así la información a la realidad del empleado.

Otro punto clave del ciclo de vida de la cuenta es la gestión de contraseñas. Cuando un usuario olvida su contraseña o sospecha que ha sido comprometida, se puede restablecer desde el portal (si tienes permisos para ello) o forzar a que el propio usuario la regenere mediante las capacidades de autoservicio (SSPR) si están habilitadas en el inquilino.

Gestión de usuarios invitados en Azure AD B2C y Entra ID

En escenarios donde quieres que personas externas colaboren con tu organización, pero sin convertirlas en usuarios internos de pleno derecho, las cuentas invitadas son tu mejor aliado. Permiten compartir acceso a aplicaciones o incluso ciertas tareas administrativas, manteniendo un control claro sobre lo que puede hacer cada invitado.

El flujo básico consiste en que un administrador u otra persona autorizada envía una invitación a una dirección de correo del usuario externo, acompañada de un mensaje que explique para qué se le está invitando y qué puede esperar. El receptor recibe un correo con un enlace que le lleva a una página de consentimiento donde acepta los permisos y la pertenencia a tu directorio.

En el caso de que la dirección de correo no tenga bandeja de entrada funcional, no está todo perdido. El usuario invitado puede ir directamente a una página de Microsoft usando sus credenciales invitadas y canjear la invitación aunque no haya abierto el correo. La URL típica para este tipo de acceso suele tener el formato de página de aplicaciones de Microsoft, vinculada a tu inquilino B2C.

Para organizaciones con muchos colaboradores externos o escenarios más complejos, también es posible automatizar la creación e invitación de usuarios invitados con Microsoft Graph API. De esta forma puedes integrarlo con tus procesos de alta de proveedores, portales externos o sistemas de recursos humanos de terceros.

Es muy recomendable crear grupos específicos para los usuarios invitados dentro de tu inquilino. De esta manera, puedes separar claramente los accesos de contratistas, proveedores o partners, y aplicar niveles de acceso diferentes según el grupo al que pertenezcan.

Creación y uso de grupos en Microsoft Entra ID

Los grupos en Entra ID son una herramienta básica para simplificar la administración de permisos: en lugar de dar acceso recurso a recurso usuario por usuario, asignas el acceso al grupo y luego añades o quitas miembros. Esto se traduce en menos errores y mucha más agilidad cuando la organización crece.

Entre otros usos, los grupos te permiten asignar licencias de productos, permisos sobre aplicaciones, acceso a datos o recursos específicos. Esto funciona igual tanto para usuarios internos como invitados, siempre que los incluyas en el grupo adecuado.

Para crear un grupo de usuarios en Microsoft Entra ID desde el portal de Azure, el procedimiento típico es sencillo: inicias sesión con una cuenta que tenga rol de administrador global del directorio, accedes al servicio de Microsoft Entra ID y, dentro de la sección de Active Directory, eliges la opción «Grupos» y luego “Nuevo grupo”.

En el diálogo de creación del nuevo grupo tendrás que establecer varios parámetros: tipo de grupo, nombre, dirección de correo del grupo y tipo de pertenencia. Por ejemplo, puedes elegir un grupo de tipo Microsoft 365, darle un nombre descriptivo, configurar o aceptar la dirección de correo que se sugiere y seleccionar el tipo de pertenencia «Asignado» para poder elegir usuarios concretos que tendrán permisos únicos.

Una vez rellenados estos campos, solo queda pulsar en “Crear” y el grupo quedará disponible en tu inquilino. Más adelante podrás añadir miembros cuando lo necesites y, sobre todo, asignar a ese grupo acceso a aplicaciones y recursos, de forma que todo el que se añada al grupo herede esos permisos de forma automática.

Otra buena práctica es aprovechar los grupos para separar perfiles: por ejemplo, tener grupos diferenciados para contratistas, proveedores y personal interno, y conceder a cada uno solo el acceso imprescindible para su trabajo diario. Esto encaja perfectamente con las políticas de seguridad de mínimo privilegio.

Administración de grupos de Azure con consolas especializadas

En algunos entornos corporativos se utiliza DRA (Directory and Resource Administrator) u otras herramientas de delegación para gestionar identidades. Como administrador asistente, puedes usar DRA para administrar grupos de Azure cuando el administrador principal haya configurado previamente la integración con Azure Active Directory.

Con los permisos adecuados, desde la consola web de este tipo de soluciones puedes realizar tareas clásicas sobre grupos: crearlos, modificarlos, gestionar miembros y controlar a qué recursos pueden acceder. No deja de ser otra capa de administración delegada por encima de Entra ID, ideal cuando quieres distribuir trabajo de gestión sin dar acceso completo al portal de Azure.

Asignación de usuarios y grupos a aplicaciones empresariales

Una vez que tienes usuarios y grupos bien organizados, llega la parte decisiva: conectar esas identidades con las aplicaciones empresariales. En Microsoft Entra ID esto se hace asignando usuarios o grupos a la «aplicación empresarial» (el service principal) correspondiente.

Cuando asignas un usuario a una aplicación, esta aparece en el portal Mis aplicaciones del usuario, lo que facilita su acceso y reduce esa típica avalancha de preguntas del tipo «¿dónde tengo que entrar para esta app?». Además, si la aplicación define roles de aplicación (AppRoles), puedes asignar un rol concreto a cada usuario o grupo, controlando con mucho detalle qué puede hacer en la aplicación.

Si en lugar de ir usuario a usuario asignas un grupo completo a una aplicación, cualquier miembro de ese grupo tendrá acceso. Es importante tener en cuenta que esta asignación no se propaga a grupos anidados: si tienes un grupo dentro de otro, el hecho de que el grupo superior esté asignado a la aplicación no implica automáticamente acceso para los grupos que contenga.

La funcionalidad de asignación basada en grupos requiere que tu tenant disponga de licencias P1 o P2 de Microsoft Entra ID. Además, solo es compatible con grupos de seguridad, grupos de Microsoft 365 y grupos de distribución cuya propiedad SecurityEnabled esté establecida en True. Si un grupo no está configurado como de seguridad, no podrá usarse para controlar acceso a aplicaciones.

Hay aplicaciones que admiten configurarse para que sea obligatorio estar asignado explícitamente para poder utilizarlas. Esto te da un control mucho más fino, ya que incluso si la política de consentimiento del usuario permitiera que se concediera acceso de forma individual, la aplicación seguirá requiriendo una asignación aprobada por un administrador.

Requisitos previos y roles necesarios para las asignaciones

Para poder asignar usuarios y grupos a aplicaciones empresariales necesitas cumplir unos requisitos mínimos. En primer lugar, debes tener una cuenta de Microsoft Entra asociada a una suscripción activa; si no la tienes, siempre puedes crear una cuenta gratuita para probar.

En segundo lugar, la persona que realiza las asignaciones debe disponer de alguno de los roles de administrador adecuados, como administrador de aplicaciones en la nube, administrador de aplicaciones, administrador de usuarios o ser propietario de la entidad de servicio de la propia aplicación. Sin el rol correcto, el portal o las llamadas a la API te limitarán las operaciones que puedes hacer.

Por último, si quieres aprovechar las ventajas de la asignación basada en grupos, recuerda que tu inquilino debe contar con Microsoft Entra ID P1 o P2. Sin estas ediciones, tendrás que recurrir a asignar individualmente cada usuario o explorar otras opciones de control de acceso.

Asignaciones de roles de aplicación con PowerShell de Entra

Cuando administras muchos usuarios y aplicaciones, hacerlo todo a mano desde el portal se vuelve insostenible. Microsoft Entra PowerShell te permite automatizar la asignación de usuarios y grupos a roles de aplicación, lo que ahorra tiempo y reduce errores humanos.

Para asignar un usuario a un rol de aplicación específico, el flujo típico en PowerShell empieza por conectarte al servicio usando el cmdlet adecuado, solicitando los ámbitos necesarios, generalmente Application.ReadWrite.All y AppRoleAssignment.ReadWrite.All. A continuación, localizas el usuario y la entidad de servicio (service principal) de la aplicación a la que quieres asignar el rol.

Una vez tengas esas referencias, seleccionas el rol de aplicación deseado buscando por su nombre visible (DisplayName) entre los AppRoles expuestos por la entidad de servicio. Con ese Id del rol en la mano, puedes invocar el cmdlet que crea la asignación para el usuario, pasando como parámetros el identificador del usuario, el identificador de la aplicación y el identificador del rol.

Si en lugar de usuarios quieres trabajar con grupos, el patrón es muy similar pero cambian los cmdlets utilizados: obtienes el grupo con algo como Get-EntraGroup y utilizas un cmdlet específico para asignar AppRoles a grupos en vez de a usuarios. El concepto es el mismo, simplemente apuntas a un principal de tipo grupo.

Anular asignaciones con PowerShell de Entra

Llega un momento en que necesitas retirar roles de aplicación a usuarios o grupos, ya sea porque cambian de funciones, salen del proyecto o abandonan la organización. Con Microsoft Entra PowerShell puedes gestionar también esta parte del ciclo de vida.

El proceso suele empezar de forma parecida: te conectas al servicio, localizas la entidad de servicio de la aplicación y el usuario o grupo afectado. Luego recuperas la lista de asignaciones de roles de aplicación existentes para esa entidad de servicio y filtras por el nombre del usuario o del grupo cuyos permisos quieres revocar.

Una vez identificadas las asignaciones específicas, puedes usar el cmdlet de eliminación apropiado para quitarlas. Este cmdlet recibe el identificador de la entidad de servicio y el identificador de la asignación de rol de aplicación y, tras ejecutarlo, el usuario o grupo dejan de tener ese rol y por tanto pierden el acceso asociado.

Si lo que quieres es eliminar todas las asignaciones de todos los usuarios y grupos para una aplicación concreta, puedes recuperar en bloque todas las AppRoleAssignments de la entidad de servicio y recorrerlas con un bucle. Dentro de ese bucle, compruebas si el principal es de tipo usuario o grupo y llamas al cmdlet de eliminación correspondiente para cada caso.

Gestión de AppRoles con PowerShell de Microsoft Graph

Además del módulo específico de Entra, también puedes administrar asignaciones de roles de aplicación usando PowerShell de Microsoft Graph, que se apoya directamente en la API Graph y ofrece una experiencia más alineada con las operaciones de bajo nivel del servicio.

Lo primero es establecer sesión con el cmdlet adecuado, solicitando ámbitos como Application.ReadWrite.All y AppRoleAssignment.ReadWrite.All. Una vez conectados, obtienes el usuario objetivo con Get-MgUser y recuperas la entidad de servicio de la aplicación con Get-MgServicePrincipal, pasando el identificador correspondiente.

Para crear una asignación, necesitas el Id del AppRole que representa el rol deseado. Sueles localizarlo filtrando la colección de AppRoles del service principal por el nombre visible del rol. Con este Id se monta un objeto de parámetros con las propiedades PrincipalId (usuario o grupo), ResourceId (entidad de servicio) y AppRoleId (rol).

Después llamas a New-MgUserAppRoleAssignment para asociar ese rol al usuario. Si quieres hacer lo mismo con un grupo, el proceso es casi idéntico pero empleando Get-MgGroup y el cmdlet New-MgGroupAppRoleAssignment, pensado específicamente para asignar roles de aplicación a grupos.

La eliminación de asignaciones con PowerShell de Microsoft Graph sigue el mismo patrón que con Entra: localizas la entidad de servicio y las AppRoleAssignments relacionadas, las filtras y las vas eliminando una a una. Aquí también tienes cmdlets específicos para operar contra los distintos tipos de principal.

Uso directo de Microsoft Graph API para AppRoles

Si necesitas integrarte desde aplicaciones personalizadas, servicios backend o herramientas externas, puedes trabajar de forma directa con Microsoft Graph API vía HTTP para gestionar todo lo relativo a usuarios, grupos, entidades de servicio y AppRoles.

Para encontrar a un usuario concreto que quieres asignar a una aplicación, puedes realizar una petición GET a la ruta de usuarios, utilizando el userPrincipalName en la URL. La respuesta incluirá un campo de identificador de objeto (objectId) que luego usarás en las operaciones de asignación.

El siguiente paso consiste en enviar una petición POST a la colección appRoleAssignedTo de la entidad de servicio de la aplicación de destino. En el cuerpo de la solicitud incluyes el principalId (Id del usuario), el resourceId (Id de la aplicación empresarial) y el appRoleId (Id del rol que quieres asignar). En estos contextos, el resource-servicePrincipal-id y el resourceId suelen representar esa misma entidad de servicio.

Para anular la asignación, el procedimiento básico pasa por recuperar primero la entidad de servicio filtrando por el nombre visible mediante una consulta GET sobre la colección de servicePrincipals con un filtro sobre displayName. Después, solicitas la lista de appRoleAssignedTo para esa entidad de servicio, identificas la asignación que quieres eliminar y ejecutas una petición DELETE dirigida al recurso individual de la asignación.

Una limitación a tener en cuenta es que Microsoft Graph Explorer no admite la eliminación masiva directa de AppRoleAssignments. Si necesitas borrar muchas asignaciones, tendrás que iterar sobre ellas y eliminarlas una por una, aunque puedes automatizar el proceso con scripts de PowerShell que hagan llamadas sucesivas a la API Graph.

Todos estos mecanismos, desde el portal hasta la API, se complementan entre sí para permitirte gestionar a fondo cuentas, grupos y accesos a aplicaciones en Microsoft Entra ID y Azure AD B2C, combinando administración visual con automatización avanzada según lo que necesite tu organización en cada momento.

Tener claros los tipos de cuentas (profesionales, invitadas y de consumidor), saber cómo agrupar usuarios y entender cómo se asignan roles de aplicación con Entra PowerShell o Microsoft Graph marca la diferencia entre un entorno controlado, seguro y fácil de mantener y un caos de permisos difíciles de auditar. Si organizas bien tu directorio desde el principio, aprovecharás al máximo todo el potencial de Azure Active Directory y tus aplicaciones empresariales funcionarán como es debido para las personas correctas.