Compartir a través de

Consideraciones comunes para la administración de usuarios multiinquilino

  • Artículo

Este artículo es el tercero de una serie de artículos que proporcionan una guía para configurar y proporcionar la administración del ciclo de vida de los usuarios en entornos multiinquilino de Microsoft Entra. En los artículos siguientes de la serie se proporciona más información, como se describe.

Las instrucciones le permiten alcanzar un estado coherente de la administración del ciclo de vida de los usuarios. La administración del ciclo de vida comprende el aprovisionamiento, la administración y el desaprovisionamiento de usuarios entre inquilinos mediante las herramientas de Azure disponibles que incluyen la colaboración B2B de Microsoft Entra (B2B) y la sincronización entre inquilinos.

Las necesidades específicas de la organización determinarán los requisitos de sincronización. A la hora de diseñar una solución que satisfaga los requisitos de su organización, las siguientes consideraciones de este artículo le ayudarán a identificar las mejores opciones.

  • Sincronización entre inquilinos
  • Objeto de directorio
  • Acceso condicional de Microsoft Entra
  • Control de acceso adicional
  • Office 365

Sincronización entre inquilinos

La sincronización entre inquilinos puede resolver los problemas de colaboración y acceso de las organizaciones multiinquilino. En la tabla siguiente se muestran casos de uso comunes de sincronización. Puede usar tanto la sincronización entre inquilinos como el desarrollo de clientes para satisfacer los casos de uso si las consideraciones son pertinentes para más de un patrón de colaboración.

Caso de uso Sincronización entre inquilinos Desarrollo personalizado
Administración del ciclo de vida de los usuarios Icono de marca de verificación Icono de marca de verificación
Uso compartido de archivos y acceso a aplicaciones Icono de marca de verificación Icono de marca de verificación
Compatibilidad con la sincronización hacia y desde nubes soberanas Icono de marca de verificación
Control de la sincronización desde el inquilino de recursos Icono de marca de verificación
Objetos de grupo de sincronización Icono de marca de verificación
Vínculos del administrador de sincronización Icono de marca de verificación Icono de marca de verificación
Origen de autoridad de nivel de atributo Icono de marca de verificación
Escritura diferida de Microsoft Entra en Windows Server Active Directory de Microsoft Icono de marca de verificación

Consideraciones sobre objetos de directorio

Invitación a un usuario externo con UPN frente a dirección SMTP

Microsoft Entra B2B espera que el UserPrincipalName (UPN) del usuario sea la dirección de Protocolo simple de transferencia de correo (SMTP) principal (correo electrónico) para enviar invitaciones. Cuando el UPN del usuario es el mismo que su dirección SMTP principal, B2B funciona según lo previsto. Sin embargo, si el UPN es diferente de la dirección SMTP principal del usuario externo, es posible que no lo resuelva cuando el usuario acepta una invitación. Este problema puede ser un desafío si no conoce el UPN real del usuario. Para enviar invitaciones para B2B, es necesario averiguar el UPN y usarlo.

En la sección Microsoft Exchange Online de este artículo se explica cómo cambiar la dirección SMTP principal predeterminada de los usuarios externos. Esta técnica es útil si desea que todo el correo electrónico y todas las notificaciones para un usuario externo se dirijan a la dirección SMTP principal real en lugar de al UPN. Puede ser un requisito si el UPN no es capaz de enrutar el flujo de correo.

Conversión del UserType de un usuario externo

Cuando se usa la consola para crear manualmente una invitación para una cuenta de usuario externo, se crea el objeto de usuario con un tipo de usuario Invitado. El uso de otras técnicas para crear invitaciones permite establecer el tipo de usuario de forma que no sea una cuenta de invitado externo. Por ejemplo, cuando usa la API, puede especificar si es una cuenta de miembro externo o una cuenta de invitado externo.

Si convierte una cuenta de usuario de invitado externo en una de miembro externo, puede haber problemas con la forma en la que Exchange Online controla las cuentas B2B. No puede habilitar por correo las cuentas que ha invitado como usuarios miembros externos. Para habilitar por correo una cuenta de miembro externo, siga este procedimiento.

  • Invite a los usuarios de las organizaciones como cuentas de usuarios invitados externos.
  • Muestre las cuentas en la LGD.
  • Establezca UserType en Miembro.

Al usar este procedimiento, las cuentas se muestran como objetos MailUser en Exchange Online y en Office 365. Además, tenga en cuenta que existe la dificultad del tiempo. Para asegurarse de que el usuario está visible en la lista global de direcciones (LGD), compruebe que la propiedad de usuario ShowInAddressList de Microsoft Entra concuerda con la propiedad HiddenFromAddressListsEnabled de PowerShell de Exchange Online (que son inversas entre ellas). En la sección Microsoft Exchange Online de este artículo se proporciona más información sobre el cambio de visibilidad.

Es posible convertir un usuario miembro en un usuario invitado, lo que resulta útil si desea restringir los permisos de los usuarios internos al nivel de invitado. Los usuarios invitados internos son usuarios que no son empleados de la organización, pero para los que administra tanto los usuarios como las credenciales. De esta forma podrá prescindir de conceder licencias a los usuarios invitados internos.

Problemas al usar objetos de contacto de correo en lugar de usuarios o miembros externos

Puede representar usuarios de otro inquilino usando una sincronización de la lista global de direcciones tradicional. Si usa la sincronización de la lista global de direcciones en lugar de usar la Colaboración B2B de Microsoft Entra, se crea un objeto contacto de correo.

  • Un objeto contacto de correo y un usuario invitado o miembro externo habilitado para correo no pueden coexistir en el mismo inquilino con la misma dirección de correo electrónico.
  • Si hay un objeto contacto de correo para la misma dirección de correo electrónico que el usuario invitado externo, se crea el usuario externo, pero no se habilita para correo electrónico.
  • Si ya existe el usuario externo habilitado para correo con la misma dirección de correo, el intento de crear un objeto contacto de correo produce una excepción.

Importante

El uso de contactos de correo requiere los servicios de Active Directory (AD DS) o PowerShell de Exchange Online. Microsoft Graph no proporciona una llamada API para administrar contactos.

En la tabla siguiente se muestran los resultados de los objetos de contacto de correo y los estados de usuario externos.

Estado actual Escenario de aprovisionamiento Resultado efectivo
Ninguno Invitar a un miembro B2B Usuario miembro no habilitado para correo. Vea la nota importante.
Ninguno Invitar a un invitado B2B Habilitación de correo electrónico de usuario externo.
Existe un objeto contacto de correo Invitar a un miembro B2B Error. Conflicto de direcciones de proxy.
Existe un objeto contacto de correo Invitar a un invitado B2B Contacto de correo y usuario externo no habilitado para correo. Vea la nota importante.
Usuario invitado externo habilitado para correo Creación de objeto de contacto de correo Error
Existe un usuario miembro externo habilitado para correo Crear contacto de correo Error

Microsoft recomienda usar la Colaboración B2B de Microsoft Entra (en lugar de la sincronización tradicional de la lista global de direcciones) para crear:

  • Usuarios externos que habilita para mostrarlos en la LGD.
  • Usuarios miembro externos que se muestran en la LGD de manera predeterminada, pero no están habilitados para correo.

Puede optar por usar el objeto contacto de correo para mostrar usuarios en la LGD. Este método integra una LGD sin proporcionar otros permisos, ya que los contactos de correo no son entidades de seguridad.

Siga este procedimiento recomendado para lograr el objetivo:

Un objeto contacto de correo no se puede convertir en un objeto de usuario. Por lo tanto, las propiedades asociadas a un objeto contacto de correo no pueden transferirse (como la pertenencia a grupos y otros accesos a recursos). El uso de un objeto contacto de correo para representar a un usuario conlleva las siguientes dificultades.

  • Grupos de Office 365. Los grupos de Office 365 admiten directivas que controlan los tipos de usuarios que pueden ser miembros de grupos e interactuar con el contenido asociado a ellos. Por ejemplo, puede que un grupo no permita que se unan usuarios invitados. Estas directivas no pueden controlar los objetos contacto de correo.
  • Administración de grupos de autoservicio (SSGM) en Microsoft Entra. Los objetos contacto de correo no pueden ser miembros de grupos que usen la característica SSGM. Es posible que se necesiten herramientas adicionales para administrar grupos con destinatarios representados como contactos en lugar de objetos de usuario.
  • Gobernanza de Microsoft Entra ID, revisiones de acceso. Puede usar la característica de revisiones de acceso para revisar y atestiguar la pertenencia al grupo de Office 365. Las revisiones de acceso se basan en objetos de usuario. Los miembros representados por objetos de contacto de correo están fuera del ámbito de las revisiones de acceso.
  • Gobernanza de Microsoft Entra ID, administración de derechos (EM). Cuando se usa la administración de derechos para habilitar las solicitudes de acceso de autoservicio para usuarios externos en el portal de administración de derechos de la empresa, se crea un objeto de usuario en el momento de la solicitud. No admite objetos contacto de correo.

Consideraciones sobre el acceso condicional de Microsoft Entra

El estado del usuario, el dispositivo o la red en el inquilino principal del usuario no se transmite al inquilino de recursos. Por tanto, es posible que una cuenta de usuario externo no cumpla las directivas de acceso condicional que utilizan los controles siguientes.

Si se permite, puede invalidar este comportamiento con la configuración del acceso entre inquilinos (CTAS) que respeta la autenticación multifactor y el cumplimiento de los dispositivos del inquilino principal.

  • Requerir autenticación multifactor. Si no se configura el acceso entre inquilinos (CTAS), los usuarios externos deben registrarse y responder a la autenticación multifactor en el inquilino de recursos (incluso aunque se haya satisfecho la autenticación multifactor en el inquilino principal). Este escenario da como resultado varios desafíos de autenticación multifactor. Si necesitan restablecer sus pruebas de autenticación multifactor, puede que no sean conscientes de los varios registros de pruebas de autenticación multifactor entre inquilinos. Este desconocimiento puede dar lugar a que el usuario deba ponerse en contacto con un administrador del inquilino principal, el inquilino de recursos o ambos.
  • Exigir que el dispositivo esté marcado como conforme. Si no se configura el acceso entre inquilinos, la identidad del dispositivo no se registra en el inquilino de recursos, por lo que el usuario externo no puede acceder a los recursos que requieren este control.
  • Requerir un dispositivo de unión híbrida a Microsoft Entra. Si no se configura el acceso entre inquilinos, la identidad del dispositivo no se registra en el inquilino de recursos (o en Active Directory local conectado al inquilino de recursos). Por lo tanto, el usuario externo no puede acceder a los recursos que requieren este control.
  • Requerir aplicaciones cliente aprobadas o una directiva de protección de aplicaciones. Si no se configura el acceso entre inquilinos (CTAS), los usuarios externos no pueden aplicar la directiva de administración de aplicaciones móviles (MAM) de Intune del inquilino de recursos, porque también requiere el registro del dispositivo. La directiva de acceso condicional del inquilino de recursos, que usa este control, no permite que la protección MAM del inquilino principal cumpla la directiva. Excluya a los usuarios externos de cada directiva de acceso condicional basada en MAM.

Además, aunque se pueden usar las siguientes condiciones de acceso condicional, debe tener en cuenta las posibles ramificaciones.

  • Riesgo de inicio de sesión y riesgo del usuario. El comportamiento del usuario en su inquilino principal determina, en parte, el riesgo de inicio de sesión y el riesgo del usuario. El inquilino principal almacena los datos y la puntuación de riesgo. Si las directivas del inquilino de recursos bloquean a un usuario externo, es posible que un administrador del inquilino de recursos no pueda habilitar el acceso. En Protección de id. de Microsoft Entra y usuarios de Colaboración B2B se explica cómo Protección de id. de Microsoft Entra detecta las credenciales en peligro de los usuarios de Microsoft Entra.
  • Ubicaciones. Las ubicaciones con nombre que se definen en el inquilino de recursos se usan para determinar el ámbito de la directiva. Las ubicaciones de confianza administradas en el inquilino principal no se evalúan en el ámbito de la directiva. Si la organización quiere compartir ubicaciones de confianza entre inquilinos, defina las ubicaciones de cada inquilino donde defina los recursos y las directivas de acceso condicional.

Protección del entorno multiinquilino

La protección de un entorno multiinquilino comienza al asegurarse de que cada inquilino cumple los procedimientos recomendados de seguridad. Revise la lista de comprobación de seguridad y los procedimientos recomendados para obtener instrucciones sobre cómo proteger el inquilino. Asegúrese de que se siguen estos procedimientos recomendados y de revisarlos con los inquilinos con los que colabora estrechamente.

Protección de cuentas de administrador y garantía de privilegios mínimos

Supervisión del entorno multiinquilino

  • Supervise los cambios en las directivas de acceso entre inquilinos mediante la interfaz de usuario de registros de auditoría, la API o la integración de Azure Monitor (para alertas proactivas). Los eventos de auditoría usan las categorías "CrossTenantAccessSettings" y "CrossTenantIdentitySyncSettings". Mediante la supervisión de eventos de auditoría en estas categorías, puede identificar cualquier cambio de directiva de acceso entre inquilinos en el inquilino y tomar medidas. Al crear alertas en Azure Monitor, puede crear una consulta como la siguiente para identificar los cambios de directiva de acceso entre inquilinos.
AuditLogs
| where Category contains "CrossTenant"
  • Supervise los nuevos asociados agregados a la configuración de acceso entre inquilinos.
AuditLogs
| where OperationName == "Add a partner to cross-tenant access setting"
| where parse_json(tostring(TargetResources[0].modifiedProperties))[0].displayName == "tenantId"
| extend initiating_user=parse_json(tostring(InitiatedBy.user)).userPrincipalName
| extend source_ip=parse_json(tostring(InitiatedBy.user)).ipAddress
| extend target_tenant=parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue
| project TimeGenerated, OperationName,initiating_user,source_ip, AADTenantId,target_tenant
| project-rename source_tenant= AADTenantId
  • Supervise los cambios en las directivas de acceso entre inquilinos, lo que permite o no permite la sincronización.
AuditLogs
| where OperationName == "Update a partner cross-tenant identity sync setting"
| extend a = tostring(TargetResources)
| where a contains "true"
| where parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue contains "true"
  • Supervise el acceso a la aplicación en el inquilino mediante el panel de actividad de acceso entre inquilinos. La supervisión le permite ver quién accede a los recursos del inquilino y de dónde proceden esos usuarios.

Grupos de pertenencia dinámica

Si la organización usa la condición de grupo de pertenencia dinámica Todos los usuarios en la directiva de acceso condicional, esta directiva afecta a los usuarios externos, porque están dentro del ámbito de Todos los usuarios.

Denegar de manera predeterminada

  • Requiera la asignación de usuarios para aplicaciones. Si una aplicación tiene la propiedad ¿Asignación de usuarios? establecida en No, los usuarios externos pueden acceder a la aplicación. Los administradores de aplicaciones deben conocer el impacto del control de acceso, especialmente si la aplicación contiene información confidencial. En Restricción de la aplicación de Microsoft Entra a un conjunto de usuarios de un inquilino de Microsoft Entra se explica cómo las aplicaciones registradas en un inquilino están disponibles para todos los usuarios del inquilino que se autentiquen correctamente. Esta configuración está activada de manera predeterminada.

Defensa en profundidad

Acceso condicional.

  • Defina directivas de control de acceso para controlar el acceso a los recursos.
  • Diseñe directivas de acceso condicional teniendo en cuenta a los usuarios externos.
  • Cree directivas específicamente para los usuarios externos.
  • Cree directivas de acceso condicional dedicadas para las cuentas externas. Si la organización usa la condición de grupo de pertenencia dinámica Todos los usuarios en la directiva de acceso condicional, esta directiva afecta a los usuarios externos, porque están dentro del ámbito de Todos los usuarios.

Unidades de administración restringidas

Cuando usa grupos de seguridad para controlar quién está en el ámbito de la sincronización entre inquilinos, querrá limitar quién puede realizar cambios en el grupo de seguridad. Minimice el número de propietarios de los grupos de seguridad asignados al trabajo de sincronización entre inquilinos e incluya los grupos en una unidad de administración restringida. Este escenario limita el número de usuarios que pueden agregar o quitar miembros del grupo y aprovisionar cuentas entre inquilinos.

Otras consideraciones sobre el control de acceso

Términos y condiciones

Términos de uso de Microsoft Entra ofrece un método sencillo que pueden usar las organizaciones para presentar información a los usuarios finales. Puede usar términos de uso para exigir a los usuarios externos que acepten los términos de uso antes de acceder a los recursos.

Consideraciones sobre las licencias para usuarios invitados con las características de Microsoft Entra ID P1 o P2

Los precios de Id. externa de Microsoft Entra se basan en los usuarios activos mensuales (MAU). El número de usuarios activos es la cantidad de usuarios únicos con actividad de autenticación en un mes natural. El modelo de facturación para Id. externa de Microsoft Entra describe cómo se basan los precios en MAU.

Consideraciones sobre Office 365

La siguiente información trata sobre Office 365 en el contexto de los escenarios de este documento. La información detallada está disponible en colaboración interinquilino de Microsoft 365. En este artículo se describen distintas opciones, como el uso de una ubicación central para archivos y conversaciones, el uso compartido de calendarios, el uso de mensajería instantánea, llamadas de audio y vídeo para la comunicación y la protección del acceso a recursos y aplicaciones.

Microsoft Exchange Online

Exchange Online limita determinadas funcionalidades para los usuarios externos. Puede crear usuarios miembros externos en lugar de usuarios invitados externos para reducir las limitaciones. La compatibilidad con usuarios externos tiene las siguientes limitaciones.

  • Puede asignar una licencia de Exchange Online a un usuario externo. Sin embargo, no puede emitirle un token para Exchange Online. Por lo tanto, no podrá acceder al recurso.
    • Los usuarios externos no pueden usar buzones de Exchange Online compartidos o delegados en el inquilino de recursos.
    • Puede asignar un buzón compartido a un usuario externo, pero este no podrá acceder a él.
  • Debe mostrar los usuarios externos para incluirlos en la LGD. De manera predeterminada, están ocultos.
    • Los usuarios externos ocultos se crean en el momento de la invitación. La creación es independiente de que el usuario haya canjeado la invitación o no. Por tanto, si todos los usuarios externos están ocultos, la lista incluye objetos de usuarios externos que no han canjeado una invitación. En función del escenario, puede querer que aparezcan o no los objetos.
    • Los usuarios externos se pueden mostrar mediante PowerShell de Exchange Online. Puede ejecutar el cmdlet Set-MailUser de PowerShell para establecer la propiedad HiddenFromAddressListsEnabled con el valor $false.

Por ejemplo:

Set-MailUser [ExternalUserUPN] -HiddenFromAddressListsEnabled:\$false\

Donde ExternalUserUPN es el valor calculado de UserPrincipalName.

Por ejemplo:

Set-MailUser externaluser1_contoso.com#EXT#@fabricam.onmicrosoft.com\ -HiddenFromAddressListsEnabled:\$false

Es posible que los usuarios externos no estén ocultos en el Centro de administración de Microsoft 365.

  • Las actualizaciones de propiedades específicas de Exchange, como PrimarySmtpAddress, ExternalEmailAddress, EmailAddresses y MailTip, solo pueden establecerse con PowerShell de Exchange Online. El Centro de administración de Exchange Online no permite modificar los atributos en la interfaz gráfica de usuario (GUI).

Como ya se ha indicado en el ejemplo, puede usar el cmdlet Set-MailUser de PowerShell para las propiedades específicas del correo. Puede modificar determinadas propiedades de usuario con el cmdlet Set-User de PowerShell. Puede modificar la mayoría de las propiedades con las API de Microsoft Graph.

Una de las características más útiles de Set-MailUser es la capacidad de manipular la propiedad EmailAddresses. Este atributo con varios valores puede contener distintas direcciones de proxy para el usuario externo (como SMTP, X500 y protocolo de inicio de sesión [SIP]). De manera predeterminada, un usuario externo tiene la dirección SMTP principal marcada en correlación con el UserPrincipalName (UPN). Si desea cambiar la dirección SMTP principal o agregar direcciones SMTP, puede establecer esta propiedad. No puede usar el Centro de admin. de Exchange; debe usar PowerShell de Exchange Online. En Agregar o quitar direcciones de correo electrónico para un buzón de Exchange Online se muestran las diferentes formas de modificar una propiedad con varios valores, como EmailAddresses.

Microsoft SharePoint en Microsoft 365

SharePoint en Microsoft 365 tiene sus propios permisos específicos del servicio en función de si el usuario (interno o externo) es del tipo miembro o invitado en el inquilino de Microsoft Entra. En Uso compartido externo de Microsoft 365 y Colaboración B2B de Microsoft Entra se describe cómo habilitar la integración con SharePoint y OneDrive para compartir archivos, carpetas, elementos de lista, bibliotecas de documentos y sitios con personas ajenas a la organización. Microsoft 365 lo hace al usar Azure B2B para la autenticación y administración.

Después de habilitar el uso compartido externo en SharePoint en Microsoft 365, la funcionalidad de búsqueda de usuarios invitados en el selector de personas de SharePoint en Microsoft 365 está desactivada de manera predeterminada. Esta configuración prohíbe que los usuarios invitados puedan detectarse cuando están ocultos en la lista LGD de Exchange Online. Puede hacer que los usuarios invitados estén visibles de dos maneras (que no son mutuamente excluyentes):

  • Puede habilitar la búsqueda de usuarios invitados de varias formas:
  • Los usuarios invitados que están visibles en la lista LGD de Exchange Online también están visibles en el selector de usuarios de SharePoint en Microsoft 365. Las cuentas están visibles independientemente de la configuración de ShowPeoplePickerSuggestionsForGuestUsers.

Microsoft Teams

Microsoft Teams tiene características para limitar el acceso en función del tipo de usuario. Los cambios en el tipo de usuario pueden afectar al acceso al contenido y a las características disponibles. Microsoft Teams exige que los usuarios cambien el contexto mediante el mecanismo de cambio de inquilino de su cliente de Teams cuando trabajen en esta plataforma fuera de su inquilino principal.

El mecanismo de cambio de inquilino de Microsoft Teams puede requerir que los usuarios cambien manualmente el contexto de su cliente de Teams cuando trabajen en esta plataforma fuera de su inquilino principal.

Puede permitir que usuarios de Teams de otro dominio externo completo busquen, llamen, chateen y configuren reuniones con sus usuarios mediante la característica de federación de Teams. En Administración de reuniones externas y chats con personas y organizaciones que usan identidades de Microsoft se describe cómo permitir que los usuarios de la organización chateen y se reúnan con personas ajenas a la organización que usan Microsoft como proveedor de identidades.

Consideraciones sobre las licencias para usuarios invitados en Teams

Cuando se usa Azure B2B con cargas de trabajo de Office 365, las consideraciones clave incluyen instancias en las que los usuarios invitados (internos o externos) no tienen la misma experiencia que los usuarios miembros.

  • Grupos de Microsoft. En Agregar invitados a Grupos de Microsoft 365 se describe cómo el acceso de invitado en los grupos de Microsoft 365 permite que tanto usted como su equipo colaboren con personas ajenas a la organización al concederles acceso a conversaciones de grupo, archivos, invitaciones de calendario y el bloc de notas del grupo.
  • Microsoft Teams. En Funcionalidades del propietario, miembro e invitado del equipo en Teams se describe la experiencia de la cuenta de invitado en Microsoft Teams. Puede habilitar una experiencia de fidelidad completa en Teams mediante usuarios miembros externos.
    • En el caso de varios inquilinos en nuestra nube comercial, los usuarios con licencia en su inquilino principal pueden acceder a los recursos de otro inquilino dentro de la misma entidad jurídica. Se puede conceder el acceso mediante la opción de miembros externos, sin honorarios de licencias adicionales. Esta configuración se aplica a SharePoint y OneDrive para Teams y grupos.
    • Para varios inquilinos en otras nubes de Microsoft y para varios inquilinos en nubes diferentes, las comprobaciones de licencia de miembro B2B aún no están disponibles. El uso del miembro B2B con Teams requiere una licencia adicional para cada miembro B2B. Este requisito también puede afectar a otras cargas de trabajo, como Power BI.
    • El uso de miembros B2B para inquilinos que no forman parte de la misma entidad jurídica están sujetos a requisitos de licencia adicionales.
  • Características de gobernanza de identidades. La administración de derechos y las revisiones de acceso pueden requerir otras licencias para los usuarios externos.
  • Otros productos. Otros productos, como la administración de las relaciones con el cliente (CRM) de Dynamics, pueden requerir licencias en todos los inquilinos donde esté representado un usuario.

Pasos siguientes

  • Introducción a la administración de usuarios multiinquilino es el primero de una serie de artículos que proporcionan instrucciones para configurar y proporcionar administración del ciclo de vida de los usuarios en entornos multiinquilino de Microsoft Entra.
  • Escenarios de administración de usuarios multiinquilino describe tres escenarios en los que se pueden usar las características de la administración de usuarios multiinquilino: iniciada por el usuario final, con scripts y automatizada.
  • Soluciones comunes para la administración de usuarios multiinquilino cuando el inquilino único no funciona en el escenario. En este artículo se proporcionan instrucciones para hacer frente a estos problemas: administración automática del ciclo de vida de los usuarios y asignación de recursos entre inquilinos, así como el uso compartido de aplicaciones locales entre inquilinos.
  • Microsoft Collaboration Framework for the US Defense Industrial Base describe arquitecturas de referencia candidatas para la identidad para dar cabida a organizaciones multiinquilino (MTO). Este escenario se aplica específicamente a las MTO que tienen una implementación en la nube soberana de EE. UU. con Microsoft 365 US Government (GCC High) y Azure Government. También aborda la colaboración externa en entornos altamente regulados, incluidas las organizaciones hospedadas en comercial o en la nube soberana de EE. UU.