Configuration d’une protection LSA supplémentaire
S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016
Cet article pour les professionnels de l’informatique explique comment configurer une protection supplémentaire pour le processus LSA (Local Security Authority) afin d’empêcher l’injection de code susceptible de compromettre les informations d’identification.
L’autorité LSA, qui comprend le processus LSASS (Local Security Authority Server Service), valide les utilisateurs pour les connexions locales et à distance, et applique les stratégies de sécurité locales. Le système d’exploitation Windows 8.1 et fournit ultérieurement une protection supplémentaire pour le LSA afin d’empêcher la lecture de la mémoire et de l’injection de code par des processus non protégés. Cette fonctionnalité fournit une sécurité supplémentaire pour les informations d’identification que LSA stocke et gère. Le paramètre de processus protégé pour LSA peut être configuré dans Windows 8.1 et versions ultérieures. Lorsque ce paramètre est utilisé avec le verrou UEFI et le démarrage sécurisé, une protection supplémentaire est obtenue, car la désactivation de la clé de Registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa n’a aucun effet.
Exigences spécifiques au processus protégé pour les plug-ins ou pilotes
Pour qu’un plug-in ou pilote LSA soit correctement chargé en tant que processus protégé, il doit répondre aux critères suivants :
Vérification de signature
Le mode protégé exige que tout plug-in chargé dans l’autorité LSA soit signé numériquement avec une signature Microsoft. Par conséquent, les plug-ins qui ne sont pas signés ou qui ne sont pas signés avec une signature Microsoft ne peuvent pas être chargés dans LSA. Ces plug-ins sont notamment les pilotes de cartes à puce, les plug-ins de chiffrement et les filtres de mots de passe.
Les plug-ins LSA qui sont des pilotes, tels que les pilotes de cartes à puce, doivent être signés à l’aide de la certification WHQL. Pour plus d’informations, consultez signature de publication WHQL.
Les plug-ins LSA qui n’ont pas de processus de certification WHQL doivent être signés à l’aide du service de signature de fichiers pour LSA.
Respect du guide de processus SDL (Security Development Lifecycle) Microsoft
Tous les plug-ins doivent être conformes au guide de processus SDL applicable. Pour plus d'informations, consultez l' Annexe SDL (Security Development Lifecycle) Microsoft.
Même si les plug-ins sont correctement signés avec une signature Microsoft, la non-conformité avec le processus SDL peut aboutir à l’échec du chargement d’un plug-in.
Pratiques recommandées
Utilisez la liste suivante pour vérifier soigneusement que la protection LSA est activée avant de déployer globalement la fonctionnalité :
- Identifiez tous les plug-ins et pilotes LSA qui sont utilisés au sein de votre organisation. Incluez des pilotes ou plug-ins non-Microsoft tels que des pilotes de carte à puce et des plug-ins de chiffrement, ainsi que tout logiciel développé en interne qui est utilisé pour appliquer des filtres de mot de passe ou des notifications de modification de mot de passe.
- Vérifiez que tous les plug-ins LSA sont signés numériquement avec un certificat Microsoft afin que le plug-in ne soit pas chargé.
- Vérifiez que tous les plug-ins correctement signés peuvent être chargés dans l’autorité LSA et qu’ils fonctionnent comme prévu.
- Utilisez les journaux d’audit pour identifier les plug-ins et pilotes LSA dont l’exécution en tant que processus protégé échoue.
Limitations introduites avec la protection LSA activée
Si une protection LSA supplémentaire est activée, vous ne pouvez pas déboguer un plug-in LSA personnalisé. Vous ne pouvez pas attacher un débogueur à LSASS lorsqu’il s’agit d’un processus protégé. En général, il n’existe aucun moyen pris en charge de déboguer un processus protégé en cours d’exécution.
Audit pour identifier les plug-ins et pilotes LSA qui ne parviennent pas à s’exécuter en tant que processus protégé
Vous pouvez utiliser le mode audit pour identifier les plug-ins et pilotes LSA dont le chargement échouera en mode de protection LSA. En mode audit, le système génère des journaux des événements qui identifient tous les plug-ins et pilotes qui ne pourront pas être chargés sous LSA si la protection LSA est activée. Les messages sont consignés sans bloquer les plug-ins ni pilotes.
Les événements décrits dans cette section figurent dans le journal des opérations sous Journaux des applications et des services\Microsoft\Windows\CodeIntegrity. Ils peuvent vous aider à identifier les plug-ins et pilotes LSA dont le chargement échoue pour des raisons de signature. Pour gérer ces événements, vous pouvez utiliser l'outil en ligne de commande wevtutil. Pour plus d'informations sur cet outil, voir Wevtutil.
Important
Les événements d’audit ne seront pas générés si Smart App Control est activé sur un appareil. Pour vérifier ou modifier l’état d’activation du contrôle d’application intelligent, ouvrez l’application Sécurité Windows et accédez à la page de contrôle du navigateur d’application&. Sélectionnez le lien des paramètres smart App Control pour vérifier l’état d’activation et modifier la configuration sur Désactivé si vous essayez d’auditer une protection LSA supplémentaire.
Activation automatique du mode Audit
Le mode audit pour une protection LSA supplémentaire est activé par défaut sur les appareils exécutant Windows 11, 22H2. Si votre appareil exécute cette build, aucune action supplémentaire n’est nécessaire pour auditer une protection LSA supplémentaire.
Activer le mode d’audit pour Lsass.exe sur un seul ordinateur en modifiant le Registre
Ouvrez l'Éditeur du Registre (RegEdit.exe) et accédez à la clé de Registre qui se trouve à l'emplacement suivant : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe.
Affectez la valeur AuditLevel=dword:00000008 à la clé de Registre.
Redémarrez l'ordinateur.
Analysez les résultats de l’événement 3065 et de l’événement 3066.
Après ces étapes, vous pouvez voir ces événements dans observateur d'événements dans les journaux des applications et des services/Microsoft/Windows/CodeIntegrity :
Événement 3065 : cet événement rapporte qu’une vérification de l’intégrité du code a déterminé qu’un processus (généralement lsass.exe) a tenté de charger un pilote spécifique qui ne répondait pas aux exigences de sécurité pour les sections partagées. Toutefois, en raison de la stratégie système qui est définie, le chargement de l’image a été autorisé.
Événement 3066 : cet événement rapporte qu’une vérification de l’intégrité du code a déterminé qu’un processus (généralement lsass.exe) a tenté de charger un pilote spécifique qui ne répondait pas aux exigences de niveau de signature Microsoft. Toutefois, en raison de la stratégie système qui est définie, le chargement de l’image a été autorisé.
Important
Ces événements opérationnels ne sont pas générés lorsqu’un débogueur du noyau est attaché et activé sur un système.
Si un plug-in ou pilote contient des sections partagées, l’événement 3066 est consigné avec l’événement 3065. La suppression des sections partagées doit empêcher les deux événements de survenir, à moins que le plug-in ne réponde pas aux exigences de niveau de signature Microsoft.
Pour activer le mode audit pour plusieurs ordinateurs d’un domaine, vous pouvez utiliser l’extension de Registre côté client pour la stratégie de groupe afin de déployer la valeur du Registre de niveau d’audit Lsass.exe. Vous devez modifier la clé de Registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe.
Comment créer le paramètre de valeur AuditLevel dans un objet de stratégie de groupe
Ouvrez la Console de gestion des stratégies de groupe (GPMC, Group Policy Management Console).
Créez un objet de stratégie de groupe qui est lié au niveau du domaine ou qui est lié à l’unité d’organisation qui contient vos comptes d’ordinateurs. Vous pouvez également sélectionner un objet de stratégie de groupe qui est déjà déployé.
Cliquez avec le bouton droit sur l’objet de stratégie de groupe, puis sélectionnez Modifier pour ouvrir l’éditeur de gestion stratégie de groupe.
Développez Configuration ordinateur, Préférences, puis Paramètres Windows.
Cliquez avec le bouton droit sur Registre, pointez sur Nouveau, puis sélectionnez Élément de Registre. La boîte de dialogue Nouvelles propriétés de Registre s'affiche.
Dans la liste Hive , sélectionnez HKEY_LOCAL_MACHINE.
Dans la liste Chemin d'accès à la clé, recherchez SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe.
Dans la zone Nom de la valeur, tapez AuditLevel.
Dans la zone Type valeur , sélectionnez REG_DWORD.
Dans la zone Données de la valeur, tapez 00000008.
Sélectionnez OK.
Notes
Pour que l’objet de stratégie de groupe entre en vigueur, la modification qui lui est apportée doit être répliquée vers tous les contrôleurs du domaine.
Pour choisir une protection LSA supplémentaire sur plusieurs ordinateurs, vous pouvez utiliser l’extension de registre Client-Side pour stratégie de groupe en modifiant HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa. Pour obtenir des instructions, consultez Comment configurer une protection LSA supplémentaire des informations d’identification dans cet article.
Après vous être inscrit : comment identifier les plug-ins et pilotes chargés par lsass.exe
Vous pouvez utiliser le journal des événements pour identifier les plug-ins et pilotes LSA qui n’ont pas pu être chargés en mode de protection LSA. Lorsque le processus protégé LSA est activé, le système génère des journaux des événements qui identifient tous les plug-ins et pilotes qui n’ont pas pu être chargés sous LSA.
Vous pouvez voir ces événements dans observateur d'événements : Microsoft-Windows-Codeintegrity/Operational :
Événement 3033 : cet événement rapporte qu’une vérification de l’intégrité du code a déterminé qu’un processus (généralement lsass.exe) a tenté de charger un pilote qui ne répondait pas aux exigences de niveau de signature Microsoft.
Événement 3063 : cet événement rapporte qu’une vérification de l’intégrité du code a déterminé qu’un processus (généralement lsass.exe) a tenté de charger un pilote qui ne répondait pas aux exigences de sécurité pour les sections partagées.
Les sections partagées sont généralement le résultat de techniques de programmation qui permettent aux données d’instance d’interagir avec d’autres processus qui utilisent le même contexte de sécurité. Il peut en résulter des failles de sécurité.
Comment configurer une protection LSA supplémentaire des informations d’identification
Sur les appareils exécutant Windows 8.1 ou version ultérieure, la configuration est possible en effectuant les procédures décrites dans cette section.
Sur les appareils x86 ou x64 avec ou sans démarrage sécurisé et UEFI
Sur les appareils x86 ou x64 qui utilisent le démarrage sécurisé ou UEFI, une variable UEFI peut être définie dans le microprogramme UEFI lorsque la protection LSA est activée à l’aide de la clé ou de la stratégie de Registre. Lorsque le paramètre est stocké dans le microprogramme, la variable UEFI ne peut pas être supprimée ou modifiée en modifiant le Registre ou par la stratégie utilisée pour activer une protection LSA supplémentaire. La variable UEFI doit être réinitialisée à l’aide des instructions ci-dessous sur la façon de désactiver la protection LSA.
Les appareils x86 ou x64 qui ne prennent pas en charge UEFI ou où le démarrage sécurisé est désactivé ne peuvent pas stocker la configuration de la protection LSA dans le microprogramme. Ces appareils s’appuient uniquement sur la présence de la clé de Registre. Dans ce scénario, il est possible de désactiver la protection LSA à l’aide de l’accès à distance à l’appareil. La désactivation de la protection LSA n’entrera pas en vigueur tant que l’appareil ne redémarre pas.
Activation automatique
Pour les appareils exécutant Windows RT 8.1, une protection LSA supplémentaire est toujours activée et elle ne peut pas être désactivée.
Pour les appareils clients exécutant Windows 11, 22H2, une protection LSA supplémentaire est activée par défaut si les critères suivants sont remplis :
- L’appareil est une nouvelle installation de Windows 11, 22H2 (non mis à niveau à partir de la version précédente).
- L’appareil est joint à l’entreprise (joint à un domaine Active Directory, joint à un domaine Azure AD ou joint à un domaine Azure AD hybride).
- L’appareil est capable d’intégrité du code protégé par Hyperviseur (HVCI)
L’activation automatique d’une protection LSA supplémentaire sur Windows 11, 22H2 ne définit pas de variable UEFI pour la fonctionnalité. Si vous souhaitez définir une variable UEFI, vous pouvez utiliser une configuration ou une stratégie de Registre.
Comment activer la protection LSA sur un seul ordinateur
Utilisation du Registre
Ouvrez l'Éditeur du Registre (RegEdit.exe) et accédez à la clé de Registre qui se trouve à l'emplacement suivant : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
Affectez la valeur suivante à la clé de Registre :
- « RunAsPPL »=dword:00000001 pour configurer la fonctionnalité avec une variable UEFI.
- « RunAsPPL »=dword:00000002 pour configurer la fonctionnalité sans variable UEFI (uniquement sur Windows 11, 22H2).
Redémarrez l'ordinateur.
Utilisation du stratégie de groupe local sur Windows 11, 22H2
Ouvrir l’Éditeur de stratégie de groupe local (gpedit.msc)
Développez Configuration ordinateur, développez Modèles d’administration, développez Système, puis développez l’autorité de sécurité locale.
Ouvrez l’instance Configurer LSASS pour qu’elle s’exécute en tant que stratégie de processus protégée .
Définissez la stratégie sur Activé.
Sous Options, définissez Configurer LSA pour qu’il s’exécute en tant que processus protégé pour :
- « Activé avec le verrou UEFI » pour configurer la fonctionnalité avec une variable UEFI.
- « Activé sans verrouillage UEFI » pour configurer la fonctionnalité sans variable UEFI.
Redémarrez l'ordinateur.
Comment activer la protection LSA à l’aide de stratégie de groupe
Ouvrez la Console de gestion des stratégies de groupe (GPMC, Group Policy Management Console).
Créez un objet de stratégie de groupe qui est lié au niveau du domaine ou qui est lié à l’unité d’organisation qui contient vos comptes d’ordinateurs. Vous pouvez également sélectionner un objet de stratégie de groupe qui est déjà déployé.
Cliquez avec le bouton droit sur l’objet de stratégie de groupe, puis sélectionnez Modifier pour ouvrir l’éditeur de gestion stratégie de groupe.
Développez Configuration ordinateur, Préférences, puis Paramètres Windows.
Cliquez avec le bouton droit sur Registre, pointez sur Nouveau, puis sélectionnez Élément de Registre. La boîte de dialogue Nouvelles propriétés de Registre s'affiche.
Dans la liste Hive , sélectionnez HKEY_LOCAL_MACHINE.
Dans la liste Chemin d’accès à la clé , recherchez SYSTEM\CurrentControlSet\Control\Lsa.
Dans la zone Nom de la valeur, tapez RunAsPPL.
Dans la zone Type valeur , sélectionnez REG_DWORD.
Dans la zone de données Valeur , tapez :
- 00000001 pour activer la protection LSA avec une variable UEFI.
- 00000002 pour activer la protection LSA sans variable UEFI (appliquée uniquement sur Windows 11, 22H2).
Sélectionnez OK.
Comment désactiver la protection LSA
Comment désactiver l’utilisation du Registre
Ouvrez l'Éditeur du Registre (RegEdit.exe) et accédez à la clé de Registre qui se trouve à l'emplacement suivant : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
Définissez « RunAsPPL »=dword:000000000 ou supprimez le DWORD.
Si PPL a été activé avec une variable UEFI, utilisez l’outil de désactivation du processus protégé par l’autorité de sécurité locale pour supprimer la variable UEFI.
Redémarrez l'ordinateur.
Comment désactiver l’utilisation de la stratégie locale sur Windows 11, 22H2
Ouvrir l’Éditeur de stratégie de groupe local (gpedit.msc)
Développez Configuration ordinateur, développez Modèles d’administration, développez Système, puis développez l’autorité de sécurité locale.
Ouvrez l’instance Configurer LSASS pour qu’elle s’exécute en tant que stratégie de processus protégée .
Définissez la stratégie sur Activé.
Sous Options, définissez Configurer LSA sur « Désactivé »
Redémarrez l'ordinateur.
Si vous définissez cette stratégie sur Non configuré et que la stratégie a été activée précédemment, le paramètre précédent n’est pas nettoyé et continuera d’être appliqué. Vous devez définir la stratégie sur Désactivé sous la liste déroulante Configurer LSA pour qu’elle s’exécute en tant que processus protégé pour désactiver la fonctionnalité.
Comment supprimer la variable UEFI de protection LSA
Utilisez l'outil d'exclusion de processus protégé LSA pour supprimer la variable UEFI si l'appareil utilise le démarrage sécurisé.
Pour plus d'informations sur l'outil d'exclusion, voir Télécharger l'outil d'exclusion de processus protégé LSA du Centre de téléchargement Microsoft officiel.
Pour plus d'informations sur la gestion du démarrage sécurisé, voir Microprogramme UEFI.
Avertissement
Lorsque le démarrage sécurisé est désactivé, toutes les configurations liées au démarrage sécurisé et à UEFI sont réinitialisées. Vous ne devez désactiver le démarrage sécurisé que lorsque tous les autres moyens de désactivation de la protection LSA ont échoué.
Vérification de la protection LSA
Pour déterminer si LSA a démarré en mode protégé au démarrage de Windows, recherchez l'événement WinInit suivant dans le journal Système sous Journaux Windows :
- 12 : LSASS.exe a démarré en tant que processus protégé avec le niveau : 4