Restaurez l’accès après une modification de sécurité incorrecte
Les contrôles de sécurité doivent être réversibles. Ce guide couvre les erreurs MFA, certificat, pare-feu, agent et heure serveur.
Utilisez un pilote et gardez un canal de récupération indépendant.
Lira modifie les contrôles d'accès sur les vrais serveurs Windows. Gardez la console, l'hyperviseur, iLO/iDRAC, VPN ou l'accès WinRM testé disponible avant d'appliquer une politique.
Principe de récupération
Garder un canal administratif indépendant en dehors du flux RDP.
Changer un contrôle à la fois, préserver l'état précédent et vérifier la réponse de l'agent avant de continuer.
N'essayez pas à plusieurs reprises une connexion échouée : elle peut créer des blocs supplémentaires et masquer l'incident original.
Vérifiez Windows, le contrôleur de domaine et l'heure du dispositif d'authentification.
Confirmez que le code correspond à l’enrôlement actuel ; demandez un nouveau challenge après l’expiration de la page.
Utilisez un contournement temporaire documenté, uniquement depuis le portail, puis supprimez-le après le test.
Si l'agent ne peut pas recevoir la politique, utilisez console ou WinRM pour restaurer le service d'abord.
Certificat RDP ou erreur d'écoute
Connectez-vous par console ou par une session existante.
Utilisez « Restaurer le service d’écoute » dans le portail ou rétablissez l’empreinte du certificat précédemment enregistrée.
Vérifiez le nom DNS, le SAN, la chaîne de confiance et l’accès à la clé privée avant de rétablir la liaison.
Ne redémarrez les Services Bureau à distance que pendant la fenêtre de maintenance approuvée.
Administrateur bloqué ou mauvaise règle de pare-feu
Ajouter l'adresse d'administration externe actuelle à la liste des autorisations.
Attendez un agent en ligne et confirmez que la règle locale Pare-feu Windows a été supprimée.
Si aucun agent n'est en ligne, utilisez le canal indépendant pour réparer la connectivité de service.
Examinez la source exacte, le nom d'utilisateur et les horodatages avant de changer la politique.
Mauvaise identité du serveur ou nom dupliqué
Comparer le nom d'hôte, l'IP interne, l'IP externe, la clé d'agent et les derniers horodatages du signal de présence.
Arrêtez le service de l’agent devenu obsolète avant d’enrôler un serveur de remplacement.
Utilisez une nouvelle clé d’enrôlement propre à l’espace de travail ; ne vous fiez jamais à un nom d’affichage identique pour établir l’identité.
Conserver l'ancien dossier pour vérification jusqu'à ce que l'incident soit clos.
Questions communes
Le portail peut-il récupérer un serveur sans agent et sans WinRM ?
Non. Au moins un canal indépendant est requis. Utilisez un hyperviseur, iLO/iDRAC/KVM/VNC ou une console locale pour restaurer l'état de l'agent ou du pare-feu.
Et si l'horloge du serveur est mauvaise ?
Synchronisation de l'heure correcte en premier. Le temps incorrect peut invalider les codes MFA, fausser la commande d'événements et faire échouer la validation du certificat.
Consigner la voie d’accès de secours avant le déploiement en production
Tester la console ou l'accès à WinRM, préserver le certificat précédent et l'état de la politique, et assigner un propriétaire d'incident.