Troubleshooting Secure Boot Lenovo : diagnostiquer la transition vers les certificats 2023

Résumé opérationnel

Le symptôme peut être une nouvelle autorité absente, un événement d’échec, une étape perpétuellement en attente ou une récupération BitLocker. Ces résultats correspondent à des couches différentes et n’appellent pas la même correction.

Je collecte avant toute action l’état Secure Boot, le modèle exact, la version BIOS, les événements système, la tâche Secure-Boot-Update, l’état BitLocker et les marqueurs Windows documentés.

La correction recommandée privilégie les mises à jour Windows et firmware validées par Lenovo, une nouvelle tentative bornée et un redémarrage contrôlé. Une écriture manuelle dans les variables UEFI n’est pas un dépannage standard.

Le symptôme peut être une nouvelle autorité absente, un événement d’échec, une étape perpétuellement en attente ou une récupération BitLocker. Ces résultats correspondent à des couches différentes et n’appellent pas la même correction.

Symptôme, contexte et périmètre de l’incident

Je commence par confirmer que l’appareil démarre en UEFI, que Secure Boot est réellement activé et que le modèle ainsi que le BIOS correspondent à une combinaison supportée. Un poste en mode Legacy ou avec Secure Boot désactivé ne suit pas le même scénario.

La tâche Microsoft Windows PI Secure-Boot-Update doit être présente et son historique doit être corrélé aux événements système. Une tâche réussie signifie seulement que l’étape Windows s’est exécutée ; l’application du firmware se produit au redémarrage.

Je définis l’objectif opérationnel avant de choisir le profil ou l’outil. Cette discipline sépare le besoin de sécurité, l’expérience utilisateur, l’autorité de gestion et la preuve attendue. Elle évite aussi qu’un paramètre soit activé uniquement parce qu’il apparaît dans la console.

Je compare toujours l’intention cloud, l’applicabilité, l’état reçu par Windows et le résultat réellement observé. Une affectation réussie, un état vert ou une requête HTTP acceptée ne prouve pas à lui seul que tout le parcours fonctionne.

• Inclus dans l’analyse : Lenovo, Secure Boot, UEFI CA 2023, Troubleshooting
• Inclus dans l’analyse : postes Windows gérés et services Microsoft officiellement documentés
• Inclus dans l’analyse : validation en laboratoire puis pilote représentatif avant généralisation

Questions à résoudre et méthode de diagnostic

Pour diagnostiquer « Troubleshooting Secure Boot Lenovo 2023 », je pars du symptôme exact et de son horodatage. Je formule plusieurs causes possibles, puis je recherche la preuve qui permet de confirmer ou d’écarter chacune d’elles. Une affectation visible dans le portail, un code isolé ou un état ancien ne suffisent pas à établir la cause.

La première collecte reste en lecture seule : contexte utilisateur ou SYSTEM, version de Windows, version des composants, identifiants de corrélation, événements, journaux et état du registre. Je ne vide pas un cache et je ne supprime ni clé, ni certificat, ni objet avant d’avoir conservé ces éléments.

Je localise ensuite la première phase qui diverge, je corrige une seule cause à la fois et je reproduis le scénario initial. Je distingue le contournement temporaire de la correction causale, puis je valide le retour arrière sur un appareil pilote avant toute extension.

La chronologie est centrale : je rapproche l’heure du portail, celle du poste, les éventuels décalages UTC et les identifiants présents dans plusieurs journaux. Deux messages identiques peuvent appartenir à des tentatives différentes. Je conserve donc une fenêtre avant et après l’incident et j’indique clairement ce qui est confirmé, probable, encore hypothétique ou impossible à vérifier avec les données disponibles.

• Question à trancher : comprendre l’architecture, les dépendances et les limites
• Question à trancher : mettre en œuvre un pilote mesurable et reproductible
• Question à trancher : construire un diagnostic et un rollback utilisables par l’exploitation

Cartographie du flux à diagnostiquer

Je commence par confirmer que l’appareil démarre en UEFI, que Secure Boot est réellement activé et que le modèle ainsi que le BIOS correspondent à une combinaison supportée. Un poste en mode Legacy ou avec Secure Boot désactivé ne suit pas le même scénario.

La tâche Microsoft Windows PI Secure-Boot-Update doit être présente et son historique doit être corrélé aux événements système. Une tâche réussie signifie seulement que l’étape Windows s’est exécutée ; l’application du firmware se produit au redémarrage.

Les événements 1800 à 1803 et 1808 décrivent différents états de disponibilité, réussite, attente ou non-applicabilité selon la version de Windows. Les événements 1795 à 1799 signalent des erreurs liées aux opérations Secure Boot ; leur texte et leur horodatage priment sur un numéro isolé.

État initial et prérequis de collecte

Je fige l’état du poste avant toute correction : versions, heure, identité, contexte d’exécution, affectations, autorités de gestion et dernier cycle connu. Cette photographie permet de distinguer la cause initiale des effets produits par les essais suivants.

Je vérifie également que le compte, l’appareil, la licence, la connectivité et les composants nécessaires rendent le scénario réellement applicable. Un prérequis absent doit être traité comme une cause potentielle, pas comme un détail de préparation.

• modèle et numéro de série inventoriés
• catalogue BIOS Lenovo approuvé
• clé BitLocker accessible
• fenêtre de maintenance
• alimentation secteur stable
• accès local ou hors bande
• journaux collectés avant action

Collecte des preuves : journaux, registre et états

Je construis une chronologie unique avec l’heure de la demande, le check-in, l’événement local, la décision du composant et la remontée dans le portail. Je conserve UTC et heure locale, mais j’anonymise UPN, DeviceId, TenantId, noms internes, certificats, adresses et contenus métiers avant partage.

La collecte initiale reste en lecture seule. Je ne vide pas un cache, ne supprime pas une clé, ne réinitialise pas un agent et ne force pas un enrôlement avant d’avoir capturé les preuves. Ces actions changent l’état et peuvent rendre la cause première impossible à démontrer.

Les scripts publiés ici sont des exemples pédagogiques non testés de niveau 1. Toute remédiation réelle doit être au minimum de niveau 2, proposer une simulation, limiter sa cible, expliquer son impact et restaurer l’état précédent. Les opérations privilégiées ou à grande échelle exigent un niveau supérieur et une approbation formelle.

• Capturer état UEFI, BIOS et BitLocker.
• Exporter les événements 1795 à 1808 et 1032.
• Contrôler tâche Secure-Boot-Update.
• Comparer avec le catalogue Lenovo.
• Appliquer la correction au poste laboratoire
• Redémarrer et relire les preuves
• Valider deux cycles avant diffusion

Investigation pas à pas

Je suis l’ordre réel du traitement et je m’arrête à la première divergence démontrée. Poursuivre malgré une preuve manquante créerait des symptômes secondaires et rendrait la chronologie moins fiable.

Pour chaque étape, je note l’action, l’emplacement, le résultat attendu et la méthode de vérification. Les champs Impact et Retour arrière concernent l’éventuelle correction ; la phase d’observation reste en lecture seule autant que possible.

Fonctionnement détaillé et responsabilités

Je commence par confirmer que l’appareil démarre en UEFI, que Secure Boot est réellement activé et que le modèle ainsi que le BIOS correspondent à une combinaison supportée. Un poste en mode Legacy ou avec Secure Boot désactivé ne suit pas le même scénario.

La tâche Microsoft Windows PI Secure-Boot-Update doit être présente et son historique doit être corrélé aux événements système. Une tâche réussie signifie seulement que l’étape Windows s’est exécutée ; l’application du firmware se produit au redémarrage.

Les événements 1800 à 1803 et 1808 décrivent différents états de disponibilité, réussite, attente ou non-applicabilité selon la version de Windows. Les événements 1795 à 1799 signalent des erreurs liées aux opérations Secure Boot ; leur texte et leur horodatage priment sur un numéro isolé.

• modèle et numéro de série inventoriés
• catalogue BIOS Lenovo approuvé
• clé BitLocker accessible
• fenêtre de maintenance

Configuration, exploitation et cas limites

Je vérifie les mises à jour cumulatives, la version de servicing stack intégrée et le BIOS Lenovo disponible pour le modèle exact. Une version destinée à une famille voisine n’est pas une preuve de compatibilité.

L’état BitLocker est relevé avant le redémarrage : protecteurs, chiffrement, identifiant de clé de récupération et présence de l’escrow. L’événement 1032 peut indiquer une préparation BitLocker liée au changement Secure Boot.

Si Windows planifie correctement la mise à jour mais que la chaîne ne change pas après redémarrage, la piste prioritaire devient le firmware. Je collecte les diagnostics Lenovo et Windows avant de flasher ou de modifier une option BIOS.

• Appliquer la correction au poste laboratoire
• Redémarrer et relire les preuves
• Valider deux cycles avant diffusion

Interpréter les résultats sans raccourci

Si l’étape est marquée non applicable, je vérifie la plateforme, l’état Secure Boot, la chaîne déjà présente et la version Windows. Forcer le même indicateur sans comprendre l’inapplicabilité ajoute du bruit et du risque.

La remédiation réelle est au minimum de niveau 2 : simulation, cible explicite, journalisation de l’état initial, confirmation de la clé BitLocker et arrêt immédiat si modèle ou firmware ne correspondent pas au catalogue approuvé.

Après correction, je valide deux redémarrages, la présence des certificats attendus, l’absence de nouveaux événements d’échec et l’accès normal aux applications utilisant des composants pré-OS ou des options ROM.

Je distingue une donnée de configuration, une donnée d’inventaire et une preuve d’exécution. La première décrit ce qui devrait arriver, la deuxième décrit un état observé à un instant donné et la troisième montre ce qu’un composant a réellement tenté. Leur horodatage et leur contexte doivent converger avant toute conclusion.

Je documente les états non applicable, pending, conflict, error et success séparément. Un poste absent d’un rapport n’est pas nécessairement sain ou en échec : il peut être hors ligne, non éligible, non ciblé, en retard de télémétrie ou exclu par la politique de collecte.

Pilote, généralisation et maintien en conditions opérationnelles

Le pilote couvre plusieurs modèles matériels, versions de Windows, profils réseau, populations utilisateur et exceptions métier. Je conserve une cohorte témoin afin de différencier l’effet du changement d’une évolution globale du service, d’une mise à jour applicative ou d’un incident réseau.

Les critères GO sont définis avant le début : couverture, taux de succès, délai de convergence, incidents, tickets support, régressions et temps de rollback. Une moyenne satisfaisante ne masque pas un sous-groupe en échec ; les résultats sont donc segmentés par version, modèle, site et mode de gestion.

Les cas négatifs sont testés volontairement : appareil hors ligne, licence absente, identité non éligible, règle non applicable, réseau filtré et retour arrière. Un design exploitable doit échouer de manière visible, sûre et compréhensible pour le support.

Après généralisation, je programme une revue des exceptions, des permissions, des versions de profil et des dépendances. Le service cloud et Windows évoluent ; une décision correcte aujourd’hui doit rester traçable et être revalidée lorsqu’un prérequis ou une interface change.

Commandes et scripts de diagnostic en lecture seule

Les commandes de cette section servent à inventorier, corréler ou illustrer. Les scripts de diagnostic sont des exemples non testés de niveau 1 : arrêt sur erreur, gestion globale de l’exception et aucune modification volontaire du poste.

Je vérifie toujours le contexte d’exécution. Une commande lancée dans la session utilisateur n’observe pas forcément les mêmes certificats, variables, chemins ou ruches de registre qu’un processus exécuté sous SYSTEM.

# Exemple pédagogique non testé — niveau 1
$ErrorActionPreference = 'Stop'
try {
  Get-CimInstance Win32_ComputerSystem | Select-Object Manufacturer,Model
  Get-CimInstance Win32_BIOS | Select-Object SMBIOSBIOSVersion,ReleaseDate
  Confirm-SecureBootUEFI
  Get-ScheduledTask -TaskPath '\Microsoft\Windows\PI\' -TaskName 'Secure-Boot-Update' | Get-ScheduledTaskInfo
  Get-BitLockerVolume | Select-Object MountPoint,VolumeStatus,ProtectionStatus,KeyProtector
  Get-WinEvent -FilterHashtable @{LogName='System';Id=1795,1796,1797,1798,1799,1800,1801,1802,1803,1808,1032} -MaxEvents 150
} catch { Write-Error "Diagnostic impossible : $($_.Exception.Message)"; exit 1 }

Arbre de décision : symptômes, causes et corrections

Le symptôme oriente l’enquête, mais ne sélectionne jamais seul une correction. Je n’applique la réponse proposée que lorsque la preuve recherchée confirme la cause et que les autres hypothèses importantes sont écartées.

Après correction, je rejoue exactement le scénario initial avec les mêmes points de mesure. Si le symptôme se déplace vers une autre phase, je poursuis l’analyse au lieu de déclarer l’incident résolu.

Validation de la correction et critères de clôture

Je valide le comportement local, puis la remontée dans le service. Les délais du portail sont pris en compte, mais l’état attendu sur le poste doit être vérifiable immédiatement ou selon le cycle officiellement documenté.

La clôture exige un résultat reproductible, l’absence de régression, une cause documentée et une correction minimale. La généralisation reste NO-GO si le résultat varie entre deux postes comparables ou si le retour arrière n’est pas maîtrisé.

• Capturer état UEFI, BIOS et BitLocker.
• Exporter les événements 1795 à 1808 et 1032.
• Contrôler tâche Secure-Boot-Update.
• Comparer avec le catalogue Lenovo.
• Appliquer la correction au poste laboratoire
• Redémarrer et relire les preuves
• Valider deux cycles avant diffusion

Retour arrière, escalade et points de vigilance

Le rollback restaure l’état ou l’autorité précédente et doit lui aussi être vérifié sur le poste. Retirer une affectation sans confirmer la convergence locale ne constitue pas un retour arrière terminé.

Si la cause reste indéterminée, je conserve la chronologie, les journaux anonymisés, les identifiants de corrélation et la liste des hypothèses déjà écartées avant l’escalade. Je n’efface jamais les preuves pour tenter une réparation générique.

• Rollback : arrêter les affectations et isoler le modèle concerné
• Rollback : restaurer la version BIOS uniquement si Lenovo le supporte
• Rollback : récupérer BitLocker avec la clé correspondant au Recovery ID
• Vigilance : ne jamais flasher sur batterie seule
• Vigilance : ne pas injecter manuellement des clés UEFI
• Vigilance : préserver les journaux avant reset
• Vigilance : isoler les modèles atypiques