Partager via


Limitations connues pour l’accès sécurisé global

Global Secure Access est le terme unifiant utilisé pour Microsoft Entra Internet Access et Microsoft Entra Private Access.

Cet article détaille les problèmes connus et les limitations que vous pouvez rencontrer lors de l’utilisation de Global Secure Access.

Limitations du client Accès sécurisé global

Le client Global Secure Access est disponible sur plusieurs plateformes. Sélectionnez chaque onglet pour plus d’informations sur les limitations connues pour chaque plateforme.

  • client Windows
  • client macOS
  • client Android
  • client iOS

Les limitations connues pour le client Global Secure Access pour Windows sont les suivantes :

Système DNS (Secure Domain Name System)

Le client Global Secure Access ne prend actuellement pas en charge le DNS sécurisé dans ses différentes versions, telles que DNS sur HTTPS (DoH), DNS sur TLS (DoT) ou DNS Security Extensions (DNSSEC). Pour configurer le client afin qu’il puisse acquérir le trafic réseau, vous devez désactiver le DNS sécurisé. Pour désactiver DNS dans le navigateur, consultez DNS sécurisé désactivé dans les navigateurs.

DNS sur TCP

DNS utilise le port 53 UDP pour la résolution de noms. Certains navigateurs ont leur propre client DNS qui prend également en charge le port 53 TCP. Actuellement, le client Global Secure Access ne prend pas en charge le port DNS 53 TCP. En guise d’atténuation, désactivez le client DNS du navigateur en définissant les valeurs de Registre suivantes :

  • Microsoft Edge
    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge] "BuiltInDnsClientEnabled"=dword:00000000
  • Chrome
    [HKEY_CURRENT_USER\Software\Policies\Google\Chrome] "BuiltInDnsClientEnabled"=dword:00000000
    Ajoutez également des chrome://flags de navigation et désactivez Async DNS resolver.

Règles de table de stratégie de résolution de noms dans la stratégie de groupe non prises en charge

Le client Global Secure Access pour Windows ne prend pas en charge les règles de table de stratégie de résolution de noms (NRPT) dans la stratégie de groupe. Pour prendre en charge le DNS privé, le client configure des règles NRPT locales sur l’appareil. Ces règles redirigent les requêtes DNS pertinentes vers le DNS privé. Si les règles NRPT sont configurées dans la stratégie de groupe, elles remplacent les règles NRPT locales configurées par le client et le DNS privé ne fonctionnent pas.

En outre, les règles NRPT qui ont été configurées et supprimées dans les versions antérieures de Windows ont créé une liste vide de règles NRPT dans le fichier registry.pol. Si cet objet de stratégie de groupe (GPO) est appliqué sur l’appareil, la liste vide remplace les règles NRPT locales et le DNS privé ne fonctionne pas.

En guise d’atténuation :

  1. Si la clé de Registre HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig existe sur l’appareil de l’utilisateur final, configurez un objet de stratégie de groupe pour appliquer des règles NRPT.
  2. Pour rechercher les objets de stratégie de groupe configurés avec des règles NRPT :
    1. Exécutez gpresult /h GPReport.html sur l’appareil de l’utilisateur final et recherchez une configuration NRPT.
    2. Exécutez le script suivant qui détecte les chemins d’accès de tous les fichiers registry.pol dans sysvol qui contiennent des règles NRPT.

Note

N’oubliez pas de modifier la variable sysvolPath pour répondre à la configuration de votre réseau.

# =========================================================================
# 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. Modifiez chacun des objets de stratégie de groupe trouvés dans la section précédente :
    1. Si la section NRPT est vide, créez une nouvelle règle fictive, mettez à jour la stratégie, supprimez la règle fictive et mettez à jour à nouveau la stratégie. Ces étapes suppriment les DnsPolicyConfig du fichier registry.pol (qui a été créé dans une version héritée de Windows).
    2. Si la section NRPT n’est pas vide et contient des règles, vérifiez que vous avez toujours besoin de ces règles. Si vous n’avez pas besoin des règles, supprimez-les. Si vous avez besoin des règles et appliquez l’objet de stratégie de groupe sur un appareil avec le client Accès sécurisé global, l’option DNS privée ne fonctionne pas. Capture d’écran de la boîte de dialogue Règles de stratégie de résolution de noms avec les boutons Créer et Appliquer mis en surbrillance.

Secours de connexion

En cas d’erreur de connexion au service cloud, le client revient à une connexion Internet directe ou bloque la connexion, en fonction de la de renforcement valeur de la règle de correspondance dans le profil de transfert.

Géolocalisation

Pour le trafic réseau qui est tunnelisé vers le service cloud, le serveur d’applications (site web) détecte l’adresse IP source de la connexion comme adresse IP de la périphérie (et non comme adresse IP de l’appareil utilisateur). Ce scénario peut affecter les services qui s’appuient sur la géolocalisation.

Pourboire

Pour Microsoft 365 et Microsoft Entra pour détecter la véritable adresse IP source de l’appareil, envisagez d’activer restauration ip source.

Prise en charge de la virtualisation

Vous ne pouvez pas installer le client Global Secure Access sur un appareil qui héberge des machines virtuelles. Toutefois, vous pouvez installer le client Global Secure Access sur une machine virtuelle, tant que le client n’est pas installé sur l’ordinateur hôte. Pour la même raison, un sous-système Windows pour Linux (WSL) n’acquiert pas le trafic à partir d’un client installé sur l’ordinateur hôte.

support Hyper-V :

  1. Commutateur virtuel externe : le client Windows Accès sécurisé global ne prend actuellement pas en charge les ordinateurs hôtes qui ont un commutateur virtuel externe Hyper-V. Toutefois, le client peut être installé sur les machines virtuelles pour tunneliser le trafic vers l’accès sécurisé global.
  2. Commutateur virtuel interne : le client Windows Accès sécurisé global peut être installé sur les ordinateurs hôtes et invités. Le client tunnels uniquement le trafic réseau de l’ordinateur sur lequel il est installé. En d’autres termes, un client installé sur une machine hôte ne tunnele pas le trafic réseau des machines invitées.

Le client Windows Accès sécurisé global prend en charge les machines virtuelles Azure et Azure Virtual Desktop (AVD).

Note

Le client Windows Accès sécurisé global ne prend pas en charge AVD multisession.

Procuration

Si un proxy est configuré au niveau de l’application (par exemple, un navigateur) ou au niveau du système d’exploitation, configurez un fichier PAC (Proxy Auto Configuration) pour exclure tous les noms de domaine complets et adresses IP que vous attendez du client à tunnel.

Pour empêcher les requêtes HTTP pour des noms de domaine complets/adresses IP spécifiques de tunneliser vers le proxy, ajoutez les noms de domaine complets/adresses IP au fichier PAC en tant qu’exceptions. (Ces noms de domaine complets/adresses IP se trouvent dans le profil de transfert d’accès sécurisé global pour le tunneling). Par exemple:

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 une connexion Internet directe n’est pas possible, configurez le client pour qu’il se connecte au service Global Secure Access via un proxy. Par exemple, définissez la variable système grpc_proxy pour qu’elle corresponde à la valeur du proxy, telle que http://proxy:8080.

Pour appliquer les modifications de configuration, redémarrez les services Windows du client Accès sécurisé global.

Injection de paquets

Le client tunnelise uniquement le trafic envoyé à l’aide de sockets. Il ne tunnele pas le trafic injecté dans la pile réseau à l’aide d’un pilote (par exemple, certains du trafic généré par Network Mapper (Nmap)). Les paquets injectés accèdent directement au réseau.

Multisession

Le client Global Secure Access ne prend pas en charge les sessions simultanées sur le même ordinateur. Cette limitation s’applique aux serveurs RDP (Remote Desktop Protocol) et aux solutions VDI (Virtual Desktop Infrastructure) telles qu’Azure Virtual Desktop (AVD) configurées pour plusieurs sessions.

Arm64

Le client Global Secure Access ne prend pas en charge l’architecture Arm64.

QUIC n’est pas pris en charge pour Internet Access

Étant donné que QUIC n’est pas encore pris en charge pour l’accès à Internet, le trafic vers les ports 80 UDP et 443 UDP ne peut pas être tunnelisé.

Pourboire

QUIC est actuellement pris en charge dans les charges de travail Private Access et Microsoft 365.

Les administrateurs peuvent désactiver le protocole QUIC déclenchant les clients à revenir au protocole HTTPS via TCP, qui est entièrement pris en charge dans Internet Access. Pour plus d’informations, consultez QUIC non pris en charge pour internet Access.

Connectivité WSL 2

Lorsque le client Global Secure Access pour Windows est activé sur l’ordinateur hôte, les connexions sortantes du sous-système Windows pour Linux (WSL) 2 peuvent être bloquées. Pour atténuer cette occurrence, créez un fichier .wslconfig qui définit dnsTunneling sur false. Ainsi, tout le trafic du WSL contourne l’accès sécurisé global et accède directement au réseau. Pour plus d’informations, consultez configuration des paramètres avancés dans WSL.

Limitations des réseaux distants

Les limitations connues pour les réseaux distants sont les suivantes :

  • Le nombre maximal de réseaux distants par locataire est de 10. Le nombre maximal de liens d’appareil par réseau distant est de quatre.
  • Le trafic Microsoft est accessible via la connectivité réseau distante sans le client Global Secure Access. Toutefois, la stratégie d’accès conditionnel n’est pas appliquée. En d’autres termes, les stratégies d’accès conditionnel pour le trafic Microsoft Global Secure Access sont appliquées uniquement lorsqu’un utilisateur dispose du client Global Secure Access.
  • Vous devez utiliser le client Global Secure Access pour Microsoft Entra Private Access. La connectivité réseau distante prend uniquement en charge Microsoft Entra Internet Access.
  • À ce stade, les réseaux distants ne peuvent être affectés qu’au profil de transfert de trafic Microsoft.

Limitations des contrôles d’accès

Les limitations connues pour les contrôles d’accès sont les suivantes :

  • L’évaluation continue de l’accès (CAE) n’est actuellement pas prise en charge pour l’accès conditionnel universel pour le trafic Microsoft.
  • L’application de stratégies d’accès conditionnel au trafic d’accès privé n’est actuellement pas prise en charge. Pour modéliser ce comportement, vous pouvez appliquer une stratégie d’accès conditionnel au niveau de l’application pour les applications Accès rapide et Accès sécurisé global. Pour plus d’informations, consultez Appliquer l’accès conditionnel aux applications d’accès privé.
  • Le trafic Microsoft est accessible via la connectivité réseau distante sans le client Global Secure Access ; toutefois, la stratégie d’accès conditionnel n’est pas appliquée. En d’autres termes, les stratégies d’accès conditionnel pour le trafic Microsoft Global Secure Access sont appliquées uniquement lorsqu’un utilisateur dispose du client Global Secure Access.
  • L’application du plan de données de vérification réseau conforme (préversion) avec l’évaluation de l’accès continu est prise en charge pour SharePoint Online et Exchange Online.
  • L’activation de la signalisation d’accès conditionnel d’accès sécurisé global permet de signaler à la fois le plan d’authentification (ID Microsoft Entra) et la signalisation du plan de données (préversion). Il n’est actuellement pas possible d’activer ces paramètres séparément.
  • La vérification du réseau conforme n’est actuellement pas prise en charge pour les applications d’accès privé.
  • Lorsque la restauration d’adresses IP source est activée, vous ne pouvez voir que l’adresse IP source. L’adresse IP du service Global Secure Access n’est pas visible. Si vous souhaitez voir l’adresse IP du service Global Secure Access, désactivez la restauration d’adresses IP sources.
  • Actuellement, seules ressources Microsoft évaluer les stratégies d’accès conditionnel basées sur l’emplacement IP, car l’adresse IP source d’origine n’est pas connue pour les ressources non-Microsoft protégées par l’évaluation continue de l’accès (CAE).
  • Si vous utilisez le application stricte de l’emplacementde CAE, les utilisateurs sont bloqués malgré qu’ils se trouvent dans une plage d’adresses IP approuvées. Pour résoudre cette condition, effectuez l’une des recommandations suivantes :
    • Si vous avez des stratégies d’accès conditionnel basées sur l’emplacement IP ciblant des ressources non-Microsoft, n’activez pas l’application stricte de l’emplacement.
    • Vérifiez que la restauration IP source prend en charge le trafic. Si ce n’est pas le cas, n’envoyez pas le trafic pertinent via l’accès sécurisé global.
  • Pour l’instant, la connexion via le client Global Secure Access est nécessaire pour acquérir le trafic d’accès privé.
  • Les fonctionnalités de protection du plan de données sont en préversion (la protection du plan d’authentification est généralement disponible).
  • Si vous avez activé les restrictions de locataire universelles et que vous accédez au Centre d’administration Microsoft Entra pour un locataire sur la liste verte, une erreur « Accès refusé » peut s’afficher. Pour corriger cette erreur, ajoutez l’indicateur de fonctionnalité suivant au Centre d’administration Microsoft Entra :
    • ?feature.msaljs=true&exp.msaljsexp=true
    • Par exemple, vous travaillez pour Contoso. Fabrikam, un locataire partenaire, est sur la liste verte. Le message d’erreur du centre d’administration Microsoft Entra du locataire Fabrikam peut s’afficher.
      • Si vous avez reçu le message d’erreur « accès refusé » pour l’URL https://entra.microsoft.com/, ajoutez l’indicateur de fonctionnalité comme suit : https://entra.microsoft.com/?feature.msaljs%253Dtrue%2526exp.msaljsexp%253Dtrue#home
  • Seul le client Accès sécurisé global pour Windows, à compter de la version 1.8.239.0, est conscient de l’autorité de certification universelle. Sur d’autres plateformes, le client Accès sécurisé global utilise des jetons d’accès réguliers.
  • Microsoft Entra ID émet des jetons de courte durée pour l’accès sécurisé global. La durée de vie d’un jeton d’accès d’autorité de certification universelle est comprise entre 60 et 90 minutes, avec prise en charge de la révocation en temps quasi réel.
  • Il faut environ deux à cinq minutes pour que le signal Microsoft Entra ID atteigne le client Global Secure Access et invite l’utilisateur à se réauthentifier.
  • Les utilisateurs ont une période de grâce de deux minutes après avoir reçu un événement CAE pour terminer la réauthentification. Après deux minutes, les flux réseau existants via l’accès sécurisé global sont interrompus jusqu’à ce que l’utilisateur se connecte correctement au client Global Secure Access.

Limitations du profil de transfert de trafic

Les limitations connues pour les profils de transfert de trafic sont les suivantes :

  • Les services individuels sont ajoutés au profil de trafic Microsoft en continu. Actuellement, l’ID Microsoft Entra, Microsoft Graph, Exchange Online et SharePoint Online sont pris en charge dans le cadre du profil de trafic Microsoft
  • À ce stade, le trafic d’accès privé ne peut être acquis qu’avec le client Global Secure Access. Le trafic d’accès privé ne peut pas être acquis à partir de réseaux distants.
  • Le tunneling du trafic vers les destinations d’accès privé par adresse IP est pris en charge uniquement pour les plages d’adresses IP en dehors du sous-réseau local de l’appareil utilisateur final.
  • Vous devez désactiver DNS sur HTTPS (DNS sécurisé) pour tunneliser le trafic réseau en fonction des règles des noms de domaine complets (FQDN) dans le profil de transfert du trafic.

Limitations d’accès privé

Les limitations connues pour l’accès privé sont les suivantes :

  • Évitez les segments d’application qui se chevauchent entre les applications Accès rapide et Accès sécurisé global.
  • Évitez les segments d’application qui se chevauchent entre l’accès rapide et l’accès par application.
  • Le tunneling du trafic vers les destinations d’accès privé par adresse IP est pris en charge uniquement pour les plages d’adresses IP en dehors du sous-réseau local de l’appareil utilisateur final.
  • À ce stade, le trafic d’accès privé ne peut être acquis qu’avec le client Global Secure Access. Les réseaux distants ne peuvent pas être affectés au profil de transfert du trafic d’accès privé.

Limitations de l’accès à Internet

Les limitations connues pour Internet Access sont les suivantes :

  • Actuellement, un administrateur peut créer jusqu’à 100 stratégies de filtrage de contenu web et jusqu’à 1 000 règles basées sur jusqu’à 8 000 noms de domaine complets. Les administrateurs peuvent également créer jusqu’à 256 profils de sécurité.
  • La plateforme suppose des ports standard pour le trafic HTTP/S (ports 80 et 443).
  • Le client Global Secure Access ne prend pas en charge IPv6. Le client tunnels uniquement le trafic IPv4. Le trafic IPv6 n’est pas acquis par le client et est donc transféré directement vers le réseau. Pour vous assurer que tout le trafic est acheminé vers l’accès sécurisé global, définissez les propriétés de la carte réseau sur préféré IPv4.
  • UDP n’est pas encore pris en charge sur cette plateforme.
  • Les notifications utilisateur final conviviales sont en cours de développement.
  • La connectivité réseau à distance pour Internet Access est en cours de développement.
  • L’inspection TLS (Transport Layer Security) est en cours de développement.
  • Le filtrage basé sur le chemin d’URL et la catégorisation d’URL pour le trafic HTTP et HTTPS sont en cours de développement.