Bastion Guacamole : dépanner les connexions RDP

Une connexion RDP qui échoue à travers le bastion peut avoir une dizaine de causes différentes, situées à des endroits différents : le bastion, le réseau, le serveur Windows ou l’Active Directory. Plutôt que de modifier des réglages au hasard, on suit une démarche : lire le message, en déduire où se situe le problème, tester une hypothèse à la fois.

Recueillir les informations

Avant tout, relancer une tentative de connexion, puis noter trois choses :

• le message affiché dans le navigateur par Guacamole ;
• si le problème touche toutes les connexions RDP ou une seule ;
• ce qui a changé depuis la dernière fois où cela fonctionnait (nouvelle connexion, nouveau réglage, mise à jour Windows, nouvelle GPO).

Ensuite, lire le journal de guacd au moment de l’échec :

Installation	Commande
Native (partie 1 de la série)	journalctl -u guacd --since "5 min ago" --no-pager
Conteneurs (variante Docker)	cd /opt/bastion && docker compose logs guacd --since 5m

Tableau de diagnostic

Repérer dans le journal ou à l’écran le message le plus proche, puis appliquer la vérification correspondante.

Message ou symptôme	Cause probable	Vérification / correction
Permission denied sur un chemin en .config/freerdp ; la session se ferme aussitôt	guacd (compte daemon) ne peut pas écrire sa configuration FreeRDP	Surcharge systemd de guacd : systemctl show guacd -p Environment doit afficher HOME=/var/lib/guacd
Erreur de certificat ou de TLS	Le serveur présente un certificat autosigné	Cocher « Ignorer le certificat du serveur » dans la connexion, ou déployer un certificat de l’autorité interne
Server refused connection (wrong security type?)	Le mode de sécurité de la connexion ne correspond pas à celui du serveur	Comparer le mode choisi dans Guacamole (NLA) et le réglage du serveur Windows (voir la réflexion sur NLA)
Échec d’authentification alors que le mot de passe semble bon	Identifiant, domaine, droits RDP, compte verrouillé ou NTLM restreint	Voir « Échec d’authentification avec NLA »
Connexion « déjà utilisée » ou refusée dès la deuxième tentative	Limite de 1 connexion par utilisateur et session fantôme restée ouverte	Paramètres → Sessions actives : terminer l’ancienne session
Délai dépassé, connexion réseau refusée	Le port 3389 n’est pas joignable depuis le bastion	Voir « Le serveur n’est pas joignable »

Échec d’authentification avec NLA

Avec NLA, Windows vérifie les identifiants avant d’ouvrir la session. Si l’un des points suivants est faux, la connexion est refusée :

Point à vérifier	Valeur attendue	Où vérifier
Nom d’utilisateur	Identifiant seul, ex. jdupont (sans domaine)	Paramètres de la connexion → Authentification
Domaine	Nom NetBIOS : DOMBTSIG (ou bien identifiant jdupont@dombtsig.local et champ Domaine vide)	Paramètres de la connexion → Authentification
Droit de connexion RDP	Compte membre du groupe Utilisateurs du Bureau à distance du serveur (ou administrateur)	Gestion de l’ordinateur → Groupes locaux, ou GPO
Compte non verrouillé	Pas de verrouillage après des tentatives répétées	« Utilisateurs et ordinateurs Active Directory » → propriétés du compte → onglet Compte
NTLM autorisé	Aucune GPO « Sécurité réseau : restreindre NTLM » qui refuse NTLM vers ce serveur	gpresult /h rapport.html sur le serveur

Pièges liés aux réglages d’utilisation

Réglage	Effet inattendu	Solution
Jetons ${GUAC_USERNAME} / ${GUAC_PASSWORD}	Guacamole transmet à Windows les identifiants du compte Guacamole. Si le bastion n’est pas relié à l’AD, ce compte n’existe pas dans le domaine : l’authentification NLA échoue.	Laisser les champs vides tant que l’extension LDAP n’est pas en place.
Limite de 1 connexion par utilisateur	Fermer l’onglet ne ferme pas la session : la tentative suivante est refusée.	Terminer la session dans Paramètres → Sessions actives, puis prendre l’habitude de se déconnecter proprement.
Restrictions horaires du compte	La connexion au bastion lui-même est refusée en dehors des créneaux.	Vérifier dates, heures et fuseau horaire dans la fiche de l’utilisateur.

Réflexion : faut-il désactiver NLA pour que « ça marche » ?

Lorsque l’authentification NLA échoue, la tentation est grande de décocher l’option NLA sur le serveur Windows (Propriétés système → Utilisation à distance). Souvent, la connexion passe alors… mais le problème n’est pas résolu, il est masqué, et le serveur est affaibli.

Ce que NLA protège

Avec NLA, Windows vérifie l’identité avant de créer quoi que ce soit. Sans NLA, toute machine qui joint le port 3389 obtient l’écran de connexion Windows, c’est-à-dire une vraie session graphique créée sans aucune authentification.

Risque sans NLA	Explication
Surface d’attaque avant authentification	Les failles RDP les plus graves (par exemple BlueKeep, CVE-2019-0708, exécution de code à distance) s’exploitent à ce stade, avant toute authentification. NLA bloque leur exploitation par un attaquant non authentifié.
Déni de service	Chaque tentative de connexion consomme une session et de la mémoire sur le serveur.
Force brute	Les mots de passe sont testés directement sur l’écran de connexion du serveur.
Fuite d’informations	L’écran de connexion peut révéler le nom du domaine, le nom du serveur ou le dernier utilisateur connecté.

Utiliser la désactivation comme test de diagnostic

Désactiver NLA quelques minutes, sur une machine de test, est en revanche un bon outil de diagnostic :

Résultat du test	Conclusion
La connexion passe sans NLA	Le réseau, le port et le certificat sont hors de cause : le blocage vient de l’authentification NLA (identifiants, domaine, compte verrouillé, NTLM).
La connexion échoue toujours	NLA n’est pas en cause : chercher ailleurs (journal guacd, réseau, certificat).

Dans les deux cas, on réactive NLA immédiatement après le test, puis on corrige la vraie cause.

Le serveur n’est pas joignable

Depuis le bastion, tester le port RDP du serveur (remplacer l’adresse) :

timeout 3 bash -c '</dev/tcp/192.168.100.12/3389' && echo "port 3389 ouvert"

Résultat	Où chercher
« port 3389 ouvert »	Le réseau fonctionne : revenir au journal de guacd et au tableau de diagnostic.
Pas de réponse (délai)	Un pare-feu bloque : pare-feu Windows du serveur, règles du pare-feu entre la DMZ et le réseau des serveurs (pfSense), routage.
« Connexion refusée » immédiate	Le serveur répond mais le Bureau à distance n’écoute pas : vérifier qu’il est activé, et que le service « Services Bureau à distance » est démarré.

Fiche de suivi d’incident

À compléter pour chaque problème : elle sert à ne pas tourner en rond, et à documenter la solution pour les suivants. Elle figure aussi, prête à imprimer, dans le livret PDF.

Rubrique	À compléter
Date, heure, connexion concernée
Message affiché par Guacamole
Extrait du journal guacd
Toutes les connexions ou une seule ?
Ce qui a changé récemment
Hypothèses testées (une à la fois) et résultats
Cause identifiée
Correction appliquée
Réglage de sécurité modifié temporairement ? Remis en place le :