Déconnexion automatique des utilisateurs RDP inactifs en 5 minutes

Connaître d'abord les trois états de session

Chaque session Bureau à distance sur le serveur se trouve dans l'un des trois états suivants. Actif signifie que l'utilisateur est connecté et travaille. Idle signifie connecté, mais sans toucher le clavier ou la souris. Déconnecté signifie que l'utilisateur a fermé la fenêtre RDP, mais que la session et toutes les applications qu'elle contient sont toujours en cours d'exécution sur le serveur.

Cette distinction est importante car Windows a une stratégie distincte pour chaque état. Fixer uniquement une limite d'inactivité est la raison pour laquelle les sessions déconnectées du vendredi sont toujours actives le lundi. Consultez vous-même l'état actuel de votre serveur : ouvrez l'invite de commande sur l'hôte de la session et exécutez :

query session

La même image est visible dans le Gestionnaire des tâches sous l'onglet Utilisateurs.

Ouvrez l'éditeur de stratégie de groupe

Pour un serveur, ouvrez l'éditeur de stratégie de groupe local à partir de la boîte de dialogue Exécuter :

gpedit.msc

Si vous gérez plusieurs serveurs via un domaine, utilisez plutôt la console de gestion des stratégies de groupe et modifiez un GPO lié à l'unité d'organisation qui contient vos serveurs hôtes de session :

gpmc.msc

Accédez ensuite à Configuration ordinateur > Stratégies > Modèles d'administration > Composants Windows > Services Bureau à distance > Hôte de session Bureau à distance > Limites de durée de session. Préférez le côté ordinateur pour une règle à l'échelle du serveur, afin que la limite suive le serveur quel que soit l'utilisateur qui se connecte. Les mêmes limites peuvent également être définies par collection RDS sous Gestionnaire de serveur > Services Bureau à distance > Collections > Propriétés > Session — mais gérez-les en un seul endroit, car la stratégie de groupe l'emporte en cas de conflit.

Définir la limite de durée d'une session inactive

Ouvrez Définir la limite de temps pour les sessions des services Bureau à distance actives mais inactives, définissez-la sur Activé et choisissez la limite d'inactivité : 5 minutes dans la vidéo.

Lorsqu'une session connectée reste inutilisée pendant une période aussi longue, Windows affiche d'abord à l'utilisateur un avertissement à l'écran l'informant qu'il est sur le point de se déconnecter, puis la limite est atteinte. Ce qui se passe à ce stade – déconnexion ou déconnexion complète – est décidé par l'étape suivante.

Définir la limite de déconnexion et le commutateur de déconnexion

Toujours dans le dossier Session Time Limits, définissez les deux autres stratégies :

Définir une limite de temps pour les sessions déconnectées : activez-la et choisissez la durée pendant laquelle une session déconnectée peut durer avant sa fin. 30 minutes à 1 jour sont des choix courants. Il s'agit de la politique qui nettoie les sessions abandonnées par les utilisateurs en fermant la fenêtre RDP.

Terminer la session lorsque les délais sont atteints : activez-le. Ce paramètre unique transforme un délai d'attente en une déconnexion au lieu d'une simple déconnexion. Sans cela, un utilisateur inactif est simplement déconnecté et la session continue de fonctionner – c'est exactement le problème avec lequel vous avez commencé.

Gardez le compte administrateur en dehors de la règle

La configuration de la vidéo laisse délibérément l'administrateur de côté : une session d'administrateur en cours de tâche sur le serveur ne doit pas être déconnectée sous la personne qui exécute le serveur. La meilleure façon de procéder consiste à cibler, et non à une deuxième politique conflictuelle :

Placez les utilisateurs RDP habituels dans leur propre unité d'organisation ou groupe de sécurité et appliquez-leur le GPO de limite de session ; gardez les comptes d'administrateur en dehors de cette portée (avec filtrage de sécurité sur le GPO si nécessaire). Sur un déploiement RDS, le même résultat vient du fait de donner à ces utilisateurs leur propre collection avec ses propres paramètres de session.

Le même itinéraire couvre les véritables exceptions : le rapport de fin de mois ou le compte d'exportation au jour le jour dont le clavier est inactif alors que la machine est occupée à travailler. Attribuez à un tel compte son propre groupe avec des limites d'inactivité plus longues, voire inexistantes, et notez l'exception avec une raison et un propriétaire. Une exception qui n’est pas écrite n’est pas une exception : c’est une rumeur.

Appliquer la politique, avertir les utilisateurs et tester

Appliquez immédiatement la stratégie sur le serveur au lieu d'attendre la prochaine actualisation automatique :

gpupdate /force

Testez ensuite avant de lui faire confiance : connectez-vous avec un compte de test via RDP, laissez la session intacte au-delà de la limite d'inactivité et regardez l'avertissement apparaître et la déconnexion se produire. Exécutez à nouveau la session de requête et confirmez que la session est complètement terminée, et pas seulement déconnectée. Testez également le chemin déconnecté : connectez-vous, fermez la fenêtre RDP et vérifiez que la session se termine après la limite de déconnexion. Ensuite seulement, appliquez les mêmes paramètres à tout le monde.