MENU
  1. ホーム
  2. Python
  3. Errore DSCONVERSIONERROR con NPS e Azure MFA su 802.1X PEAP‑TLS: cause, fix e architettura consigliata

Errore DSCONVERSIONERROR con NPS e Azure MFA su 802.1X PEAP‑TLS: cause, fix e architettura consigliata

Python

Se usi NPS con estensione Azure MFA e le autenticazioni 802.1X cablate in PEAP‑TLS (solo macchina) falliscono con “DSCONVERSIONERROR: No mapping between account names and security IDs was done”, qui trovi diagnosi, cause e un’architettura risolutiva realmente supportata.

Indice

Scenario e sintomi

In un’infrastruttura con Network Policy Server (NPS) già integrato con l’estensione Azure MFA, le autenticazioni utente funzionano regolarmente (OTP, push, ecc.), ma le richieste 802.1X wired in modalità PEAP‑TLS limitata all’autenticazione computer vengono respinte. Dai log si osserva il seguente pattern:

  • RADIUS Access‑Challenge durante lo scambio EAP.
  • L’estensione MFA non tenta il secondo fattore perché interviene solo in caso di Access‑Accept.
  • Messaggio DSCONVERSIONERROR con testo “No mapping between account names and security IDs was done”.
  • Nel dettaglio, l’identità arriva in forma host/FQDN e non viene risolta in SID AD.

Perché accade: la radice tecnica del problema

La pipeline è importante per capire dove si rompe il flusso:

  1. Il supplicant (Windows client) inizia EAP con il proprio certificato macchina (EAP‑TLS incapsulato in PEAP).
  2. Lo switch (RADIUS client) inoltra a NPS.
  3. NPS valuta le Connection Request Policy (CRP) e le Network Policy (NP). Nelle autenticazioni machine‑based spesso si genera un Access‑Challenge intermedio.
  4. Estensione Azure MFA: per design, viene chiamata solo quando NPS è già deciso su Access‑Accept. Se la risposta è Challenge, l’estensione non parte.
  5. Contestualmente, l’estensione tenta di mappare l’identità presentata dal supplicant in UPN/SID. Se riceve host/FQDN o un formato non coerente con un UPN valido o con un oggetto computer risolvibile in AD, la chiamata di directory fallisce e compare DSCONVERSIONERROR (errore di sistema 1332).

In breve: l’errore nasce prima del secondo fattore (fase RADIUS/EAP) e la conversione dell’identità computer‑>SID non è affidabile perché l’estensione è pensata per autenticazioni utente, non per il contesto macchina.

Riepilogo delle cause principali

AreaDettaglio
Mappatura identitàL’estensione MFA prova a recuperare UPN/SID in AD. Se l’identità è host/FQDN, se l’oggetto computer è disabilitato/inesistente o c’è un problema DNS/LDAP, la risoluzione fallisce ⇒ DSCONVERSIONERROR.
Stato RADIUSAzure MFA interviene solo su Access‑Accept. Su Access‑Challenge il flusso MFA non parte: il fallimento è pre‑MFA.
Limiti MFA per macchineL’estensione è progettata per principal utente. Con PEAP/EAP‑TLS macchina il mapping spesso non è supportato o non riconosciuto.

Dove guardare nei log (e cosa aspettarsi)

  • Event Viewer → NPS:
    • Eventi di concessione/negazione (es. 6272/6273) con dettagli su EAP‑Type, gruppi e vincoli.
    • Tracce di “Authentication failed due to a user credentials mismatch” o vincoli non soddisfatti.
  • Event Viewer → Applicazioni e servizi → Microsoft → AzureMFA (AuthN/AuthZ):
    • Messaggi “Access‑Challenge received, skipping MFA”.
    • Errori di conversione identità “No mapping between account names and SIDs”.
  • File di log NPS (%SystemRoot%\System32\LogFiles): utile per correlare Calling‑Station‑ID (MAC) e Client‑IP‑Address (switch).

Diagnosi guidata: verifiche fondamentali

Active Directory: oggetto computer e attributi

  1. Assicurati che l’oggetto computer esista e sia abilitato.
  2. Controlla che non ci siano SPN duplicati: setspn -Q HOST/<FQDN> setspn -X
  3. Verifica l’oggetto SID a directory: Get-ADComputer -Filter "sAMAccountName -eq 'COMPUTERNAME$'" -Properties objectSid,servicePrincipalName | Select-Object Name, objectSid, servicePrincipalName
  4. (Opzionale) Se vuoi confrontare il SID “visto” dal sistema, esegui PowerShell sul domain controller o su una macchina amministrativa per interrogare AD, non il client utente. Evita di basarti su whoami /user in sessione utente: restituisce il SID dell’utente, non della macchina. Usa piuttosto: ([ADSI]"LDAP://<DN-oggetto-computer>").objectSid

NPS: criteri, vincoli e certificati

  1. Connection Request Policy: la richiesta 802.1X cablata deve arrivare al NPS corretto (NAS‑Port‑Type: Ethernet; client RADIUS definito con IP e secret coerenti).
  2. Network Policy per Machine Authentication:
    • Condizioni: appartenere al gruppo Domain Computers (o un gruppo mirato).
    • Constraints: EAP = “Protected EAP (PEAP)” con metodo interno Smart Card or other certificate (EAP‑TLS).
    • Disattiva metodi non usati (MS‑CHAPv2, PAP) per evitare negoziazioni spurie.
  3. Certificato server NPS:
    • EKU: Server Authentication.
    • Catena completa (intermediate + root) installata nel Computer Store.
    • Subject/SAN coerenti con il nome che i client si aspettano (FQDN del NPS).

Tracciamento e raccolta evidenze

REM Abilita tracing RAS/NPS
netsh ras set tracing * enabled

REM Verifica porta RADIUS dall’NPS verso lo switch
Test-NetConnection  -Port 1812

REM Dopo modifiche a criteri/registro, riavvia NPS
net stop ias && net start ias

Work‑around pragmatico: IP_WHITELIST

In laboratori e scenari di break‑fix si è verificato che bypassare l’estensione MFA per specifici RADIUS client consente il buon esito di PEAP‑TLS macchina. Si realizza tramite la chiave di registro dell’estensione:

Percorso: HKLM\SOFTWARE\Microsoft\AzureMfa
Valore:   IPWHITELIST (REGMULTI_SZ)
Contenuto: uno o più indirizzi IP dei RADIUS client (switch) – uno per riga

Dopo l’inserimento, riavvia il servizio NPS:

net stop ias && net start ias

Note importanti di sicurezza:

  • Il traffico proveniente dagli IP in IP_WHITELIST non passerà per l’estensione MFA. È un bypass esplicito, da usare come temporaneo o per ambienti di test.
  • Documenta gli IP, monitora i log e limita l’elenco allo stretto necessario.

La soluzione strutturale consigliata

Allineandosi alle migliori pratiche operative, la stabilità si ottiene separando i flussi:

  • NPS‑MFA: gestisce autenticazioni utente (VPN, Wi‑Fi user‑based, applicazioni RADIUS) con estensione Azure MFA.
  • NPS‑802.1X: gestisce autenticazioni macchina (PEAP/EAP‑TLS) senza estensione MFA.

Vantaggi:

  • Riduzione della complessità nella pipeline EAP/RADIUS.
  • Eliminazione delle ambiguità di mapping identità per i computer.
  • Minore rischio di regressioni ogni volta che si aggiorna l’estensione.

Implementazione passo‑passo della doppia istanza NPS

  1. Provisioning: predisponi due VM/host Windows Server distinti, con NPS installato.
  2. NPS‑MFA:
    • Installa/configura l’estensione Azure MFA.
    • Definisci RADIUS Clients correlati ai flussi utente (es. server VPN). Ordina le policy mettendo in testa quelle user‑based.
  3. NPS‑802.1X:
    • Non installare l’estensione Azure MFA.
    • Definisci i RADIUS Clients che sono switch e controller wired.
    • Configura CRP/NP per EAP‑TLS macchina con il certificato server corretto.
  4. Distribuzione certificati e profili:
    • Certificati macchina ai client (SCEP/PKCS via GPO o MDM).
    • Root/Intermediate nel Trusted Root dei client e dell’NPS.
    • Profili wired 802.1X via GPO o MDM (Intune).
  5. Routing dei flussi: configura gli switch affinché le richieste 802.1X vadano a NPS‑802.1X; lascia VPN/altro verso NPS‑MFA.
  6. Export/import configurazione per replicare RADIUS clients e policy: netsh nps export filename="C:\temp\nps-export.xml" exportPSK=YES netsh nps import filename="C:\temp\nps-export.xml"
  7. Monitoraggio: attiva log dettagliati su entrambi, imposta alert su errori critici e soglie di Access‑Reject.

Controlli di integrità rapidissimi (checklist)

  • Il computer oggetto in AD è abilitato, senza SPN duplicati (HOST/FQDN), e risolvibile dai DC usati dall’NPS.
  • Il certificato server dell’NPS ha EKU corretta e catena completa.
  • La Network Policy macchina usa PEAP con EAP‑TLS come metodo interno; niente MS‑CHAPv2.
  • Gli switch puntano al NPS giusto (802.1X → NPS‑802.1X).
  • L’estensione MFA non è installata sull’NPS che gestisce le macchine oppure il client è in IP_WHITELIST (bypass controllato).
  • Dopo ogni modifica: net stop ias && net start ias.

Approfondimento: PEAP‑TLS vs EAP‑TLS e identità “host/…”

PEAP crea un tunnel TLS protetto; all’interno, come metodo “interno”, si usa tipicamente EAP‑TLS. Nelle autenticazioni macchina, l’identità può apparire come host/<FQDN> o COMPUTERNAME$. L’estensione MFA cerca un UPN o un oggetto risolvibile direttamente; poiché i computer non hanno normalmente un UPN valorizzato e l’identità “host/…” è legata agli SPN, la LookupAccountName verso AD può non produrre un SID ⇒ DSCONVERSIONERROR. Questo è il motivo per cui l’estensione è affidabile nel mondo user‑based ma non in quello machine‑based.

FAQ velocissime

Posso forzare Azure MFA anche per le macchine?
Tecnicamente no in modo supportato: l’estensione è pensata per utenti. Con i computer si ottengono spesso false‑negative di mapping e rotture del flusso EAP.

Perché vedo Access‑Challenge prima del fallimento?
È tipico durante la negoziazione PEAP/EAP quando alcuni vincoli (politiche, trust di certificato, attributi) non sono ancora soddisfatti. L’estensione MFA non si attiva finché NPS non è in stato di Access‑Accept.

Il bypass IP_WHITELIST è sicuro?
È un mezzo, non un fine: limita l’impatto ai soli switch e usalo come ponte verso l’architettura a doppio NPS. Documenta e monitora.

Raccomandazioni operative aggiuntive

  • Log “parlanti”: mantieni tracce NPS e AzureMFA su canali separati, con retention adeguata (almeno 14–30 giorni) e indicizzale in un SIEM.
  • Alert: soglia su aumenti di Access‑Reject per RADIUS client, errori 6273, e occorrenze di DSCONVERSIONERROR.
  • Change management: ogni modifica a criteri/registro deve prevedere test di rollback e finestra.

Alternative moderne da valutare

  • Azure AD Certificate‑Based Authentication (CBA): per scenari cloud dove l’identità è gestita in AAD e il certificato è emesso via MDM; elimina la dipendenza dall’estensione NPS per l’identificazione dell’utente.
  • Profili wired via Intune/MDM: distribuisci automaticamente profili 802.1X e certificati macchina (SCEP/PKCS), riducendo gli errori di configurazione e il fabbisogno di NPS on‑prem per la parte device.

Esempi pratici e snippet utili

Verifica rapida SPN e SID

REM SPN duplicati
setspn -X

REM SPN del computer specifico
setspn -Q HOST/

REM SID da AD via PowerShell RSAT
Get-ADComputer -Filter "sAMAccountName -eq 'COMPUTERNAME$'" -Properties objectSid |
Select-Object Name, objectSid

Impostazione del bypass per uno switch

REM Aggiungi due IP di switch all’IP_WHITELIST
reg add "HKLM\SOFTWARE\Microsoft\AzureMfa" /v IPWHITELIST /t REGMULTI_SZ /d "10.0.10.2\0 10.0.10.3" /f

REM Riavvio di NPS
net stop ias && net start ias

Policy NPS (indicazioni sintetiche)

  • CRP 802.1X: Condition = Client IPv4 in subnet degli switch; Authentication = “Authenticate requests on this server”.
  • NP Macchine: Condition = Gruppo “Domain Computers”; Constraints = PEAP con EAP‑TLS interno; Settings = “Override network policy authentication settings” disattivo.

Conclusioni

DSCONVERSIONERROR è quasi sempre la spia di una mappatura identità macchina fallita in AD, accentuata dal fatto che l’estensione Azure MFA non è progettata per aggiungere un secondo fattore a autenticazioni computer‑based. La strategia più robusta e scalabile è quindi:

  • Macchine → PEAP/EAP‑TLS senza MFA su un NPS dedicato.
  • Utenti → RADIUS + Azure MFA su un altro NPS.

Il bypass tramite IP_WHITELIST è utile come soluzione temporanea o per laboratorio; la segmentazione dei server resta l’approccio definitivo e supportato, che evita rotture di flusso e semplifica i cicli di aggiornamento.

Python
802.1X Azure MFA NPS PEAP-TLS RADIUS Troubleshooting Windows Server
Indice