Entra ID B2B: colaborar con externos sin gestionar sus credenciales
Cómo funciona el acceso de invitados, qué revisar antes de habilitarlo y cómo retirarlo cuando termina la colaboración.
Un banco contrata a una consultora durante seis meses y, de un día para otro, veinte personas que no son empleados necesitan entrar a Azure DevOps, a una aplicación interna y a la documentación del proyecto. La reacción automática es crear veinte cuentas corporativas. Y con ellas llegan veinte contraseñas que resetear, veinte cuentas que nadie recordará desactivar cuando termine el contrato y una superficie de ataque que crece sin que nadie la haya decidido.
Microsoft Entra ID B2B existe para no tener que hacer eso.
La idea en una frase
Tu organización administra el acceso; la organización externa administra la identidad.
Todo lo demás es consecuencia de esa frase. El consultor sigue siendo de su empresa: ella gestiona su identidad de origen, su contraseña y el ciclo de vida de esa cuenta. Tú decides a qué puede acceder, durante cuánto tiempo y con qué requisitos de MFA. No conoces, no almacenas, no restableces y no rotas la contraseña de su cuenta de origen.
Cómo funciona
Supongamos que tu organización (Empresa A) quiere dar acceso a consultor@empresaB.com, que trabaja para un proveedor (Empresa B), a una aplicación interna desplegada en Azure. Recorre el flujo paso a paso:
En la práctica, la invitación se envía desde el centro de administración de Microsoft Entra: Microsoft Entra ID → Users → New user → Invite external user. El invitado recibe un correo y, en ese mismo formulario, ya puedes asignarlo a sus grupos. Un detalle a tener en cuenta: la invitación no caduca.
El banco y la consultora
Volvamos al banco. En lugar de crear cuentas, invita a cada desarrollador con su identidad de siempre (developer@consultora.com). Hasta ahí, B2B resuelve quién entra. Pero invitar es la parte fácil. Lo difícil es todo lo que pasa después: con qué condiciones entra cada uno y, sobre todo, cuándo deja de entrar.
No es un caso de manual. A mí me tocó dar acceso a proveedores externos que colaboraban con nosotros en el backend de una aplicación, incluida la base de datos. Cuando el acceso llega hasta los datos, esa pregunta deja de ser teórica.
Lo que más me costó fue lo más básico: encontrar la manera de enviarles la invitación. El control vino después. Usé grupos de seguridad de Entra para acotar el alcance de lo que cada invitado podía tocar, apliqué políticas de Conditional Access sobre su acceso y fui auditando con Access Reviews quién seguía necesitándolo. Si lo hiciera de nuevo, empezaría por mapear todo lo que ofrece B2B antes de invitar a nadie. Buena parte de este artículo es ese mapa.
Por eso B2B casi nunca va solo:
- Grupos de seguridad para acotar el alcance: los permisos se asignan al grupo, no a cada invitado, y sacar a alguien del grupo le retira todo de una vez.
- Conditional Access + MFA en la puerta: el banco exige sus propias condiciones a cada acceso externo, aunque no gestione ninguna contraseña.
- Access Reviews cada tres meses: alguien confirma si cada externo todavía necesita acceso; si no, se revoca.
El banco controla el acceso; la consultora conserva la identidad.
El detalle que más me gusta del diagrama está abajo, en el carril del Access Review. Las cuentas de invitado no caducan solas: un contrato termina en una fecha concreta, pero el acceso sigue ahí hasta que alguien lo quita. La revisión periódica convierte "alguien debería acordarse" en un proceso que no depende de la memoria de nadie.
Lo que viene activado por defecto
Dos comportamientos por defecto que conviene conocer antes de invitar al primer externo:
- Todostus usuarios internos pueden invitar externos por defectoMicrosoft Learn
- P1licencia necesaria para confiar en el MFA de la otra organizaciónMicrosoft Learn
- Quién abre la puerta. B2B viene habilitado con todas las organizaciones externas de Entra. Si no quieres que cualquiera invite, restríngelo desde la configuración de colaboración externa.
- MFA dos veces. Si tu tenant exige MFA y no confía en el realizado en la organización de origen, el consultor debe satisfacer ese requisito también en tu tenant. Con las trust settings del acceso entre tenants puedes aceptar el MFA y el estado del dispositivo validados por su organización; tus políticas siguen aplicándose.
B2B no es B2C
Es la confusión más común, y la diferencia está en quién es el usuario:
Colaboradores externos y clientes requieren modelos de acceso distintos.
Si trabajan contigo, B2B. Si usan lo que vendes, External ID.
Cuándo B2B no es la respuesta
B2B resuelve muy bien un problema concreto, y por eso conviene saber dónde termina. Si dudas, responde estas preguntas:
¿Qué necesitas?
¿Quiénes son los usuarios que necesitan acceso?
Y una duda que aparece siempre: ¿qué pasa si el externo no usa Microsoft Entra en su empresa? B2B sigue funcionando. Puede entrar con una cuenta Microsoft o con un código de un solo uso que recibe por email.
Quién es dueño de qué
No gestionar las contraseñas de los invitados no te exime de gestionar su acceso. Define quién puede entrar, con qué condiciones y cuándo debes retirarlo.
Si mañana vas a invitar al primer externo, empieza por tres cosas:
- Revisa quién puede invitar en tu tenant y restríngelo si hace falta.
- Crea una Access Review para los invitados antes de que el primero entre, no después.
- Decide si confías en el MFA de las organizaciones con las que más colaboras.
Fuentes
- B2B collaboration overview, Microsoft Learn.
- Cross-tenant access overview, Microsoft Learn.