Autenticación y acceso condicional para el id. externo
Se aplica a: 
inquilinos de Workforce 
inquilinos externos (más información)
Sugerencia
Este artículo se aplica a la colaboración B2B y a la conexión directa B2B en inquilinos de personal. Para obtener información sobre inquilinos externos, vea Seguridad y gobernanza en Id. externa de Microsoft Entra.
Cuando un usuario externo accede a los recursos de su organización, el flujo de autenticación está determinado por el método de colaboración (colaboración B2B o conexión directa B2B), el proveedor de identidades del usuario (un inquilino externo de Microsoft Entra, proveedor de identidades social, etc.), las políticas de acceso condicional y la configuración de acceso entre inquilinos configurada tanto en el inquilino principal del usuario como en los recursos de hospedaje del inquilino.
En este artículo se describe el flujo de autenticación para los usuarios externos que acceden a los recursos de su organización. Las organizaciones pueden aplicar varias directivas de acceso condicional para sus usuarios externos, que se pueden aplicar en el nivel de inquilino, aplicación o usuario concreto de la misma manera que están habilitadas para empleados a tiempo completo y miembros de la organización.
Flujo de autenticación para usuarios externos de Microsoft Entra
En el diagrama siguiente se muestra el flujo de autenticación cuando una organización de Microsoft Entra comparte recursos con usuarios de otras organizaciones de Microsoft Entra. En este diagrama se muestra cómo funciona la configuración de acceso entre inquilinos con directivas de acceso condicional, como la autenticación multifactor, para determinar si el usuario puede acceder a los recursos. Este flujo se aplica tanto a la colaboración B2B como a la conexión directa B2B, excepto como se indica en el paso 6.
| Paso | Description |
|---|---|
| 1 | Un usuario de Fabrikam (el inquilino principal del usuario) inicia el inicio de sesión en un recurso de Contoso (el inquilino del recurso). |
| 2 | Durante el inicio de sesión, el servicio de token de seguridad (STS) de Microsoft Entra evalúa las directivas de acceso condicional de Contoso. También comprueba si se permite el acceso al usuario de Fabrikam mediante la evaluación de la configuración de acceso entre inquilinos (la configuración de salida de Fabrikam y la configuración de entrada de Contoso). |
| 3 | Microsoft Entra ID comprueba la configuración de confianza de entrada de Contoso para ver si Contoso confía en MFA y las notificaciones de dispositivo (cumplimiento de dispositivos, estado unido a Microsoft Entra ID híbrido) de Fabrikam. Si no es necesario, vaya al paso 6. |
| 4 | Si Contoso confía en MFA y las notificaciones de dispositivo de Fabrikam, Microsoft Entra ID comprueba la sesión de autenticación del usuario en busca de una indicación de que el usuario ha completado MFA. Si Contoso confía en la información del dispositivo de Fabrikam, Microsoft Entra ID busca una notificación en la sesión de autenticación que indique el estado del dispositivo (compatible o unido a Microsoft Entra híbrido). |
| 5 | Si se requiere MFA, pero no se completa, o si no se proporciona una notificación de dispositivo, Microsoft Entra ID emite desafíos de MFA y de dispositivo en el inquilino principal del usuario según sea necesario. Cuando se cumplen los requisitos de MFA y dispositivo en Fabrikam, se permite al usuario acceder al recurso en Contoso. Si no se pueden satisfacer las comprobaciones, se bloquea el acceso. |
| 6 | Cuando no se configura ninguna configuración de confianza y se requiere MFA, se solicita a los usuarios de colaboración B2B MFA. Necesitan satisfacer la MFA en el inquilino de recursos. El acceso está bloqueado para los usuarios de conexión directa B2B. Si se requiere el cumplimiento del dispositivo, pero no se puede evaluar, se bloquea el acceso para los usuarios de colaboración B2B y conexión directa B2B. |
Para más información, consulte la sección Acceso condicional para usuarios externos.
Flujo de autenticación para usuarios externos que no son de Azure AD
Cuando una organización de Microsoft Entra comparte recursos con usuarios externos con un proveedor de identidades distinto de Microsoft Entra ID, el flujo de autenticación depende de si el usuario se autentica con un proveedor de identidades o con la autenticación de código de acceso de un solo uso por correo electrónico. En cualquier caso, el inquilino de recursos identifica qué método de autenticación usar y, a continuación, redirige al usuario a su proveedor de identidades o emite un código de acceso de un solo uso.
Ejemplo 1: Flujo de autenticación y token para un usuario externo que no es de Azure AD
En el diagrama siguiente se muestra el flujo de autenticación cuando un usuario externo inicia sesión con una cuenta de un proveedor de identidades que no es de Azure AD, como Google, Facebook o un proveedor de identidades SAML/WS-Fed federado.
| Paso | Description |
|---|---|
| 1 | El usuario invitado de B2B solicita acceso a un recurso. El recurso redirige al usuario a su inquilino de recursos, un IdP de confianza. |
| 2 | El inquilino de recursos identifica al usuario como externo y redirige al usuario al IdP del usuario invitado de B2B. El usuario realiza la autenticación principal en el IdP. |
| 3 | Las directivas de autorización se evalúan en el IdP del usuario invitado B2B. Si el usuario cumple estas directivas, el IdP del usuario invitado B2B emite un token al usuario. El usuario se redirige de nuevo al inquilino de recursos con el token. El inquilino de recursos valida el token y luego evalúa el usuario con sus directivas de acceso condicional. Por ejemplo, el inquilino de recursos podría requerir que el usuario realice la autenticación multifactor de Microsoft Entra. |
| 4 | Se evalúan la configuración de acceso entre inquilinos de entrada y las directivas de acceso condicional. Si se cumplen todas las directivas, el inquilino de recursos emite su propio token y redirige al usuario a su recurso. |
Ejemplo 2: Flujo de autenticación y token para un usuario de código de acceso de un solo uso
En el diagrama siguiente se muestra el flujo cuando la autenticación de código de acceso de un solo uso por correo electrónico está habilitada y el usuario externo no se autentica a través de otros medios, como Microsoft Entra ID, cuenta Microsoft (MSA) o un proveedor de identidades sociales.
| Paso | Description |
|---|---|
| 1 | El usuario solicita acceso a un recurso de otro inquilino. El recurso redirige al usuario a su inquilino de recursos, un IdP de confianza. |
| 2 | El inquilino de recursos identifica al usuario como un usuario de código de acceso de un solo uso (OTP) de correo electrónico externo y envía al usuario un correo electrónico con el OTP. |
| 3 | El usuario recupera el OTP y envía el código. El inquilino de recursos evalúa el usuario con sus directivas de acceso condicional. |
| 4 | Una vez que se cumplen todas las directivas de acceso condicional, el inquilino de recursos emite un token y redirige al usuario a su recurso. |
Acceso condicional para usuarios externos
Las organizaciones pueden aplicar directivas de acceso condicional para usuarios externos de colaboración B2B y conexión directa B2B de la misma manera que están habilitadas para empleados a tiempo completo y miembros de la organización. Con la introducción de la configuración de acceso entre inquilinos, también puede confiar en MFA y las notificaciones de dispositivo de organizaciones externas de Microsoft Entra. En esta sección se describen consideraciones importantes para aplicar el acceso condicional a usuarios fuera de su organización.
Nota:
Los controles personalizados con acceso condicional no son compatibles con las confianzas entre inquilinos.
Asignación de directivas de acceso condicional a tipos de usuario externos
Al configurar una directiva de acceso condicional, tiene un control pormenorizado sobre los tipos de usuarios externos a los que desea aplicar la directiva. Los usuarios externos se clasifican en función de cómo se autentican (interna o externamente) y su relación con su organización (invitado o miembro).
- Usuarios invitados de colaboración B2B: la mayoría de los usuarios que suelen considerar invitados se encuentran en esta categoría. Este usuario de colaboración B2B tiene una cuenta en una organización de Microsoft Entra externa o un proveedor de identidades externo (como una identidad social) y tiene permisos de nivel de invitado en la organización. El objeto de usuario creado en su directorio de Microsoft Entra del recurso tiene un valor UserType de Invitado. Esta categoría incluye usuarios de colaboración B2B invitados y que usaron el registro de autoservicio.
- Usuarios miembros de colaboración B2B: este usuario de colaboración B2B tiene una cuenta en una organización de Microsoft Entra externa o un proveedor de identidades externo (como una identidad social) y acceso de nivel de miembro a los recursos de su organización. Este escenario es común en organizaciones que constan de varios inquilinos, donde los usuarios se consideran parte de la organización más grande y necesitan acceso de nivel de miembro a los recursos de los otros inquilinos de la organización. El objeto de usuario creado en el directorio de Microsoft Entra del recurso tiene un valor UserType de Miembro.
- Usuarios de conexión directa B2B: usuarios externos que pueden acceder a los recursos a través de la conexión directa B2B, que es una conexión bidireccional mutua con otra organización de Microsoft Entra que permite el acceso de inicio de sesión único a determinadas aplicaciones de Microsoft (actualmente, canales compartidos de Microsoft Teams Connect). Los usuarios de conexión directa B2B no tienen presencia en la organización de Microsoft Entra, sino que se administran desde dentro de la aplicación (por ejemplo, por el propietario del canal compartido de Teams).
- Usuarios invitados locales: los usuarios invitados locales tienen credenciales que se administran en el directorio. Antes de que la colaboración de Microsoft Entra B2B estuviera disponible, era habitual colaborar con distribuidores, proveedores, vendedores y otros mediante la configuración de credenciales internas para ellos y su designación como invitados estableciendo el objeto de usuario UserType en Invitado.
- Usuarios del proveedor de servicios: organizaciones que sirven como proveedores de servicios en la nube para su organización (la propiedad isServiceProvider de la configuración específica del asociado de Microsoft Graph es true).
- Otros usuarios externos: se aplica a los usuarios que no se encuentran en estas categorías, pero que no se consideran miembros internos de su organización, lo que significa que no se autentican internamente a través de Microsoft Entra ID y el objeto de usuario creado en el directorio de Microsoft Entra del recurso no tiene un UserType de tipo Miembro.
Nota:
La selección "Todos los usuarios invitados y externos" ahora se ha reemplazado por "Usuarios invitados y externos" y todos sus subtipos. En el caso de los clientes que anteriormente tenían una directiva de acceso condicional con la opción "Todos los usuarios invitados y externos" seleccionados ahora verán "Usuarios invitados y externos" junto con todos los subtipos seleccionados. Este cambio en la experiencia de usuario no tiene ningún impacto funcional sobre cómo el back-end de acceso condicional evalúa la directiva. La nueva selección proporciona a los clientes la granularidad necesaria para elegir tipos específicos de usuarios invitados y externos para incluir o excluir del ámbito de usuario al crear su directiva de acceso condicional.
Obtenga más información sobre las asignaciones de usuarios de acceso condicional.
Comparación de directivas de acceso condicional de Id. externa
En la tabla siguiente se proporciona una comparación detallada de las opciones de cumplimiento y directiva de seguridad en Microsoft Entra External ID. La directiva de seguridad y el cumplimiento las administra la organización anfitriona o invitadora con directivas de acceso condicional.
| Directiva | Usuarios de colaboración B2B | Usuarios de conexión directa B2B |
|---|---|---|
| Conceder controles—Bloquear el acceso | Compatible | Compatible |
| Conceder controles: Requerir autenticación multifactor | Compatible | Compatible, requiere configurar las opciones de confianza de entrada para aceptar notificaciones de MFA de la organización externa. |
| Conceder controles: Requerir un dispositivo compatible | Compatible, requiere configurar las opciones de confianza de entrada para aceptar notificaciones de dispositivo compatible de la organización externa. | Compatible, requiere configurar las opciones de confianza de entrada para aceptar notificaciones de dispositivo compatible de la organización externa. |
| Conceder controles: requerir dispositivo unido a Microsoft Entra híbrido | Compatible, requiere configurar las opciones de confianza de entrada para aceptar notificaciones de dispositivo unido a Microsoft Entra híbrido de la organización externa. | Compatible, requiere configurar las opciones de confianza de entrada para aceptar notificaciones de dispositivo unido a Microsoft Entra híbrido de la organización externa. |
| Conceder controles: Requerir aplicación cliente aprobada | No compatible | No compatible |
| Conceder controles: Requerir directiva de protección de aplicaciones | No compatible | No compatible |
| Conceder controles: Requerir cambio de contraseña | No compatible | No compatible |
| Conceder controles: Términos de uso | Compatible | No compatible |
| Controles de sesión: Uso de restricciones aplicadas a la aplicación | Compatible | No compatible |
| Controles de sesión: Uso del control de aplicaciones de acceso condicional | Compatible | No compatible |
| Controles de sesión: Frecuencia de inicio de sesión | Compatible | No compatible |
| Controles de sesión: Sesión del explorador persistente | Compatible | No compatible |
MFA para usuarios externos de Microsoft Entra
En un escenario entre inquilinos de Microsoft Entra, la organización de recursos puede crear directivas de acceso condicional que requieran el cumplimiento de MFA o dispositivos para todos los usuarios invitados y externos. Por lo general, un usuario de colaboración B2B que accede a un recurso debe configurar su autenticación multifactor de Microsoft Entra con el inquilino del recurso. Sin embargo, Microsoft Entra ID ahora ofrece la posibilidad de confiar en las notificaciones de MFA de otros inquilinos de Microsoft Entra. La habilitación de la confianza de MFA con otro inquilino simplifica el proceso de inicio de sesión para los usuarios de colaboración B2B y permite el acceso a los usuarios de conexión directa B2B.
Si ha configurado las opciones de confianza de entrada para aceptar notificaciones de MFA de una colaboración B2B o un inquilino principal del usuario de conexión directa B2B, Microsoft Entra ID comprueba la sesión de autenticación del usuario. Si la sesión contiene una notificación que indica que las directivas de MFA ya se cumplieron en el inquilino principal del usuario, se concede al usuario el inicio de sesión sin problemas al recurso compartido.
Si la confianza de MFA no está habilitada, la experiencia del usuario es diferente para los usuarios de colaboración B2B y los usuarios de conexión directa B2B:
Usuarios de colaboración B2B: si la organización del recurso no habilita la confianza de MFA con el inquilino principal del usuario, se presenta al usuario un desafío de MFA de la organización del recurso. (El flujo es el mismo que el flujo de MFA para usuarios externos que no son de Azure AD).
Usuarios de conexión directa B2B: si la organización del recurso no habilita la confianza de MFA con el inquilino principal del usuario, el usuario no puede acceder a los recursos. Si quiere permitir la conexión directa B2B con una organización externa y las directivas de acceso condicional requieren MFA, debe configurar los valores de confianza de entrada para aceptar notificaciones de MFA de la organización.
Obtenga información sobre cómo configurar las opciones de confianza de entrada para MFA.
MFA para usuarios externos que no son de Azure AD
En el caso de los usuarios externos que no son de Azure AD, el inquilino de recursos siempre es responsable de MFA. En el ejemplo siguiente se muestra un flujo de MFA típico: Este escenario funciona para cualquier identidad, incluida una cuenta Microsoft (MSA) o un identificador social. Este flujo también se aplica a usuarios externos de Microsoft Entra cuando no se configura la configuración de confianza con su organización de Microsoft Entra principal.
Un administrador o un trabajador de la información de una empresa denominada Fabrikam invita a un usuario de otra compañía llamada Contoso a usar la aplicación de Fabrikam.
La aplicación de Fabrikam está configurada para requerir la autenticación multifactor de Microsoft Entra al acceder.
Cuando el usuario de colaboración B2B de Contoso intenta acceder a la aplicación de Fabrikam, se le pide que complete el desafío de autenticación multifactor de Microsoft Entra.
A continuación, el usuario invitado puede configurar la autenticación multifactor de Microsoft Entra con Fabrikam y seleccionar las opciones.
Fabrikam debe tener suficientes licencias de Microsoft Entra ID prémium que admitan la autenticación multifactor de Microsoft Entra. El usuario de Contoso consume esta licencia de Fabrikam. Consulte el modelo de facturación de Microsoft Entra External ID para obtener información sobre las licencias B2B.
Nota:
MFA se completa en el servicio de recursos para garantizar la previsibilidad. Cuando el usuario invitado inicie sesión, verá la página de inicio de sesión del inquilino de recursos en segundo plano, y su propia página de inicio de sesión del inquilino principal y el logotipo de la empresa en primer plano.
Restablecimiento de la autenticación multifactor (prueba) de Microsoft Entra para usuarios de colaboración B2B
Los siguientes cmdlets de PowerShell están disponibles para probar o solicitar el registro de MFA a los usuarios de colaboración B2B.
Nota:
Los módulos de PowerShell de Azure AD y MSOnline están en desuso a partir del 30 de marzo de 2024. Para obtener más información, lee la actualización de desuso. Desde esta fecha, el soporte de estos módulos se limita a la asistencia de migración al SDK de PowerShell de Microsoft Graph y a las correcciones de seguridad. Los módulos en desuso seguirán funcionando hasta el 30 de marzo de 2025.
Se recomienda migrar a PowerShell de Microsoft Graph para interactuar con Microsoft Entra ID (anteriormente Azure AD). Para preguntas comunes sobre la migración, consulta las Preguntas más frecuentes sobre migración. Nota: Versiones 1.0.x de MSOnline pueden experimentar interrupciones después del 30 de junio de 2024.
Conéctese a Microsoft Entra ID:
$cred = Get-Credential Connect-MsolService -Credential $credObtenga todos los usuarios con los métodos de prueba:
Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}Por ejemplo:
Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}Restablezca el método de autenticación multifactor de Microsoft Entra de un usuario específico para exigir que el usuario establezca de nuevo los métodos de prueba, por ejemplo:
Reset-MsolStrongAuthenticationMethodByUpn -UserPrincipalName gsamoogle_gmail.com#EXT#@ WoodGroveAzureAD.onmicrosoft.com
Directivas de seguridad de autenticación para usuarios externos
La seguridad de la autenticación es un control de acceso condicional que permite definir una combinación específica de métodos de autenticación multifactor que un usuario externo debe completar para acceder a los recursos. Este control es especialmente útil para restringir el acceso externo a aplicaciones confidenciales de su organización, ya que puede aplicar métodos de autenticación específicos, como un método resistente a la suplantación de identidad, para usuarios externos.
También tiene la capacidad de aplicar la seguridad de autenticación a los diferentes tipos de usuarios invitados o externos con los que colabora o se conecta. Esto significa que puede aplicar requisitos de seguridad de autenticación que sean exclusivos de la colaboración B2B, la conexión directa B2B y otros escenarios de acceso externo.
Microsoft Entra ID proporciona tres puntos de seguridad de autenticación integrados:
- Seguridad de la autenticación multifactor
- Seguridad de MFA sin contraseña
- Seguridad de MFA frente a la suplantación de identidad
Puede usar uno de estos puntos fuertes integrados o crear una directiva de seguridad de autenticación personalizada en función de los métodos de autenticación que desee requerir.
Nota:
Actualmente, solo puede aplicar directivas de seguridad de autenticación a usuarios externos que se autentiquen con Microsoft Entra ID. Para el código de acceso de un solo uso de correo electrónico, SAML/WS-Fed y los usuarios de federación de Google, use el control de concesión de MFA para requerir MFA.
Cuando se aplica una directiva de seguridad de autenticación a usuarios externos de Microsoft Entra, la directiva funciona junto con la configuración de confianza de MFA en la configuración de acceso entre inquilinos para determinar dónde y cómo el usuario externo debe realizar MFA. Un usuario de Microsoft Entra se autentica primero con su propia cuenta en su inquilino de Microsoft Entra principal. Después, cuando este usuario intenta acceder al recurso, Microsoft Entra ID aplica la directiva de acceso condicional de seguridad de autenticación y comprueba si habilitó la confianza de MFA.
En escenarios de usuario externo, los métodos de autenticación que son aceptables para cumplir la seguridad de autenticación varían, en función de si el usuario está completando MFA en su inquilino principal o en el inquilino de recursos. En la tabla siguiente se indican los métodos aceptables en cada inquilino. Si un inquilino de recursos opta por confiar en las notificaciones de organizaciones externas de Microsoft Entra ID, el inquilino de recursos acepta para la MFA solo las notificaciones enumeradas en la columna "Inquilino principal" que aparece a continuación. Si el inquilino de recursos deshabilita la confianza de MFA, el usuario externo debe completar MFA en el inquilino de recursos mediante uno de los métodos enumerados en la columna "Inquilino de recursos".
Tabla 1. Métodos de MFA de seguridad de autenticación para usuarios externos
| Método de autenticación | Inquilino principal | Inquilino de recursos |
|---|---|---|
| SMS como segundo factor | ✅ | ✅ |
| Llamada de voz | ✅ | ✅ |
| Notificación de inserción de Microsoft Authenticator | ✅ | ✅ |
| Inicio de sesión en el teléfono de Microsoft Authenticator | ✅ | |
| Token de software OATH | ✅ | ✅ |
| Token de hardware OATH | ✅ | |
| Clave de seguridad FIDO2 | ✅ | |
| Windows Hello para empresas | ✅ | |
| Autenticación basada en certificados | ✅ |
Para configurar una directiva de acceso condicional que aplique los requisitos de seguridad de autenticación a usuarios externos o invitados, consulte Acceso condicional: Requerir una seguridad de autenticación para usuarios externos.
Experiencia del usuario para usuarios externos de Microsoft Entra
Las directivas de seguridad de autenticación funcionan junto con la configuración de confianza de MFA en la configuración de acceso entre inquilinos para determinar dónde y cómo debe realizar MFA el usuario externo.
En primer lugar, un usuario de Microsoft Entra se autentica con su propia cuenta en su inquilino principal. Después, cuando este usuario intenta acceder al recurso, Microsoft Entra ID aplica la directiva de acceso condicional de seguridad de autenticación y comprueba si se ha habilitado la confianza de MFA.
- Si la confianza de MFA está habilitada, Microsoft Entra ID comprueba la sesión de autenticación del usuario para obtener una notificación que indica que cumplió la MFA en el inquilino principal del usuario. Consulte la Tabla 1 para ver los métodos de autenticación que son aceptables para el cumplimiento de la MFA cuando se completa en el inquilino principal de un usuario externo. Si la sesión contiene una notificación que indica que las directivas de MFA ya se cumplieron en el inquilino principal del usuario, y los métodos cumplen los requisitos de intensidad de autenticación, se permite el acceso al usuario. De lo contrario, Microsoft Entra ID presenta al usuario un desafío para completar la MFA en el inquilino principal mediante un método de autenticación aceptable. El método MFA debe estar habilitado en el inquilino principal y el usuario debe poder registrarse para él.
- Si la confianza de la MFA está deshabilitada, Microsoft Entra ID presenta al usuario un desafío para completar la MFA en el inquilino del recurso mediante un método de autenticación aceptable. (Consulte la tabla 1 para conocer los métodos de autenticación que son aceptables para el suministro de MFA por parte de un usuario externo).
Si el usuario no puede completar MFA o si una directiva de acceso condicional (por ejemplo, una directiva de dispositivo compatible) impide que se registre, se bloquea el acceso.
Cumplimiento de dispositivos y directivas de dispositivos unidos a Microsoft Entra híbrido
Las organizaciones pueden usar directivas de acceso condicional para requerir que los dispositivos de los usuarios se administren mediante Microsoft Intune. Estas directivas pueden bloquear el acceso de los usuarios externos, ya que un usuario externo no puede registrar su dispositivo no administrado en la organización del recurso. Los dispositivos solo se pueden administrar mediante el inquilino principal de un usuario.
Sin embargo, puede usar la configuración de confianza del dispositivo para desbloquear a los usuarios externos mientras se siguen requiriendo dispositivos administrados. En la configuración de acceso entre inquilinos, puede elegir confiar en las notificaciones del inquilino principal de un usuario externo sobre si el dispositivo del usuario cumple sus directivas de cumplimiento de dispositivos o está unido a Microsoft Entra híbrido. Puede establecer la configuración de confianza del dispositivo para todas las organizaciones de Microsoft Entra o para organizaciones individuales.
Cuando la configuración de confianza del dispositivo está habilitada, Microsoft Entra ID comprueba la sesión de autenticación de un usuario en busca de una notificación de dispositivo. Si la sesión contiene una notificación de dispositivo que indica que las directivas ya se cumplieron en el inquilino principal del usuario, se concede al usuario externo el inicio de sesión sin problemas al recurso compartido.
Importante
- A menos que esté dispuesto a confiar en las notificaciones relacionadas con el cumplimiento de dispositivos o el estado de la unión a Microsoft Entra híbrido desde el inquilino principal de un usuario externo, no se recomienda aplicar directivas de acceso condicional que requieran que los usuarios externos usen dispositivos administrados.
Filtros de dispositivo
Al crear directivas de acceso condicional para usuarios externos, puede evaluar una directiva en función de los atributos de dispositivo de un dispositivo registrado en Microsoft Entra ID. Mediante el uso de la condición de filtrado por dispositivos, puede dirigirse a dispositivos específicos mediante operadores y propiedades admitidos y otras condiciones de asignación disponibles en las directivas de acceso condicional.
Los filtros de dispositivo se pueden usar junto con la configuración de acceso entre inquilinos para basar directivas en dispositivos administrados en otras organizaciones. Por ejemplo, supongamos que quiere bloquear los dispositivos de un inquilino externo de Microsoft Entra en función de un atributo de dispositivo específico. Puede hacer lo siguiente para configurar una directiva basada en atributos de dispositivo:
- Configure las opciones de acceso entre inquilinos para confiar en las notificaciones de dispositivo de esa organización.
- Asigne el atributo de dispositivo que quiere usar para filtrar a uno de los atributos de extensión de dispositivo admitidos.
- Cree una directiva de acceso condicional con un filtro de dispositivo que bloquee el acceso a los dispositivos que contienen ese atributo.
Más información sobre el filtrado de dispositivos con acceso condicional.
Directivas de administración de aplicaciones móviles
No se recomienda requerir una directiva de protección de aplicación para usuarios externos. Los controles de concesión de acceso condicional, como Requerir aplicaciones cliente aprobadas y Requerir directivas de protección de aplicación, requieren que el dispositivo esté registrado en el inquilino del recurso. Estos controles solo pueden aplicarse a dispositivos iOS y Android. Dado que el dispositivo de un usuario solo se puede administrar mediante su inquilino principal, estos controles no se pueden aplicar a los usuarios invitados externos.
Acceso condicional basado en la ubicación
La directiva basada en la ubicación que se fundamenta en intervalos IP se puede aplicar si la organización que invita puede crear un intervalo de direcciones IP de confianza que defina sus organizaciones asociadas.
Las directivas también se pueden aplicar en función de las ubicaciones geográficas.
Acceso condicional basado en riesgos
La directiva de riesgo de inicio de sesión se aplica si el usuario invitado externo cumple el control de concesión. Por ejemplo, una organización podría requerir la autenticación multifactor de Microsoft Entra para el riesgo medio o alto de inicio de sesión. Sin embargo, si un usuario no se ha registrado previamente para la autenticación multifactor de Microsoft Entra en el inquilino de recursos, dicho usuario se bloquea. Esto se hace para evitar que usuarios malintencionados registren sus propias credenciales de autenticación multifactor de Microsoft Entra en el caso de que pongan en peligro la contraseña de un usuario legítimo.
Sin embargo, la directiva de riesgo de usuario no se puede resolver en el inquilino de recursos. Por ejemplo, si requiere un cambio de contraseña para los usuarios invitados externos de alto riesgo, estos se bloquean debido a la imposibilidad de restablecer las contraseñas en el directorio del recurso.
Acceso condicional con condición de aplicaciones cliente
Las condiciones de las aplicaciones cliente se comportan de la misma manera para los usuarios invitados de B2B que para cualquier otro tipo de usuario. Por ejemplo, puede impedir que los usuarios invitados usen protocolos de autenticación heredados.
Controles de sesión de acceso condicional
Los controles de sesión se comportan de la misma manera para los usuarios invitados de B2B que para cualquier otro tipo de usuario.
Protección de id. de Microsoft Entra y directivas de riesgo de usuario
Protección de id. de Microsoft Entra detecta credenciales en peligro de los usuarios de Microsoft Entra y marca las cuentas de usuario que puedan estar en peligro como "en riesgo". Como inquilino de recursos, puede aplicar directivas de riesgo de usuario a usuarios externos para bloquear inicios de sesión de riesgo. Para un usuario externo, el riesgo del usuario se evalúa en su directorio particular. El riesgo de inicio de sesión en tiempo real para estos usuarios se evalúa en el directorio de recursos cuando intentan acceder al recurso. Sin embargo, dado que la identidad de un usuario externo existe en su directorio particular, existen las siguientes limitaciones:
- Si un usuario externo desencadena la directiva de riesgo de usuario de Protección de id. para forzar el restablecimiento de contraseña, se bloquea porque no puede restablecer su contraseña en la organización del recurso.
- El informe de usuarios de riesgo de la organización del recurso no refleja a los usuarios externos porque la evaluación de riesgos se produce en el directorio particular del usuario externo.
- Los administradores de la organización del recurso no pueden descartar ni corregir un usuario externo de riesgo porque no tienen acceso al directorio principal del usuario B2B.
Puede impedir que las directivas basadas en riesgos afecten a los usuarios externos mediante la creación de un grupo en Microsoft Entra ID que contenga todos los usuarios externos de la organización. A continuación, agregue este grupo como exclusión para las directivas de acceso condicional basadas en riesgo de usuario e inicio de sesión.
Para obtener más información, consulte Usuarios de Protección de id. de Microsoft Entra y B2B.
Pasos siguientes
Para más información, consulte los siguientes artículos.