Questions fréquentes (FAQ) sur la fonctionnalité Proxy d’application Microsoft Entra

Non, les éléments de configuration suivants sont utilisés par le proxy d’application et ne doivent pas être modifiés ou supprimés :

• Activer/désactiver « Autoriser les flux de clients publics ».
• CWAP_AuthSecret (secrets client).
• API autorisées. La modification de l’un des éléments de configuration ci-dessus sur la page d’inscription de l’application interrompt la pré-authentification pour le proxy d’application Microsoft Entra.

Non, vous devez supprimer une application de proxy d’application de la zone Applications d’entreprise du centre d’administration Microsoft Entra. Si vous supprimez l’application de proxy d’application de la zone Inscriptions d’applications du centre d’administration Microsoft Entra, vous pourriez rencontrer des problèmes.

Pour utiliser la fonctionnalité Proxy d’application Microsoft Entra, vous devez disposer d’une licence Microsoft Entra ID P1 ou P2. Pour plus d’informations sur les licences, consultez la tarification Microsoft Entra.

Si votre licence expire, le proxy d’application est automatiquement désactivé. Les informations de votre application sont enregistrées pendant un an.

Vérifiez que vous disposez au moins d’une licence Microsoft Entra ID P1 ou P2 et d’un connecteur de réseau privé Microsoft Entra installé. Une fois votre premier connecteur correctement installé, le service de proxy d’application Microsoft Entra s’active automatiquement.

Oui, le proxy d’application Microsoft Entra et l’Accès privé Microsoft Entra utilisent le connecteur de réseau privé Microsoft Entra. Pour en savoir plus sur le connecteur, veuillez consulter la rubrique Connecteur de réseau privé Microsoft Entra. Pour résoudre des problèmes de configuration du connecteur, veuillez consulter la rubrique Résoudre des problèmes de connecteurs.

Bien que ces suffixes apparaissent dans la liste des suffixes, vous ne devez pas les utiliser. Ces suffixes de domaine ne sont pas destinés à une utilisation avec le proxy d’application Microsoft Entra. Si vous utilisez ces suffixes de domaine, l’application Proxy d’application Microsoft Entra créée ne fonctionnera pas. Vous pouvez utiliser le suffixe de domaine standard msappproxy.net ou un domaine personnalisé.

Microsoft Entra ID dispose d’un service Proxy d’application qui permet aux utilisateurs d’accéder à des applications locales en se connectant avec leur compte Microsoft Entra. Si vous avez installé des connecteurs dans différentes régions, vous pouvez optimiser le trafic en sélectionnant la région de service cloud proxy d’application la plus proche à utiliser avec chaque groupe de connecteurs, consultez Optimiser le flux de trafic avec le proxy d’application Microsoft Entra.

Une fois le certificat SSL chargé, vous recevez le message « certificat non valide, mot de passe peut-être incorrect » sur le portail.

Voici quelques conseils pour résoudre cette erreur :

• Vérifiez les problèmes liés au certificat. Installez le certificat sur votre ordinateur local. Si vous ne rencontrez aucun problème, cela signifie que le certificat est correct.
• Vérifiez que le mot de passe ne contient pas de caractères spéciaux. Le mot de passe ne doit contenir que des caractères 0-9, A-Z et a-z.
• Si le certificat a été créé avec le fournisseur de stockage de clés pour les Logiciels Microsoft, l’algorithme RSA doit être utilisé.

La durée par défaut s’élève à 85 secondes. Le paramètre « long » s’élève à 180 secondes. Il n’est pas possible d’augmenter la limite du délai d’expiration.

Non, cela n’est pas pris en charge actuellement.

La clé secrète client, également appelée CWAP_AuthSecret, est automatiquement ajoutée à l’objet application (inscription d’application) lors de la création de l’application Proxy d’application Microsoft Entra.

La clé secrète client est valide pendant un an. Une nouvelle clé secrète client d’un an est créée automatiquement avant l’expiration de la clé secrète client valide actuelle. Trois clés secrètes client CWAP_AuthSecret sont toujours conservées dans l’objet application.

Non, vous devez utiliser le domaine de secours d’origine.

Article mentionné en question : Ajouter et remplacer votre domaine de secours onmicrosoft.com dans Microsoft 365

À partir de la page des inscriptions d’applications, vous pouvez remplacer l’URL de la page d’accueil par l’URL externe souhaitée pour la page d’arrivée. La page spécifiée est chargée quand l’application est lancée à partir de Mes applications ou du Portail Office 365. Pour connaître les étapes de configuration, consultez l’article Définir une page d’accueil personnalisée pour les applications publiées à l’aide du proxy d’application Microsoft Entra.

Si la pré-authentification Microsoft Entra est configurée et que l’URL de l’application contient un caractère « # » quand vous tentez d’accéder à l’application pour la première fois, vous êtes redirigé vers Microsoft Entra ID (login.microsoftonline.com) pour l’authentification. Une fois que vous avez procédé à l’authentification, vous êtes redirigé vers la partie de l’URL qui se trouve avant le caractère « # » et tout ce qui vient après le « # » semble être ignoré/supprimé. Par exemple, si l’URL est https://www.contoso.com/#/home/index.html, une fois l’authentification Microsoft Entra effectuée, l’utilisateur est redirigé vers https://www.contoso.com/. Ce comportement est normal en raison de la façon dont le caractère « # » est géré par le navigateur.

Solutions/alternatives possibles :

• Configurer une redirection de https://www.contoso.com vers https://contoso.com/#/home/index.html. L’utilisateur doit d’abord accéder à https://www.contoso.com.
• L’URL utilisée pour la première tentative d’accès doit inclure le caractère « # » sous la forme encodée (%23). Le serveur publié risque de ne pas l’accepter.
• Configurer un type de pré-authentification pass-through (non recommandé).

Non, aucune configuration IIS n’est requise pour les applications publiées. Vous pouvez publier des applications web qui s’exécutent sur des serveurs autres que Windows Server. En revanche, vous ne pourrez peut-être pas utiliser la pré-authentification avec un serveur autre que Windows Server, selon que le serveur web prend en charge ou non Negotiate (authentification Kerberos). IIS n’est pas exigé sur le serveur sur lequel le connecteur est installé.

Le proxy d’application n’ajoute pas automatiquement l’en-tête HTTP Strict-Transport-Security aux réponses HTTPS mais conserve l’en-tête s’il est dans la réponse d’origine envoyée par l’application publiée. La mise au point d’un paramètre pour activer cette fonctionnalité figure dans la feuille de route.

Non. Si le protocole http est configuré dans l’URL externe, le point de terminaison du proxy d’application Microsoft Entra accepte les demandes entrantes sur le port TCP 80. Dans le cas du protocole https, il s’agit du port TCP 443.

Oui, voici quelques exemples pour les URL internes, y compris les ports : http://app.contoso.local:8888/, https://app.contoso.local:8080/, https://app.contoso.local:8081/test/.

Certaines réponses envoyées par les applications web publiées peuvent contenir des URL codées en dur. Dans ce cas, il faut s’assurer, à l’aide d’une solution de traduction de liens, que le client utilise toujours l’URL correcte. Les solutions de traduction de liens peuvent être complexes et ne pas fonctionner dans tous les scénarios. Vous trouverez ici nos solutions documentées pour la traduction de liens.

En guise de meilleure pratique, nous vous recommandons d’utiliser des URL externes et internes identiques. Les URL externes et internes sont considérées comme identiques si les protocol://hostname:port/path/ des deux URL sont identiques.

Pour ce faire, vous pouvez utiliser la fonctionnalité des domaines personnalisés.

Exemples :

Identique :

External URL: https://app1.contoso.com/test/
Internal URL: https://app1.contoso.com/test/

Différent :

External URL: https://app1.contoso.com/test/
Internal URL: http://app1.contoso.com/test/

External URL: https://app1.contoso.com/test/
Internal URL: https://app1.contoso.com:8080/test/

External URL: https://app1.msappproxy.net/test/
Internal URL: https://app1.contoso.com:/test/

Les URL externes et internes ne peuvent en aucun cas être identiques si l’URL interne contient un port non standard (autre que TCP 80/443).

Dans certains scénarios, les modifications doivent être effectuées dans la configuration de l’application web.

La méthode PrincipalsAllowedToDelegateToAccount est utilisée lorsque les serveurs du connecteur se trouvent dans un domaine différent de celui du compte de service de l’application web. Elle exige l’utilisation d’une délégation contrainte basée sur les ressources. Si les serveurs du connecteur et le compte de service de l’application web se trouvent dans le même domaine, vous pouvez utiliser Utilisateurs et ordinateurs Active Directory pour configurer les paramètres de délégation sur chacun des comptes d’ordinateur du connecteur, ce qui leur permet de déléguer au SPN cible.

Si les serveurs du connecteur et le compte de service de l’application web se trouvent dans des domaines différents, la délégation basée sur les ressources est utilisée. Les autorisations de délégation sont configurées sur le serveur web cible et le compte de service de l’application web. Cette méthode de délégation contrainte est relativement nouvelle. Elle a été introduite dans Windows Server 2012, qui prend en charge la délégation interdomaines en permettant au propriétaire de la ressource (service web) de contrôler la machine et les comptes de service qui peuvent déléguer. Il n’y a pas d’interface utilisateur pour faciliter cette configuration. Vous devez donc utiliser PowerShell. Pour plus d’informations, consultez le livre blanc Understanding Kerberos Constrained Delegation with Application Proxy (Présentation de la délégation contrainte Kerberos avec le proxy d’application).

L’authentification NTLM ne peut pas être utilisée en tant que méthode de pré-authentification ou d’authentification unique. L’authentification NTLM ne peut être utilisée que quand elle peut être négociée directement entre le client et l’application web publiée. L’utilisation de l’authentification NTLM entraîne généralement l’affichage d’une invite de connexion dans le navigateur.

Non, cela ne fonctionnera pas, car les utilisateurs invités dans Microsoft Entra ID ne possèdent pas l'attribut requis par l’une des identités de connexion mentionnées ci-dessus.

Dans ce cas, « Nom d’utilisateur principal » est utilisé comme solution de repli. Si vous souhaitez en savoir plus sur le scénario B2B, veuillez lire l’article Accorder aux utilisateurs B2B de Microsoft Entra ID l’accès à vos applications locales.

Les stratégies d’accès conditionnel s’appliquent uniquement aux utilisateurs correctement préauthentifiés dans Microsoft Entra ID. L’authentification directe ne déclenche pas l’authentification Microsoft Entra, donc les stratégies d’accès conditionnel ne peuvent pas être appliquées. Avec l’authentification pass-through, des stratégies MFA doivent être implémentées sur le serveur local, si possible, ou en activant la pré-authentification auprès du proxy d’application Microsoft Entra.

Non, ce scénario n’est pas pris en charge, car le proxy d’application arrête le trafic TLS.

Consultez l’article Publier le bureau à distance avec le proxy d’application Microsoft Entra.

Non, ce scénario n’est pas pris en charge.

Oui, c’est normal. Le scénario de pré-authentification exige un contrôle ActiveX, qui n’est pas pris en charge dans les navigateurs tiers.

Oui, ce scénario est actuellement en préversion publique. Consultez l’article Publier le bureau à distance avec le proxy d’application Microsoft Entra.

Oui, c’est normal. Si l’ordinateur de l’utilisateur est joint à Microsoft Entra, l’utilisateur se connecte automatiquement à Microsoft Entra ID. Il doit fournir ses informations d’identification uniquement dans le formulaire de connexion RDWeb.

Cette option permet à l’utilisateur de télécharger le fichier RDP et de l’utiliser par un autre client RDP (en dehors du client web Bureau à distance). En règle générale, les autres clients RDP (comme le client Bureau à distance Microsoft) ne peuvent pas gérer la préauthentification en mode natif. C’est pourquoi le scénario est impossible.

Consultez l’article Activer l’accès à distance à SharePoint avec le proxy d’application Microsoft Entra.

Pour le moment, l’application mobile SharePoint ne prend pas en charge la préauthentification Microsoft Entra.

Non, le proxy d’application Microsoft Entra est conçu pour fonctionner avec Microsoft Entra ID et ne répond pas aux exigences d’un rôle de proxy AD FS.

Non, cela n’est pas pris en charge.

Les applications qui utilisent le protocole WebSocket, par exemple QlikSense et le client web Bureau à distance (HTML5), sont désormais prises en charge. Les limitations connues sont les suivantes :

• Le proxy d’application ignore le cookie qui est défini sur la réponse du serveur lors de l’ouverture de la connexion WebSocket.
• Aucune authentification unique n’est appliquée à la requête WebSocket.
• Les fonctionnalités (Eventlogs, PowerShell et Services Bureau à distance) de Windows Admin Center (WAC) ne fonctionnent pas via le proxy d’application Microsoft Entra.

L’application WebSocket n’a pas d’exigences de publication uniques et peut être publiée de la même façon que toutes les autres applications de proxy d’application.

Oui. La traduction de liens affecte les performances. Le service de proxy d’application analyse l’application à la recherche de liens codés en dur, puis les remplace par leurs URL externes publiées respectives avant de les présenter à l’utilisateur.

Pour optimiser les performances, nous vous recommandons d’utiliser des URL internes et externes identiques en configurant des domaines personnalisés. Si vous n’avez pas la possibilité d’utiliser des domaines personnalisés, vous pouvez améliorer les performances de la traduction des liens à l’aide de l’extension de connexion sécurisée Mes applications ou du navigateur Microsoft Edge sur mobile. Consultez l’article Rediriger les liens codés en dur pour des applications publiées avec le proxy d’application Microsoft Entra.

Ce scénario n’est pas pris en charge directement. Vos possibilités pour ce scénario sont les suivantes :

1. Publiez les URL HTTP et HTTPS en tant qu’applications distinctes avec un caractère générique, mais donnez à chacune un nom de domaine personnalisé différent. Cette configuration fonctionne, car elles ont des URL externes différentes.

2. Publiez l’URL HTTPS par le biais d’une application générique. Publiez les applications HTTP séparément à l’aide de ces cmdlets PowerShell du proxy d’application :

   • Gestion des applications de proxy d’application
   • gestion des connecteurs de réseau privé