Rol Admin Invitado Entra Confianza B2B Entre Tenants: Cómo un Usuario Externo Llega a Administrador Global

Rol Admin Invitado Entra Confianza B2B Entre Tenants: qué controlan realmente estos ajustes

Rol admin invitado Entra confianza B2B entre tenants agrupa dos de las capas menos auditadas de la gobernanza de identidades externas de Microsoft Entra ID, y su combinación forma uno de los caminos de escalada de privilegios más silenciosos de la plataforma: una cuenta de invitado externa que posee directamente un rol de directorio, detrás de unos Cross-Tenant Access Settings que, por defecto, dejan que otras organizaciones de Microsoft Entra alcancen su tenant. Ninguna de las dos mitades es exótica por sí sola — la colaboración B2B y la asignación de roles de directorio son funciones Entra centrales y documentadas — pero la combinación de ambas rara vez se audita como un único control.

Este es un ángulo distinto de otras dos brechas relacionadas que conviene conocer primero. Si le preocupa quién puede invitar invitados, si necesitan MFA, o si se acumulan cuentas obsoletas, vea Cuentas de invitado en Azure: la superficie de ataque olvidada. Si le preocupa que un invitado herede privilegio al caer en un grupo de seguridad anidado dentro de un grupo asignable a roles, vea Grupos privilegiados anidados en Entra ID, grupos asignables a roles e invitados en grupos de seguridad. Este artículo cubre algo anterior a ambos casos: un invitado que posee directamente un rol de Microsoft Entra — sin grupo, sin anidamiento — y la configuración de confianza B2B a nivel de tenant que decide, de entrada, qué organizaciones externas pueden alcanzar la identidad de origen de ese invitado.

Cinco comprobaciones componen esta capa de gobernanza:

Cómo un invitado termina con un rol de directorio, y cómo los ajustes de confianza amplían la puerta

Asignar un rol a un invitado no es un caso especial en el RBAC de Entra

El modelo de asignación de roles de Microsoft Entra no trata a un principal invitado de forma distinta a un principal miembro cuando se trata de poseer un rol de directorio. El mismo flujo de asignación de roles — New-MgRoleManagementDirectoryRoleAssignment en PowerShell, o POST /roleManagement/directory/roleAssignments en Microsoft Graph — que asigna Administrador de la mesa de ayuda a un empleado interno asigna con la misma facilidad Administrador global a un objeto invitado externo. La propia documentación de la API de Microsoft para listar asignaciones de roles lo muestra explícitamente: su ejemplo de expansión del principal en una respuesta de asignación de roles incluye usuarios invitados ("userType": "Guest") que poseen un rol de directorio junto a usuarios miembros, sin ningún tratamiento especial.

Esto importa porque los permisos de directorio predeterminados de un invitado son intencionadamente reducidos. El nivel de permiso de invitado de Microsoft Entra (el ajuste authorizationPolicy.guestUserRoleId) es por defecto Acceso limitado (GUID 10dae51f-b6af-4016-8d66-8c2a99b929b3), y puede restringirse a Acceso restringido (2af84b1e-32c8-42b7-82bc-daa82404023b), lo que impide incluso que un invitado enumere la pertenencia a grupos más allá de los suyos propios. Pero ese ajuste rige la visibilidad predeterminada de objetos de directorio para cada invitado — no es un techo sobre lo que una asignación de rol explícita puede otorgar a un invitado concreto. Un invitado al que se le asigna Administrador global tiene permisos administrativos completos del tenant, sin importar cuán restrictivo sea el nivel de permiso de invitado predeterminado. Las propias guías de seguridad Zero Trust de Microsoft incluyen Los invitados no tienen asignados roles de directorio altamente privilegiados como recomendación nombrada, advirtiendo que una cuenta de invitado comprometida con un rol elevado da a los atacantes una vía para escalar privilegios, crear cuentas de puerta trasera y persistir en el tenant — y las herramientas de postura de terceros lo rastrean como un hallazgo propio e independiente: el catálogo de exposiciones de Tenable incluye explícitamente «Guest Account With a Privileged Role», citando como riesgo central una auditabilidad reducida y una postura de seguridad más débil en el tenant de origen.

Los Cross-Tenant Access Settings deciden qué identidades externas pueden siquiera alcanzar esa asignación

Una asignación de rol de directorio a un invitado está tan contenida como la identidad externa que hay detrás. Los Cross-Tenant Access Settings de Microsoft Entra controlan esto desde la otra dirección — son reglas predeterminadas, a nivel de tenant, que se aplican a cualquier otra organización de Microsoft Entra a menos que configure excepciones específicas por organización. Según los valores iniciales predeterminados documentados por Microsoft:

• Colaboración B2B (b2bCollaborationInbound / b2bCollaborationOutbound): todos sus usuarios internos están habilitados para la colaboración B2B por defecto — pueden invitar a invitados externos, y ser invitados a otros sitios como invitados, sin necesidad de una lista de permitidos por organización.
• Confianza entrante (inboundTrust): las reclamaciones de MFA y dispositivo (dispositivo conforme, unión híbrida a Microsoft Entra) de organizaciones externas no son de confianza por defecto. Si un administrador habilita después «Confiar en la autenticación multifactor de los tenants de Microsoft Entra» a nivel predeterminado en lugar de por socio, la reclamación de MFA de cada organización externa de Microsoft Entra se acepta — el acceso condicional deja de volver a comprobar el MFA para cualquier invitado, de cualquier tenant, incluidos los que nunca ha oído mencionar. Eso es B2B_INBOUND_TRUST_ALL.
• Conexión directa B2B (b2bDirectConnectInbound / b2bDirectConnectOutbound): bloqueada en ambas direcciones, a nivel de tenant, por defecto — Microsoft documenta esto como el único ajuste de esta familia que se entrega cerrado: «la conexión directa B2B saliente está bloqueada para todo su tenant, y la conexión directa B2B entrante está bloqueada para todas las organizaciones externas de Microsoft Entra». B2B_DIRECT_CONNECT_ENABLED se dispara cuando un cambio a nivel predeterminado — no un cambio intencionado por socio — la abre.
• Acceso saliente: también abierto por defecto — sus usuarios pueden ser invitados a los recursos de cualquier organización externa de Microsoft Entra a menos que el acceso saliente esté acotado. B2B_OUTBOUND_UNRESTRICTED señala exactamente ese valor saliente sin acotar.

Tanto las listas de permitidos/bloqueados como los ajustes de acceso entre tenants se comprueban en el momento de la invitación, pero si un dominio externo no está en ninguna de las dos listas, Microsoft Entra recurre a lo que sea que esté configurado como valor predeterminado de acceso entre tenants — que, de fábrica, está abierto a la colaboración.

La cadena de escalada

Paso 1 — Una organización externa invita, o es invitada, sin restricción específica por organización

Como los ajustes de colaboración B2B por defecto permiten el acceso entrante y saliente hacia cualquier organización externa de Microsoft Entra, una cuenta de invitado de prácticamente cualquier tenant puede ser invitada al suyo — o una cuenta de empleado comprometida puede invitar a una — sin toparse con una comprobación de lista de permitidos.

Paso 2 — Los ajustes de confianza entrante suprimen un nuevo desafío de MFA

Si la confianza entrante está configurada para aceptar reclamaciones de MFA de organizaciones externas a nivel predeterminado, Microsoft Entra comprueba si el token del invitado ya trae una reclamación de MFA satisfecha en su tenant de origen — un tenant que usted no controla ni puede auditar. No se emite ningún desafío nuevo en su tenant si esa reclamación está presente, sin importar lo débil o fuerte que sea en realidad la aplicación de MFA del tenant de origen.

Paso 3 — Al objeto invitado se le asigna directamente un rol de directorio

En algún punto del historial del tenant — un compromiso puntual con un proveedor, un rodeo tipo «break-glass», un administrador que usó «asignar temporalmente Administrador global al invitado» como atajo que nunca se revirtió — el ID de objeto del invitado se pasó a una llamada de asignación de roles. Nada en el RBAC de Entra ID bloquea esto a nivel de API, y a menos que alguien consulte específicamente la pertenencia a roles para principales invitados, no aparece en una revisión rutinaria de «quiénes son nuestros administradores» que lista nombres a simple vista.

Paso 4 — La sesión privilegiada persiste a través del tenant de origen del invitado

Como la autenticación de ese invitado sigue ocurriendo en su tenant de origen, sus políticas de acceso condicional, detecciones de riesgo de inicio de sesión y la aplicación de contraseña/MFA en su tenant solo ven lo que los ajustes de confianza dejan pasar. Un compromiso de las credenciales del tenant de origen del invitado se convierte, de forma transitiva, en un compromiso de una identidad privilegiada en el suyo.

Detección

# Microsoft Graph — postura predeterminada actual de acceso entre tenants
GET https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/default

# Microsoft Graph — todas las excepciones específicas por socio
GET https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners

# Microsoft Graph — todas las asignaciones de rol de directorio con principal expandido;
# filtrar la respuesta en el cliente por principal.userType eq 'Guest'
GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?$expand=principal

// Registros de auditoría de Microsoft Entra — asignaciones de rol que recaen en un UPN de invitado
AuditLogs
| where OperationName in ("Add member to role", "Add eligible member to role")
| where TargetResources[0].userPrincipalName contains "#EXT#"
| project TimeGenerated, OperationName, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName), Target = tostring(TargetResources[0].userPrincipalName)

// Registros de auditoría de Microsoft Entra — cambios en el ajuste predeterminado de acceso entre tenants
AuditLogs
| where Category == "CrossTenantAccessSettings"
| where OperationName has "default"
| project TimeGenerated, OperationName, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName)

Remediación

1. Inventaríe cada asignación de rol de directorio que posea un invitado, y decida para cada una: ¿necesita acceso permanente, necesita algún rol siquiera, o nunca se revirtió tras un compromiso de corta duración? Trate «no sabemos por qué este invitado tiene este rol» como un incidente, no como una nota de configuración.
2. Traslade cualquier acceso privilegiado legítimo de un invitado a PIM como asignación elegible y limitada en el tiempo, con aprobación requerida, en lugar de una asignación directa permanente. Vea Acceso privilegiado en Azure: demasiados administradores globales para entender por qué el acceso privilegiado permanente ya es un hallazgo habitual incluso en cuentas miembro, y Funciones de Azure AD Premium P2 para lo que PIM necesita para habilitarse.
3. Ponga el acceso de colaboración B2B entrante y saliente por defecto en Bloquear, y añada ajustes específicos por organización solo para los tenants externos con los que realmente colabora. La propia guía de Microsoft es identificar primero los inicios de sesión entrantes/salientes, para que un cambio del valor predeterminado a Bloquear no corte un acceso de negocio activo.
4. Saque la confianza de MFA y dispositivo entrante del ámbito predeterminado. Si necesita confiar en el MFA de un socio concreto, configúrelo como excepción específica de ese socio únicamente — no como un valor predeterminado general aplicado a cualquier tenant de Microsoft Entra que se invite alguna vez.
5. Deje la conexión directa B2B bloqueada por defecto — la propia postura inicial de Microsoft — y actívela, por organización, solo para los socios que haya validado mediante configuración mutua.
6. Acote el acceso saliente a los usuarios y grupos que realmente necesiten colaborar externamente, en lugar de dejar a todos los usuarios internos elegibles para B2B saliente por defecto.
7. Ejecute revisiones de acceso enfocadas específicamente en la pertenencia a roles privilegiados, no solo en la pertenencia a grupos — una revisión que solo comprueba «quién está en el grupo de Administradores globales» pasa por alto a un invitado con una asignación de rol directa fuera de cualquier grupo. Refuerce más ampliamente los ajustes predeterminados del tenant usando Endurecimiento del tenant de Azure: corrija los ajustes predeterminados inseguros como checklist complementaria.

Cómo lo detecta EtcSec

La auditoría de Entra ID de EtcSec comprueba directamente esta capa de gobernanza. Guest User with Administrative Role (GUEST_ADMIN_ROLE) señala cualquier principal invitado que posea una asignación de rol de directorio. Cross-Tenant Access Open (B2B_CROSS_TENANT_OPEN) y Outbound B2B Access Unrestricted (B2B_OUTBOUND_UNRESTRICTED) comprueban la postura predeterminada de colaboración B2B entrante/saliente frente a las excepciones específicas por organización. Inbound Trust for All Organizations (B2B_INBOUND_TRUST_ALL) señala una confianza de MFA/dispositivo configurada a nivel predeterminado en lugar de por socio. B2B Direct Connect Enabled (B2B_DIRECT_CONNECT_ENABLED) confirma que la conexión directa no se ha abierto más allá de la postura bloqueada por defecto de Microsoft.

Para los ángulos de gobernanza de invitados adyacentes que este artículo no cubre, vea Cuentas de invitado en Azure: la superficie de ataque olvidada para política de invitación, requisitos de MFA y limpieza de cuentas obsoletas, y Grupos privilegiados anidados en Entra ID, grupos asignables a roles e invitados en grupos de seguridad para invitados que alcanzan privilegio mediante anidamiento de grupos en lugar de una asignación directa. Para la revisión más amplia en la que se enmarcan estas comprobaciones, vea Cómo auditar la seguridad de Microsoft Entra ID.