Il y a peu de choses plus décourageantes que de s’asseoir pour se connecter à distance à son propre PC, de saisir ses identifiants et de se faire dire, de la manière la moins utile qui soit, qu’« une restriction de compte utilisateur (par exemple, une restriction horaire) vous empêche de vous connecter ».

Une restriction horaire ? J’ai moi-même configuré cette machine.

C’était moi, bloqué à l’extérieur d’un serveur Windows une heure après l’avoir migré vers un niveau fonctionnel de domaine plus récent. Après avoir parcouru la documentation de Microsoft et les forums d’administrateurs système, j’ai fini par reconstituer ce qui s’était mal passé, et ce n’était pas du tout ce que suggérait le message d’erreur.

Voici ce que personne ne vous dit d’emblée : cette erreur n’est pas un problème unique, c’est une catégorie. La cause peut aller d’un compte sans mot de passe à un chemin d’authentification qui revient silencieusement à NTLM alors que seul Kerberos est autorisé. Une fois que vous avez compris cela, vous avez déjà fait la moitié du chemin pour la corriger.

Une restriction de compte utilisateur empêche l’ouverture de session

Table des matières

Symptôme / Cause	Environnement	Première action	Fréquence
Vide / aucun mot de passe sur le compte local	Autonome / PC domestique	Correctif 1 — Définir un mot de passe	Fréquent
Compte absent du droit Autoriser l’ouverture de session par Services Bureau à distance	Tous	Correctif 2 — Vérifier l’attribution des droits utilisateur	Fréquent
Compte présent dans le droit Refuser l’ouverture de session par Services Bureau à distance	Tous	Correctif 2 — Retirer de la stratégie de refus	Fréquent
Connexion par IP, NTLM restreint	Domaine	Correctif 3 — Utiliser le nom d’hôte FQDN	Fréquent
Compte verrouillé	Tous	Correctif 4 — Déverrouiller dans ADUC / lusrmgr	Occasionnel
Restriction des heures d’ouverture de session	Domaine	Correctif 4 — Vérifier les heures d’ouverture de session dans ADUC	Occasionnel
Compte dans Protected Users, Kerberos défaillant	Domaine	Correctif 5 — Réparer Kerberos ou retirer du groupe	Admin/renforcé
Les journaux d’événements indiquent un échec d’authentification	Tous	Correctif 6 — Lire le journal Sécurité (événement 4625)	Diagnostic

Le correctif dont vous avez besoin dépend entièrement de votre environnement. Passez en revue ces questions avant de toucher à quoi que ce soit.

Pouvez-vous vous connecter localement avec le même compte ? Si oui, et que seul RDP échoue, il ne s’agit pas d’identifiants incorrects. Le problème est une attribution de droits RDP, une restriction de stratégie ou un problème de chemin d’authentification. Vérifiez Observateur d’événements → Journaux Windows → Sécurité sur la machine cible pour l’ID d’événement 4625. Pour les environnements de domaine, vérifiez également les journaux de sécurité des contrôleurs de domaine, car certains échecs d’authentification ne sont visibles qu’à cet endroit.

Un seul utilisateur ou tout le monde ? Un seul utilisateur verrouillé indique un paramètre au niveau du compte. Tout le monde verrouillé simultanément suggère une modification récente de stratégie, une mise à jour de stratégie de groupe ou un changement de configuration côté serveur.

Machine autonome ou jointe à un domaine ? Les environnements de domaine introduisent des stratégies de groupe Active Directory, Kerberos, des restrictions NTLM et le comportement des Utilisateurs protégés. Si vous êtes sur un PC domestique autonome, seuls les correctifs 1, 2 et 4 sont probablement pertinents. Si vous êtes dans un domaine, tous les correctifs peuvent s’appliquer.

Vous connectez-vous par adresse IP ou par nom d’hôte ? C’est plus important que la plupart des gens ne le pensent. La connexion par adresse IP empêche généralement Windows d’utiliser Kerberos et force un repli vers NTLM. Si NTLM est restreint dans votre environnement, ce repli échoue et vous obtenez exactement cette erreur, même si rien n’a changé concernant votre compte. Voir le correctif 3.

Quelque chose a-t-il changé récemment ? Des mises à jour de stratégie de groupe, des correctifs du système d’exploitation, des mises à niveau du niveau fonctionnel du domaine et un durcissement de la sécurité peuvent tous casser RDP du jour au lendemain sans avertissement visible. Posez toujours cette question avant de supposer que le problème vient de votre compte.

Les correctifs 1–4 sont les plus pertinents ici. Ceux-ci ne nécessitent aucune connaissance d’Active Directory ni de domaine.

Commencez ici, notamment sur un PC domestique ou une machine autonome.

Par défaut, Windows bloque les connexions à distance pour les comptes locaux qui n’ont pas de mot de passe. C’est intentionnel et conforme à une stratégie de sécurité documentée : le paramètre “Accounts: Limit local account use of blank passwords to console logon only” est activé par défaut, ce qui signifie que les comptes sans mot de passe sont limités aux connexions interactives à la console. Le RDP est une connexion interactive à distance et est donc bloqué.

Pourquoi cela se produit: Microsoft documente ce comportement dans le paramètre de stratégie de sécurité locale “Comptes : limiter l’utilisation de mots de passe vides par les comptes locaux à l’ouverture de session sur la console uniquement.” (Microsoft Learn)

Définissez un mot de passe : ouvrez Gestion de l’ordinateur → Utilisateurs et groupes locaux → Utilisateurs → cliquez avec le bouton droit sur le compte → Définir le mot de passe. Si cela résout le problème, vous avez terminé.

Il existe une solution de contournement : vous pouvez désactiver la restriction sur les mots de passe vides via secpol.msc ou la clé de registre LimitBlankPasswordUse. À n’utiliser qu’en dernier recours sur toute machine accessible au réseau.

Avertissement: Désactiver les restrictions sur les mots de passe vides affaiblit considérablement votre surface d’attaque. Définir un mot de passe fort est toujours la bonne solution.

C’est l’une des causes les plus courantes et l’une des plus faciles à ignorer.

Windows utilise deux paramètres complémentaires de Stratégie de groupe pour contrôler l’accès RDP:

Autoriser l’ouverture de session par Services Bureau à distance — accorde le droit de se connecter.
Refuser l’ouverture de session par Services Bureau à distance — bloque le droit de se connecter.

La stratégie Refuser l’emporte toujours sur Autoriser, quelle que soit l’appartenance au groupe. Ce comportement est documenté par Microsoft.

Où le trouver : Ouvrez gpedit.msc → Configuration ordinateur → Paramètres Windows → Paramètres de sécurité → Stratégies locales → Attribution des droits utilisateur.

Vérifiez les deux stratégies. Confirmez que votre compte, ou un groupe auquel il appartient, tel que Remote Desktop Users ou Administrators, apparaît dans Allow. Confirmez qu’il n’apparaît pas dans Deny. Si votre compte est totalement absent de Allow, l’accès RDP est bloqué, quel que soit votre mot de passe ou vos informations d’identification.

Sur les ordinateurs du domaine: Ces droits peuvent être définis au niveau du domaine par la Stratégie de groupe et peuvent outrepasser les paramètres locaux. Si les paramètres locaux semblent corrects mais que le problème persiste, vérifiez l’existence de GPO en conflit à l’aide de gpresult /h report.html sur la machine cible.

Ce simple changement règle plus de problèmes qu’il ne devrait.

Lorsque vous vous connectez en utilisant une adresse IP (par exemple, 192.168.1.100), Windows ne peut généralement pas utiliser l’authentification Kerberos et se rabat alors sur NTLM. Sur des machines domestiques autonomes, cela convient souvent. Sur des machines jointes à un domaine où NTLM est restreint ou désactivé, ce repli échoue silencieusement, et vous obtenez l’erreur de restriction de compte, même si rien n’a changé concernant votre compte.

Utilisez plutôt le nom d’hôte de la machine :

server.yourdomain.com ✔ Recommandé

192.168.1.100 ✘ Force le repli sur NTLM

Utilisez également des informations d’identification au format UPN lors de la connexion à des machines du domaine : user@domain.com plutôt que DOMAIN\user. Cela aide Windows à sélectionner la bonne méthode d’authentification et évite un nombre surprenant de cas particuliers.

Exception : Microsoft a documenté une fonctionnalité Kerberos-over-IP plus récente pour les environnements Windows Server, mais elle nécessite une configuration explicite et n’est pas activée par défaut. (Microsoft Learn : Configuration de Kerberos pour l’adresse IP).

Windows renvoie le même message générique pour plusieurs types de restrictions distincts, ce qui rend cette erreur si frustrante. Les verrouillages de compte et les restrictions d’horaires de connexion sont deux des rares cas où le message d’erreur est littéralement exact.

Pour les comptes locaux (autonomes ou de domaine) Ouvrez lusrmgr.msc → sélectionnez l’utilisateur → vérifiez si l’option Le compte est verrouillé est cochée. Déverrouillez-le le cas échéant.

Pour les comptes de domaine Ouvrez Utilisateurs et ordinateurs Active Directory → recherchez l’utilisateur → double-cliquez → onglet Compte. Cochez l’option Déverrouiller le compte et vérifiez les heures d’ouverture de session.

Un administrateur Windows Server 2016 a décrit avoir rencontré exactement ce problème : la connexion au serveur échouait avec le message de restriction de compte, mais aucune restriction horaire n’avait été configurée délibérément. La cause était une stratégie de groupe qui avait discrètement appliqué une restriction de connexion après une mise à jour de la stratégie de domaine. L’ID d’événement 4625 dans le journal Sécurité aurait montré le sous-code spécifique.

Événement 4625: L’entrée du journal de sécurité pour une ouverture de session ayant échoué inclut un code de sous-état qui identifie la raison exacte. Valeurs courantes : 0xC0000234 (compte verrouillé), 0xC000006F (ouverture de session en dehors des heures autorisées), 0xC0000022 (accès refusé). Vérifiez cela avant d’émettre des hypothèses sur la cause.

Les correctifs 5 et 6 nécessitent un accès à Active Directory et une familiarité avec Kerberos et NTLM. Si vous utilisez un PC domestique autonome, vous pouvez ignorer cette section.

C’est le mode de défaillance qui prend par surprise les administrateurs expérimentés, souvent après une mise à niveau de domaine.

Le groupe de sécurité Utilisateurs protégés d’Active Directory impose des règles d’authentification plus strictes à ses membres :

L’authentification NTLM est totalement bloquée.
Seul Kerberos est autorisé, et uniquement avec le chiffrement AES.
Les types de chiffrement Kerberos RC4 et DES sont interdits.
Les informations d’identification ne sont pas mises en cache sur la machine.

Sur le papier, c’est une excellente hygiène de sécurité. En pratique, cela casse l’accès RDP dans des environnements qui dépendaient silencieusement de NTL, ce qui se produit précisément lorsque vous vous connectez par adresse IP, lorsque le DNS est mal configuré ou lorsque Kerberos n’a pas été entièrement validé après une mise à niveau de domaine. L’utilisateur reçoit le message générique de restriction de compte sans aucune indication qu’Utilisateurs protégés est en cause.

Pourquoi cela apparaît-il après des mises à niveau du domaine : Élever le niveau fonctionnel du domaine permet souvent une application plus stricte des stratégies existantes. Les comptes déjà membres du groupe Utilisateurs protégés mais pour lesquels les mécanismes de repli NTLM étaient auparavant tolérés peuvent soudainement échouer. (Microsoft Learn: Groupe de sécurité Utilisateurs protégés)

Avant de retirer quiconque de Protected Users, essayez ces étapes dans l’ordre :

Utilisez le FQDN de la machine (server.domain.com), et non une adresse IP.
Utilisez des informations d’identification UPN (user@domain.com).
Vérifiez que la résolution DNS fonctionne correctement depuis la machine qui se connecte.
Confirmez la connectivité au contrôleur de domaine et que le service Kerberos est en cours d’exécution.

Si Kerberos fonctionne correctement, le problème disparaît généralement sans modification de compte. Sinon, vous pouvez retirer le compte de Protected Users à titre temporaire :

powershell
$Cred = Get-Credential Remove-ADGroupMember -Identity "Protected Users" -Members YourAccountName -Credential $Cred

À propos de PowerShell Remoting: Cette approche fonctionne lorsque PowerShell Remoting est disponible. Notez que PowerShell Remoting utilise également Kerberos lorsqu’il est disponible et NTLM comme solution de repli ; il peut donc se heurter aux mêmes restrictions d’authentification dans des environnements entièrement durcis. (Microsoft Learn : Sécurité WinRM)

Avertissement: Retirer un compte du groupe Utilisateurs protégés affaiblit sa posture de sécurité. Considérez cela comme une étape de diagnostic, pas comme une solution permanente. La véritable solution consiste à s’assurer que Kerberos fonctionne correctement dans votre environnement.

Déconnectez-vous et laissez l’authentification se mettre à jour avant de réessayer la connexion RDP après toute modification d’appartenance à un groupe.

À ce stade, arrêtez de deviner et commencez à lire.

Sur la machine cible Observateur d’événements → Journaux Windows → Sécurité. Filtrez sur l’ID d’événement 4625. Chaque entrée comprend une raison de l’échec et un code de sous‑état qui identifient la cause exacte, bien plus précisément que le message d’erreur RDP lui‑même.

Pour une traçabilité de l’authentification plus approfondie, activez également : Journaux des applications et des services → Microsoft → Windows → Authentification.

Sur les contrôleurs de domaine Certains échecs d’authentification, notamment ceux liés à Kerberos, ne sont consignés que sur le contrôleur de domaine qui a traité la demande, et non sur la machine cible. Vérifiez les journaux Sécurité sur vos contrôleurs de domaine lorsque les journaux locaux de la cible ne vous donnent pas une vue complète.

Une fois que vous avez trouvé le code de sous‑état dans l’événement 4625, l’erreur cesse d’être vague et devient un problème spécifique et diagnostiquable. Les codes courants sont répertoriés dans la note du correctif 4 ci‑dessus.

Si vous voyez le code d’erreur 0xC07, en particulier sur macOS avec Microsoft Remote Desktop, il apparaît généralement avec la même catégorie de problèmes d’authentification et de restrictions décrits dans cet article. Des rapports de la communauté suggèrent que se connecter par nom d’hôte plutôt que par adresse IP le résout dans de nombreux cas, ce qui est cohérent avec le schéma de repli NTLM décrit dans le Correctif 3.

Il n’existe pas de documentation Microsoft définitive associant clairement 0xC07 à une cause racine unique. Considérez‑le comme un signal que vous êtes dans la bonne catégorie de problème plutôt que comme un diagnostic précis. Les correctifs ci‑dessus s’appliquent.

Lorsque l’accès RDP est refusé avec le message “user account restriction”, Windows fait exactement ce qu’il est censé faire, simplement sans vous indiquer quelle règle vous avez déclenchée.

La façon la plus rapide de résoudre le problème est la suivante :

Utilisez la matrice de diagnostic en haut de cet article pour identifier votre cause la plus probable.
Appliquez le correctif approprié à votre environnement (domestique/autonome ou domaine).
Vérifiez l’Event ID 4625 sur la machine cible si la cause reste incertaine.
Pour les environnements de domaine, consultez également les journaux du contrôleur de domaine et confirmez que Kerberos fonctionne avant de modifier les paramètres du compte.

La plupart du temps, c’est quelque chose de simple. Même lorsque ce n’est pas le cas, c’est généralement quelque chose de logique, simplement masqué derrière un message très peu utile.

Comment corriger la restriction du compte utilisateur empêchant la connexion

Diagnostic rapide

Partie 1 : PC domestique & machines autonomes

Correctif 1 : le compte n'a pas de mot de passe

Solution 2 : Vérifier qui est autorisé à se connecter via RDP

Solution 3 : Arrêtez de vous connecter par adresse IP

Correctif 4 : Vérifier les verrouillages de compte et les restrictions des heures de connexion

Partie 2 : Environnements de domaine et d'entreprise

Correctif 5 : Le groupe Utilisateurs protégés

Solution 6 : Lire les journaux lorsque rien d'autre n'a de sens

Qu'en est-il du code d'erreur 0xC07 ?

Résumé