Partilhar via


Limitações conhecidas do Global Secure Access

Global Secure Access é o termo unificador usado para o Microsoft Entra Internet Access e Microsoft Entra Private Access.

Este artigo detalha os problemas e limitações conhecidos que você pode encontrar ao usar o Acesso Seguro Global.

Limitações do cliente Global Secure Access

O cliente Global Secure Access está disponível em várias plataformas. Selecione cada guia para obter detalhes sobre as limitações conhecidas de cada plataforma.

As limitações conhecidas para o cliente Global Secure Access para Windows incluem:

Sistema de Nomes de Domínio Seguro (DNS)

Atualmente, o cliente Global Secure Access não oferece suporte a DNS seguro em suas diferentes versões, como DNS sobre HTTPS (DoH), DNS sobre TLS (DoT) ou DNS Security Extensions (DNSSEC). Para configurar o cliente para que ele possa adquirir tráfego de rede, você deve desativar o DNS seguro. Para desativar o DNS no navegador, consulte DNS seguro desativado em navegadores.

DNS sobre TCP

O DNS usa a porta 53 UDP para resolução de nomes. Alguns navegadores têm seu próprio cliente DNS que também suporta a porta 53 TCP. Atualmente, o cliente Global Secure Access não suporta a porta DNS 53 TCP. Como atenuação, desative o cliente DNS do navegador definindo os seguintes valores do Registro:

  • Borda da Microsoft
    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge] "BuiltInDnsClientEnabled"=dword:00000000
  • Cromado
    [HKEY_CURRENT_USER\Software\Policies\Google\Chrome] "BuiltInDnsClientEnabled"=dword:00000000
    Adicione também chrome://flags de navegação e desative Async DNS resolver.

Não há suporte para as regras da Tabela de Política de Resolução de Nomes na Diretiva de Grupo

O cliente Global Secure Access para Windows não suporta regras NRPT (Tabela de Políticas de Resolução de Nomes) na Política de Grupo. Para suportar DNS privado, o cliente configura regras NRPT locais no dispositivo. Essas regras redirecionam consultas DNS relevantes para o DNS privado. Se as regras NRPT estiverem configuradas na Diretiva de Grupo, elas substituem as regras NRPT locais configuradas pelo cliente e o DNS privado não funcionará.

Além disso, as regras NRPT que foram configuradas e excluídas em versões mais antigas do Windows criaram uma lista vazia de regras NRPT no arquivo registry.pol. Se esse GPO (Objeto de Diretiva de Grupo) for aplicado no dispositivo, a lista vazia substituirá as regras NRPT locais e o DNS privado não funcionará.

Como atenuação:

  1. Se a chave do Registro HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig existir no dispositivo do usuário final, configure um GPO para aplicar regras NRPT.
  2. Para localizar quais GPOs estão configurados com regras NRPT:
    1. Execute gpresult /h GPReport.html no dispositivo do usuário final e procure uma configuração NRPT.
    2. Execute o seguinte script que deteta os caminhos de todos os arquivos registry.pol em sysvol que contêm regras NRPT.

Observação

Lembre-se de alterar a variável sysvolPath para atender à configuração da sua rede.

# =========================================================================
# 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 um dos GPOs encontrados na seção anterior:
    1. Se a seção NRPT estiver vazia, crie uma nova regra fictícia, atualize a política, exclua a regra fictícia e atualize a política novamente. Estas etapas removem o DnsPolicyConfig do arquivo registry.pol (que foi criado em uma versão herdada do Windows).
    2. Se a seção NRPT não estiver vazia e contiver regras, confirme se você ainda precisa dessas regras. Se você não precisa as regras, exclua-as. Se você precisar das regras e aplicar o GPO em um dispositivo com cliente de Acesso Seguro Global, a opção DNS privado não funcionará. Captura de ecrã da caixa de diálogo Regras da Política de Resolução de Nomes com os botões Criar e Aplicar realçados.

Fallback de conexão

Se houver um erro de conexão com o serviço de nuvem, o cliente retornará à conexão direta com a Internet ou bloqueará a conexão, com base no valor de de proteção de da regra de correspondência no perfil de encaminhamento.

Geolocalização

Para o tráfego de rede encapsulado para o serviço de nuvem, o servidor de aplicativos (site) deteta o IP de origem da conexão como o endereço IP da borda (e não como o endereço IP do dispositivo do usuário). Esse cenário pode afetar os serviços que dependem da geolocalização.

Dica

Para que o Microsoft 365 e o Microsoft Entra detetem o IP de origem verdadeiro do dispositivo, considere habilitar restauração de IP de origem.

Suporte à virtualização

Não é possível instalar o cliente Global Secure Access em um dispositivo que hospeda máquinas virtuais. No entanto, você pode instalar o cliente Global Secure Access em uma máquina virtual, desde que o cliente não esteja instalado na máquina host. Pela mesma razão, um Subsistema Windows para Linux (WSL) não adquire tráfego de um cliente instalado na máquina host.

Hyper-V apoio:

  1. Comutador virtual externo: Atualmente, o cliente Windows de Acesso Seguro Global não suporta máquinas host que tenham um comutador virtual externo Hyper-V. No entanto, o cliente pode ser instalado nas máquinas virtuais para encapsular o tráfego para o Acesso Seguro Global.
  2. Comutador virtual interno: O cliente Windows de Acesso Seguro Global pode ser instalado em máquinas host e convidadas. O cliente encapsula apenas o tráfego de rede da máquina em que está instalado. Em outras palavras, um cliente instalado em uma máquina host não encapsula o tráfego de rede das máquinas convidadas.

O cliente Windows de Acesso Seguro Global suporta Máquinas Virtuais do Azure e Ambiente de Trabalho Virtual do Azure (AVD).

Observação

O cliente Windows de Acesso Seguro Global não suporta AVD de várias sessões.

Procuração

Se um proxy estiver configurado no nível do aplicativo (como um navegador) ou no nível do sistema operacional, configure um arquivo de configuração automática de proxy (PAC) para excluir todos os FQDNs e IPs que você espera que o cliente túnel.

Para evitar que solicitações HTTP para FQDNs/IPs específicos sejam encapsuladas no proxy, adicione os FQDNs/IPs ao arquivo PAC como exceções. (Esses FQDNs/IPs estão no perfil de encaminhamento do Global Secure Access para tunelamento). Por exemplo:

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
}

Se não for possível uma conexão direta com a Internet, configure o cliente para se conectar ao serviço Global Secure Access por meio de um proxy. Por exemplo, defina a variável de sistema grpc_proxy para corresponder ao valor do proxy, como http://proxy:8080.

Para aplicar as alterações de configuração, reinicie os serviços do Windows do cliente Global Secure Access.

Injeção de pacotes

O cliente apenas túneis tráfego enviado usando soquetes. Ele não encapsula o tráfego injetado na pilha de rede usando um driver (por exemplo, parte do tráfego gerado pelo Network Mapper (Nmap)). Os pacotes injetados vão diretamente para a rede.

Multi-sessão

O cliente Global Secure Access não suporta sessões simultâneas na mesma máquina. Esta limitação aplica-se a servidores RDP (Remote Desktop Protocol) e soluções VDI (Virtual Desktop Infrastructure), como o Azure Virtual Desktop (AVD), que estão configurados para várias sessões.

Braço64

O cliente Global Secure Access não suporta a arquitetura Arm64.

QUIC não suportado para acesso à Internet

Como o QUIC ainda não é suportado para acesso à Internet, o tráfego para as portas 80 UDP e 443 UDP não pode ser encapsulado.

Dica

Atualmente, o QUIC é suportado em cargas de trabalho do Private Access e do Microsoft 365.

Os administradores podem desativar o protocolo QUIC acionando os clientes para recorrer a HTTPS sobre TCP, que é totalmente suportado no Acesso à Internet. Para obter mais informações, consulte QUIC não suportado para acesso à Internet.

Conectividade WSL 2

Quando o cliente Global Secure Access para Windows está habilitado na máquina host, as conexões de saída do ambiente Windows Subsystem for Linux (WSL) 2 podem ser bloqueadas. Para atenuar essa ocorrência, crie um arquivo .wslconfig que defina dnsTunneling como false. Desta forma, todo o tráfego da WSL contorna o Global Secure Access e vai diretamente para a rede. Para obter mais informações, consulte Configuração de definições avançadas no WSL.

Limitações de redes remotas

As limitações conhecidas para redes remotas incluem:

  • O número máximo de redes remotas por locatário é 10. O número máximo de links de dispositivo por rede remota é quatro.
  • O tráfego da Microsoft é acessado por meio de conectividade de rede remota sem o cliente Global Secure Access. No entanto, a política de Acesso Condicional não é imposta. Em outras palavras, as políticas de Acesso Condicional para o tráfego Microsoft de Acesso Seguro Global só são aplicadas quando um usuário tem o cliente de Acesso Seguro Global.
  • Você deve usar o cliente Global Secure Access para o Microsoft Entra Private Access. A conectividade de rede remota suporta apenas o Microsoft Entra Internet Access.
  • Neste momento, as redes remotas só podem ser atribuídas ao perfil de encaminhamento de tráfego da Microsoft.

Limitações dos controles de acesso

As limitações conhecidas para controles de acesso incluem:

  • Atualmente, a avaliação de acesso contínuo (CAE) não é suportada pelo Acesso Condicional Universal para tráfego da Microsoft.
  • Atualmente, não há suporte para a aplicação de políticas de Acesso Condicional ao tráfego de Acesso Privado. Para modelar esse comportamento, você pode aplicar uma política de Acesso Condicional no nível do aplicativo para aplicativos de Acesso Rápido e Acesso Seguro Global. Para obter mais informações, consulte Aplicar acesso condicional a aplicativos de acesso privado.
  • O tráfego da Microsoft pode ser acessado através da conectividade de rede remota sem o Global Secure Access Client; no entanto, a política de Acesso Condicional não é imposta. Em outras palavras, as políticas de Acesso Condicional para o tráfego Microsoft de Acesso Seguro Global só são aplicadas quando um usuário tem o Cliente de Acesso Seguro Global.
  • A imposição do plano de dados de verificação de rede compatível (visualização) com Avaliação de Acesso Contínuo é suportada para o SharePoint Online e o Exchange Online.
  • A habilitação da sinalização de Acesso Condicional de Acesso Seguro Global habilita a sinalização para o plano de autenticação (ID do Microsoft Entra) e a sinalização do plano de dados (visualização). Atualmente, não é possível ativar essas configurações separadamente.
  • Atualmente, a verificação de rede compatível não é suportada para aplicativos de acesso privado.
  • Quando a restauração do IP de origem está habilitada, você só pode ver o IP de origem. O endereço IP do serviço Global Secure Access não está visível. Se você quiser ver o endereço IP do serviço Global Secure Access, desative a restauração do IP de origem.
  • Atualmente, apenas recursos da Microsoft avaliar políticas de Acesso Condicional baseadas em localização IP, uma vez que o endereço IP de origem original não é conhecido por recursos que não sejam da Microsoft protegidos por CAE (avaliação contínua de acesso).
  • Se você estiver usando ode aplicação de localização rigoroso do CAE, os usuários serão bloqueados apesar de estarem em um intervalo de IP confiável. Para resolver essa condição, siga uma das seguintes recomendações:
    • Se você tiver políticas de Acesso Condicional baseadas em localização IP direcionadas a recursos que não sejam da Microsoft, não habilite a imposição estrita de local.
    • Certifique-se de que a restauração do IP de origem suporte o tráfego. Caso contrário, não envie o tráfego relevante através do Global Secure Access.
  • Neste momento, a ligação através do cliente Global Secure Access é necessária para adquirir tráfego de Acesso Privado.
  • Os recursos de proteção do plano de dados estão em visualização (a proteção do plano de autenticação está geralmente disponível).
  • Se tiver ativado as Restrições Universais de Inquilino e aceder ao centro de administração do Microsoft Entra para um inquilino na lista de permissões, poderá ver um erro "Acesso negado". Para corrigir esse erro, adicione o seguinte sinalizador de recurso ao centro de administração do Microsoft Entra:
    • ?feature.msaljs=true&exp.msaljsexp=true
    • Por exemplo, você trabalha para a Contoso. A Fabrikam, um locatário parceiro, está na lista de permissões. Poderá ver a mensagem de erro para o centro de administração Microsoft Entra do inquilino da Fabrikam.
      • Se você recebeu a mensagem de erro "acesso negado" para o URL https://entra.microsoft.com/, adicione o sinalizador de recurso da seguinte maneira: https://entra.microsoft.com/?feature.msaljs%253Dtrue%2526exp.msaljsexp%253Dtrue#home
  • Somente o cliente Global Secure Access para Windows, a partir da versão 1.8.239.0, está ciente do Universal CAE. Em outras plataformas, o cliente Global Secure Access usa tokens de acesso regulares.
  • O Microsoft Entra ID emite tokens de curta duração para o Global Secure Access. O tempo de vida de um token de acesso CAE Universal é entre 60 e 90 minutos, com suporte para revogação quase em tempo real.
  • Demora aproximadamente dois a cinco minutos para que o sinal de ID do Microsoft Entra chegue ao cliente Global Secure Access e solicite que o usuário se autentique novamente.
  • Os usuários têm um período de carência de dois minutos após receber um evento CAE para concluir a reautenticação. Após dois minutos, os fluxos de rede existentes através do Acesso Seguro Global são interrompidos até que o utilizador inicie sessão com êxito no cliente de Acesso Seguro Global.

Limitações do perfil de encaminhamento de tráfego

As limitações conhecidas para perfis de encaminhamento de tráfego incluem:

  • Serviços individuais são adicionados ao perfil de tráfego da Microsoft continuamente. Atualmente, Microsoft Entra ID, Microsoft Graph, Exchange Online e SharePoint Online são suportados como parte do perfil de tráfego da Microsoft
  • No momento, o tráfego de Acesso Privado só pode ser adquirido com o cliente Global Secure Access. O tráfego de Acesso Privado não pode ser adquirido a partir de redes remotas.
  • O tráfego de encapsulamento para destinos de Acesso Privado por endereço IP é suportado apenas para intervalos de IP fora da sub-rede local do dispositivo do usuário final.
  • Você deve desabilitar o DNS sobre HTTPS (DNS seguro) para encapsular o tráfego de rede com base nas regras dos FQDNs (nomes de domínio totalmente qualificados) no perfil de encaminhamento de tráfego.

Limitações de acesso privado

As limitações conhecidas do Acesso Privado incluem:

  • Evite a sobreposição de segmentos de aplicativos entre aplicativos de Acesso Rápido e de Acesso Seguro Global.
  • Evite a sobreposição de segmentos de aplicativos entre o Acesso Rápido e o acesso por aplicativo.
  • O tráfego de encapsulamento para destinos de Acesso Privado por endereço IP é suportado apenas para intervalos de IP fora da sub-rede local do dispositivo do usuário final.
  • No momento, o tráfego de Acesso Privado só pode ser adquirido com o cliente Global Secure Access. As redes remotas não podem ser atribuídas ao perfil de encaminhamento de tráfego de acesso privado.

Limitações de acesso à Internet

As limitações conhecidas para o acesso à Internet incluem:

  • Atualmente, um administrador pode criar até 100 políticas de filtragem de conteúdo da Web e até 1.000 regras com base em até 8.000 FQDNs totais. Os administradores também podem criar até 256 perfis de segurança.
  • A plataforma assume portas padrão para tráfego HTTP/S (portas 80 e 443).
  • O cliente Global Secure Access não suporta IPv6. O cliente encapsula apenas o tráfego IPv4. O tráfego IPv6 não é adquirido pelo cliente e, portanto, é transferido diretamente para a rede. Para garantir que todo o tráfego seja roteado para o Acesso Seguro Global, defina as propriedades do adaptador de rede como IPv4 preferencial.
  • UDP ainda não é suportado nesta plataforma.
  • Estão em desenvolvimento notificações conviviais para os utilizadores finais.
  • A conectividade de rede remota para acesso à Internet está em desenvolvimento.
  • A inspeção TLS (Transport Layer Security) está em desenvolvimento.
  • A filtragem baseada em caminho de URL e a categorização de URL para tráfego HTTP e HTTPS estão em desenvolvimento.