L'installation des correctifs de sécurité microsoft du 8 juin 2021 liés à CVE-2021-26414 génère des erreurs sur les contrôleurs de domaine.
Symptom
Lorsque les correctifs de sécurité de Microsoft du 8 juin 2021 liés à CVE-2021-26414 sont installés sur des serveurs Windows hébergeant le ou les contrôleurs de domaine, les erreurs système suivantes sont visibles dans les journaux des événements sur le ou les contrôleurs de domaine toutes les 2 secondes.
Le niveau policy d’authentification côté serveur n’autorise pas l’utilisateur <nom d’utilisateur> à partir de l’adresseFW IP <> à activer le DCOM serveur. Augmentez au moins le niveau d’authentification d’activation pour RPC_C_AUTHN_LEVEL_PKT_INTEGRITY dans l’application cliente.
Environment
PAN-OS Firewall
Windows Server hébergeant le protocole de transport contrôleur(s) de domaine
WMI pour la surveillance du serveur
Cause
Le 8 juin 2021, Microsoft a publié un ensemble de correctifs en réponse à CVE-2021-26414 dans le cadre de sa version mensuelle de correctifs. Pour corriger la vulnérabilité décrite dans CVE-2021-26414, les clients doivent installer les mises à jour publiées le 8 juin 2021 et activer la clé de Registre « HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat » conformément aux instructions de l’article KB5004442.
L’activation de cette clé de Registre obligera RPC les serveurs à appliquer un niveau d’authentification de RPC_C_AUTHN_LEVEL_PKT_INTEGRITY ou supérieur. À la suite de ces modifications de renforcement, les erreurs système suivantes sont visibles sur le ou les contrôleurs de domaine toutes les 2 secondes.
Le niveau policy d’authentification côté serveur n’autorise pas l’utilisateur <nom d’utilisateur> à partir de l’adresseFW IP <> à activer le DCOM serveur. Augmentez au moins le niveau d’authentification d’activation pour RPC_C_AUTHN_LEVEL_PKT_INTEGRITY dans l’application cliente
Voici une chronologie des modifications de renforcement décrites dans Microsoft KB5004442 : comme décrit dans Microsoft KB5004442 :
|
|
|
|
|
|
|
|
Resolution
Vous pouvez résoudre ce problème à l’aide de l’une des solutions de contournement suivantes :
Option 1 : Annuler le correctif Microsoft
La restauration des correctifs de sécurité du 8 juin sur le serveur Windows hébergeant le(s) contrôleur(s) de domaine résout ce problème. Si ce n’est pas une option pour vous, envisagez l’une des options énumérées ci-dessous.
Option 2 : Désactiver la clé de Registre
Pour résoudre ce problème, vous pouvez désactiver la clé de Registre RequireIntegrityActivationAuthenticationLevel sur le serveur Windows hébergeant le ou les contrôleurs de domaine. Si ce n’est pas une option pour vous, considérez l’une des options restantes énumérées ci-dessous.
- Chemin d’accès : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat
- Nom de la valeur : « RequireIntegrityActivationAuthenticationLevel »
- Type: dword
- Données de valeur: 0x00000000 signifie désactivé.
Remarque : Vous devez entrer les données de valeur au format hexadécimal. Vous devez redémarrer votre appareil après avoir défini cette clé de Registre pour qu’elle prenne effet.
À partir du 14 mars 2023, les modifications DCOM de renforcement seront activées par défaut et les clients auront NOT la possibilité de désactiver la clé de Registre. Ainsi, la désactivation de la clé de Registre n’est qu’une solution de contournement temporaire. Vous devriez envisager de mettre en œuvre l’option 3 ou 4 avant mars 2023.
Option 3: Passez au protocole de transport WinRM (Firewall doit exécuter la PAN-OS version 9.0 et supérieure).
À partir de PAN-OS la version 9.0, les clients ont la possibilité d’utiliser WMI ou WinRM comme protocole de transport pour lire les événements du journal de sécurité à partir du ou des contrôleurs de domaine.
Des erreurs système sont observées lors de ONLY l’utilisation WMI comme protocole de transport sur PAN-OS les pare-feu. Ces erreurs sont visibles NOT lors de l’utilisation du protocole de transport WinRM.
Si vous firewall exécutez la PAN-OS version 9.0 et les versions ultérieures, vous pouvez changer le protocole de transport pour utiliser WinRM afin de résoudre ce problème. Le protocole de transport WinRM est également le protocole de transport recommandé par Palo Alto Networks pour la surveillance des contrôleurs de domaine.
(Il n’y a pas de perte de fonctionnalité UtilisateurID lors de l’utilisation de WinRM au lieu de WMI, Le protocole WinRM est plus efficace que WMI, et améliore les performances et l’évolutivité de la surveillance utilisateurID .Le protocole WinRM est plus efficace que WMI, et améliore les performances et l’évolutivité de la surveillance des utilisateursID .WinRM peut aider à réduire firewall CPU l’utilisation de la mémoire, ainsi qu’à améliorer la vitesse à laquelle IP-les mappages utilisateur sont récupérés à partir de serveurs surveillés. Reportez-vous à ce lien pour obtenir des instructions sur la configuration de la surveillance du serveur à l’aide du protocole WinRM).
Si vous avez plusieurs contrôleurs de domaine, vous pouvez basculer le protocole de transport vers WinRM sur ALL les contrôleurs de WMI domaine à la fois ou modifier le protocole de transport sur un contrôleur de domaine à la fois. Assurez-vous que le compte de service dédié dispose des autorisations requises, comme indiqué dans le document , pour utiliser les protocoles de WMI transport WinRM et WinRM.
Pour firewall les déploiements exécutant les PAN-OS versions 8.1 et antérieures, palo alto network recommande de mettre à niveau votre firewall version 9.0+ pour tirer parti des avantages de l’utilisation du protocole de transport WinRM. Veuillez noter que les PAN-OS versions 8.1 et 9.0 arriveront en fin de vie le 1er mars 2022.
Option 4 : Passez à l’agent utilisateurID windows.
Si vous ne pouvez utiliser aucune des 3 options ci-dessus, vous pouvez passer à l’agent utilisateurID Windows pour résoudre ce problème. Pour plus d’informations sur la configuration de l’agent utilisateurID Windows pour le mappage utilisateur, reportez-vous à ce lien.