Solución de problemas de migración de sIDHistory entre bosques con ADMTv2

En este artículo se describe cómo solucionar problemas de migración de sIDHistory entre bosques con la herramienta de migración de Active Directory versión 2 (ADMTv2).

Número de KB original: 322970

Más información

Cuando se usa ADMTv2 para migrar sIDHistory como parte de una migración de usuarios o grupos entre bosques, se requiere la configuración con los requisitos de migración base.

De forma predeterminada, sIDHistory, password y objectGUID se conservan durante las migraciones dentro del bosque, pero esto no es cierto para la clonación entre bosques.

Dado que no hay ningún contexto de seguridad integrado para las operaciones entre bosques, debe tomar medidas para proteger la seguridad de las operaciones a través de los límites del bosque.

Configuración

Los requisitos básicos para las operaciones de migración entre bosques son:

Migración básica de cuentas de usuario y grupo basadas en asistente sin sIDHistory

• El dominio de origen debe confiar en el dominio de destino.
• La cuenta de usuario que ejecuta ADMTv2 debe tener derechos de administrador en el dominio de origen.
• La cuenta de usuario de ADMT debe tener permisos delegados para crear objetos de usuario o grupo en el contenedor de destino.
• La resolución de nombres DNS (nombre de host) y NetBIOS entre los dominios debe existir.

La migración de sIDHistory requiere las siguientes dependencias adicionales

• Auditoría correcta y de error de la administración de cuentas para dominios de origen y de destino.
• Los dominios de origen llaman a esta auditoría de administración de grupos y usuarios.
• Un grupo local vacío en el dominio de origen denominado {SourceNetBIOSDom}}.
• La HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupportclave del Registro debe establecerse en 1 en el controlador de dominio principal del dominio de origen.
• Debe reiniciar el controlador de dominio principal del dominio de origen después de la configuración del Registro.
• La seguridad de Windows requiere credenciales de usuario con el derecho extendido MigratesIDHistory delegado o derechos de administrador en el dominio de destino. Estas credenciales se agregan en el asistente cuando se activa la migración de sIDHistory.

Para delegar el derecho extendido MigrateSidHistory en un controlador de dominio o en un equipo que tenga instalado el paquete herramientas de administración de Windows Server, siga estos pasos:

1. Haga clic en Inicio, luego en Herramientas administrativas y, a continuación, haga clic en Usuarios y equipos de Active Directory.
2. Haga clic con el botón derecho en el nombre del dominio desde el que desea delegar la extensión MigrateSidHistory y, a continuación, haga clic en Delegar control para abrir la ventana Delegación del Asistente para controles.
3. Haga clic en Siguiente, haga clic en Agregar, escriba el nombre del usuario o grupo que desea agregar en el cuadro de diálogo Seleccionar usuarios, equipos o grupos, haga clic en Aceptar y, a continuación, haga clic en Siguiente.
4. Haga clic para seleccionar la opción Crear una tarea personalizada para delegar y, a continuación, haga clic en Siguiente.
5. Asegúrese de que está seleccionada la opción Esta carpeta, los objetos existentes de esta carpeta y la creación de nuevos objetos en esta carpeta y, a continuación, haga clic en Siguiente.
6. Asegúrese de que la opción General está seleccionada, haga clic en Migrar historial de SID en la lista Permisos y, a continuación, haga clic en Siguiente.
7. Compruebe que la información es correcta y, a continuación, haga clic en Finalizar.
   • Ningún sID que se va a migrar puede existir en el bosque de destino, ya sea como sID principal o como atributo sIDHistory de otro objeto.

Requisitos adicionales para migrar sIDHistory con la línea de comandos o las interfaces de scripting

• Al iniciar una migración de usuario o grupo con la migración de sIDHistory desde la línea de comandos o desde un script, el comando o script debe ejecutarse en el controlador de dominio del dominio de destino.
• La cuenta de usuario que ejecuta la migración debe tener derechos de administrador tanto en el origen como en los dominios de destino.

Requisitos especiales para la asignación de grupos y el asistente para combinar

• Si sIDHistory se va a migrar durante la asignación de grupos y la combinación, el ámbito de los grupos de origen debe coincidir con el ámbito del grupo de destino.

Solución de problemas

El paso más básico que puede usar para solucionar problemas de migración de sIDHistory entre bosques es usar el Asistente para migración de cuentas de usuario o el Asistente para migración de cuentas de grupo para ejecutar una migración en modo de prueba.

Durante la migración en modo de prueba, ADMTv2 valida las siguientes dependencias:

• Se crea el grupo local {SourceNetBIOSDom}} .
• TcpipClientSupport en el controlador de dominio principal de origen o el emulador del controlador de dominio principal está activado.
• La auditoría en ambos dominios está activada.

Opcionalmente, ADMT puede reparar cualquiera de estas dependencias que no están establecidas. Para reparar o configurar estas opciones, la cuenta que se usa para ejecutar ADMT debe tener permisos suficientes en cada dominio respectivo para llevar a cabo las tareas.

Solo el asistente realiza estas comprobaciones y correcciones. Las interfaces de línea de comandos y scripting no realizan estas comprobaciones y no funcionan sin una configuración correcta.

Mensajes de error comunes con la migración de sIDHistory entre bosques

"El identificador no es válido (código de error = 6)."

Este error indica un problema de RPC en el que la herramienta de migración no se puede enlazar a un punto de conexión RPC en el controlador de dominio principal de origen. Entre las posibles causas se incluyen:

• TcpipClientSupport en el controlador de dominio principal de origen o el emulador del controlador de dominio principal no se ha activado.
• El controlador de dominio principal o el emulador del controlador de dominio principal no se reiniciaron después de configurar TcpipClientSupport.
• La resolución de nombres DNS o NetBIOS no funciona.

No se pudo comprobar la auditoría y TcpipClientSupport en dominios. No podrá migrar sid. El grupo local especificado no existe.

Este error suele indicar que un usuario o un grupo global o universal con el nombre {SourceNetBIOSDom}} ya existe. ADMT normalmente crea el grupo local de ese nombre, pero no puede hacerlo si ya existe una entidad de seguridad con el nombre.

No se pudo comprobar la auditoría y TcpipClientSupport en dominios. No podrá migrar sid. Acceso denegado.

Este error suele indicar que la cuenta de usuario que se usa para ejecutar ADMT no tiene permisos suficientes para realizar la migración en uno o ambos dominios. Error en la búsqueda de nombres de dominio, rc=1332. No se ha efectuado ninguna asignación entre los nombres de cuenta y los id. de seguridad Este error en el archivo Migration.log después de una migración con sIDHistory normalmente indica que el dominio de origen ha configurado confianzas que no existen en el dominio de destino. Para resolver este problema, ejecute el Asistente para la migración de confianza para asignar las confianzas en el dominio de origen y, a continuación, replique las relaciones en el dominio de destino.

Información adicional de sIDHistory

sIDHistory es un atributo multivalor de entidades de seguridad de Active Directory que pueden contener hasta 850 valores. Para proporcionar compatibilidad con versiones anteriores con controladores de dominio que ejecutan versiones anteriores de Windows, el atributo sIDHistory solo está disponible en dominios que funcionan en el nivel funcional de Windows.

Algunos productos de proveedores de terceros permiten activar sIDHistory en dominios de modo mixto. Estas notificaciones no representan el uso legítimo de las API públicas. Los administradores de dominio que usan estas herramientas corren el riesgo de poner su implementación de Active Directory en un estado no admitido.

Durante las migraciones dentro del bosque, LDAP_Rename es responsable de mover objetos. Debido a esto, los objetos migrados conservan datos de identificación importantes, incluidos objectGUID y la contraseña. Este no es el caso de las migraciones entre bosques, que llaman a DSAddSidHistory para rellenar el atributo en el dominio de destino. La migración de contraseñas se puede activar para la clonación entre bosques, pero el objectGUID siempre se pierde durante este tipo de migración.

En ambos casos, el dominio de destino asigna un nuevo sID a los objetos migrados. El sID original se agrega al atributo sIDHistory del objeto migrado en el nuevo dominio. Después de esto, es posible que el atributo sIDHistory no se modifique o elimine mediante las herramientas de administración estándar de Active Directory. Esto no se permite porque el atributo sIDHistory es propiedad de SAM. Es posible borrar sIDHistory mediante un script o una herramienta interna de Microsoft no pública.

Tenga en cuenta que sIDHistory es una herramienta de transición y no está pensada para existir indefinidamente asociada a entidades de seguridad. Aunque la migración de sIDHistory puede simplificar significativamente el proceso de migración de dominio, hay importantes ramificaciones de seguridad que se deben tener en cuenta antes de implementar sIDHistory en una empresa de producción.

Un token de seguridad de Windows puede contener un máximo de 1023 sID, incluidos sIDHistory y sID de grupo. Kerberos también está limitado porque Windows Kerberos tiene un búfer de 73 sID. Este tamaño se puede duplicar mediante un cambio en el registro de toda la empresa. Si se superan estos límites, se infringe la restricción MaxTokenSize y se pueden producir resultados imprevisibles, incluidos los errores de autenticación Kerberos y la aplicación errática o inexistente de las directivas. Para evitar estos problemas, use La traducción de seguridad en lugar de sIDHistory como solución a largo plazo para mantener el acceso a los recursos después de una migración de dominio.