Panne RADIUS NPS après KB5040430 : causes, contournements et correctifs (CVE‑2024‑3596)

Après l’installation de KB5040430 sur un serveur NPS, l’authentification RADIUS d’un VPN derrière pare‑feu tombe en échec sans erreur visible côté NPS/Entra. Voici un guide complet et concret pour diagnostiquer, rétablir le service et sécuriser durablement.

Sommaire

Contexte et symptômes

Vous exploitez Network Policy Server (NPS) sur Windows Server, avec l’extension Entra/Azure NPS pour la MFA, et un pare‑feu/VPN jouant le rôle de client RADIUS. Après le cumul mensuel de juillet 2024 (KB5040430), les connexions VPN échouent. Les journaux NPS et Entra ne montrent rien d’anormal, mais le basculement vers un NPS non mis à jour restaure aussitôt l’accès.

Le problème est spécifique au serveur ayant reçu KB5040430.
Le retour arrière ou l’utilisation d’un NPS non patché rétablit l’authentification.
Plusieurs environnements signalent une interopérabilité RADIUS dégradée avec certains pare‑feux après les durcissements liés à CVE‑2024‑3596 “Blast‑RADIUS”.

Pourquoi cette panne après KB5040430 ?

Pour contrer CVE‑2024‑3596, Microsoft a durci la pile RADIUS en juillet 2024. Ce durcissement rend NPS plus strict, notamment sur des points clés comme l’exigence du champ Message‑Authenticator dans les Access‑Request et la validation de l’intégrité des paquets. Résultat :

Si le pare‑feu/VPN ne génère pas ou ne valide pas correctement Message‑Authenticator, NPS considère la requête non fiable et la rejette très tôt, parfois avant même qu’un journal explicite n’apparaisse côté NPS.
Certains clients RADIUS “tolérés” auparavant deviennent incompatibles jusqu’à mise à jour/contournement.

En parallèle, certains éditeurs de pare‑feu ont livré un workaround côté équipement et annoncé un correctif général attendu pour T4 (calendaire de l’éditeur).

Ce que l’on constate sur le terrain

Le NPS patché refuse en silence des requêtes Access‑Request dépourvues de Message‑Authenticator ou au MAC incohérent, d’où l’absence de traces “classiques”.
Les mêmes sessions, relayées vers un NPS non patché, passent immédiatement.
La désinstallation de KB5040430 fait repartir la production, mais réouvre l’exposition à Blast‑RADIUS et autres faiblesses RADIUS/UDP.

Arbre de décision express

Besoin d’un plan d’action clair selon votre niveau d’urgence et vos contraintes sécurité ? Utilisez ce tableau comme boussole.

Objectif	Action recommandée	Délai	Impact sécurité	Quand l’utiliser
Rétablir en urgence	Désinstaller KB5040430 ou basculer le trafic vers un NPS non patché	Immédiat	Risque accru (CVE réintroduite)	Service critique, aucun contournement côté pare‑feu disponible
Stabiliser sans rollback global	Appliquer le workaround de l’éditeur du pare‑feu (profil RADIUS compatible “durci”)	Court	Modéré à faible	L’éditeur a publié un contournement validé
Optimiser compat vs sécurité	Ajuster la configuration de durcissement RADIUS exposée par Microsoft (cf. doc KB5040268)	Court à moyen	Faible si bien paramétré	Besoin d’un équilibre temporaire en attendant le patch pare‑feu
Solution durable	Mettre à jour pare‑feu/VPN et Entra/Azure NPS Extension, envisager RADIUS sur TLS/DTLS	Moyen	Faible (meilleure posture)	Vision long terme, conformité aux exigences récentes

Procédure de diagnostic pas à pas

Vérifier le serveur NPS

Confirmer le patch : Get-HotFix -Id KB5040430
Redémarrer proprement NPS (utile après changement de config) : net stop ias && net start ias
Port d’écoute : vérifier que NPS écoute en 1812/1813 (ou 1645/1646 si héritage).
Journaux : activer la journalisation texte et Sécurité si ce n’est pas déjà le cas :
- NPS > Comptabilité : cocher “Journaliser les logs d’authentification” (fichiers dans %SystemRoot%\System32\LogFiles).
- Journal Sécurité : surveiller les événements 6272 (autorisé) et 6273 (refusé).
Exporter la config pour sauvegarde/diff : netsh nps export filename="C:\Temp\NPS-export.xml" exportpsk=yes

Vérifier le client RADIUS (pare‑feu/VPN)

Shared secret identique côté NPS et pare‑feu (pas d’espaces ou d’encodage exotique).
Type EAP : EAP‑MSCHAPv2 fréquemment impliqué dans les VPN d’entreprise.
Horloge : NTP cohérent (une dérive excessive peut perturber des vérifications).
Workaround éditeur : appliquer le profil/patch provisoire recommandé pour le client RADIUS.

Captures réseau pour confirmer “Message‑Authenticator”

Sur l’interface entre pare‑feu et NPS, capturez quelques secondes avec un filtre ciblé :

udp.port == 1812 || udp.port == 1645

Dans chaque paquet Access‑Request, recherchez l’attribut Message‑Authenticator :

Présent et valide : le problème est ailleurs (politiques NPS, MFA, extensions).
Absent : le pare‑feu doit être mis à jour/contourné (incompatibilité avec le durcissement).
Invalide : souvent lié au secret partagé ou à une implémentation client non conforme.

Solutions et contournements efficaces

Retour arrière ciblé (dernier recours)

Utile pour rétablir immédiatement un service critique. Deux approches :

Désinstaller KB5040430 : wusa /uninstall /kb:5040430 /quiet /norestart
Bascule vers un NPS non patché (pool/round‑robin DNS, bascule sur l’IP secondaire du RADIUS).

Attention : ceci réintroduit les risques corrigés par le patch. Appliquez des compensations de sécurité : ACL très restrictives, segmentation réseau, supervision, et rollback le plus court possible.

Workaround côté pare‑feu

La majorité des éditeurs ont fourni une configuration temporaire alignant le client RADIUS sur les exigences du serveur NPS “durci” : ajout systématique de Message‑Authenticator, validation stricte des MAC, correction d’encodages d’attributs et de tailles de champs.

Appliquez le workaround immédiatement.
Planifiez l’installation du patch éditeur dès sa sortie (fenêtre T4 annoncée dans les notes de l’éditeur).

Ajuster le durcissement RADIUS côté Windows

Microsoft expose des paramètres de compatibilité autour des mitigations RADIUS introduites avec KB5040430 (référencés dans la documentation associée, par ex. KB5040268). L’idée : piloter finement le niveau d’exigence pour conserver la compatibilité le temps du correctif client, sans désactiver totalement la protection.

Utilisez d’abord un mode d’observation/audit s’il est proposé, puis durcissez progressivement.
Déployez ces réglages via GPO ou script, seulement sur les serveurs NPS concernés.
Testez en pré‑production avant de généraliser.

Bonnes pratiques de déploiement et d’exploitation

Anneaux de mise à jour : staging → pilote → production pour les serveurs NPS.
Redondance NPS : au moins deux nœuds, plan de bascule documenté (DNS, load‑balancer, bascule manuelle).
Surveillance : métriques RADIUS (volumétrie d’Access‑Reject, délais), alertes sur événements 6273.
Contrôles sécurité en cas de rollback : ACL strictes, IP de confiance uniquement, corrélation SIEM.
Long terme : aligner le pare‑feu/VPN sur les exigences récentes et envisager RADIUS sur TLS (RadSec) ou DTLS pour réduire les risques inhérents à RADIUS/UDP.

Checklist de diagnostic rapide

Contrôle	Commande / Action	Résultat attendu	Interprétation si KO
Présence du patch	`Get-HotFix -Id KB5040430`	Le patch est listé	Si absent : chercher un autre facteur
Écoute RADIUS	Scanner les ports 1812/1813	Ports ouverts sur l’IP du NPS	Service NPS arrêté, pare‑feu OS, IP erronée
Attribut `Message‑Authenticator`	Wireshark sur l’interface NPS	Attribut présent dans Access‑Request	Client RADIUS à corriger/mise à jour requise
Journal Sécurité	Événements 6272/6273	Rejets explicites si erreur d’authz	Rejet très en amont (intégrité, paquet invalide)
Extension Entra/Azure NPS	Vérifier la version installée	Version la plus récente	Mettre à jour l’extension (incompatibilité possible)

Exemples de messages et indices utiles

NPS log : “The message authenticator attribute is invalid or missing” (selon niveau de verbosité).
Wireshark : Access‑Request sans attribut 80 (Message‑Authenticator).
VPN : logs génériques de time‑out RADIUS ou “authentication server not responding”.

Plan d’action recommandé

Assurer la continuité : basculer temporairement vers un NPS non patché ou désinstaller KB5040430 en dernier recours, avec des mesures compensatoires.
Appliquer le workaround côté pare‑feu et planifier l’installation du patch éditeur annoncé pour T4.
Suivre les communications Microsoft (KB5040430 / KB5040268) et celles de l’éditeur du pare‑feu ; tester la prochaine CU Windows sur un NPS de pré‑prod avant généralisation.
Vérifier la conformité RADIUS côté client (présence et validité de Message‑Authenticator) et mettre à jour l’extension Entra/Azure NPS si une version plus récente est disponible.

Stratégie de test avant remise en production

Mettez en place un cycle de validation court, reproductible et documenté :

Sandbox : cloner une VM NPS et y appliquer le patch/le réglage de durcissement ciblé.
Jeu d’essai : comptes “techniques” et clients VPN représentatifs (différents EAP, différents profils pare‑feu).
Observabilité : activer les logs NPS et les compteurs de performance (rejets, latence, time‑out).
Critères de sortie : 0 rejet “intégrité” sur 500 essais, latence < x ms, stabilité > N heures.
Go/No‑Go : si OK, élargir à l’anneau pilote puis à la production.

Mesures de sécurité si vous maintenez un rollback temporaire

Limiter l’exposition du NPS aux seules IP du pare‑feu/VPN (ACL strictes réseau/OS).
Segmentation : isoler le VLAN du NPS, bloquer toute sortie non nécessaire.
Supervision renforcée : détection des anomalies volumétriques RADIUS, alertes sur échecs répétés.
Fenêtre minimale : plan de retour à une version corrigée dès qu’un patch pare‑feu certifié est disponible.

FAQ rapide

Pourquoi mes journaux NPS ne montrent rien ?
Parce que le rejet peut intervenir avant l’évaluation des stratégies, au moment des contrôles d’intégrité/messagerie. D’où l’importance des captures réseau et d’une journalisation NPS plus verbeuse.

Ce problème touche‑t‑il tous les EAP ?
Pas nécessairement. Les piles EAP gérées par certains clients RADIUS peuvent mieux gérer Message‑Authenticator. Mais la recommandation reste d’aligner tous les clients sur la stricte conformité.

RadSec/DTLS, est‑ce indispensable ?
Pas obligatoire, mais fortement recommandé en 2024+ pour protéger l’intégrité/confidentialité des échanges RADIUS et éviter des classes d’attaques rendues plus difficiles par TLS/DTLS.

Modèles prêts à l’emploi

Script PowerShell – vérifications de base NPS

# Vérifie la présence du correctif et l'état du service NPS (IAS)
$kb = "KB5040430"
$hotfix = Get-HotFix -Id $kb -ErrorAction SilentlyContinue
if ($hotfix) {
  Write-Host "✅ $kb installé le $($hotfix.InstalledOn)"
} else {
  Write-Host "⚠️ $kb non trouvé"
}

# État du service NPS

Get-Service -Name IAS | Format-List Name,Status,StartType

# Ports d'écoute (nécessite netstat)

netstat -ano | findstr ":1812"
netstat -ano | findstr ":1813"

# Rappel : exporter la configuration NPS

# netsh nps export filename='C:\Temp\NPS-export.xml' exportpsk=yes

Checklist d’audit de configuration NPS

Clients RADIUS déclarés avec l’IP exacte du pare‑feu et le secret partagé à jour.
Stratégies réseau cohérentes : ordre, conditions, contraintes, chiffrement EAP.
Connexion à Entra/MFA opérationnelle (extension à jour, certificats, proxy si nécessaire).
Journalisation activée et centralisée (SIEM) avec conservation suffisante.

Étude de cas synthétique

Environnement : 2 NPS en Windows Server, extension Entra pour MFA, VPN SSL d’un pare‑feu du marché, round‑robin DNS côté VPN.

Incident : après KB5040430, tous les tentatives RADIUS échouent. Aucun log NPS pertinent. Le basculement vers le NPS non patché rétablit l’accès.

Diagnostic : capture Wireshark sur l’interface NPS → Access‑Request sans Message‑Authenticator. L’éditeur du pare‑feu confirme une non‑conformité corrigée dans un patch à venir.

Résolution : mise en place du workaround éditeur (profil RADIUS “strict”), maintien temporaire d’un NPS non patché en secours (ACL très restrictives), puis déploiement du patch éditeur en T4. Réactivation complète du durcissement côté Windows.

Ce qu’il faut retenir

KB5040430 introduit un durcissement RADIUS cohérent avec la mitigation de CVE‑2024‑3596.
Les pannes VPN peuvent venir d’une non‑conformité du client RADIUS face à l’attribut Message‑Authenticator.
Des solutions immédiates existent (rollback/bascule), mais privilégiez vite le workaround puis le patch côté pare‑feu.
Surveillez la doc Microsoft (notamment KB5040268) pour ajuster le niveau de durcissement si nécessaire.
À long terme, visez la conformité RADIUS et, si possible, RADIUS sur TLS/DTLS.

Ressources internes à préparer

Playbook incident RADIUS (diagramme de flux, commandes, modèles de communication).
Procédure de test pré‑production pour les CUs Windows ciblant NPS.
Inventaire des clients RADIUS (pare‑feux, contrôleurs Wi‑Fi, NAS) avec leurs versions et matrices de compatibilité.

Annexes techniques

Structure simplifiée d’un Access‑Request

Code: Access-Request (1)
Identifier: 0xNN
Length: ....
Authenticator: 16 bytes
Attributes:
  User-Name
  NAS-IP-Address / NAS-Identifier
  Called-Station-Id / Calling-Station-Id
  EAP-Message (si EAP)
  Message-Authenticator  <-- requis par le durcissement

Exemples d’indices en hexadécimal

Dans un paquet sans Message‑Authenticator, on ne trouve aucun attribut 0x50 (80). À l’inverse, un attribut 0x50 suivi de 16 octets indique que le champ est présent ; Wireshark en valide aussi la cohérence.

Recommandations de durcissement côté réseau

Bloquer à la périphérie toute source RADIUS non reconnue.
Limiter l’accès RADIUS aux IP de management des pare‑feux/VPN (pas d’adresses dynamiques).
Journaliser et corréler les anomalies RADIUS avec les logs VPN et authentifications Entra.

Conclusion

La panne RADIUS après KB5040430 n’est pas un hasard : elle révèle une incompatibilité que la mitigation Blast‑RADIUS (CVE‑2024‑3596) met en lumière. Rétablissez vite le service si nécessaire, mais surtout alignez votre client RADIUS (pare‑feu/VPN) et vos réglages NPS avec les exigences 2024+. C’est le meilleur compromis entre disponibilité immédiate et sécurité pérenne.