Compartir vía


Limitaciones conocidas del acceso seguro global

Global Secure Access es el término unificante que se usa para Microsoft Entra Internet Access y Microsoft Entra Private Access.

En este artículo se detallan los problemas conocidos y las limitaciones que puede encontrar al usar el acceso seguro global.

Limitaciones del cliente de Acceso seguro global

El cliente de Acceso seguro global está disponible en varias plataformas. Seleccione cada pestaña para obtener más información sobre las limitaciones conocidas de cada plataforma.

  • cliente de Windows
  • de cliente macOS
  • de cliente Android
  • de cliente iOS

Entre las limitaciones conocidas del cliente de acceso seguro global para Windows se incluyen las siguientes:

Sistema de nombres de dominio seguro (DNS)

El cliente de acceso seguro global no admite actualmente DNS seguro en sus distintas versiones, como DNS a través de HTTPS (DoH), DNS a través de TLS (DoT) o Extensiones de seguridad DNS (DNSSEC). Para configurar el cliente para que pueda adquirir tráfico de red, debe deshabilitar DNS seguro. Para deshabilitar DNS en el explorador, consulte DNS seguro deshabilitado en exploradores.

DNS a través de TCP

DNS usa el puerto 53 UDP para la resolución de nombres. Algunos exploradores tienen su propio cliente DNS que también admite el puerto 53 TCP. Actualmente, el cliente de acceso seguro global no admite el puerto DNS 53 TCP. Como mitigación, deshabilite el cliente DNS del explorador estableciendo los siguientes valores del Registro:

  • Microsoft Edge
    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge] "BuiltInDnsClientEnabled"=dword:00000000
  • Cromo
    [HKEY_CURRENT_USER\Software\Policies\Google\Chrome] "BuiltInDnsClientEnabled"=dword:00000000
    Agregue también chrome://flags de exploración y deshabilite Async DNS resolver.

No se admiten las reglas de tabla de directivas de resolución de nombres en la directiva de grupo

El cliente de acceso seguro global para Windows no admite reglas de tabla de directivas de resolución de nombres (NRPT) en la directiva de grupo. Para admitir DNS privado, el cliente configura reglas NRPT locales en el dispositivo. Estas reglas redirigen las consultas DNS pertinentes al DNS privado. Si las reglas NRPT están configuradas en la directiva de grupo, invalidan las reglas NRPT locales configuradas por el cliente y el DNS privado no funcionan.

Además, las reglas NRPT que se configuraron y eliminaron en versiones anteriores de Windows crearon una lista vacía de reglas NRPT en el archivo registry.pol. Si este objeto de directiva de grupo (GPO) se aplica en el dispositivo, la lista vacía invalida las reglas NRPT locales y el DNS privado no funciona.

Como mitigación:

  1. Si la clave del Registro HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig existe en el dispositivo del usuario final, configure un GPO para aplicar reglas de NRPT.
  2. Para buscar qué GPO están configurados con reglas de NRPT:
    1. Ejecute gpresult /h GPReport.html en el dispositivo del usuario final y busque una configuración de NRPT.
    2. Ejecute el siguiente script que detecte las rutas de acceso de todos los archivos de registry.pol en sysvol que contienen reglas de NRPT.

Nota

Recuerde cambiar la variable sysvolPath para cumplir la configuración de la red.

# =========================================================================
# THIS CODE-SAMPLE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER 
# EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES 
# OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
#
# This sample is not supported under any Microsoft standard support program 
# or service. The code sample is provided AS IS without warranty of any kind. 
# Microsoft further disclaims all implied warranties including, without 
# limitation, any implied warranties of merchantability or of fitness for a 
# particular purpose. The entire risk arising out of the use or performance
# of the sample and documentation remains with you. In no event shall 
# Microsoft, its authors, or anyone else involved in the creation, 
# production, or delivery of the script be liable for any damages whatsoever 
# (including, without limitation, damages for loss of business profits, 
# business interruption, loss of business information, or other pecuniary 
# loss) arising out of  the use of or inability to use the sample or 
# documentation, even if Microsoft has been advised of the possibility of 
# such damages.
#========================================================================= 

# Define the sysvol share path.
# Change the sysvol path per your organization, for example: 
# $sysvolPath = "\\dc1.contoso.com\sysvol\contoso.com\Policies"
$sysvolPath = "\\<DC FQDN>\sysvol\<domain FQDN>\Policies"  ## Edit

# Define the search string.
$searchString = "dnspolicyconfig"

# Define the name of the file to search.
$fileName = "registry.pol"

# Get all the registry.pol files under the sysvol share.
$files = Get-ChildItem -Path $sysvolPath -Recurse -Filter $fileName -File

# Array to store paths of files that contain the search string.
$matchingFiles = @()

# Loop through each file and check if it contains the search string.
foreach ($file in $files) {
    try {
        # Read the content of the file.
        $content = Get-Content -Path $file.FullName -Encoding Unicode
        
        # Check if the content contains the search string.
        if ($content -like "*$searchString*") {
            $matchingFiles += $file.FullName
        }
    } catch {
        Write-Host "Failed to read file $($file.FullName): $_"
    }
}

# Output the matching file paths.
if ($matchingFiles.Count -eq 0) {
    Write-Host "No files containing '$searchString' were found."
} else {
    Write-Host "Files containing '$searchString':"
    $matchingFiles | ForEach-Object { Write-Host $_ }
}

  1. Edite cada uno de los GPO encontrados en la sección anterior:
    1. Si la sección NRPT está vacía, cree una nueva regla ficticia, actualice la directiva, elimine la regla ficticia y vuelva a actualizar la directiva. Estos pasos quitan el DnsPolicyConfig del archivo registry.pol (que se creó en una versión heredada de Windows).
    2. Si la sección NRPT no está vacía y contiene reglas, confirme que todavía necesita estas reglas. Si no necesita las reglas, elimínelas. Si necesita las reglas y aplica el GPO en un dispositivo con el cliente de acceso seguro global, la opción DNS privada no funciona. Captura de pantalla del cuadro de diálogo Reglas de directiva de resolución de nombres con los botones Crear y Aplicar resaltados.

Reserva de conexión

Si se produce un error de conexión al servicio en la nube, el cliente vuelve a la conexión directa a Internet o bloquea la conexión, en función del protección valor de la regla de coincidencia en el perfil de reenvío.

Geolocalización

Para el tráfico de red que se tuneliza al servicio en la nube, el servidor de aplicaciones (sitio web) detecta la dirección IP de origen de la conexión como la dirección IP del perímetro (y no como la dirección IP del dispositivo de usuario). Este escenario podría afectar a los servicios que dependen de la geolocalización.

Propina

Para que Microsoft 365 y Microsoft Entra detecten la dirección IP de origen verdadera del dispositivo, considere la posibilidad de habilitar restauración de ip de origen.

Compatibilidad con la virtualización

No se puede instalar el cliente de acceso seguro global en un dispositivo que hospeda máquinas virtuales. Sin embargo, puede instalar el cliente de acceso seguro global en una máquina virtual, siempre y cuando el cliente no esté instalado en la máquina host. Por el mismo motivo, un subsistema de Windows para Linux (WSL) no adquiere tráfico de un cliente instalado en el equipo host.

Hyper-V soporte técnico:

  1. Conmutador virtual externo: el cliente de Windows de acceso seguro global no admite actualmente máquinas host que tengan un conmutador virtual externo Hyper-V. Sin embargo, el cliente se puede instalar en las máquinas virtuales para tunelizar el tráfico al acceso seguro global.
  2. Conmutador virtual interno: el cliente de Windows de acceso seguro global se puede instalar en máquinas invitadas y host. El cliente solo tuneliza el tráfico de red de la máquina en la que está instalado. Es decir, un cliente instalado en un equipo host no tunelizar el tráfico de red de las máquinas invitadas.

El cliente de Windows de acceso seguro global admite Azure Virtual Machines y Azure Virtual Desktop (AVD).

Nota

El cliente de Windows de Acceso seguro global no admite varias sesiones de AVD.

Proxy

Si un proxy está configurado en el nivel de aplicación (por ejemplo, un explorador) o en el nivel del sistema operativo, configure un archivo de configuración automática de proxy (PAC) para excluir todos los FQDN e direcciones IP que espera que el cliente tunele.

Para evitar que las solicitudes HTTP de FQDN o direcciones IP específicas tunelizarán al proxy, agregue los FQDN/IP al archivo PAC como excepciones. (Estos FQDNs/DIRECCIONES IP se encuentran en el perfil de reenvío del acceso seguro global para la tunelización). Por ejemplo:

function FindProxyForURL(url, host) {   
        if (isPlainHostName(host) ||   
            dnsDomainIs(host, ".microsoft.com") || // tunneled 
            dnsDomainIs(host, ".msn.com")) // tunneled 
           return "DIRECT";                    // If true, sets "DIRECT" connection 
        else                                   // If not true... 
           return "PROXY 10.1.0.10:8080";  // forward the connection to the proxy
}

Si no es posible una conexión directa a Internet, configure el cliente para conectarse al servicio acceso seguro global a través de un proxy. Por ejemplo, establezca la variable del sistema grpc_proxy para que coincida con el valor del proxy, como http://proxy:8080.

Para aplicar los cambios de configuración, reinicie los servicios de Windows del cliente de Acceso seguro global.

Inyección de paquetes

El cliente solo tuneliza el tráfico enviado mediante sockets. No tunelizar el tráfico insertado en la pila de red mediante un controlador (por ejemplo, parte del tráfico generado por el asignador de red (Nmap)). Los paquetes insertados van directamente a la red.

Multisesión

El cliente de Acceso seguro global no admite sesiones simultáneas en la misma máquina. Esta limitación se aplica a los servidores de Protocolo de Escritorio remoto (RDP) y a las soluciones de infraestructura de escritorio virtual (VDI), como Azure Virtual Desktop (AVD) que están configurados para varias sesiones.

Arm64

El cliente de Acceso seguro global no admite la arquitectura arm64.

QUIC no se admite para el acceso a Internet

Dado que QUIC aún no se admite para el acceso a Internet, no se puede tunelizar el tráfico a los puertos 80 UDP y 443 UDP.

Propina

QUIC se admite actualmente en cargas de trabajo de Acceso privado y Microsoft 365.

Los administradores pueden deshabilitar el protocolo QUIC que desencadena clientes para revertir a HTTPS a través de TCP, que es totalmente compatible con el acceso a Internet. Para obtener más información, vea QUIC no compatible con Internet Access.

Conectividad de WSL 2

Cuando el cliente de acceso seguro global para Windows está habilitado en el equipo host, es posible que se bloqueen las conexiones salientes del entorno subsistema de Windows para Linux (WSL) 2. Para mitigar esta aparición, cree un archivo de .wslconfig que establezca dnsTunneling en false. De este modo, todo el tráfico de WSL omite el acceso seguro global y va directamente a la red. Para obtener más información, consulte Configuración avanzada en WSL.

Limitaciones de redes remotas

Entre las limitaciones conocidas de las redes remotas se incluyen las siguientes:

  • El número máximo de redes remotas por inquilino es 10. El número máximo de vínculos de dispositivo por red remota es cuatro.
  • Se accede al tráfico de Microsoft a través de la conectividad de red remota sin el cliente de acceso seguro global. Sin embargo, no se aplica la directiva de acceso condicional. En otras palabras, las directivas de acceso condicional para el tráfico global de Microsoft de acceso seguro solo se aplican cuando un usuario tiene el cliente de acceso seguro global.
  • Debe usar el cliente de Acceso seguro global para Microsoft Entra Private Access. La conectividad de red remota solo admite Microsoft Entra Internet Access.
  • En este momento, las redes remotas solo se pueden asignar al perfil de reenvío de tráfico de Microsoft.

Limitaciones de los controles de acceso

Entre las limitaciones conocidas de los controles de acceso se incluyen:

  • La evaluación continua del acceso (CAE) no se admite actualmente para el acceso condicional universal para el tráfico de Microsoft.
  • Actualmente no se admite la aplicación de directivas de acceso condicional al tráfico de acceso privado. Para modelar este comportamiento, puede aplicar una directiva de acceso condicional en el nivel de aplicación para aplicaciones de acceso rápido y acceso seguro global. Para obtener más información, consulte Aplicar acceso condicional a aplicaciones de acceso privado.
  • Se puede acceder al tráfico de Microsoft a través de la conectividad de red remota sin el cliente de acceso seguro global; sin embargo, no se aplica la directiva de acceso condicional. Es decir, las directivas de acceso condicional para el tráfico global de Microsoft de acceso seguro solo se aplican cuando un usuario tiene el cliente de acceso seguro global.
  • Se admite la aplicación del plano de datos de comprobación de red compatible (versión preliminar) con evaluación continua de acceso para SharePoint Online y Exchange Online.
  • Al habilitar la señalización de acceso condicional de acceso seguro global, se habilita la señalización para el plano de autenticación (Id. de Microsoft Entra) y la señalización del plano de datos (versión preliminar). Actualmente no es posible habilitar esta configuración por separado.
  • Actualmente, no se admite la comprobación de red compatible con las aplicaciones de acceso privado.
  • Cuando la restauración de ip de origen está habilitada, solo puede ver la dirección IP de origen. La dirección IP del servicio Acceso seguro global no está visible. Si desea ver la dirección IP del servicio acceso seguro global, deshabilite la restauración de ip de origen.
  • Actualmente, solo recursos de Microsoft evaluar las directivas de acceso condicional basadas en la ubicación IP, ya que la dirección IP de origen original no se conoce como recursos que no son de Microsoft protegidos por la evaluación continua de acceso (CAE).
  • Si usa la estricta aplicación de ubicación de CAE, los usuarios se bloquean a pesar de estar en un intervalo IP de confianza. Para resolver esta condición, realice una de las siguientes recomendaciones:
    • Si tiene directivas de acceso condicional basadas en ubicación IP destinadas a recursos que no son de Microsoft, no habilite la aplicación estricta de la ubicación.
    • Asegúrese de que la restauración de IP de origen admite el tráfico. Si no es así, no envíe el tráfico pertinente a través del acceso seguro global.
  • En este momento, es necesario conectarse a través del cliente de acceso seguro global para adquirir tráfico de acceso privado.
  • Las funcionalidades de protección del plano de datos están en versión preliminar (la protección del plano de autenticación está disponible con carácter general).
  • Si ha habilitado restricciones de inquilino universal y tiene acceso al Centro de administración de Microsoft Entra para un inquilino en la lista de permitidos, es posible que vea un error de "Acceso denegado". Para corregir este error, agregue la siguiente marca de característica al Centro de administración de Microsoft Entra:
    • ?feature.msaljs=true&exp.msaljsexp=true
    • Por ejemplo, trabaja para Contoso. Fabrikam, un inquilino de asociado, está en la lista de permitidos. Es posible que vea el mensaje de error del Centro de administración de Microsoft Entra del inquilino de Fabrikam.
      • Si recibió el mensaje de error "acceso denegado" para la dirección URL https://entra.microsoft.com/, agregue la marca de característica de la siguiente manera: https://entra.microsoft.com/?feature.msaljs%253Dtrue%2526exp.msaljsexp%253Dtrue#home
  • Solo el cliente global de Acceso seguro para Windows, a partir de la versión 1.8.239.0, es consciente de Universal CAE. En otras plataformas, el cliente de Acceso seguro global usa tokens de acceso normales.
  • Microsoft Entra ID emite tokens de corta duración para el acceso seguro global. La duración de un token de acceso cae universal está entre 60 y 90 minutos, con compatibilidad con la revocación casi en tiempo real.
  • La señal de Id. de Microsoft Entra tarda aproximadamente dos o cinco minutos en llegar al cliente de Acceso seguro global y solicitar al usuario que vuelva a autenticarse.
  • Los usuarios tienen un período de gracia de dos minutos después de recibir un evento CAE para completar la reautenticación. Después de dos minutos, los flujos de red existentes a través del acceso seguro global se interrumpen hasta que el usuario inicie sesión correctamente en el cliente de Acceso seguro global.

Limitaciones del perfil de reenvío de tráfico

Entre las limitaciones conocidas de los perfiles de reenvío de tráfico se incluyen:

  • Los servicios individuales se agregan al perfil de tráfico de Microsoft de forma continua. Actualmente, microsoft Entra ID, Microsoft Graph, Exchange Online y SharePoint Online se admiten como parte del perfil de tráfico de Microsoft.
  • En este momento, el tráfico de acceso privado solo se puede adquirir con el cliente de acceso seguro global. El tráfico de acceso privado no se puede adquirir desde redes remotas.
  • La tunelización del tráfico a destinos de acceso privado por dirección IP solo se admite para intervalos IP fuera de la subred local del dispositivo del usuario final.
  • Debe deshabilitar DNS a través de HTTPS (DNS seguro) para tunelizar el tráfico de red en función de las reglas de los nombres de dominio completos (FQDN) en el perfil de reenvío de tráfico.

Limitaciones de acceso privado

Entre las limitaciones conocidas del acceso privado se incluyen las siguientes:

  • Evite superponer segmentos de aplicaciones entre aplicaciones de acceso rápido y acceso seguro global.
  • Evite superponer segmentos de aplicación entre el acceso rápido y el acceso por aplicación.
  • La tunelización del tráfico a destinos de acceso privado por dirección IP solo se admite para intervalos IP fuera de la subred local del dispositivo del usuario final.
  • En este momento, el tráfico de acceso privado solo se puede adquirir con el cliente de acceso seguro global. Las redes remotas no se pueden asignar al perfil de reenvío de tráfico de acceso privado.

Limitaciones de acceso a Internet

Entre las limitaciones conocidas del acceso a Internet se incluyen:

  • Actualmente, un administrador puede crear hasta 100 directivas de filtrado de contenido web y hasta 1000 reglas basadas en hasta 8000 FQDN totales. Los administradores también pueden crear hasta 256 perfiles de seguridad.
  • La plataforma supone puertos estándar para el tráfico HTTP/S (puertos 80 y 443).
  • El cliente de Acceso seguro global no admite IPv6. El cliente solo tuneliza el tráfico IPv4. El cliente no adquiere el tráfico IPv6 y, por tanto, se transfiere directamente a la red. Para asegurarse de que todo el tráfico se enruta a Acceso seguro global, establezca las propiedades del adaptador de red en IPv4 preferido.
  • UDP aún no se admite en esta plataforma.
  • Las notificaciones de usuario final fáciles de usar están en desarrollo.
  • La conectividad de red remota para el acceso a Internet está en desarrollo.
  • La inspección de seguridad de la capa de transporte (TLS) está en desarrollo.
  • El filtrado basado en la ruta de dirección URL y la categorización de direcciones URL para el tráfico HTTP y HTTPS están en desarrollo.