RDS : bouton « Ajouter un utilisateur ou un groupe » grisé – corriger « Allow log on through Remote Desktop Services » via GPO

Le bouton « Ajouter un utilisateur ou un groupe » est grisé dans secpol.msc pour « Autoriser l’ouverture d’une session par les Services Bureau à distance » ? Voici pourquoi (GPO de domaine, contrôleur de domaine) et comment rétablir l’accès RDP, proprement et en sécurité.

Vue d’ensemble de la question

Vous tentez d’ouvrir une session RDP sur un serveur joint à Active Directory (fréquemment un contrôleur de domaine). L’échec de connexion affiche un message de type :

“To sign in remotely, you need the right to sign in through Remote Desktop Services…”

Lorsque vous ouvrez Stratégie de sécurité locale (secpol.msc) > Stratégies locales > Attribution des droits utilisateur > Autoriser l’ouverture d’une session par les Services Bureau à distance, le bouton Ajouter un utilisateur ou un groupe est grisé. Vous ne pouvez donc pas ajouter le groupe ou l’utilisateur qui doit se connecter.

Ce que cela signifie : l’option grisée indique que le paramètre est imposé par une GPO (stratégie de groupe de domaine). Sur un contrôleur de domaine (DC), il n’existe pas d’« Utilisateurs et groupes locaux » : tout passe par Active Directory et la Console de gestion des stratégies de groupe (GPMC).

Réponse & solution

Pourquoi c’est grisé

• La valeur est définie par une GPO : toute tentative de modification locale est bloquée et l’UI affiche le bouton en grisé.
• Compte insuffisamment privilégié : si vous n’êtes pas membre d’un rôle d’admin adapté (ex. Administrateurs du domaine), vous ne pourrez ni modifier la GPO ni visualiser certains liens d’héritage.
• Spécificité des DC : sur un contrôleur de domaine, il n’y a pas de groupes locaux. Les groupes « Remote Desktop Users » ou autres sont des groupes de domaine et c’est la GPO appliquée aux DC qui leur confère (ou non) le droit « SeRemoteInteractiveLogonRight ».

Chemin exact du paramètre dans une GPO

Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Attribution des droits utilisateur > Autoriser l’ouverture d’une session par les Services Bureau à distance

Nom système du droit : SeRemoteInteractiveLogonRight (et son pendant « interdiction » : SeDenyRemoteInteractiveLogonRight).

Procédure de résolution pas à pas

1. Identifier le rôle de la machine
   • Contrôleur de domaine (DC) : ciblez l’OU Domain Controllers.
   • Serveur membre / poste : ciblez l’OU où se trouve l’objet ordinateur.
2. Configurer les droits via GPMC (obligatoire si le paramètre est géré par GPO)
   • Ouvrez GPMC (gpmc.msc) avec un compte membre de Administrateurs du domaine.
   • Bonnes pratiques :
     • Évitez de modifier la Default Domain Policy.
     • Pour un DC, préférez un GPO dédié lié à Domain Controllers (ou, à défaut, la Default Domain Controllers Policy).
   • Éditez le GPO qui s’applique à la machine : Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Attribution des droits utilisateur > Autoriser l’ouverture d’une session par les Services Bureau à distance
   • Ajoutez Administrators (ne le retirez jamais) et le(s) groupe(s) qui doivent se connecter :
     • Serveur membre : ajoutez un groupe AD dédié (ex. RDP-Servers-Users) ou Remote Desktop Users.
     • Contrôleur de domaine : ajoutez un groupe AD (ex. DC-RDP-Access) soigneusement contrôlé. Par défaut, seuls les Administrateurs devraient y figurer.
   • Vérifiez l’option d’interdiction Refuser l’ouverture d’une session par les Services Bureau à distance (SeDenyRemoteInteractiveLogonRight) : aucun utilisateur/groupe autorisé ne doit y apparaître. Le « Refuser » l’emporte toujours sur « Autoriser ».
3. Gérer l’appartenance aux groupes
   • Serveur membre : ajoutez le compte/le groupe au groupe local Remote Desktop Users (utile pour les ACL/permissions locales) : lusrmgr.msc net localgroup "Remote Desktop Users" /add "DOMAINE\Groupe"
   • Contrôleur de domaine : pas de groupes locaux ; ajoutez les comptes au groupe AD visé par la GPO : Add-ADGroupMember -Identity "DC-RDP-Access" -Members "DOMAINE\jdupont"
4. Forcer et vérifier l’application des GPO
   • Sur la machine cible, exécutez : gpupdate /forcegpresult /h C:\gpo.html Ouvrez C:\gpo.html et contrôlez :
     • Quel GPO définit Autoriser l’ouverture d’une session par les Services Bureau à distance.
     • Que votre groupe/utilisateur apparaît bien dans la liste effective.
   • Équivalent PowerShell (sur la machine cible) : Get-GPResultantSetOfPolicy -ReportType Html -Path C:\gpo.html
   • Si nécessaire, fermez/ouvrez la session ou redémarrez.
5. Re-test RDP
   • Si l’erreur persiste :
     • Assurez-vous que le bon GPO est lié à la bonne OU et s’applique à l’objet ordinateur (filtrage de sécurité/WMI).
     • Vérifiez qu’aucun des groupes de l’utilisateur n’est dans Refuser l’ouverture….
     • Validez les informations d’identification et, si la NLA est activée, la capacité du compte à s’authentifier.

Résultat attendu

Après configuration via GPMC, ajustement des appartenances et vérifications (gpresult, absence d’entrées contradictoires dans Refuser l’ouverture…), la connexion RDP aboutit.

Tableaux récapitulatifs utiles

Symptômes, causes et corrections

Symptôme	Cause probable	Action corrective
Bouton « Ajouter » grisé dans secpol.msc	Paramètre forcé par une GPO	Modifier le GPO appliqué via GPMC
Erreur RDP « need the right to sign in through Remote Desktop Services »	Droit SeRemoteInteractiveLogonRight non accordé	Ajouter le groupe dans le GPO (et retirer du SeDenyRemoteInteractiveLogonRight si présent)
Utilisateur membre de « Remote Desktop Users » mais toujours bloqué	Entrée dans « Refuser l’ouverture… » ou GPO non appliquée	Contrôler l’héritage, le filtrage de sécurité/WMI et le paramètre Refuser
Sur DC, impossibilité d’ajouter dans « groupes locaux »	Les DC n’ont pas de groupes locaux	Utiliser un groupe AD + GPO liée à Domain Controllers

Où lier la GPO et quels groupes viser

Type de machine	OU/Scope recommandé	Groupes à inclure dans « Autoriser… »	Points d’attention
Contrôleur de domaine	Domain Controllers	Administrators + groupe AD dédié (ex. DC-RDP-Access)	N’accordez pas RDP aux non-admins sauf nécessité impérieuse
Serveur membre	OU de l’ordinateur (ex. Servers\RDS)	Remote Desktop Users ou un groupe AD RDP-Servers-Users	Conservez Administrators ; évitez les comptes individuels
Poste client	OU des postes	Groupe AD dédié par périmètre (ex. Helpdesk-RDP)	Limiter par filtrage de sécurité le cas échéant

Étapes détaillées et bonnes pratiques

Création d’un GPO propre et traçable

1. Dans GPMC, créez un nouveau GPO (ex. DC – RDP Logon Rights / Servers – RDP Logon Rights).
2. Ajoutez une description mentionnant l’objectif, le propriétaire et la date.
3. Liez le GPO à l’OU adéquate (Domain Controllers pour les DC).
4. Éditez le paramètre Autoriser l’ouverture d’une session par les Services Bureau à distance et ajoutez les groupes attendus.
5. Contrôlez immédiatement l’option Refuser… pour éviter toute contradiction.

Gestion des groupes recommandée

• Préférez des groupes AD aux comptes individuels afin de déléguer la gestion d’accès sans modifier la GPO.
• Utilisez la nesting strategy (AGDLP/AGUDLP) : groupe global (utilisateurs) → groupe de domaine local (accès RDP) → référencé dans le GPO.
• Sur serveur membre, conserver la cohérence entre le GPO et le groupe local Remote Desktop Users si vous l’utilisez pour d’autres ACL.

Vérifications après déploiement

• RSOP/gpresult : identifiez la GPO « gagnante ».
• Filtrage de sécurité : le Computer doit pouvoir lire et appliquer la GPO (droits Read + Apply group policy).
• Filtrage WMI : vérifiez que la requête n’exclut pas la machine.
• Réplication : si vous avez plusieurs DC, patientez ou forcez la réplication AD/SYSVOL (repadmin /syncall selon vos procédures).

Diagnostics complémentaires

• Journaux d’événements : dans Security, un échec avec Event ID 4625, Status/SubStatus 0xC000015B indique que le type de connexion demandé n’est pas accordé à cet utilisateur (logon type not granted).
• NLA : si l’Authentification au niveau du réseau est active, assurez-vous que le compte peut s’authentifier et négocier une session (mots de passe expirés/verrouillés, restrictions d’heure, etc.).
• Pare-feu : ce cas d’article concerne un droit manquant ; néanmoins, vérifiez que les règles Remote Desktop entrantes sont actives si vous avez toujours un refus.

Sécurité : recommandations essentielles

• Ne retirez jamais le groupe Administrators de Autoriser l’ouverture d’une session par les Services Bureau à distance.
• Limitez fortement l’accès RDP aux DC. Idéalement, passez par un jump server/bastion et journalisez les accès.
• Nommez vos GPO explicitement (ex. DC – RDP Logon Rights) et documentez qui peut modifier quoi.
• Auditez régulièrement les membres de vos groupes d’accès RDP et les entrées dans SeDenyRemoteInteractiveLogonRight.

Dépannage ciblé par scénario

Serveur membre

1. Dans la GPO de l’OU Servers, ajoutez le groupe AD RDP-Servers-Users à Autoriser l’ouverture….
2. Assurez-vous que l’utilisateur est membre (direct ou via nesting).
3. Optionnel : ajoutez le même groupe au groupe local Remote Desktop Users pour des permissions locales :

net localgroup "Remote Desktop Users" /add "DOMAINE\RDP-Servers-Users"

Contrôleur de domaine

1. Dans un GPO lié à Domain Controllers, ajoutez Administrators + un groupe AD DC-RDP-Access.
2. Vérifiez que SeDenyRemoteInteractiveLogonRight ne contient pas vos administrateurs.
3. Déconseillez l’ajout d’utilisateurs non-admins ; si indispensable, justifiez, journalisez et limitez par plage horaire/lieu.

FAQ rapides

Quelle différence entre « Autoriser l’ouverture d’une session locale » et « par les Services Bureau à distance » ?
La première autorise une connexion console locale (physique). La seconde autorise une connexion via RDP (logon type RemoteInteractive). Elles sont indépendantes.

Faut-il redémarrer après ajout dans la GPO ?
Pas nécessaire en général. Un gpupdate /force, une nouvelle ouverture de session et la réplication AD/SYSVOL suffisent.

Le groupe « Remote Desktop Users » suffit-il ?
Uniquement si la GPO qui s’applique accorde le droit SeRemoteInteractiveLogonRight à ce groupe. Sur DC, ce groupe doit être ajouté explicitement dans la GPO liée à Domain Controllers.

Pourquoi l’utilisateur est-il toujours bloqué alors qu’il est dans le « bon » groupe ?
Vérifiez SeDenyRemoteInteractiveLogonRight, l’héritage GPO, le filtrage de sécurité/WMI et les groupes imbriqués (un groupe refusé l’emporte sur un groupe autorisé).

Check-list express

• Machine DC ou serveur membre ? Choisissez l’OU et la GPO en conséquence.
• Modifier la GPO, pas la stratégie locale.
• Autoriser : Administrators + groupe(s) d’accès RDP requis.
• Refuser : aucun utilisateur/groupe autorisé ne doit y figurer.
• Groupes : privilégier des groupes AD dédiés, pas des comptes individuels.
• Validation : gpresult /h ou rsop.msc pour confirmer la GPO gagnante.

Commandes utiles

:: Forcer l’application des stratégies
gpupdate /force

\:: Rapport RSOP
gpresult /h C:\gpo.html
Get-GPResultantSetOfPolicy -ReportType Html -Path C:\gpo.html

\:: Ajouter un groupe AD dans le groupe local (serveur membre)
net localgroup "Remote Desktop Users" /add "DOMAINE\RDP-Servers-Users"

\:: Ajouter un membre à un groupe AD (contrôleur de domaine & serveurs)
Add-ADGroupMember -Identity "RDP-Servers-Users" -Members "DOMAINE\jdupont"

\:: Synchroniser la réplication (à adapter à vos procédures)
repadmin /syncall

Erreurs fréquentes à éviter

• Modifier la Default Domain Policy pour ce besoin. Préférez un GPO dédié.
• Retirer « Administrators » de la liste d’autorisation.
• Oublier le « Refuser » : une seule entrée de refus bloque tous les membres.
• Confondre DC et serveur membre : sur DC, aucun groupe local ; tout se fait via groupes AD + GPO sur Domain Controllers.
• Déléguer à des comptes individuels : utilisez des groupes pour la maintenabilité et les audits.

Informations complémentaires utiles

• Symptôme clé : le bouton grisé dans secpol.msc = paramètre contrôlé par GPO. Modifiez la GPO qui s’applique, pas la stratégie locale.
• Sécurité : accorder RDP à des non‑administrateurs sur un DC n’est généralement pas recommandé. Favorisez un jump server/bastion et restreignez l’accès (groupe dédié + GPO dédiée + audit).
• Rappels pratiques :
  • Ne retirez jamais Administrators de Autoriser l’ouverture…
  • Documentez le GPO (nom explicite : DC – RDP Logon Rights) et limitez sa portée.
  • En cas de doute visuel, lancez rsop.msc pour identifier la GPO « gagnante ».

Annexe : correspondance des droits

• Autoriser l’ouverture d’une session par les Services Bureau à distance : SeRemoteInteractiveLogonRight
• Refuser l’ouverture d’une session par les Services Bureau à distance : SeDenyRemoteInteractiveLogonRight

Exemple complet de mise en œuvre

1. Créer les groupes : RDP-Servers-Users (global) et RDP-Access (domaine local).
2. Imbriquer : ajoutez RDP-Servers-Users dans RDP-Access.
3. GPO : sur l’OU Servers, créez Servers – RDP Logon Rights et, dans Autoriser l’ouverture…, ajoutez Administrators + RDP-Access.
4. Validation : exécutez gpupdate /force puis gpresult /h C:\gpo.html. Vérifiez que la GPO définit bien SeRemoteInteractiveLogonRight et que SeDenyRemoteInteractiveLogonRight est vide pour ces groupes.
5. Test : connectez-vous en RDP avec un utilisateur membre de RDP-Servers-Users.

Conclusion

Quand « Ajouter un utilisateur ou un groupe » est grisé pour le droit RDP, ce n’est pas un bug : la stratégie est contrôlée par GPO. La résolution passe par la modification du GPO approprié (et non la stratégie locale), la gestion rigoureuse des groupes AD, puis la validation RSOP. En appliquant ces étapes et bonnes pratiques, vous restaurez un accès RDP maîtrisé, conforme et durable.