Depuis fin janvier 2024, de nombreux postes Windows affichent l’erreur « user is required to permit SSO » lors d’une connexion Remote Desktop. Voici un guide pratico‑pratique pour comprendre la cause, diagnostiquer rapidement et remettre vos accès en service, AVD compris.
Vue d’ensemble du problème
Des PC Windows 11 — et, dans certains environnements, des Windows 10 — ne parviennent plus à établir de session RDP lorsque l’option Use a web account to sign in to remote computer est activée dans le client classique (mstsc.exe) ou lorsque l’authentification Azure AD (aussi appelée « compte web ») est utilisée dans Remote Desktop App (MSRDC). Le message exact observé est : « user is required to permit SSO ». Le blocage touche aussi bien les connexions Home → Pro que l’accès à Azure Virtual Desktop (AVD).
Contexte et cause principale
À la suite de l’installation de la mise à jour KB5034204 (builds 22621.3085 / 22631.3085, publiée le 23 janvier 2024), la logique de Single Sign‑On (SSO) de Windows a été ajustée pour se conformer au Digital Markets Act dans l’Espace Économique Européen. Dans certains cas, après ce déploiement, le client RDP — classique (mstsc) ou Remote Desktop App — cesse de transmettre correctement le jeton SSO, provoquant l’erreur citée et empêchant l’ouverture de session distante.
Solutions éprouvées
Les retours de terrain indiquent quatre actions qui rétablissent le service dans la majorité des configurations. Choisissez la première applicable à votre contexte, puis passez aux suivantes si nécessaire.
| Solution | Détails | Avantages | Inconvénients |
|---|---|---|---|
| 1. Désinstaller KB5034204 | Via Paramètres > Windows Update > Historique des mises à jour > Désinstaller. Suspendre les MAJ pendant 1 semaine. | Rétablit immédiatement la connexion SSO. | Perte des correctifs inclus ; risque de réinstallation automatique. |
| 2. Mettre à jour le client Remote Desktop | Installer la dernière version MSI ou Microsoft Store (correctif déployé début février 2024). | Corrige le problème sans toucher à Windows Update. | Peut nécessiter un redémarrage ; effet non systématique sur tous les postes. |
| 3. Contournement via fichier .RDP | Ajouter :enablecredsspsupport:i:0authentication level:i:2puis désactiver l’envoi préalable des identifiants. | Permet de se connecter même avec KB5034204 installée. | Perte du SSO ; saisie manuelle des identifiants côté distant. |
| 4. Redémarrer le poste | Un simple reboot réactive parfois temporairement l’authentification. | Aucune modification système. | Effet souvent éphémère (retour après veille ou nouvelle session). |
Procédures détaillées
Mettre à jour le client Remote Desktop (recommandé)
Si vos utilisateurs passent par Remote Desktop App (MSRDC) ou par l’icône « Remote Desktop » issue du Microsoft Store pour accéder à AVD :
- Fermez toute session AVD et quittez l’application Remote Desktop.
- Vérifiez la version du client : Paramètres > À propos dans l’app Remote Desktop. Sur
mstsc.exe, Aide > À propos permet d’identifier la version du composant RDC. - Installez la dernière version disponible (MSI ou Microsoft Store) puis redémarrez le poste si le programme l’exige.
- Rouvrez l’application, supprimez puis recréez le workspace AVD si utilisé (menu Workspaces > Remove puis Add), et testez la connexion.
Pourquoi cela fonctionne ? Les builds de client RDP publiés début février 2024 ont reçu des ajustements pour aligner la négociation SSO avec les changements introdutits par KB5034204.
Désinstaller KB5034204 (mesure de remédiation rapide)
Sur un poste isolé, la suppression de la mise à jour fautive est la manière la plus rapide de restaurer le SSO natif, en attendant un correctif de votre parc.
- Ouvrez Paramètres > Windows Update > Historique des mises à jour > Désinstaller des mises à jour, sélectionnez KB5034204 et cliquez sur Désinstaller.
- Suspendrez les mises à jour pendant 7 jours pour éviter une réinstallation immédiate.
- Redémarrez et validez la connexion RDP.
Pour automatiser (administrateurs) :
REM Désinstallation silencieuse (nécessite élévation)
wusa /uninstall /kb:5034204 /quiet /norestart
REM Blocage temporaire (Intune/GPO ou pause locale)
REM > Appliquez une pause de 7 jours sur Windows Update qualité Si wusa échoue, passez par DISM en ciblant le package exact (obtenu via dism /online /get-packages) :
dism /online /get-packages | findstr 5034204
dism /online /remove-package /packagename:<NomExactDuPackage> /quiet /norestart
Prudence : la désinstallation retire aussi les correctifs de sécurité inclus. Planifiez un rétablissement vers une build ultérieure corrigée dès que possible.
Contournement via fichier .RDP (désactive le SSO côté client)
Quand une correction immédiate du client ou du système n’est pas possible, créez un fichier .rdp spécifique pour la ressource distante :
- Dans
mstsc.exe, configurez l’hôte, les options d’affichage, la passerelle si nécessaire (Options > Avancé), puis cliquez sur Enregistrer sous… pour générer un.rdp. - Éditez le fichier dans un éditeur texte et ajoutez :
enablecredsspsupport:i:0
authentication level:i:2
prompt for credentials:i:1
negotiate security layer:i:1
Ensuite, désactivez l’envoi préalable des identifiants dans l’interface mstsc : onglet Options > Général, cochez « Toujours demander mes informations d’identification » (ou laissez vide le nom d’utilisateur) afin d’entrer les identifiants sur la machine distante.
Impact sécurité : vous perdez le SSO et, selon vos stratégies, vous pourrez être amené à taper un UPN/MDP ou à utiliser MFA côté distant. Ce contournement est acceptable comme plan de continuité le temps d’un correctif.
Redémarrer la machine (effet transitoire)
Le redémarrage purge certains caches d’authentification et réinitialise la pile réseau. Sur plusieurs cas, cela rétablit l’auth temporairement ; le problème revient souvent après une veille prolongée, un basculement d’utilisateur ou une nouvelle obtention de jeton.
Diagnostic : confirmer que votre poste est concerné
Avant d’engager une action globale, vérifiez les éléments suivants :
- Version de Windows : Windows 11 22H2/23H2 avec build 22621/22631 et la mise à jour
.3085installée (indiquant KB5034204). - Client utilisé :
mstsc.exeavec l’option « Use a web account to sign in to remote computer » activée ou Remote Desktop App (MSRDC) avec authentification Azure AD. - Message d’erreur : « user is required to permit SSO » au moment de l’établissement de session.
- Contexte AVD : échec d’ouverture de session après découverte des workspaces, ou demande d’identifiants inattendue malgré une session déjà approuvée.
- Journaux (Observateur d’événements) : Applications and Services Logs > Microsoft > Windows > RemoteDesktopServices‑RdpCoreTS/Operational et journaux liés à AAD. Recherchez des échecs d’acquisition/présentation de jeton.
- Gestion des informations d’identification : vérifiez dans le Gestionnaire d’identifiants s’il existe des entrées
TERMSRV/hostnameou MicrosoftAccount pouvant interférer. Supprimez‑les puis retestez.
Cas d’usage Azure Virtual Desktop (AVD) et Azure AD
Pour AVD, le symptôme typique est une demande d’identifiants répétée malgré un SSO attendu ou un échec immédiat avec le message « user is required to permit SSO » au lancement d’une application/desktop publié. Approche conseillée :
- Mettre à jour Remote Desktop App (MSRDC) sur tous les postes clients.
- Supprimer puis réenregistrer les workspaces AVD dans l’app, afin de régénérer les métadonnées d’authentification.
- Sur un petit échantillon pilote, valider l’ouverture de session avec SSO et MFA selon vos politiques.
- Si l’urgence l’impose, dégrader temporairement le SSO côté client (fichier
.rdpdédié) pour les utilisateurs critiques.
Bon à savoir : l’infrastructure AVD (host pools, broker) n’est généralement pas en cause ; le défaut se situe sur le chemin d’authentification côté client et la manière dont le jeton est présenté au service lors de la négociation RDP.
Arbre de décision rapide
| Situation | Action immédiate | Action durable |
|---|---|---|
| AVD avec Remote Desktop App | Mettre à jour l’app, recréer le workspace, retenter. | Généraliser la version corrigée via Intune/logiciel de déploiement. |
| MSTSC avec « compte web » activé | Tester un .rdp dédié avec enablecredsspsupport:i:0. | Déployer un client RDP à jour ou retirer KB5034204 sur les postes concernés. |
| Poste critique en production | Désinstaller KB5034204, suspendre les MAJ 7 jours. | Réinstaller une build ultérieure stable et réactiver la pause en anneaux de déploiement. |
Recommandations complémentaires
- Tester en environnement pilote chaque patch Windows Preview avant déploiement large, notamment sur les postes clés pour AVD/accès distants.
- Suivre les notes Microsoft relatives aux « Upcoming changes to Windows single sign‑on » ; elles détaillent les ajustements DMA et les versions client/serveur compatibles.
- Mettre en place une stratégie de pause automatique des mises à jour de qualité sur les machines critiques pour disposer d’un délai d’analyse (anneaux Pilote → Large → Entreprise).
- Documenter un plan de secours (fichier
.rdpmodifié, accès VPN alternatif, authentification manuelle) pour garantir la continuité de service si un patch bloque de nouveau le SSO.
Bonnes pratiques d’exploitation
- Anneaux de mise à jour : Séparez clairement vos groupes (IT, champions, général, sensibles). Une pause automatique de 7 jours sur « Qualité » pour les groupes sensibles réduit l’exposition aux régressions.
- Observabilité : Mettez en place des tableaux de bord d’échecs d’ouverture de session (intégration Intune/Defender/Log Analytics) pour détecter tôt toute recrudescence d’erreurs RDP.
- Standardisation client : Homogénéisez la version du client RDP (MSRDC) et consignez‑la dans votre CMDB. Évitez les écarts de version entre équipes.
- Gestion des identifiants : Nettoyez régulièrement les entrées obsolètes dans le Gestionnaire d’identifiants (TERMSRV/*) via script si nécessaire.
FAQ technique
Le problème est‑il limité à l’EEE ?
La modification SSO répond à des contraintes DMA en EEE, mais l’impact peut se manifester au‑delà selon vos paramètres régionaux, canaux de mise à jour et versions de client.
Pourquoi la mise à jour du client RDP suffit‑elle parfois ?
Parce qu’elle corrige la manière dont le client présente le jeton SSO au serveur RDP/AVD, sans nécessiter de retour arrière sur Windows.
Le contournement enablecredsspsupport:i:0 est‑il sécurisé ?
Il réduit le confort (plus de SSO) et peut amener une saisie manuelle ou MFA côté distant. Il reste acceptable en continuité de service, mais rétablissez le SSO dès que possible.
Faut‑il modifier des stratégies Azure AD ou AVD ?
Non dans la majorité des cas : le défaut se situe côté client/OS. Évitez les changements structurants tant que le correctif client/OS n’est pas évalué.
Un simple redémarrage règle‑t‑il le souci ?
Parfois, mais l’effet est souvent temporaire (retour après veille ou renouvellement de jeton).
Comment vérifier rapidement si KB5034204 est présente ?
Exécutez winver (build .3085 visible) ou consultez l’historique des mises à jour. En PowerShell : Get-HotFix | Where-Object {$_.HotFixID -eq 'KB5034204'}.
Playbook d’intervention pas‑à‑pas
- Identifier le périmètre : extraire la liste des machines avec build .3085 et/ou KB5034204 installée, plus la version du client RDP.
- Corriger en pilote : déployer la dernière version de Remote Desktop App (MSRDC) sur 10–20 postes représentatifs. Mesurer l’amélioration.
- Basculer un plan B : fournir un
.rdpavecenablecredsspsupport:i:0pour les utilisateurs critiques qui ne peuvent attendre. - Remédiation OS ciblée : si l’update client ne suffit pas, désinstaller KB5034204 sur les machines encore affectées, avec une pause MAJ de 7 jours.
- Stabiliser : dès qu’une build Windows/Client RDP corrigée est validée, rétablir un niveau de patch homogène et lever progressivement la pause.
- Capitaliser : documenter l’incident (chronologie, métriques, décisions) et mettre à jour vos normes (anneaux, surveillance des erreurs RDP, communication).
Scripts et commandes utiles
:: Vérifier la présence de KB5034204
powershell -command "Get-HotFix | ? HotFixID -eq 'KB5034204'"
:: Désinstaller silencieusement KB5034204
wusa /uninstall /kb:5034204 /quiet /norestart
:: Lister les packages contenant 5034204
dism /online /get-packages | findstr 5034204
:: Paramètres .rdp pour contourner le SSO
enablecredsspsupport:i:0
authentication level:i:2
prompt for credentials:i:1
negotiate security layer:i:1 Points d’attention sécurité et conformité
- SSO désactivé : le contournement .rdp change l’expérience utilisateur et peut augmenter le nombre de saisies d’identifiants. Communiquez clairement et limitez sa durée.
- Rollback de correctifs : la désinstallation d’une mise à jour peut exposer à des vulnérabilités corrigées. N’utilisez cette voie qu’avec une fenêtre courte et contrôlée.
- Journalisation : conservez les logs de vos actions (scripts, Intune, GPO) pour audit et retour d’expérience.
Modèle de message utilisateur
Objet : Connexion Bureau à distance – message « user is required to permit SSO »
Nous rencontrons un incident affectant l’authentification SSO lors des connexions Remote Desktop. Une mise à jour du client sera déployée aujourd’hui. En attendant, si vous devez vous connecter en urgence, utilisez le fichier .rdp fourni et saisissez vos identifiants lorsqu’ils sont demandés. Nous vous informerons dès la restauration complète du SSO.
Résumé exécutif
Le message « user is required to permit SSO » résulte d’un changement de la pile SSO introduit avec KB5034204 et de certaines versions de clients RDP qui ne transmettent plus correctement le jeton. La mise à jour du client Remote Desktop résout le problème dans la plupart des cas ; à défaut, la désinstallation de KB5034204 ou un fichier .rdp configuré pour contourner le SSO permettent de rétablir la connectivité, le temps d’aligner votre parc sur des versions stables. Encadrez ces mesures par des anneaux de déploiement, une surveillance des échecs RDP et une communication claire aux utilisateurs.
En appliquant l’une de ces méthodes — en priorité la mise à jour du client Remote Desktop, puis, si nécessaire, la désinstallation de KB5034204 — la plupart des utilisateurs ont restauré l’accès RDP sans devoir modifier les politiques Azure AD ni les paramètres SSO globaux.
Checklist rapide
- ❑ Le poste est‑il en build .3085 avec KB5034204 ?
- ❑ Le client RDP (MSRDC/mstsc) est‑il à jour ?
- ❑ Le test via
.rdpavecenablecredsspsupport:i:0fonctionne‑t‑il ? - ❑ En cas d’urgence, la désinstallation de KB5034204 a‑t‑elle été planifiée et documentée ?
- ❑ Les utilisateurs critiques disposent‑ils d’un plan de secours communiqué ?
Conclusion : stabilisez d’abord le client, gardez le rollback OS comme filet de sécurité, et institutionnalisez un cycle de tests/pauses pour éviter qu’une évolution SSO n’interrompe à nouveau vos accès distants.