Après avoir activé l’accès filaire 802.1X (PEAP‑TLS) sur un serveur NPS étendu par Azure MFA, toutes les authentifications machine échouent avec DS_CONVERSION_ERROR. Voici l’analyse, les causes réelles et un plan d’action éprouvé pour corriger durablement l’architecture.
802.1X PEAP‑TLS sur NPS avec l’extension Azure MFA : erreur DS_CONVERSION_ERROR
Vue d’ensemble de la question
Contexte typique : un NPS déjà intégré avec l’extension Azure MFA fonctionne pour les utilisateurs (VPN, Wi‑Fi). Après ajout de l’authentification filaire 802.1X (PEAP‑TLS) au niveau machine, toutes les demandes RADIUS sont rejetées.
- Logs NPS / AuthZOptCh : l’extension MFA ignore les paquets à l’état Access‑Challenge (« seulement traités en Access‑Accept »).
- Logs NPS / AuthZAdminCh : « User not found in on‑premises AD … DS_CONVERSION_ERROR : No mapping between account names and security IDs was done ». L’identifiant présenté est un UPN de type
host/nom_complet_machine.
Réponse & solution (synthèse)
| Problème identifié | Explications | Correctifs / bonnes pratiques |
|---|---|---|
| Incompatibilité MFA ↔ 802.1X machine‑TLS | L’extension Azure MFA ne déclenche que la seconde authentification pour des comptes utilisateurs et uniquement lorsque NPS a déjà produit un Access‑Accept. En PEAP‑TLS niveau machine, NPS émet d’abord un Access‑Challenge pour négocier le tunnel EAP ; l’extension n’intervient pas et tente ensuite de convertir l’UPN host/FQDN (compte ordinateur) en SID utilisateur → échec (DS_CONVERSION_ERROR). | Séparer les flux : • NPS #1 avec extension Azure MFA → authentifications utilisateur (VPN, Wi‑Fi, portails). • NPS #2 sans MFA → authentifications machine 802.1X (PEAP/EAP‑TLS). Alternative court terme : liste blanche IP_WHITELIST (HKLM\SOFTWARE\Microsoft\AzureMfa) pour exclure les IP des commutateurs/contrôleurs 802.1X. Simple mais moins maintenable. |
| Objets AD et certificats | NPS doit résoudre correctement le SID de l’identité présentée ; un décalage UPN/SID ou un certificat machine inadapté renforce l’erreur perçue. | Vérifier que le compte ordinateur est actif, qu’il possède un certificat machine valide (EKU Client Auth) et que la CRL/OCSP de l’autorité émettrice est accessible. Contrôler la concordance SID/identité via whoami /user et inspection de l’objet AD. Assurer la cohérence des stratégies NPS 802.1X (type EAP, chaîne de confiance, contraintes). |
| Journalisation & diagnostic | Les messages de l’extension ne mentionnent pas toujours explicitement DS_CONVERSION_ERROR ; l’échec peut n’apparaître qu’en fin de flux EAP. | Activer le niveau de log maximal côté NPS et côté extension (canaux AuthN/AuthZ) pour remonter le GUID du certificat et l’étape exacte d’échec. Redémarrer le service NPS après toute modification (registre, stratégies). |
Pourquoi cette erreur apparaît‑elle ? (démystification EAP/NPS/MFA)
En 802.1X, l’authentification se déroule via EAP dans des paquets RADIUS. Avec PEAP‑TLS, on construit un tunnel TLS (outer EAP) puis on exécute un inner EAP (ici, TLS pour la machine). La séquence sur NPS ressemble à ceci :
- Le commutateur (ou contrôleur) envoie un Access‑Request avec EAP‑Start/EAP‑TLS ClientHello.
- NPS répond Access‑Challenge pour poursuivre la poignée de main TLS (c’est normal et peut se produire plusieurs fois).
- Lorsque la négociation EAP‑TLS succès, NPS peut enfin produire Access‑Accept.
- Seulement à cet instant, l’extension Azure MFA est invitée à appliquer une seconde étape – sur la base d’une identité utilisateur. Or l’identité présentée est un compte machine (
host/FQDN), sans facteur humain, ce qui invalide le scénario.
La tentative de « conversion » de host/FQDN en SID utilisateur échoue par conception : l’extension n’est pas prévue pour effectuer un challenge MFA sur un principal ordinateur. D’où le message :
DS_CONVERSION_ERROR: No mapping between account names and security IDs was done
UPN presented: host/PC01.corp.exemple.com
Conclusion clé : ce n’est pas un bug de certificat mais une limitation fonctionnelle. Le moteur MFA pour NPS sait faire du second‑facteur pour des utilisateurs, pas pour des machines en PEAP/EAP‑TLS.
Plan d’action recommandé (architecture « deux NPS »)
Pour stabiliser l’infra et éviter les régressions, isolez les cas d’usage :
Étape 1 — Cartographier les flux
- Utilisateurs : VPN, Wi‑Fi entreprise (PEAP‑MSCHAPv2 / EAP‑TLS utilisateur), portail d’administration réseau.
- Machines : LAN filaire 802.1X, IoT/OT gérés par certificats, imprimantes 802.1X.
Étape 2 — Déployer deux rôles NPS
- NPS‑MFA : conserve l’extension Azure MFA. Sert de RADIUS pour VPN et Wi‑Fi utilisateur.
- NPS‑Machine : NPS sans extension. Traitement des authentifications 802.1X machine (PEAP‑TLS ou EAP‑TLS).
Étape 3 — Répartir les clients RADIUS
Sur les commutateurs/contrôleurs, définissez deux serveurs RADIUS et associez le profil 802.1X filaire/IoT au NPS‑Machine uniquement. Exemple (pseudo‑config Cisco‑like) :
radius server NPS-MACHINE
address ipv4 10.10.10.21 auth-port 1812 acct-port 1813
key <secret>
radius server NPS-MFA
address ipv4 10.10.10.22 auth-port 1812 acct-port 1813
key <secret>
aaa group server radius RADIUS-DOT1X
server name NPS-MACHINE
aaa group server radius RADIUS-VPN
server name NPS-MFA
aaa authentication dot1x default group RADIUS-DOT1X
aaa authentication login VPN-Policy group RADIUS-VPN </code></pre>
<h3>Étape 4 — Stratégies NPS</h3>
<p>Sur <strong>NPS‑Machine</strong> :</p>
<ul>
<li><strong>Connection Request Policy</strong> : faire traiter localement les demandes 802.1X filaire (NAS‑Port‑Type = Ethernet, Service‑Type = Framed, EAP MS PEAP/EAP‑TLS autorisé).</li>
<li><strong>Network Policy</strong> : condition <em>Machine Groups</em> (ex. « Domain Computers »), méthode d’authentification <strong>Smart Card or other certificate (EAP‑TLS)</strong> ou <strong>Microsoft: Protected EAP (PEAP)</strong> avec <em>inner method</em> TLS seulement. Chaîne de certificats ancrée sur votre AC interne.</li>
</ul>
<p>Sur <strong>NPS‑MFA</strong> : ne pas accepter les demandes filaires (ou les proxifier vers NPS‑Machine). Conserver les politiques orientées <em>utilisateur</em> et compatibles MFA.</p>
<h3>Étape 5 — GPO côté postes</h3>
<p>Déployer la stratégie « Wired Network (IEEE 802.3) » en <em>Computer Configuration</em> :</p>
<ul>
<li>Authentification : <strong>Machine</strong> (ou Machine puis Utilisateur si votre modèle le requiert).</li>
<li>Méthode EAP : <strong>Smart Card or other certificate</strong> (EAP‑TLS) <em>ou</em> PEAP avec <em>inner EAP‑TLS</em>.</li>
<li>Faire confiance à la racine AC entreprise et au certificat serveur NPS (nom DNS du NPS dans le CN/SAN du certificat).</li>
</ul>
<hr>
<h2>Alternative court terme : exclure les IP 802.1X avec <code>IP_WHITELIST</code></h2>
<p>Si le découpage « deux NPS » n’est pas immédiat, vous pouvez temporairement demander à l’extension MFA d’<em>ignorer</em> les demandes provenant des commutateurs/contrôleurs 802.1X en les ajoutant à la liste blanche.</p>
<h3>Procédure</h3>
<ol>
<li>Sur le serveur NPS équipé de l’extension, créer (ou compléter) la valeur de registre <code>IP_WHITELIST</code> sous <code>HKLM\SOFTWARE\Microsoft\AzureMfa</code>.</li>
<li>Renseigner une liste d’adresses IPv4/IPv6 des équipements 802.1X (une par entrée si la valeur est multiligne).</li>
<li>Redémarrer le service <strong>Network Policy Server</strong>.</li>
</ol>
<p>Impacts :</p>
<ul>
<li>Les flux 802.1X machine <strong>ne déclencheront plus</strong> MFA (attendu), mais les flux utilisateur <em>depuis ces IP</em> seront aussi ignorés. D’où la pertinence d’une solution pérenne avec deux NPS.</li>
</ul>
<hr>
<h2>Bonnes pratiques certificats & Active Directory</h2>
<ul>
<li><strong>Modèles de certificats</strong> : utilisez un modèle <em>Machine</em> (Client Authentication, OID 1.3.6.1.5.5.7.3.2) et, côté serveur NPS, un certificat <em>Serveur NPS</em> (Server Authentication) avec CN/SAN = nom DNS du NPS.</li>
<li><strong>Chaînes & révocation</strong> : publiez CRL/Delta CRL, validez OCSP si utilisé. Les EAP‑TLS rigoureux rejettent si CRL inaccessible.</li>
<li><strong>Inscription auto</strong> : GPO d’auto‑enrôlement pour les ordinateurs du domaine afin d’éviter des postes sans certificat valide.</li>
<li><strong>Enregistrement NPS dans AD</strong> : exécutez « Register server in Active Directory » (ou <code>netsh nps add registeredserver</code>) pour déléguer l’accès en lecture aux attributs nécessaires.</li>
</ul>
<hr>
<h2>Diagnostic guidé (check‑list pas à pas)</h2>
<ol>
<li><strong>Établir si la demande est <em>machine</em> ou <em>utilisateur</em></strong><br>
Recherchez dans les journaux l’identité présentée : <code>host/PC01.corp.exemple.com</code> = machine. Un UPN <code>prenom.nom@domaine</code> = utilisateur.</li>
<li><strong>Valider l’EAP négocié</strong><br>
Assurez‑vous que la stratégie NPS correspond au type EAP attendu (EAP‑TLS ou PEAP‑TLS) et que le bon certificat serveur est proposé.</li>
<li><strong>Inspecter les événements NPS (Event Viewer)</strong><br>
<em>Applications and Services Logs → Microsoft → Windows → NPS/Operational</em> : évènements 6272/6273 et détails EAP. Exemple :
<pre><code>Event ID: 6273 (Network Policy Server denied access)
Reason Code: 49
Reason: The certificate chain was issued by an authority that is not trusted.
Client Friendly Name: SW-Edge‑01
NAS IPv4 Address: 10.10.1.5
Fully-Qualified-User-Name: host/PC01.corp.exemple.com
Lire les traces de l’extension Azure MFA
Vérifiez les canaux AuthZOptCh et AuthZAdminCh et/ou le journal applicatif de l’extension. Vous verrez typiquement :
Extension processing skipped: RADIUS packet state = Access-Challenge
AuthZAdminCh: DS_CONVERSION_ERROR - No mapping between account names and SIDs was done
UPN received: host/PC01.corp.exemple.com
Tester avec un poste « propre »
Révoquez et ré‑émettez le certificat machine, videz le cache EAP (redémarrage du service « Wired AutoConfig »), et retentez.
Confirmer la topologie RADIUS
Sur le commutateur, vérifiez que le profil 802.1X pointe bien vers le NPS‑Machine (ou, à défaut, que l’IP du commutateur est dans IP_WHITELIST).
FAQ — points d’architecture souvent mal compris
Peut‑on faire du MFA sur une authentification 802.1X machine ?
Non. Par nature, la machine n’a pas de « facteur » supplémentaire à prouver. L’extension NPS n’a pas de mode « MFA machine » et ne déclenche pas pendant les échanges Access‑Challenge.
Et sur 802.1X utilisateur (ex. PEAP‑MSCHAPv2) ?
Oui, si la négociation aboutit à un Access‑Accept pour un utilisateur, l’extension peut appliquer le second facteur. Mais cette approche est indépendante du cas machine‑TLS décrit ici.
Pourquoi le message parle de « User not found » alors que c’est un compte machine ?
Parce que l’extension tente de convertir l’identité reçue en utilisateur afin de lancer MFA ; avec host/FQDN elle n’y parvient pas → DS_CONVERSION_ERROR.
Le passage de PEAP‑TLS à EAP‑TLS change‑t‑il quelque chose ?
Pas sur l’aspect MFA machine : le problème n’est pas PEAP vs EAP, mais machine vs utilisateur. En revanche, EAP‑TLS « pur » simplifie parfois le dépannage en supprimant la couche PEAP.
Stratégies alternatives « Zero‑Trust »
- EAP‑TLS pur + conformité post‑connexion : laisser la machine établir la connectivité via certificat, puis imposer du contrôle d’accès (isolation VLAN, NAC, posture) et des politiques de conformité (gestion MDM, durcissement CIS) après mise en réseau.
- Azure AD Certificate‑Based Authentication (CBA) : s’appuyer sur la CBA côté cloud pour les ressources qui la supportent, évitant de surcharger NPS d’un rôle MFA hors de son périmètre machine.
Exemples concrets de configuration NPS
Exporter/relire la configuration
netsh nps show config > C:\Temp\nps-config.txt
Utilisez ce dump pour comparer les serveurs NPS‑MFA et NPS‑Machine (listes des clients RADIUS, politiques, EAP).
Vérifier l’inscription dans AD
netsh nps add registeredserver
Sans cette inscription, NPS peut manquer d’autorisations de lecture nécessaires à certaines vérifications AD.
Paramètres EAP côté NPS‑Machine
- PEAP : cochez « Vérifier l’identité du serveur par certificat », sélectionnez le certificat serveur NPS, désactivez les méthodes internes inutiles, ne laissez que Smart Card or other certificate (EAP‑TLS).
- EAP‑TLS (direct) : même principe de sélection du certificat serveur, pas de méthode interne.
Contraintes de stratégie (Network Policy)
- NAS Port Type : Ethernet.
- Authentication Type : EAP.
- Machine Groups : incluez votre groupe AD (ex. « Domain Computers » ou un groupe cible plus restreint).
Modèle d’analyse des journaux (extraits types)
Évènement NPS 6273 — refus
Reason Code: 16
Reason: Authentication failed due to a user credentials mismatch.
Policy Name: Dot1X-Machine
Identity: host/PC01.corp.exemple.com
EAP Type: EAP-TLS
Trace extension MFA
AuthZOptCh: PacketType=Access-Challenge, MFA bypassed
AuthZAdminCh: DS_CONVERSION_ERROR - No mapping between account names and SIDs was done
UPN: host/PC01.corp.exemple.com
Tableau de décision (quoi faire, tout de suite)
| Symptôme | Cause la plus probable | Action immédiate |
|---|---|---|
| Toutes les machines échouent avec DS_CONVERSION_ERROR | MFA attaché au flux 802.1X machine | Basculer les commutateurs vers NPS‑Machine (sans MFA) ou ajouter leurs IP dans IP_WHITELIST (temporaire) |
| Échecs sporadiques, codes « certificat non approuvé » | Chaîne AC/CRL inaccessible ou certificat serveur NPS inadapté | Vérifier CRL/OCSP, renouveler le certificat serveur, corriger la racine de confiance côté clients |
| Certains VLANs ne passent pas 802.1X | Politiques NPS incomplètes (NAS‑Port‑Type, conditions) | Cloner/ajuster la Network Policy par profil de switch/VLAN, tester avec un poste de référence |
Contrôles de sécurité complémentaires
- Timeouts RADIUS : adaptez dot1x timeout pour laisser NPS conclure EAP‑TLS (surtout avec CRL distantes).
- VLAN critique : définissez un VLAN « remédiation » pour postes non conformes, afin de limiter l’impact des refus.
- SIEM/Monitoring : centralisez Microsoft‑Windows‑NPS/Operational et les journaux de l’extension pour corréler rapidement les DS_CONVERSION_ERROR à l’objet AD fautif et automatiser l’alerte.
En bref
L’erreur DS_CONVERSION_ERROR dans un scénario 802.1X machine sur NPS étendu par Azure MFA n’est pas liée au certificat présenté, mais à une limitation de périmètre : l’extension MFA agit après Access‑Accept et uniquement pour des utilisateurs, pas pour des comptes ordinateur. La solution pérenne consiste à dissocier les serveurs (ou les politiques) : le flux 802.1X machine s’authentifie directement contre AD sans MFA, tandis que les flux utilisateur (VPN/Wi‑Fi) restent protégés par MFA sur un NPS dédié.
Procédure courte « tout‑en‑un » (à imprimer)
- Créer NPS‑Machine (sans extension) et y copier les clients RADIUS (commutateurs/contrôleurs).
- Déplacer les Connection Request Policies et Network Policies filaires 802.1X vers NPS‑Machine (EAP‑TLS/PEAP‑TLS).
- Sur les commutateurs, pointer le profil 802.1X vers NPS‑Machine. Garder NPS‑MFA pour VPN/Wi‑Fi utilisateurs.
- Valider la chaîne AC, CRL, et les modèles de certificats machine.
- Surveiller les journaux NPS et l’extension ; absence de DS_CONVERSION_ERROR = succès.
Annexes utiles
Exemple de GPO « Wired 802.3 » (résumé paramètres)
| Paramètre | Valeur recommandée |
|---|---|
| Auth mode | Machine (ou Machine puis Utilisateur) |
| Méthode EAP | EAP‑TLS (ou PEAP avec inner EAP‑TLS) |
| Valider certificat serveur | Activé, liste des AC de confiance + CN/SAN = DNS du NPS |
| Rapport automatique de l’identité | Activé (utiliser l’identité machine) |
Rappels sur les EKU (Extended Key Usage)
- Client Auth (1.3.6.1.5.5.7.3.2) requis pour les machines.
- Server Auth (1.3.6.1.5.5.7.3.1) requis pour le certificat du NPS.
Codes NPS fréquents
| Code/ID | Signification | Piste |
|---|---|---|
| 6272 | Accès accordé | La partie EAP est OK ; si MFA était attendu côté utilisateur, l’extension s’active ici |
| 6273 | Accès refusé | Regarder « Reason Code » (certificat, stratégie, groupes) |
| 49 | Chaîne non approuvée | Vérifier CRL/OCSP et racines de confiance |
| 16 | Échec d’authentification | Certificat non valide/inadapté, ou mauvaise méthode EAP |
Mot de la fin
Plutôt que de lutter contre le DS_CONVERSION_ERROR à coups de correctifs hasardeux, alignez vos briques avec leur périmètre : NPS‑Machine pour l’accès 802.1X des ordinateurs (certificats, EAP‑TLS), NPS‑MFA pour les flux utilisateur (VPN/Wi‑Fi) nécessitant un second facteur. Vous obtenez ainsi une architecture claire, maintenable et conforme aux principes Zero‑Trust : identité forte et contrôle contextuel, chacun au bon endroit.