Lira RDP Security

GUIDE OPÉRATIONNEL · RDP 2FA / MFA

Déployer RDP 2FA / MFA sans verrouiller les utilisateurs

Lira ajoute un deuxième facteur au processus d’ouverture de session Windows. Traitez l’activation comme une modification du contrôle d’accès : préparez la voie d’accès de secours, enrôlez un utilisateur pilote, validez le fonctionnement depuis un client RDP distinct, puis étendez l’application de la politique.

N’activez pas la MFA pour tous les comptes dès la première étape.

Si aucun utilisateur n’est enrôlé, si le portail est indisponible ou si le Credential Provider ne fonctionne pas correctement, une activation immédiate à grande échelle peut interrompre l’accès distant. Conservez une voie de récupération testée en dehors du parcours RDP protégé.

Pourquoi l'authentification à deux facteurs (2FA/MFA) est importante pour le RDP

Un mot de passe peut être obtenu par phishing, réutilisé depuis un autre service, dérobé par un logiciel malveillant ou deviné. La MFA exige une seconde preuve indépendante avant la création d’une session RDP ; un mot de passe volé ne suffit donc plus, à lui seul, pour compromettre un compte d’administration.

La MFA complète, sans les remplacer, l’authentification au niveau du réseau (NLA), la limitation de l’exposition réseau, le verrouillage des comptes, les comptes d’administrateur nominatifs, la journalisation, l’application des correctifs et une procédure de récupération testée.

Directives et normes en matière de sécurité

L’accès peut-il être restauré depuis la console Lira ?

Oui, tant qu’au moins un canal d’administration indépendant reste disponible.

Ce qui change lors de l’ouverture de session Windows

Le Credential Provider Lira intervient dans le processus d’ouverture de session Windows avant la création de la session de bureau. Après l’acceptation du mot de passe Windows, l’utilisateur protégé effectue la vérification du second facteur configuré.

Les clients RDP existants restent utilisables ; les utilisateurs n’ont pas besoin d’une nouvelle application de bureau à distance. Le risque opérationnel se concentre au point de contrôle de l’authentification, ce qui rend indispensable une activation progressive.

1. Préparez l'accès de récupération

  1. Confirmez l’accès direct au serveur depuis la console ou l’hyperviseur.
  2. Créez ou identifiez un compte administrateur d’urgence dédié et conservez ses identifiants conformément à la politique d’accès privilégié de votre organisation.
  3. Vérifiez que ce compte peut ouvrir une session avant de modifier la politique de MFA.
  4. Indiquez qui est autorisé à utiliser l’accès d’urgence et comment son utilisation sera contrôlée.

Un compte de récupération ne remplace pas la MFA. Il s’agit d’un accès d’urgence contrôlé destiné à rétablir le service.

2. Enrôlez et testez un utilisateur pilote

  1. Sélectionnez un administrateur non partagé ou un utilisateur de test dont les identifiants Windows sont connus pour fonctionner.
  2. Créez l’enrôlement dans le portail Lira et ajoutez le secret TOTP à l’application d’authentification de l’utilisateur.
  3. Vérifiez le code affiché dans le portail avant d’activer la protection.
  4. Activez la MFA uniquement pour cet utilisateur sur un serveur.
  5. Ouvrez une nouvelle connexion RDP depuis un client distinct, puis effectuez l’authentification par mot de passe et la vérification MFA.
  6. Déconnectez-vous, puis répétez le test afin qu’une session mise en cache ne puisse pas masquer un problème.

3. Choisissez délibérément la politique de disponibilité

  • Le mode permissif préserve la disponibilité de RDP lors d’une indisponibilité temporaire du portail ou du réseau, mais suspend provisoirement l’exigence du second facteur.
  • Le mode strict (fail-closed) assure l’application continue de la MFA, mais peut empêcher les utilisateurs de se connecter lorsque le service de vérification est inaccessible.
  • Documentez le mode sélectionné, les exceptions autorisées, le responsable de la récupération et la durée d’indisponibilité maximale acceptable.

4. Étendre l’application de la politique à des groupes contrôlés

Ajoutez les utilisateurs et les serveurs par petits groupes. Après chaque groupe, confirmez les validations réussies, la visibilité des refus, la connectivité des agents et la disponibilité de l’accès d’urgence. Évitez les déploiements généralisés juste avant la nuit, un week-end ou une période de gel des changements.

  • Commencez par un serveur et un utilisateur.
  • Continuez avec les administrateurs qui peuvent signaler les problèmes rapidement.
  • Ensuite, inscrivez les utilisateurs ordinaires par département ou groupe de serveurs.
  • Supprimez les exceptions temporaires uniquement après avoir terminé le bilan du déploiement.

Validation après activation

  • Un utilisateur protégé peut effectuer une nouvelle connexion RDP.
  • Un code TOTP invalide ou expiré est rejeté et un nouveau code actuel réussit.
  • Un utilisateur non assigné suit la politique prévue.
  • Le portail enregistre la décision de la MFA et l’agent reste en ligne.
  • L’écart entre l’horloge du serveur et la source de temps autorisée reste inférieur à la tolérance définie.
  • L'accès à la récupération fonctionne toujours et n'a pas été accidentellement placé sous la même dépendance.

Récupération et retour arrière

  1. Ne réessayez pas plusieurs connexions RDP avec différents mots de passe ; cela peut déclencher le blocage de l’adresse IP.
  2. Utilisez la console testée ou le compte d’urgence pour accéder au serveur.
  3. Désactivez l’application de la politique pour l’utilisateur ou le serveur concerné dans le portail Lira.
  4. Confirmez que l'agent reçoit la politique mise à jour ; redémarrez le service de l'agent seulement si l'exécution de la politique est bloquée.
  5. Testez une nouvelle session RDP, puis vérifiez la synchronisation de l’heure, l’état de l’enrôlement, la connectivité et le fonctionnement du Credential Provider avant de réactiver la MFA.

Questions communes

Pourquoi un code valide peut-il être rejeté ?

TOTP dépend de l’heure. Vérifiez l’heure de Windows, du contrôleur de domaine et des appareils d’authentification. Confirmez également que le code correspond à l’enrôlement actuel et qu’il n’a pas expiré.

Les comptes d'administrateurs partagés devraient-ils utiliser la MFA ?

Les identités partagées réduisent la traçabilité. Préférez des comptes d’administrateur nominatifs avec un enrôlement MFA individuel et réservez un compte d’urgence contrôlé à la récupération.

MFA peut-il être activé pour tous les serveurs en même temps ?

Le portail peut appliquer la politique dans son ensemble, mais le déploiement de la production doit rester échelonné. Un pilote confirme la compatibilité et la récupération avant que le changement affecte l'ensemble du parc serveur.

Préparer le pilote avant d’appliquer la MFA

Connectez-vous à Lira, vérifiez l’état de l’agent, enrôlez un utilisateur et effectuez le premier test tout en conservant un accès de secours par console.

Ouvrez la console Lira