Restricción del acceso a un inquilino

Las organizaciones de gran tamaño que hacen hincapié en la seguridad desean moverse a servicios en la nube como Microsoft 365, pero deben saber que sus usuarios solo podrán acceder a los recursos aprobados. Tradicionalmente, las empresas restringen los nombres de dominio o las direcciones IP cuando desean administrar el acceso. Este enfoque no sirve en un mundo donde las aplicaciones de software como servicio (o SaaS) se hospedan en una nube pública, ejecutándose en nombres de dominio compartidos como outlook.office.com y login.microsoftonline.com. El bloqueo de estas direcciones evitaría por completo que los usuarios accedieran a Outlook en la web, en lugar de simplemente limitarlos a identidades y recursos aprobados.

La solución de Microsoft Entra para este desafío es una característica denominada restricciones de inquilino. Con las restricciones de inquilino, las organizaciones pueden controlar el acceso a aplicaciones en la nube SaaS según el inquilino de Microsoft Entra que usan las aplicaciones para el inicio de sesión único. Por ejemplo, puede que te interese permitir el acceso a las aplicaciones de Microsoft 365 de tu organización y, al mismo tiempo, impedir el acceso a instancias de otras organizaciones de estas mismas aplicaciones.

Con las restricciones de inquilino, las organizaciones pueden especificar la lista de inquilinos a los que los usuarios de su red pueden acceder. Microsoft Entra ID solo concede acceso a estos inquilinos permitidos; todos los demás se bloquean, incluso aquellos a los que los usuarios pueden ser invitados.

Este artículo se centra en las restricciones de inquilino de Microsoft 365, pero la característica protege todas las aplicaciones que envían al usuario al inicio de sesión único de Microsoft Entra ID. Si usas aplicaciones SaaS con un inquilino de Microsoft Entra diferente al inquilino que usa Microsoft 365, asegúrese de que todos los inquilinos necesarios tengan permiso. (Por ejemplo, en escenarios de colaboración B2B). Para más información sobre aplicaciones en la nube SaaS, consulte Active Directory Marketplace.

La característica de restricciones de inquilino también permite bloquear el uso de todas las aplicaciones de consumidor de Microsoft (aplicaciones MSA), como OneDrive, Hotmail y Xbox.com. Esta funcionalidad usa un encabezado distinto para el punto de conexión login.live.com y se detalla al final de este artículo.

Funcionamiento

La solución general consta de los siguientes componentes:

1. Microsoft Entra ID: si el encabezado Restrict-Access-To-Tenants: <permitted tenant list> está presente, Microsoft Entra solo emite tokens de seguridad para los inquilinos permitidos.

2. Infraestructura de servidor proxy local: Esta infraestructura es un dispositivo proxy compatible con la inspección de Seguridad de la capa de transporte (TLS). Debe configurar el proxy para insertar el encabezado que contiene la lista de inquilinos permitidos en el tráfico destinado a Microsoft Entra ID.

3. Software cliente: para admitir restricciones de inquilino, el software de cliente debe solicitar tokens directamente de Microsoft Entra ID, de forma que la infraestructura del proxy pueda interceptar el tráfico. Actualmente, las aplicaciones de Microsoft 365 basadas en explorador admiten las restricciones de inquilino, así como los clientes de Office que usan la autenticación moderna (como OAuth 2.0).

4. Autenticación moderna: los servicios en la nube deben usar la autenticación moderna para utilizar restricciones de inquilino y bloquear el acceso a todos los inquilinos no permitidos. Debe configurar los servicios en la nube de Microsoft 365 para usar protocolos de autenticación modernos de manera predeterminada. Para ver la información más reciente sobre la compatibilidad con Microsoft 365 para la autenticación moderna, consulte Autenticación moderna actualizada de Office 365.

En el siguiente diagrama se ilustra el flujo de tráfico de alto nivel. Las restricciones de inquilino solo requieren la inspección TLS en el tráfico hacia Microsoft Entra ID, no hacia los servicios en la nube de Microsoft 365. Esta distinción es importante porque el volumen de tráfico de autenticación hacia Microsoft Entra ID es normalmente mucho menor que el volumen de tráfico hacia aplicaciones SaaS como Exchange Online y SharePoint Online.

Configuración de restricciones de inquilino

Se deben realizar dos pasos para empezar a trabajar con restricciones de inquilino. En primer lugar, debe asegurarse de que los clientes pueden conectarse a las direcciones correctas. En segundo lugar, configure la infraestructura del proxy.

Direcciones URL e IP reservadas

Para usar restricciones de inquilino, los clientes deben poder conectarse a las siguientes direcciones URL de Microsoft Entra para autenticarse:

• login.microsoftonline.com
• login.microsoft.com
• login.windows.net

Además, para acceder a Office 365, los clientes también deben ser capaces de conectarse a los nombre de dominio completo (FQDN), las direcciones URL y las direcciones IP que se definen en URL de Office 365 e intervalos de direcciones IP.

Requisitos y configuración de proxy

Se necesita la configuración siguiente para habilitar restricciones de inquilino a través de la infraestructura del proxy. Esta guía es genérica, por lo que debe remitirse a la documentación del proveedor del proxy para conocer los pasos de implementación específicos.

Requisitos previos

• El proxy debe ser capaz de realizar la intercepción de TLS y la inserción de encabezados HTTP, así como de filtrar destinos mediante direcciones URL o FQDN.

• Los clientes deben confiar en la cadena de certificados que presenta el proxy para las comunicaciones TLS. Por ejemplo, si se usan certificados de una infraestructura de clave pública (PKI) interna, el certificado de la entidad de certificación raíz emisora interna debe ser de confianza.

• Las licencias P1 o P2 de Microsoft Entra ID son necesarias para el uso de restricciones de inquilino.

Configuración

En cada solicitud saliente hacia login.microsoftonline.com, login.microsoft.com y login.windows.net, inserte dos encabezados HTTP: Restrict-Access-To-Tenants y Restrict-Access-Context.

Nota:

No incluya subdominios en *.login.microsoftonline.com en la configuración de proxy. Si lo hace, incluirá device.login.microsoftonline.com, que interferirá con la autenticación de certificados de cliente que se usa en los escenarios de registro de dispositivos y acceso condicional basado en dispositivos. Configure el servidor proxy para que excluya device.login.microsoftonline.com y enterpriseregistration.windows.net de la inyección de encabezados y la interrupción e inspección de TLS.

Los encabezados deben incluir los siguientes elementos:

• Para Restrict-Access-To-Tenants (Restringir acceso para inquilinos), use un valor de <permitted tenant list> (lista de inquilinos permitidos), que es una lista separada por comas de los inquilinos a los que quiere que los usuarios puedan tener acceso. Se puede utilizar cualquier dominio que esté registrado en un inquilino para identificar al inquilino en esta lista y el identificador de directorio mismo. Para ver un ejemplo de las tres formas de describir un inquilino, el par de nombre-valor para permitir Contoso, Fabrikam y Microsoft tiene el siguiente aspecto: Restrict-Access-To-Tenants: contoso.com,fabrikam.onmicrosoft.com,aaaabbbb-0000-cccc-1111-dddd2222eeee

• Para Restrict-Access-Context (Contexto para restringir acceso), use un valor de un identificador de directorio único que declare qué inquilino está estableciendo restricciones de inquilino. Por ejemplo, para declarar Contoso como el inquilino que establece la directiva de restricciones de inquilino, el par nombre-valor puede ser algo así como: Restrict-Access-Context: bbbbcccc-1111-dddd-2222-eeee3333ffff. Aquí debe usar su propio identificador de directorio para obtener registros de estas autenticaciones. Si usas cualquier identificador de directorio que no sea el tuyo propio, los registros de inicio de sesión aparecerán en el inquilino de otra persona y se quitará toda la información personal. Para más información, consulte Experiencia del administrador.

Para buscar el identificador de directorio:

1. Inicie sesión en el Centro de administración de Microsoft Entrar al menos comoGlobal Reader.
2. Vaya a Información general de la>Identidad>Información general.
3. Copie el valor del Id. de inquilino.

Para validar que un id. de directorio o un nombre de dominio hagan referencia al mismo inquilino, use ese id. o dominio en lugar de <tenant> en esta dirección URL: https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration. Si los resultados con el dominio y el identificador son los mismos, hacen referencia al mismo inquilino.

Para evitar que los usuarios inserten su propio encabezado HTTP con inquilinos no aprobados, el proxy debe reemplazar el encabezado Restrict-Access-To-Tenants si ya está presente en la solicitud entrante.

Se tiene que forzar a los clientes para que usen el proxy para todas las solicitudes a login.microsoftonline.com, login.microsoft.com y login.windows.net. Por ejemplo, si los archivos PAC se emplean para indicar a los clientes que usen el proxy, los usuarios finales no deben poder editar ni deshabilitar los archivos PAC.

La experiencia del usuario final

En esta sección se describe la experiencia de los usuarios finales y los administradores.

Experiencia del usuario final

Un usuario de ejemplo se encuentra en la red de Contoso, pero está intentando acceder a la instancia de Fabrikam de una aplicación SaaS compartida como Outlook en línea. Si Fabrikam es un inquilino no permitido de la instancia de Contoso, el usuario ve un mensaje de denegación de acceso. El mensaje de denegación de acceso indica que estás intentando obtener acceso a un recurso que pertenece a una organización no aprobada por el departamento de TI.

Experiencia de administrador

Mientras la configuración de restricciones de inquilino se realice en la infraestructura del proxy corporativo, los administradores podrán tener acceso a los informes de restricciones de inquilino directamente en centro de administración de Microsoft Entra. Para ver los informes:

1. Inicie sesión en el Centro de administración de Microsoft Entrar al menos comoGlobal Reader.
2. Vaya a Identidad>información general>restricciones de inquilino.

El administrador del inquilino especificado como inquilino Restricted-Access-Context puede usar este informe para ver todos los inicios de sesión bloqueados debido a la directiva de restricciones de inquilino, incluida la identidad que se usa y el identificador de directorio de destino. Los inicios de sesión se incluyen si el inquilino que establece la restricción es el inquilino del usuario o el inquilino del recurso para el inicio de sesión.

El informe puede contener información limitada, como el identificador del directorio de destino, cuando un usuario que está en un inquilino distinto del inquilino Restricted-Access-Context inicia sesión. En este caso, la información de identificación del usuario, como el nombre y el nombre principal de usuario, se enmascara para proteger los datos de usuario de otros inquilinos (por ejemplo, "{PII Removed}@domain.com" or 00000000-0000-0000-0000-000000000000 en lugar de los nombres de usuario y los identificadores de objeto, según corresponda).

Al igual que otros informes en centro de administración de Microsoft Entra, puede usar filtros para especificar el ámbito del informe. Puede filtrar por un usuario, una aplicación, un cliente, un estado o un intervalo de tiempo específico. Si selecciona el botón Columnas, puede elegir mostrar los datos con cualquier combinación de los siguientes campos:

• Usuario: este campo puede tener los datos personales quitados, donde su valor se establece en 00000000-0000-0000-0000-000000000000.
• Aplicación
• Estado
• Date
• Fecha (UTC) : donde UTC es la hora universal coordinada.
• Dirección IP
• Cliente
• Nombre de usuario: este campo puede tener los datos personales quitados, donde su valor se establece en {PII Removed}@domain.com
• Ubicación
• Identificador de inquilino de destino

Soporte técnico de Microsoft 365

Las aplicaciones de Microsoft 365 deben cumplir dos criterios para que sean totalmente compatibles con las restricciones de inquilino:

1. El cliente utilizado admite la autenticación moderna.
2. La autenticación moderna está habilitada como el protocolo de autenticación predeterminado para el servicio en la nube.

Para ver la información más reciente sobre qué clientes de Office admiten actualmente la autenticación moderna, consulte Autenticación moderna actualizada de Office 365. Esa página también incluye vínculos a instrucciones para habilitar la autenticación moderna en inquilinos específicos de Exchange Online y Skype Empresarial Online. SharePoint Online ya habilita la autenticación moderna de manera predeterminada. Teams solo admite la autenticación moderna y no admite la autenticación heredada, por lo que este problema de omisión no se aplica a Teams.

Actualmente, las aplicaciones de Microsoft 365 basadas en explorador (como el portal de Office, Yammer, los sitios de SharePoint y Outlook en la web) son compatibles con las restricciones de inquilino. Los clientes pesados (Outlook, Skype Empresarial, Word, Excel, PowerPoint, etc.) pueden exigir restricciones de inquilino solo cuando se usa la autenticación moderna.

Es posible que los clientes de Outlook y Skype Empresarial que admiten la autenticación moderna puedan seguir usando protocolos heredados en inquilinos donde la autenticación moderna no está habilitada, lo que evita eficazmente restricciones de inquilino. Es posible que las restricciones de inquilino bloqueen las aplicaciones que usan protocolos heredados si se ponen en contacto con login.microsoftonline.com, login.microsoft.com o login.windows.net durante la autenticación.

Para Outlook en Windows, los clientes pueden optar por implementar restricciones que impidan a los usuarios finales agregar cuentas de correo no aprobadas a sus perfiles. Por ejemplo, ve el establecimiento de directiva de grupo Impedir la incorporación de cuentas de Exchange no predeterminadas.

Incompatibilidad de Azure RMS y el cifrado de mensajes de Office

Las características Azure Rights Management Service (Azure RMS) y Cifrado de mensajes de Office no son compatibles con las restricciones de inquilino. Estas características se basan en la firma de los usuarios en otros inquilinos para obtener las claves de descifrado de los documentos cifrados. Dado que las restricciones de inquilino bloquean el acceso a otros inquilinos, no se puede acceder al correo y los documentos cifrados enviados a los usuarios desde inquilinos que no son de confianza.

Prueba

Si quiere probar la característica de restricciones de inquilino antes de implementarla para toda la organización, tiene dos opciones: un enfoque basado en host mediante una herramienta como Fiddler o un lanzamiento por fases de configuración de proxy.

Fiddler para un enfoque basado en host

Fiddler es un proxy de depuración web gratis que puede usarse para capturar y modificar el tráfico HTTP/HTTPS que incluye la inserción de encabezados HTTP. Para configurar Fiddler para probar las restricciones de inquilino, realice los pasos siguientes:

1. Descargue e instale Fiddler.

2. Configure Fiddler para descifrar el tráfico HTTPS siguiendo las indicaciones de la documentación de la ayuda de Fiddler.

3. Configure Fiddler para insertar los encabezados Restrict-Access-To-Tenants y Restrict-Access-Context utilizando reglas personalizadas:

   1. En la herramienta Fiddler Web Debugger, seleccione el menú Rules (Reglas) y luego Customize Rules… (Personalizar reglas...) para abrir el archivo CustomRules.

   2. Agregue las siguientes líneas dentro de la función.de lenguaje OnBeforeRequest. Reemplace <List of tenant identifiers> por un dominio registrado con el inquilino (por ejemplo, contoso.onmicrosoft.com). Reemplace <Id. de directorio> por el identificador GUID de Microsoft Entra del inquilino. Debe incluir el identificador GUID correcto para que los registros aparezcan en el inquilino.

    // Allows access to the listed tenants.
      if (
          oSession.HostnameIs("login.microsoftonline.com") ||
          oSession.HostnameIs("login.microsoft.com") ||
          oSession.HostnameIs("login.windows.net")
      )
      {
          oSession.oRequest["Restrict-Access-To-Tenants"] = "<List of tenant identifiers>";
          oSession.oRequest["Restrict-Access-Context"] = "<Your directory ID>";
      }
   
    // Blocks access to consumer apps
      if (
          oSession.HostnameIs("login.live.com")
      )
      {
          oSession.oRequest["sec-Restrict-Tenant-Access-Policy"] = "restrict-msa";
      }
   

   Si necesita permitir varios inquilinos, use una coma para separar los nombres de los mismos. Por ejemplo:

   oSession.oRequest["Restrict-Access-To-Tenants"] = "contoso.onmicrosoft.com,fabrikam.onmicrosoft.com";

4. Guarde y cierre el archivo CustomRules.

Después de configurar Fiddler, podrá capturar el tráfico yendo al menú File (Archivo) y seleccionando Capture Traffic (Capturar tráfico).

Lanzamiento por fases de configuración de proxy

Dependiendo de las funcionalidades de la infraestructura del proxy, es posible que puedas llevar a cabo el lanzamiento de la configuración a los usuarios. Consulte las siguientes opciones generales para tener en cuenta:

1. Usar archivos PAC para dirigir a los usuarios de prueba a una infraestructura del proxy de prueba, mientras que los usuarios convencionales siguen usando la infraestructura del proxy de producción.
2. Algunos servidores proxy pueden admitir distintas configuraciones mediante grupos.

Para obtener detalles específicos, consulte la documentación del servidor proxy.

Bloqueo de aplicaciones de consumidor

Las aplicaciones de Microsoft que admiten cuentas tanto de consumidor como de la organización, como OneDrive, a veces se pueden hospedar en la misma dirección URL. Esto significa que los usuarios que tienen que acceder a esa dirección URL en el trabajo también tienen acceso a ella para uso personal. Es posible que esta opción no se permita en las directrices de funcionamiento.

Para solucionar este error, algunas organizaciones bloquean login.live.com para impedir que las cuentas personales se autentiquen. Esta solución presenta una serie de inconvenientes:

1. El bloqueo de login.live.com impide el uso de cuentas personales en escenarios de invitados B2B, lo que puede interponerse con los visitantes y la colaboración.
2. Autopilot requiere el uso de login.live.com para implementarse. Los escenarios de Intune y Autopilot pueden producir errores cuando se bloquea login.live.com.
3. La telemetría de la organización y las actualizaciones de Windows en las que los identificadores de dispositivo dependen del servicio login.live.com dejan de funcionar.

Configuración para aplicaciones de consumidor

Aunque el encabezado Restrict-Access-To-Tenants funciona como una lista de permitidos, el bloqueo de la cuenta Microsoft (MSA) funciona como una señal de denegación, que indica a la plataforma de cuentas Microsoft que no permita a los usuarios iniciar sesión en las aplicaciones de consumidor. Para enviar esta señal, el encabezado sec-Restrict-Tenant-Access-Policy se inserta en el tráfico que visita login.live.com mediante el mismo proxy corporativo o firewall que se mencionó en la sección configuración y requisitos del proxy de este artículo. El valor del encabezado debe ser restrict-msa. Cuando existe el encabezado y una aplicación de consumidor intenta iniciar la sesión de un usuario directamente, ese inicio de sesión se bloquea.

En este momento, la autenticación en las aplicaciones de consumidor no aparece en los registros de administración, ya que login.live.com se hospeda de forma independiente de Microsoft Entra ID.

Qué bloquea y no bloquea el encabezado

La directiva restrict-msa bloquea el uso de las aplicaciones de consumidor, pero lo permite a través de otros tipos de tráfico y autenticación:

1. Tráfico sin usuario en dispositivos. Esta opción incluye el tráfico de Autopilot, Windows Update y la telemetría de la organización.
2. Autenticación B2B de cuentas de consumidor. Los usuarios con cuentas Microsoft que están invitados a colaborar con un inquilino se autentican en login.live.com para tener acceso a un inquilino de recursos.
   1. Este acceso se controla mediante el encabezado Restrict-Access-To-Tenants para permitir o denegar el acceso a ese inquilino de recursos.
3. La autenticación "transferida", que usan muchas aplicaciones de Azure y Office.com, donde las aplicaciones emplean Microsoft Entra ID para iniciar la sesión de los usuarios consumidores en un contexto de consumidor.
   1. Este acceso también se controla mediante el encabezado Restrict-Access-To-Tenants para permitir o denegar el acceso al inquilino "de paso a través" especial (f8cdef31-a31e-4b4a-93e4-5f571e91255a). Si este inquilino no aparece en tu lista Restrict-Access-To-Tenants de dominios permitidos, Microsoft Entra ID impide a las cuentas de consumidor iniciar sesión en estas aplicaciones.

Plataformas que no admiten la interrupción e inspección de TLS

Las restricciones de inquilino dependen de la inserción de una lista de inquilinos permitidos en el encabezado HTTPS. Esta dependencia requiere inspección de seguridad de la capa de transporte (TLSI) para interrumpir e inspeccionar el tráfico. En los entornos en los que el lado del cliente no puede interrumpir e inspeccionar el tráfico para agregar encabezados, las restricciones de inquilino no funcionan.

Tome el ejemplo de Android 7.0 y las versiones posteriores. Android cambió la forma en que controla las entidades de certificación (CA) de confianza para proporcionar valores predeterminados más seguros para el tráfico seguro de aplicaciones. Para más información, consulte Cambios en entidades de certificación de confianza en Android Nougat.

Siguiendo la recomendación de Google, las aplicaciones cliente de Microsoft omiten los certificados de usuario de forma predeterminada. Esta directiva hace que estas aplicaciones no puedan trabajar con restricciones de inquilino, ya que los certificados usados por el proxy de red se instalan en el almacén de certificados de usuario, que las aplicaciones cliente no confían.

Para los entornos que no puedan interrumpir e inspeccionar el tráfico para agregar los parámetros de restricción de inquilino al encabezado, otras características de Microsoft Entra ID pueden proporcionar protección. En la lista siguiente se proporciona más información sobre estas características de Microsoft Entra.

• Acceso condicional: permitir solo el uso de dispositivos administrados o compatibles
• Acceso condicional: administrar el acceso para usuarios invitados o externos
• Colaboración B2B: restringir las reglas de salida por acceso entre inquilinos para los mismos inquilinos enumerados en el parámetro "Restrict-Access-To-Tenants"
• Colaboración B2B: restringir invitaciones a usuarios B2B a los mismos dominios enumerados en el parámetro "Restrict-Access-To-Tenants"
• Administración de aplicaciones: restricción de cómo los usuarios dan su consentimiento a las aplicaciones
• Intune: aplique la directiva de aplicaciones a través de Intune para restringir el uso de aplicaciones administradas únicamente al UPN de la cuenta que inscribió el dispositivo: consulte la sección del subencabezado Permitir solo las cuentas de organización configuradas en las aplicaciones.

Sin embargo, algunos escenarios específicos solo se pueden tratar mediante restricciones de inquilino.

Pasos siguientes

• Lea Updated Office 365 modern authentication (Autenticación moderna actualizada de Office 365)
• Revise URL de Office 365 e intervalos de direcciones IP