Solución al error 0x801c03ed al iniciar sesión con cuenta Microsoft

El error 0x801c03ed al intentar unir o registrar un dispositivo en Microsoft Entra ID (antes Azure AD) o durante una implementación con Windows Autopilot, tranquilo puede llegar a ser un gran dolor de cabeza. Por desgracia, es un fallo muy habitual cuando se mezclan uniones a Azure AD, inscripción en Intune y políticas de administrador mal configuradas.

En este artículo vamos a analizar el código de error 0x801c03ed y, sobre todo, cómo diagnosticar y corregir el fallo paso a paso tanto desde el punto de vista del administrador como del usuario final. La idea es que al terminar de leerlo puedas identificar el origen del problema y aplicar la solución adecuada sin ir dando palos de ciego.

Qué significa realmente el error 0x801c03ed

El código 0x801c03ed se asocia a errores de registro y unión a Microsoft Entra ID, especialmente en escenarios de Windows Autopilot, Azure AD Join y Windows Hello para empresas. Suele aparecer durante la fase AADEnroll de Autopilot o cuando un usuario intenta unir un dispositivo desde el asistente de inicio (OOBE) o desde la configuración de Windows.

La descripción técnica que da Microsoft para 0x801c03ed es bastante amplia. El error puede indicar, entre otras cosas, que la autenticación multifactor es obligatoria para la operación «ProvisionKey» y no se ha completado, que falta el token en el encabezado Authorization, que no se han podido leer determinados objetos, que la solicitud enviada al servidor no es válida o que el usuario no tiene permisos para unir el dispositivo a Microsoft Entra ID.

En escenarios de usuario final, este mismo error se traduce en mensajes del estilo «Something went wrong» o «Administrator policy does not allow user to device join». Es decir, el servidor responde que, según la configuración del inquilino (tenant), ese usuario no puede unir dispositivos o hay algún problema de autenticación o de objeto de dispositivo en el directorio.

En el contexto de Windows Autopilot, en los registros aparece algo como «AutoPilotManager failed during device enrollment phase AADEnroll. HRESULT = 0x801C03ED», dejando claro que el fallo se produce en el momento de la autenticación/registro del dispositivo en Azure AD durante OOBE.

Principales causas del error 0x801c03ed

Este código de error no tiene una única causa. De hecho, puede deberse a varias condiciones que conviene revisar una por una para no volverse loco. Las razones más habituales por las que aparece 0x801c03ed durante un Autopilot o Azure AD Join son las siguientes:

En primer lugar, es muy frecuente que exista una política de administrador que impide a los usuarios unir dispositivos a Microsoft Entra ID. En la práctica, esto quiere decir que en la configuración de dispositivos del tenant se ha establecido que ningún usuario (o solo un grupo concreto) pueda registrar nuevos equipos, y el usuario con el que se está intentando unir el dispositivo no cumple ese criterio.

Otra causa típica está relacionada con la propia autenticación: no se ha realizado la autenticación multifactor (MFA) cuando es obligatoria para la operación ProvisionKey, o el token de acceso que se envía en la cabecera Authorization de la solicitud no está presente, es inválido o ha caducado. En estos casos el servidor rechaza la petición y devuelve el error 0x801c03ed.

También puede suceder que la solicitud HTTP enviada al servidor tenga un formato incorrecto o contenga objetos que no se pueden leer. Esto se ve reflejado en mensajes de servidor indicando que la solicitud no es válida, que se ha producido un error de autenticación o que algún objeto relacionado con el dispositivo o el usuario no se encuentra o no es accesible.

En entornos donde se usan dispositivos previamente unidos o sincronizados, otra causa muy habitual es que el objeto de dispositivo esperado en Microsoft Entra ID no exista o no coincida con el hardware hash o los identificadores que está enviando el cliente. Esto se da, por ejemplo, cuando un equipo se sincronizó previamente como híbrido, luego se formateó e intentas usar Autopilot sin limpiar los objetos antiguos.

Relación entre 0x801c03ed y Windows Autopilot

El error 0x801c03ed se ve con bastante frecuencia en despliegues de Windows Autopilot durante la fase de registro AADEnroll. En estos escenarios, el dispositivo se provisiona a partir de un perfil de Autopilot asociado a un hardware hash que se ha importado previamente en Intune.

Cuando el proceso de out-of-box experience (OOBE) no va como debería, una de las primeras cosas que hay que comprobar es si el dispositivo ha recibido correctamente un perfil de Autopilot y qué configuración contiene ese perfil. Dependiendo de la versión de Windows cliente, hay herramientas distintas para revisar esa asignación, pero el concepto es el mismo: verificar que el equipo está identificado correctamente y que la configuración apunta a lo que queremos.

Es importante entender que al importar un dispositivo de Autopilot se crea un objeto de dispositivo en Azure AD, que actúa como ancla para el grupo al que pertenece y para el perfil de Autopilot. Si ese objeto se elimina del directorio, se desactiva o se corrompe, el equipo puede empezar a producir errores como 0x801c03ed durante el intento de unión, porque el servidor no es capaz de encontrar el dispositivo con los identificadores que espera.

Hay casos documentados en los que, al revisar los registros de Autopilot, aparecen mensajes como «AuthenticationError»,»Subcode»:»DeviceNotFound»,»Message»:»No se encontró un dispositivo con los identificadores de dispositivo esperados» y un estado HTTP 400 devuelto por el servidor. En situaciones así, el problema suele solucionarse eliminando el dispositivo antiguo de Autopilot, borrando el objeto anterior sincronizado con Azure AD y volviendo a importar el hardware hash del equipo para regenerar los objetos necesarios.

En muchos despliegues también se hace hincapié en que, si se borra accidentalmente el objeto de dispositivo que crea Autopilot en Azure AD, la forma correcta de arreglarlo es eliminar el hardware hash de Intune y reimportarlo, no intentar «forzar» la unión desde el cliente, porque eso da lugar precisamente a errores de unión como el 0x801c03ed.

Revisión de eventos y diagnóstico con el Visor de eventos

Cuando el error aparece durante Autopilot o durante la unión a Microsoft Entra ID, una buena práctica es ir directo a los registros de ModernDeployment y Autopilot en el Visor de eventos de Windows para obtener detalles más finos de lo que está fallando.

En el Visor de eventos, se puede consultar la ruta Application and Services Logs > Microsoft > Windows > ModernDeployment-Diagnostics-Provider > Autopilot. Ahí se registran distintos eventos que reflejan cada fase del proceso de inscripción y unión. Cuando aparece 0x801c03ed, suele haber eventos acompañados de un mensaje del tipo «AutoPilotManager failed during device enrollment phase AADEnroll» y el HRESULT exacto.

Estos eventos pueden incluir información sobre el mensaje devuelto por el servidor, el estado HTTP (por ejemplo, un 400 con detalle AuthenticationError, DeviceNotFound) y un identificador de actividad (Activity ID o TraceId) que sirve para correlacionar lo que se ve en el cliente con lo que aparece en los registros del servicio en la nube. Esa información es oro para un administrador que quiera ir a fondo en el análisis.

Si el fallo tiene que ver con permisos del usuario, tokens o políticas, en los eventos también se pueden ver mensajes como «Administrator policy does not allow user to device join», lo que deja claro que el problema no está en el equipo, sino en la configuración del tenant o de la cuenta que se está usando para autenticarse.

En cualquier caso, el Visor de eventos se convierte en una herramienta clave para diferenciar entre un problema de perfil de Autopilot, un conflicto de dispositivo, un error de token o una política de unión demasiado restrictiva.

Permisos de unión a Microsoft Entra ID y política del administrador

Una de las fuentes más recurrentes del error 0x801c03ed es la configuración de quién puede unir dispositivos a Microsoft Entra ID dentro del inquilino. Si esta política está mal definida, el servidor directamente rechaza la unión del dispositivo aunque todo lo demás sea correcto.

En Microsoft Entra ID existe un ajuste llamado «Users may join devices to Azure AD» (Usuarios pueden unir dispositivos a Azure AD), accesible desde la sección de Dispositivos y su configuración. Si este ajuste está en «None» (Ninguno), ningún usuario conseguirá unir un dispositivo y puede encontrarse con el código 0x801c03ed acompañado de mensajes que indican que la política del administrador no permite la unión de dispositivos.

Para evitar este bloqueo, el administrador debe revisar esta configuración y establecerla en «All» (Todos) o en «Selected» (Seleccionados) incluyendo al usuario o grupo adecuado. De este modo, los usuarios previstos podrán llevar a cabo la unión del dispositivo a Entra ID sin que salte este error por una simple cuestión de permisos.

Reimportar el hardware hash y gestionar dispositivos en Autopilot

Otro enfoque clave para resolver problemas relacionados con 0x801c03ed, especialmente en despliegues de Autopilot, es revisar cómo se han importado los dispositivos y cómo se gestionan sus objetos en Intune y Azure AD. Cuando hay errores de tipo DeviceNotFound o inconsistencias entre el cliente y la nube, la solución suele pasar por limpiar y reimportar.

En Intune, al importar un dispositivo de Autopilot con su hardware hash, se genera automáticamente un objeto de dispositivo en Azure AD. Ese objeto se utiliza como referencia para incluir el dispositivo en grupos, aplicar el perfil de Autopilot correspondiente y gestionar su ciclo de vida. Si se elimina ese objeto por error, se desactiva o se manipula de manera incorrecta, se rompe la cadena que permite al servidor reconocer el equipo durante la fase de unión.

Cuando se detecta que el objeto de dispositivo ya no existe o está desalineado, suele recomendarse a los administradores que eliminen el dispositivo de la lista de Autopilot en Intune y vuelvan a importar el hardware hash. Ese proceso recrea el objeto en Azure AD y permite que el equipo pueda volver a provisionarse correctamente, desapareciendo el error 0x801c03ed en el siguiente intento.

Para gestionar estos elementos, desde el Centro de administración de Microsoft Intune se puede ir a la sección de dispositivos, luego a Windows, después a Inscripción de Windows y finalmente a Dispositivos. Desde ahí es posible eliminar registros de Autopilot y volver a cargar el CSV con los hashes de los equipos que se desean gestionar mediante este sistema.

Además, es importante tener cuidado con no borrar ni desactivar a la ligera el objeto de dispositivo en Azure AD asociado a un equipo gestionado por Autopilot. Muchos problemas de unión y errores como 0x801c03ed vienen precisamente de haber roto ese vínculo pensando que no era importante, cuando en realidad es la base para que el dispositivo reciba su perfil y se asigne correctamente a los grupos que le tocan.

Otros códigos de error relacionados en el mismo contexto

Junto al 0x801c03ed, hay una colección bastante amplia de códigos que se dan en situaciones similares, sobre todo durante el registro de Windows Hello para empresas, operaciones con TPM y unión a Microsoft Entra ID. Conocerlos ayuda a entender mejor el entorno en el que aparece 0x801c03ed y a descartar otros problemas.

• Los códigos 0x80090005 (NTE_BAD_DATA), 0x8009000F y 0x80090011 hacen referencia a situaciones en las que el contenedor o la clave criptográfica ya existe, no se encuentra o hay datos corruptos. En muchos de estos casos, la solución recomendada pasa por desvincular el dispositivo de Microsoft Entra ID y volver a unirlo, lo que fuerza la recreación de claves y contenedores.
• El código 0x80090029 indica que el TPM no está configurado. Para resolverlo, se propone iniciar sesión con una cuenta de administrador, abrir la consola tpm.msc desde Inicio, y en el panel de Acciones seleccionar la opción «Preparar el TPM». Esta acción inicializa y pone en marcha el módulo de plataforma segura necesario para operaciones como Windows Hello para empresas.
• El error 0x8009002A (NTE_NO_MEMORY) apunta a falta de memoria disponible para completar la operación. En este caso, lo que se recomienda es cerrar programas que estén consumiendo memoria y volver a intentarlo, algo más simple pero que a veces se pasa por alto.
• Otros códigos como 0x80090031 (NTE_AUTHENTICATION_IGNORED) llevan asociadas soluciones del tipo reiniciar el dispositivo y, si el problema persiste, restablecer el TPM o ejecutar comandos como Clear-TPM, que limpian el estado del módulo de seguridad para permitir una nueva configuración.

Token, certificados y errores de atestación

En el entorno de Windows Hello para empresas y la unión a Microsoft Entra ID, hay varias situaciones en las que los problemas no vienen tanto de la política como de la validez de los tokens y certificados implicados. A partir de la lista de códigos se pueden identificar varios de ellos.

El error 0x801C03EA indica que el servidor no ha podido autenticar al usuario o al dispositivo, y sugiere comprobar si el token es válido y si el usuario tiene permiso para registrar claves de Windows Hello para empresas. El 0x801C044D apunta a que el token de autorización no contiene el identificador de dispositivo, lo que se resuelve muchas veces volviendo a desenlazar el dispositivo del id de Microsoft Entra y volviendo a unirlo para generar de nuevo un contexto de autenticación correcto.

Luego están los errores de atestación como 0x801C03EE (error de atestación) o certificación, como 0x801C0010 y 0x801C03EF, que señalan que el certificado AIK no es válido, no es de confianza o ya no es válido. En estos escenarios se suele recomendar cerrar sesión y volver a iniciarla, lo que fuerza una serie de renovaciones y comprobaciones, o incluso restablecer ciertos componentes si el problema persiste.

Otros códigos como 0x801C03E9 y 0x801C03EB se refieren a que el mensaje de respuesta del servidor no es válido o que el estado HTTP de la respuesta no es correcto, así que normalmente se trata de errores transitorios del servicio que se intentan mitigar cerrando sesión y volviendo a entrar, o repitiendo el proceso de unión tras unos minutos.

Además, hay mensajes que indican que no se ha podido obtener el token de usuario o recibir la entrada de credenciales, recomendando de nuevo cerrar sesión, comprobar la conectividad de red y asegurarse de que las credenciales son correctas, ya que sin un token válido no se puede completar la operación de registro o unión.

Códigos específicos de usuario, PIN y métodos de inicio de sesión

En el ámbito del inicio de sesión, especialmente cuando interviene Windows Hello, también aparecen códigos que, aunque no sean 0x801c03ed, se mueven en el mismo ecosistema de problemas de seguridad y autenticación. Conocerlos ayuda a diagnosticar problemas encadenados.

Por ejemplo, hay errores en los que se indica que el PIN o determinada opción de inicio de sesión no está disponible temporalmente, acompañados del código 0xC00000BB. En estos casos, el mensaje aclara que el controlador de dominio de destino no admite el método de inicio de sesión, a menudo porque el servicio KDC no tiene el certificado adecuado o el cliente no puede comprobar la CRL de dicho certificado. La solución pasa por usar otro método de inicio de sesión y revisar la infraestructura de certificados.

Otro caso interesante es el relacionado con la cuenta de conmutador de token de usuario, donde se propone eliminar los archivos del agente de tokens del Administrador de cuentas web en la ruta %LOCALAPPDATA%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AC\TokenBroker\Accounts\*.*\ y reiniciar el equipo. Esta limpieza fuerza la regeneración de los tokens de usuario y puede resolver problemas persistentes de autenticación.

Además, hay códigos que simplemente indican que el usuario canceló un cuadro de diálogo interactivo. Aunque parecen triviales, en algunos flujos de configuración (como la creación de un PIN de Windows Hello o la aceptación de términos de uso) cancelar un cuadro puede dejar el proceso en un estado a medio camino que luego se traduce en errores de registro o unión.

En el contexto concreto de usuarios que intentan instalar o activar Windows 11 con credenciales académicas o corporativas y se topan con 0x801c03ed, lo más habitual es que el mensaje completo incluya detalles como «Server error code: 801c03ed» y «Administrator policy does not allow user … to device join», lo que refuerza la idea de que el origen está en la política y no en el dispositivo.

Pasos prácticos para administradores ante el error 0x801c03ed

Con toda la teoría sobre la mesa, es útil aterrizar en una serie de acciones concretas que un administrador puede llevar a cabo cuando se enfrenta al error 0x801c03ed en un entorno de Autopilot o de unión a Microsoft Entra ID.

1. Revisar la configuración de «Users may join devices to Azure AD» en Microsoft Entra ID > Devices > Device settings, asegurándose de que no está en «None». Lo ideal, según el caso, es ajustarla a «All» o «Selected» y añadir las cuentas de usuario que deben poder unir dispositivos, especialmente si hablamos de administradores que están probando Autopilot.
2. Comprobar si el dispositivo afectado tiene un perfil de Autopilot asignado correctamente y un objeto de dispositivo activo en Azure AD. Desde el portal de Intune se puede verificar si el hardware hash figura en la lista de dispositivos de Autopilot y si el objeto asociado en Azure AD está activo. Si aparece desactivado, se puede reactivar. Si ha sido borrado, habrá que eliminar el hardware hash del listado y volverlo a importar.
3. Eliminar completamente el dispositivo de Autopilot, borrar cualquier referencia antigua sincronizada con Azure AD y añadir de nuevo el hardware hash limpio. Esta limpieza suele resolver conflictos de identificadores.
4. Si en la organización se exige MFA para ciertas operaciones, hay que comprobar que el usuario esté completando correctamente el segundo factor. Además, es importante asegurarse de que no se estén bloqueando las solicitudes de token por cuestiones de red, firewall o proxies que puedan dañar las cabeceras de autenticación.

Para el usuario final que no tiene permisos de administración, las recomendaciones suelen reducirse a cerrar sesión y volver a iniciarla, comprobar la conexión de red y, sobre todo, contactar con el departamento de TI para confirmar que su cuenta está autorizada a unir dispositivos y que no se ha alcanzado el límite máximo de equipos asociados.

Con todos estos factores bien controlados —políticas de unión, objetos de dispositivo en Azure AD, perfiles de Autopilot correctamente asignados, tokens válidos y, cuando toque, MFA completada— las probabilidades de volver a ver el código 0x801c03ed en nuevos despliegues o registros de dispositivos se reducen considerablemente, permitiendo que tanto administradores como usuarios puedan centrarse en trabajar con sus equipos en lugar de pelearse con el asistente de inicio.