MENU
  1. Inicio
  2. Windows
  3. Windows Server
  4. Soluciona el error DS\CONVERSION\ERROR con Azure MFA y NPS en 802.1x PEAP‑TLS

Soluciona el error DS\CONVERSION\ERROR con Azure MFA y NPS en 802.1x PEAP‑TLS

Windows Server

¿Tienes un servidor NPS con la extensión de Azure MFA y tu autenticación 802.1x por PEAP‑TLS deja de funcionar mostrando “DS\CONVERSION\ERROR”? En esta guía encontrarás la causa exacta y todas las acciones comprobadas para resolverla sin comprometer la seguridad de tu red.

Índice

Contexto técnico

En muchas redes corporativas se centraliza la autenticación cableada 802.1x (dot1x) en un servidor NPS (Network Policy Server). Al instalar la extensión de Azure MFA sobre ese mismo rol, cualquier solicitud RADIUS que llegue con un estado Access‑Accept se reenvía a la nube para el segundo factor. Sin embargo, cuando el cliente usa EAP‑TLS con certificado de máquina, el proceso requiere un Access‑Challenge intermedio. La extensión no maneja desaf íos (por diseño) y, al intentar resolver el UPN del equipo en Active Directory, lanza el error:

User not found in on‑premises Active Directory
ErrorCode: DSCONVERSIONERROR
No mapping between account names and security IDs was done

Por qué ocurre el error

  • Conversión UPN → SID fallida: la extensión ejecuta una búsqueda LDAP con el UPN contenido en el paquete RADIUS (por ejemplo host/PC01.fabrikam.com). Los objetos de equipo no siempre exponen atributos equivalentes a los de usuarios y la consulta devuelve nulo.
  • Access‑Challenge ignorado: la lógica de la extensión está optimizada para accesos interactivos de usuario. Si NPS responde Access‑Challenge, se descarta el flujo completo pensando que el cliente “no es compatible”.
  • Conflicto de credenciales: mezclar certificados de máquina (que no requieren MFA) con una capa de MFA de usuario genera rutas de código poco probadas.

Pistas visibles en los registros

  • En el visor de eventos, AzureMFA\Authentication muestra DSCONVERSIONERROR.
  • En Security, NPS anota un Failure Reason = 66 – Access‑Challenge seguido de Discarded por la extensión.
  • WireShark evidencia que el switch manda una solicitud RADIUS, NPS responde Challenge, el paquete nunca vuelve al switch y se reinicia el handshake.

Pasos de diagnóstico recomendados

  1. Verificar existencia del objeto de equipo
    Confirmar en Active Directory que PC01$ está habilitado, pertenece a la OU correcta y su UPN coincide exactamente con el atributo host/PC01.fabrikam.com.
  2. Resolver SID manualmente
    En el NPS:
    wmic useraccount where name='PC01$' get sid Si el comando no devuelve SID, el problema es de replicación o el objeto está corrupto.
  3. Revisar directivas de red
    • Tipo de acceso: Ethernet.
    • Restricciones → Authentication Methods: solo PEAP con Smart Card or other certificate (EAP‑TLS).
    • Desactivar métodos heredados como MS‑CHAPv2.
  4. Activar logs detallados en NPS
    NPS → Properties → Accounting; marcar Log Successful and Rejected Attempts y habilitar IAS format. Esto graba el identificador de cuenta exacto que llega en cada petición.
  5. Incrementar verbosidad en la extensión
    Editar HKLM\SOFTWARE\Microsoft\AzureMfa y establecer RADIUSAUDITLEVEL = 3 para capturar trazas de conversión UPN→SID.

Soluciones prácticas

Opción A – Corregir el objeto de equipo

Si la causa es un UPN malformado o un atributo ausente, basta con:

  • Reestablecer la unión al dominio: dsregcmd /leave seguido de Add‑Computer /DomainName.
  • Sincronizar las DCs y reiniciar el servicio Netlogon en el NPS.

Opción B – Whitelist temporal

Mientras se soluciona, permite que el switch se salte el MFA:

reg add HKLM\SOFTWARE\Microsoft\AzureMfa /v IPWHITELIST /t REGSZ /d 10.0.0.10

Tras reiniciar Network Policy Server, las solicitudes desde 10.0.0.10 llegarán a un Access‑Accept directo.

Opción C – Separar roles (recomendado)

ServidorFunciónExtensión MFATráfico RADIUS
NPS #1Autenticación de usuarios VPN/Wi‑FiInstaladaUsers → Azure AD MFA
NPS #2Autenticación de equipos 802.1xNo instaladaSwitches → AD solo

Esta arquitectura evita que la extensión intercepte desafíos TLS de máquina, simplifica el troubleshooting y permite escalar ambos servicios de forma independiente.

¿Necesitas MFA en 802.1x?

Microsoft solo lo recomienda si los certificados son de usuario (no de equipo) y se combina con métodos push, OATH o FIDO2. Con certificados de máquina el MFA carece de interacción y aporta poca seguridad adicional, además de introducir complejidad.

Buenas prácticas adicionales

  • Certificado CA intermedia dedicada: evita dependencias con la CA que firma certificados de usuario.
  • Renovación automática vía GPO: comprueba que los equipos renueven su certificado antes de expirar.
  • Supervisión proactiva: envía los Event ID 6273 y 6272 a Azure Monitor o SIEM para alertas tempranas.
  • Documenta exclusiones IP: toda excepción (whitelist) requiere un proceso de gobernanza.
  • Pruebas de regresión tras parches de Windows Server y actualizaciones de la extensión MFA.

Flujo de autenticación comparado

Escenario actual (con error)

  1. Switch envía Access‑Request (EAP‑TLS Start).
  2. NPS responde Access‑Challenge.
  3. Extensión descarta sesión → equipo sin red.

Escenario recomendado (roles separados)

  1. Switch → NPS #2: Access‑Request.
  2. NPS #2 finaliza el handshake TLS y devuelve Access‑Accept.
  3. Extensión no interviene → conexión exitosa.

Preguntas frecuentes

¿Puedo modificar la extensión para que acepte Access‑Challenge?

No. Es un binario firmado y cualquier cambio rompería el soporte. Microsoft no publica una versión que procese desafíos intermedios.

¿El modo “Bypass” de Azure MFA ayuda?

No. Bypass solo omite el segundo factor tras un Access‑Accept. El Access‑Challenge seguirá abandonado.

¿Se puede usar NPS Proxy en vez de dos servidores?

Sí. Un NPS perimetral con la extensión puede reenviar solicitudes a un NPS interno sin ella, manteniendo la lógica de roles separados con menos infraestructura.

Script de comprobación rápida

Crea Check‑DSConversion.ps1 y ejecútalo en tu NPS:

Param(
    [Parameter(Mandatory)]
    [string]$ComputerName
)
$acct = "CN=$ComputerName`$,OU=Devices,DC=fabrikam,DC=com"
try {
    $sid = (Get-ADComputer -Identity $acct -ErrorAction Stop).SID.Value
    Write-Host "SID encontrado: $sid"
} catch {
    Write-Warning "Equipo no existe en AD o no resuelve SID"
}

Así detectas de inmediato objetos de equipo incongruentes antes de que provoquen el error.

Resumen ejecutivo

El error DS\CONVERSION\ERROR surge porque la extensión Azure MFA intenta transformar un UPN de equipo en SID durante un Access‑Challenge, algo que su lógica no soporta. La forma más limpia y estable de operar es:

  • Segregar servidores NPS: uno con extensión para usuarios y otro sin extensión para certificados de máquina.
  • Mantener objetos de equipo sanos (UPN y SID) y revisar directivas NPS específicas para EAP‑TLS.
  • Usar MFA solo donde aporte valor: accesos interactivos con credenciales de usuario.

Aplicando estos principios eliminas la causa raíz, simplificas la operación de dot1x y aseguras una autenticación robusta, escalable y transparente para la organización.

Windows Server
802.1X Windows Server NPS azure mfa peap-tls
Índice