L’utilisateur ne peut pas s’authentifier ou doit s’authentifier deux fois

  • Article

Cet article traite de plusieurs problèmes qui peuvent entraîner des problèmes qui affectent l’authentification utilisateur.

Accès refusé, type d’ouverture de session restreint

Dans ce cas, un utilisateur Windows 10 qui tente de se connecter à des ordinateurs Windows 10 ou Windows Server 2016 se voit refuser l’accès avec le message suivant :

Connexion Bureau à distance : l’administrateur système a restreint le type d’ouverture de session (réseau ou interactive) que vous pouvez utiliser. Pour obtenir de l’aide, contactez votre administrateur système ou le support technique.

Ce problème se produit lorsque l’authentification au niveau du réseau (NLA) est requise pour les connexions RDP et que l’utilisateur n’est pas membre du groupe Utilisateurs bureau à distance . Cela peut également se produire si le groupe Utilisateurs du Bureau à distance n’a pas été affecté au droit d’accès à cet ordinateur à partir du réseau .

Pour résoudre ce problème, effectuez l’une des opérations suivantes :

Modifier l’appartenance au groupe ou l’attribution des droits de l’utilisateur

Si ce problème affecte un seul utilisateur, la solution la plus simple consiste à ajouter l’utilisateur au groupe Utilisateurs bureau à distance .

Si l’utilisateur est déjà membre de ce groupe (ou si plusieurs membres du groupe rencontrent le même problème), case activée la configuration des droits utilisateur sur l’ordinateur Windows 10 ou Windows Server 2016 distant.

  1. Ouvrez stratégie de groupe Rédacteur d’objets (GPE) et connectez-vous à la stratégie locale de l’ordinateur distant.

  2. Accédez à Configuration\ ordinateurParamètres Windows Paramètres\de sécurité Stratégies\locales\Attribution des droits de l’utilisateur, cliquez avec le bouton droit sur Accéder à cet ordinateur à partir du réseau, puis sélectionnez Propriétés.

  3. Vérifiez la liste des utilisateurs et des groupes pour les utilisateurs Bureau à distance (ou un groupe parent).

  4. Si la liste n’inclut pas les utilisateurs du Bureau à distance ou un groupe parent comme Tout le monde, vous devez l’ajouter à la liste. Si vous avez plusieurs ordinateurs dans votre déploiement, utilisez un objet de stratégie de groupe.

    Par exemple, l’appartenance par défaut pour Accéder à cet ordinateur à partir du réseau inclut Tout le monde. Si votre déploiement utilise un objet de stratégie de groupe pour supprimer Tout le monde, vous devrez peut-être restaurer l’accès en mettant à jour l’objet de stratégie de groupe pour ajouter des utilisateurs Bureau à distance.

Accès refusé, un appel distant à la base de données SAM a été refusé

Ce comportement est plus susceptible de se produire si vos contrôleurs de domaine s’exécutent Windows Server 2016 ou une version ultérieure et que les utilisateurs tentent de se connecter à l’aide d’une application de connexion personnalisée. En particulier, les applications qui accèdent aux informations de profil de l’utilisateur dans Active Directory se voient refuser l’accès.

Ce comportement résulte d’une modification apportée à Windows. Dans Windows Server 2012 R2 et versions antérieures, lorsqu’un utilisateur se connecte à un bureau à distance, le Gestionnaire des connexions distant (RCM) contacte le contrôleur de domaine (DC) pour interroger les configurations spécifiques au Bureau à distance sur l’objet utilisateur dans services de domaine Active Directory (AD DS). Ces informations s’affichent sous l’onglet Profil des services Bureau à distance des propriétés d’objet d’un utilisateur dans le composant logiciel enfichable MMC Utilisateurs et ordinateurs Active Directory.

À compter de Windows Server 2016, RCM n’interroge plus l’objet de l’utilisateur dans AD DS. Si vous avez besoin de RCM pour interroger AD DS parce que vous utilisez les attributs des services Bureau à distance, vous devez activer manuellement la requête.

Importante

Cette section, méthode ou tâche contient des étapes vous indiquant comment modifier le Registre. Toutefois, des problèmes graves peuvent se produire si vous modifiez le Registre de façon incorrecte. Par conséquent, veillez à suivre ces étapes scrupuleusement. Pour pallier à toute éventualité, sauvegardez le Registre avant de le modifier afin de pouvoir le restaurer en cas de problème. Pour plus d’informations sur la procédure de sauvegarde et de restauration du Registre, consultez l’article Comment sauvegarder et restaurer le Registre dans Windows.

Pour activer le comportement RCM hérité sur un serveur hôte de session Bureau à distance, configurez les entrées de Registre suivantes, puis redémarrez le service Services Bureau à distance :

  • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\<Winstation name>\
    • Nom : fQueryUserConfigFromDC
    • Type : Reg_DWORD
    • Valeur : 1 (décimal)

Pour activer le comportement RCM hérité sur un serveur autre qu’un serveur hôte de session Bureau à distance, configurez ces entrées de Registre et l’entrée de Registre supplémentaire suivante (puis redémarrez le service) :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server

Pour plus d’informations sur ce comportement, consultez Modifications apportées aux Gestionnaire des connexions à distance dans Windows Server 2016.

L’utilisateur ne peut pas se connecter à l’aide d’un carte intelligent

Cette section traite de trois scénarios courants où un utilisateur ne peut pas se connecter à un Bureau à distance à l’aide d’un carte intelligent.

Impossible de se connecter avec un carte intelligent dans une succursale avec un contrôleur de domaine en lecture seule (RODC)

Ce problème se produit dans les déploiements qui incluent un serveur RDSH sur un site de succursale qui utilise un contrôleur de domaine en lecture seule. Le serveur RDSH est hébergé dans le domaine racine. Les utilisateurs du site de succursale appartiennent à un domaine enfant et utilisent des cartes à puce pour l’authentification. Le contrôleur de domaine en lecture seule est configuré pour mettre en cache les mots de passe utilisateur (le contrôleur de domaine en lecture seule appartient au groupe de réplication de mot de passe RODC autorisé). Lorsque les utilisateurs tentent de se connecter à des sessions sur le serveur RDSH, ils reçoivent des messages tels que « La tentative d’ouverture de session n’est pas valide. Cela est dû à un nom d’utilisateur ou à des informations d’authentification incorrectes. »

Ce problème est dû à la façon dont le contrôleur de domaine racine et le RDOC gèrent le chiffrement des informations d’identification utilisateur. Le contrôleur de domaine racine utilise une clé de chiffrement pour chiffrer les informations d’identification et le contrôleur de domaine en lecture seule donne au client la clé de déchiffrement. Lorsqu’un utilisateur reçoit l’erreur « non valide », ce qui signifie que les deux clés ne correspondent pas.

Pour contourner ce problème, essayez l’une des opérations suivantes :

  • Modifiez votre topologie de contrôleur de domaine en désactivant la mise en cache du mot de passe sur le contrôleur de domaine en lecture seule ou déployez un contrôleur de domaine accessible en écriture sur le site de la branche.
  • Déplacez le serveur RDSH vers le même domaine enfant que les utilisateurs.
  • Autoriser les utilisateurs à se connecter sans carte à puce.

Notez que toutes ces solutions nécessitent des compromis en matière de performances ou de sécurité.

L’utilisateur ne peut pas se connecter à un ordinateur Windows Server 2008 SP2 à l’aide d’un carte intelligent

Ce problème se produit lorsque les utilisateurs se connectent à un ordinateur Windows Server 2008 SP2 qui a été mis à jour avec KB4093227 (2018.4B). Lorsque des utilisateurs tentent de se connecter à l’aide d’un carte intelligent, l’accès leur est refusé avec des messages tels que « Aucun certificat valide trouvé. Vérifiez que le carte est correctement inséré et qu’il s’ajuste bien. » En même temps, l’ordinateur Windows Server enregistre l’événement Application « Une erreur s’est produite lors de la récupération d’un certificat numérique à partir du carte intelligent inséré. Signature non valide. »

Pour résoudre ce problème, mettez à jour l’ordinateur Windows Server avec la version 2018.06 B de la base de connaissances 4093227, Description de la mise à jour de sécurité pour la vulnérabilité de déni de service RDP (Windows Remote Desktop Protocol) dans Windows Server 2008 : 10 avril 2018.

Impossible de rester connecté avec un carte intelligent et le service Services Bureau à distance se bloque

Ce problème se produit lorsque les utilisateurs se connectent à un ordinateur Windows ou Windows Server qui a été mis à jour avec la base de connaissances 4056446. Dans un premier temps, l’utilisateur peut être en mesure de se connecter au système à l’aide d’un carte intelligent, mais reçoit ensuite un message d’erreur « SCARD_E_NO_SERVICE ». L’ordinateur distant peut ne plus répondre.

Pour contourner ce problème, redémarrez l’ordinateur distant.

Pour résoudre ce problème, mettez à jour l’ordinateur distant avec le correctif approprié :

Si le PC distant est verrouillé, l’utilisateur doit entrer un mot de passe deux fois

Ce problème peut se produire lorsqu’un utilisateur tente de se connecter à un bureau à distance exécutant Windows 10 version 1709 dans un déploiement dans lequel les connexions RDP ne nécessitent pas de NLA. Dans ces conditions, si le Bureau à distance a été verrouillé, l’utilisateur doit entrer ses informations d’identification deux fois lors de la connexion.

Pour résoudre ce problème, mettez à jour l’ordinateur Windows 10 version 1709 avec kb 4343893, 30 août 2018-KB4343893 (build du système d’exploitation 16299.637).

L’utilisateur ne peut pas se connecter et reçoit les messages « Erreur d’authentification » et « Correction oracle de chiffrement CredSSP »

Lorsque les utilisateurs essaient de se connecter à l’aide d’une version de Windows à partir de Windows Vista SP2 et versions ultérieures ou de Windows Server 2008 SP2 et versions ultérieures, ils se voient refuser l’accès et reçoivent des messages comme ceux-ci :

Une erreur d’authentification s’est produite. La fonction demandée n’est pas prise en charge. ... Cela peut être dû à la correction oracle de chiffrement CredSSP ...

« Correction oracle de chiffrement CredSSP » fait référence à un ensemble de mises à jour de sécurité publiées en mars, avril et mai 2018. CredSSP est un fournisseur d’authentification qui traite les demandes d’authentification pour d’autres applications. Le 13 mars 2018, « 3B » et les mises à jour suivantes ont résolu une attaque dans laquelle un attaquant pouvait relayer les informations d’identification de l’utilisateur pour exécuter du code sur le système cible.

Les mises à jour initiales ont ajouté la prise en charge d’un nouvel objet stratégie de groupe, Encryption Oracle Remediation, qui a les paramètres possibles suivants :

  • Vulnérable : les applications clientes qui utilisent CredSSP peuvent revenir à des versions non sécurisées, mais ce comportement expose les bureaux à distance à des attaques. Les services qui utilisent CredSSP acceptent les clients qui n’ont pas été mis à jour.

  • Atténué : les applications clientes qui utilisent CredSSP ne peuvent pas revenir aux versions non sécurisées, mais les services qui utilisent CredSSP acceptent les clients qui n’ont pas été mis à jour.

  • Forcer la mise à jour des clients : les applications clientes qui utilisent CredSSP ne peuvent pas revenir aux versions non sécurisées, et les services qui utilisent CredSSP n’acceptent pas les clients non corrigés.

    Remarque

    Ce paramètre ne doit pas être déployé tant que tous les hôtes distants ne prennent pas en charge la version la plus récente.

La mise à jour du 8 mai 2018 a modifié le paramètre de correction Oracle de chiffrement par défaut de Vulnérable à Atténué. Une fois cette modification en place, les clients Bureau à distance qui disposent des mises à jour ne peuvent pas se connecter aux serveurs qui n’en ont pas (ou aux serveurs mis à jour qui n’ont pas été redémarrés). Pour plus d’informations sur les mises à jour credSSP, consultez 4093492 de la base de connaissances.

Pour résoudre ce problème, mettez à jour et redémarrez tous les systèmes. Pour obtenir la liste complète des mises à jour et plus d’informations sur les vulnérabilités, consultez CVE-2018-0886 | Vulnérabilité d’exécution de code à distance CredSSP.

Pour contourner ce problème jusqu’à ce que les mises à jour soient terminées, case activée Ko 4093492 pour les types de connexions autorisés. S’il n’existe aucune alternative possible, vous pouvez envisager l’une des méthodes suivantes :

  • Pour les ordinateurs clients affectés, définissez de nouveau la stratégie de correction Oracle de chiffrement sur Vulnérable.
  • Modifiez les stratégies suivantes dans le dossier de stratégie de groupe Configuration\ ordinateurModèles\ d’administrationComposants\ WindowsServices Bureau à distance\ Hôte \de session Bureau à distanceSécurité :

    • Exiger l’utilisation d’une couche de sécurité spécifique pour les connexions distantes (RDP) : définissez sur Activé et sélectionnez RDP.

    • Exiger l’authentification utilisateur pour les connexions à distance à l’aide de l’authentification au niveau du réseau : définissez sur Désactivé.

      Importante

      La modification de ces stratégies de groupe réduit la sécurité de votre déploiement. Nous vous recommandons de ne les utiliser que temporairement, le cas échéant.

Pour plus d’informations sur l’utilisation de la stratégie de groupe, consultez Modification d’un objet de stratégie de groupe bloquant.

Après avoir mis à jour les ordinateurs clients, certains utilisateurs doivent se connecter deux fois

Lorsque les utilisateurs se connectent au Bureau à distance à l’aide d’un ordinateur exécutant Windows 7 ou Windows 10 version 1709, ils voient immédiatement une deuxième invite de connexion. Ce problème se produit si l’ordinateur client dispose des mises à jour suivantes :

Pour résoudre ce problème, assurez-vous que les ordinateurs auxquels les utilisateurs souhaitent se connecter (ainsi que les serveurs RDSH ou RDVI) sont entièrement mis à jour jusqu’en juin 2018. Cela inclut les mises à jour suivantes :

Les utilisateurs se voient refuser l’accès sur un déploiement qui utilise Remote Credential Guard avec plusieurs répartiteurs de connexions Bureau à distance

Ce problème se produit dans les déploiements à haute disponibilité qui utilisent au moins deux répartiteurs de connexion Bureau à distance, si Windows Defender Remote Credential Guard est en cours d’utilisation. Les utilisateurs ne peuvent pas se connecter aux bureaux à distance.

Ce problème se produit car Remote Credential Guard utilise Kerberos pour l’authentification et restreint NTLM. Toutefois, dans une configuration à haute disponibilité avec équilibrage de charge, les répartiteurs de connexions Bureau à distance ne peuvent pas prendre en charge les opérations Kerberos.

Si vous devez utiliser une configuration à haute disponibilité avec des répartiteurs de connexions Bureau à distance à charge équilibrée, vous pouvez contourner ce problème en désactivant Remote Credential Guard. Pour plus d’informations sur la gestion de Windows Defender Remote Credential Guard, consultez Protéger les informations d’identification bureau à distance avec Windows Defender Remote Credential Guard.