Error 1500 (Win32Err=5) al migrar equipos y perfiles con una confianza externa entre dominios

Cuando CopyRight2 Computer & Profile Migration prepara un cliente para la migración, el registro del cliente puede detenerse con CopyRight2 Error 1500, Access is denied y Win32Err=5. Aunque el mensaje parece indicar un problema de permisos, este comportamiento se produce en la configuración predeterminada de migración basada en una confianza después de que las actualizaciones de Windows de abril de 2026 deshabilitaran RC4: Windows no dirige la solicitud Kerberos basada en el host del controlador de dominio de destino al realm correcto.

Por qué «Access is denied» puede inducir a error

En la configuración predeterminada, el dominio de destino confía en el dominio de origen. Esta dirección de la confianza permite a CopyRight2 realizar la migración sin un usuario independiente para unir el equipo: a la cuenta de equipo del dominio de origen se le conceden los permisos necesarios para unirlo al objeto de equipo de destino. El cliente CopyRight2 sigue unido al dominio de origen y se comunica con un controlador del dominio de destino a través de la confianza externa.

El agente de CopyRight2 Computer & Profile Migration se ejecuta como LocalSystem. Por tanto, Windows accede al controlador de dominio de destino utilizando la cuenta de equipo del dominio de origen, no la cuenta interactiva del usuario que haya iniciado sesión. Durante la preparación, CopyRight2 obtiene información del dominio de destino, incluido su SID. Si Kerberos no puede enrutar la solicitud correctamente, esta consulta falla y el registro del cliente indica el error 1500 y el error Win32 5. El mensaje Access is denied resulta engañoso aunque se hayan asignado correctamente los permisos para unir el equipo.

La confianza en sí puede funcionar. Desde una consola que se ejecute como LocalSystem, Windows puede obtener correctamente el ticket de concesión de tickets entre realms:

klist get krbtgt/TARGET.COM

Sin embargo, Windows no consigue dirigir la solicitud de servicio basada en el host del controlador de dominio de destino al realm TARGET.COM:

klist get cifs/dstdc.target.com

Por tanto, la solicitud del TGT entre realms se completa, pero falla la del ticket de servicio CIFS. La misma consulta funciona con una confianza entre bosques. Este artículo trata la confianza externa entre dominios y el procedimiento predeterminado de CopyRight2 descritos aquí; otros casos del error 1500 de CopyRight2 pueden tener causas diferentes.

Diagnóstico en el contexto de LocalSystem

Puede reproducir las comprobaciones pertinentes sin ejecutar toda la migración. Abra una consola como LocalSystem mediante PsExec de Microsoft Sysinternals:

psexec.exe -accepteula -i -s cmd.exe

En la nueva consola, confirme el contexto de seguridad y pruebe ambas solicitudes de tickets:

whoami
klist get krbtgt/TARGET.COM
klist get cifs/dstdc.target.com

whoami debe devolver nt authority\system. Si se obtiene el TGT, pero la solicitud CIFS para el controlador de destino falla porque Windows selecciona el realm equivocado, aplique una asignación Kerberos de host a realm.

Solución: asignar el controlador de destino a su realm

Ejecute estos comandos en la consola de LocalSystem:

ksetup /addhosttorealmmap dstdc.target.com TARGET.COM
klist purge
klist get cifs/dstdc.target.com

Utilice el nombre de dominio completo exacto del controlador de dominio de destino con el que se comunica CopyRight2. El comando ksetup /addhosttorealmmap asigna ese nombre de host al realm Kerberos de destino. Al purgar la caché de tickets de LocalSystem, la siguiente solicitud utiliza la nueva asignación.

Cuando se emite correctamente el ticket de servicio CIFS, se completa la consulta del dominio de destino, CopyRight2 obtiene el SID del dominio y continúa la preparación de Computer & Profile Migration.

Implementar la asignación mediante directiva de grupo

Las asignaciones de host a realm se almacenan localmente en cada cliente de migración en:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\HostToRealm

Por ejemplo, la entrada TARGET.COM contiene un valor SpnMappings para dstdc.target.com. Compruebe el Registro para verificar la implementación, porque ksetup no siempre muestra las asignaciones existentes.

Si tiene varios clientes, implemente la asignación de forma centralizada mediante directiva de grupo:

Computer Configuration > Administrative Templates > System > Kerberos > Define host name-to-Kerberos realm mappings

Una vez aplicada la directiva, purgue la caché de tickets Kerberos de LocalSystem y vuelva a solicitar el ticket CIFS. Utilice en la directiva el FQDN exacto del controlador de destino y el realm correspondiente, igual que con ksetup /addhosttorealmmap.

Una asignación de host a realm solo corrige el enrutamiento Kerberos. No repara una confianza defectuosa, errores de resolución DNS, tráfico bloqueado por el cortafuegos, restricciones de autenticación selectiva ni permisos realmente ausentes. Compruebe esas condiciones por separado si también falla la solicitud del TGT o si la solicitud de servicio sigue devolviendo un error tras aplicar la asignación.

La dirección de la confianza es la inversa de la que se suele emplear para SID-History. En el artículo de diagnóstico de Kerberos con SID-History, el dominio de origen confía en el de destino para que un usuario migrado del dominio de destino pueda acceder a recursos del dominio de origen. En la configuración predeterminada de CopyRight2 Computer & Profile Migration descrita aquí, el dominio de destino confía en el de origen, y una cuenta de equipo unida al dominio de origen accede al controlador de dominio de destino.