Partager via

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

  • Article

Cet article aborde plusieurs problèmes pouvant affecter l’authentification utilisateur.

Accès refusé, type de connexion restreint

Dans cette situation, un utilisateur de Windows 10 qui tente de se connecter à des ordinateurs Windows 10 ou Windows Server2016 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 interactif) que vous pouvez utiliser. Demandez de l’aide à votre administrateur ou votre 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. Il peut également se produire si le groupe Utilisateurs bureau à distance n’a pas été affecté à l’accès à cet ordinateur à partir du droit de l’utilisateur réseau .

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

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

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

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

  1. Ouvrez l’Éditeur d’objets de stratégie de groupe et connectez-vous à la stratégie locale de l’ordinateur distant.

  2. Accédez à Paramètres de sécurité des paramètres windows de\configuration\ordinateur :\Attribution des droits utilisateur des stratégies locales\, cliquez avec le bouton droit sur Accéder à cet ordinateur à partir du réseau, puis sélectionnez Propriétés.

  3. Vérifiez si Utilisateurs du Bureau à distance (ou un groupe parent) figure dans la liste des utilisateurs et groupes.

  4. Si la liste n’inclut pas Utilisateurs du Bureau à distance ou un groupe parent comme Tout le monde, vous devez l’ajouter à la liste. Si votre déploiement comprend plusieurs ordinateurs, 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 de façon à ajouter Utilisateurs du Bureau à distance.

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

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

Ce comportement est dû à une modification dans Windows. Dans Windows Server 2012 R2 et les versions antérieures, quand un utilisateur se connecte à un Bureau à distance, le Gestionnaire des connexions d’accès à distance contacte le contrôleur de domaine afin d’interroger les configurations propres au Bureau à distance sur l’objet utilisateur dans Active Directory Domain Services (AD DS). Ces informations sont affichées sous l’onglet Profil des services Bureau à distance des propriétés d’objets d’un utilisateur dans le composant logiciel enfichable MMC Utilisateurs et ordinateurs Active Directory.

À compter de Windows Server 2016, le Gestionnaire des connexions d’accès à distance n’interroge plus l’objet utilisateur dans AD DS. S’il est nécessaire que le Gestionnaire des connexions d’accès à distance interroge les services AD DS car vous utilisez des attributs des Services Bureau à distance, vous devez activer la requête manuellement.

Important

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, vérifiez que vous suivez ces étapes attentivement. 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 sauvegarde et la restauration du registre, voir : Procédure de sauvegarde, de modification et de restauration du 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’une carte à puce

Cette section aborde trois scénarios courants dans lesquels un utilisateur ne peut pas se connecter à un Bureau à distance à l’aide d’une carte à puce.

Impossible de se connecter avec une carte à puce à une succursale avec un contrôleur de domaine en lecture seule (RODC, read-only domain controller)

Ce problème se produit dans les déploiements qui incluent un serveur RDSH sur un site de filiale qui utilise un RODC. Le serveur RDSH est hébergé dans le domaine racine. Les utilisateurs sur le site de filiale appartiennent à un domaine enfant et utilisent des cartes à puce pour l’authentification. Le RODC est configuré pour mettre en cache les mots de passe des utilisateurs (le RODC appartient au Groupe de réplication dont le mot de passe RODC est autorisé). Quand des utilisateurs essaient d’ouvrir des sessions sur le serveur RDSH, ils reçoivent des messages tels que « La tentative d’ouverture de session n’est pas valide. Ceci est dû soit à un nom d’utilisateur incorrect, soit à des informations d’authentification incorrectes. »

Ce problème est dû à la façon dont le contrôleur de domaine racine et le RODC gèrent le chiffrement des informations d’identification de l’utilisateur. Le contrôleur de domaine racine utilise une clé de chiffrement pour chiffrer les informations d’identification, et le RODC fournit la clé de déchiffrement au client. 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 méthodes suivantes :

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

Notez que toutes ces solutions demandent des compromis en termes de performances ou de niveau de sécurité.

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

Ce problème se produit quand des utilisateurs se connectent à un ordinateur Windows Server 2008 SP2 qui a été mis à jour avec KB4093227 (2018.4B). Lorsque les utilisateurs tentent de se connecter à l’aide d’une carte à puce, ils ont refusé l’accès avec des messages tels que « Aucun certificat valide trouvé ». Vérifiez que la carte est bien insérée. En même temps, l’ordinateur Windows Server enregistre l’événement d’application « Une erreur s’est produite lors du retrait d’un certificat numérique de la carte à puce insérée. Signature non valide. »

Pour résoudre ce problème, mettez à jour l’ordinateur Windows Server avec la nouvelle publication 2018.06 B de KB 4093227, Description de la mise à jour de sécurité pour la vulnérabilité de déni de service dans le protocole RDP (Remote Desktop Protocol) pour Windows Server 2008 datée du 10 avril 2018.

Impossible de rester connecté avec une carte à puce, et le service Services Bureau à distance se bloque

Ce problème se produit quand les utilisateurs se connectent à un ordinateur Windows ou Windows Server qui a été mis à jour avec le correctif KB 4056446. Dans un premier temps, l’utilisateur peut être en mesure de se connecter au système à l’aide d’une carte à puce, mais ensuite il reçoit un message d’erreur « SCARD_E_NO_SERVICE ». L’ordinateur distant peut cesser de 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 reprises

Ce problème peut se produire quand un utilisateur tente de se connecter à un Bureau à distance qui exécute Windows 10 version 1709 dans un déploiement dans lequel les connexions RDP ne nécessitent pas l’authentification au niveau du réseau. Dans ces conditions, si le Bureau à distance a été verrouillé, l’utilisateur doit entrer ses informations d’identification à deux reprises lors de la connexion.

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

L’utilisateur ne peut pas se connecter et reçoit des messages de type Erreur d’authentification ou Correction d’oracle de chiffrement CredSSP

Lorsque les utilisateurs essaient de se connecter à l’aide de n’importe quelle version de Windows Vista SP2 et des versions ultérieures ou de Windows Server 2008 SP2 et versions ultérieures, ils sont refusés d’accéder et reçoivent des messages tels que 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 ...

Le terme correction d’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. Les mises à jour du 13 mars 2018, « 3B » et ultérieures traitent d’une faille de sécurité qui fait qu’un attaquant pourrait 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 de stratégie de groupe, la correction Oracle de chiffrement, qui a les paramètres possibles suivants :

  • Vulnérable : Les applications clientes qui utilisent CredSSP peuvent revenir aux versions non sécurisées, mais ce comportement expose les Bureaux distants à 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.

    Notes

    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 changé la valeur par défaut de Correction d’oracle de chiffrement de Vulnérable à Atténué. Avec ce changement, les clients Bureau à distance disposant des mises à jour ne peuvent pas se connecter aux serveurs qui n’en disposent pas (ou aux serveurs mis à jour qui n’ont pas été redémarrés). Pour plus d’informations sur les mises à jour de CredSSP, consultez KB 4093492.

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

Pour contourner ce problème jusqu’à ce que les mises à jour soient terminées, consultez KB 4093492 afin de connaître 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, réaffectez la valeur Vulnérable à la stratégie Correction d’oracle de chiffrement.
  • Modifiez les stratégies suivantes dans le dossier de stratégie de groupe de sécurité hôte des services Bureau à distance des services\Bureau\à distance\des modèles\d’administration de configuration\ordinateur :

    • Nécessite l’utilisation d’une couche de sécurité spécifique pour les connexions distantes (RDP) : affectez la valeur Activé et sélectionnez RDP.

    • Requérir l’authentification utilisateur pour les connexions à distance à l’aide de l’authentification au niveau du réseau : affectez la valeur Désactivé.

      Important

      La modification de ces stratégies de groupe altère la sécurité du déploiement. Nous vous recommandons de ne pas les utiliser ou de ne les utiliser que temporairement.

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 que vous avez mis à jour des ordinateurs clients, certains utilisateurs doivent se connecter à deux reprises

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

Pour résoudre ce problème, vérifiez 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. Celle-ci comprend les mises à jour suivantes :

Les utilisateurs se voient refuser l’accès sur un déploiement qui utilise Credential Guard à distance avec plusieurs services Broker pour les connexions Bureau à distance

Ce problème se produit dans les déploiements à haute disponibilité qui utilisent plusieurs services Broker pour les connexions Bureau à distance, si Windows Defender Credential Guard à distance est en cours d’utilisation. Les utilisateurs ne peuvent pas se connecter aux Bureaux à distance.

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

Si vous avez besoin d’utiliser une configuration à haute disponibilité avec des services Broker pour les connexions Bureau à distance à charge équilibrée, vous pouvez contourner ce problème en désactivant Credential Guard à distance. Pour plus d’informations sur la façon de gérer Windows Defender Credential Guard à distance, consultez Protéger les informations d’identification du Bureau à distance avec Windows Defender Credential Guard à distance.