Cómo solucionar problemas de la migración de sIDHistory entre bosques con ADMTv2

Resumen

Este artículo 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).

Más información

Cuando se utiliza ADMTv2 para migrar sIDHistory como parte de una migración de grupos o usuarios entre bosques, configuración se requiere con los requisitos de migración básicos.

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

Porque 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 de cuentas de grupo sin sIDHistory y usuarios basada en Asistente

  • El dominio de origen debe confiar en el dominio de destino.
  • El dominio de origen debe estar ejecutando Microsoft Windows NT 4.0 Service Pack 4 (SP4) o posterior.
  • El dominio de destino debe estar en modo nativo de Microsoft Windows 2000 o posterior.
  • La cuenta de usuario que está ejecutando ADMTv2 debe tener derechos de administrador en el dominio de origen.
  • La cuenta de usuario ADMT debe poseer permisos delegados para crear objetos de grupo o usuario en el contenedor de destino.
  • Deben existir el host DNS y resolución de nombres NetBIOS entre los dominios.

la migración de sIDHistory requiere las siguientes dependencias adicionales

  • Auditoría de aciertos y errores de administración de cuentas de dominios de origen y destino.
  • Los dominios de origen de Windows NT 4.0, llame a este usuario y auditoría de administración de grupo.
  • Un grupo local vacío en el dominio de origen denominado {SourceNetBIOSDom} $$$.
  • La clave del registro HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupport 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.
  • Si el dominio de destino es un dominio de Windows 2000, seguridad de Windows requiere credenciales de usuario con derechos de administrador en el dominio de destino. Estas credenciales se agregan en el asistente cuando se activa la migración sIDHistory.

    Para delegar el MigrateSidHistory extendido en un controlador de dominio de Microsoft Windows Server o en un equipo que tiene instalado el paquete de herramientas de administración de Windows Server 2003, siga estos pasos:
  • Si el dominio de destino es un dominio de Windows Server 2003, la seguridad de Windows requiere credenciales de usuario con el MigratesIDHistory delegado extendido derecho o derechos de administrador en el dominio de destino.
  • Ningún sID que se migrarán puede existir en el bosque de destino como sID principal o como un atributo sIDHistory de otro objeto.

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

  • Cuando se inicia una migración de grupo o de usuario con la migración sIDHistory desde la línea de comandos o desde una secuencia de comandos, el comando o la secuencia de comandos debe ejecutarse en el controlador de dominio en el dominio de destino.
  • La cuenta de usuario que está ejecutando la migración debe tener derechos de administrador en el origen y los dominios de destino.

Requisitos especiales para el Asistente para combinación y asignación de grupos

  • Si debe migrarse durante la asignación y combinación sIDHistory, 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 utilizar para solucionar problemas de la 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 dependencias siguientes:
  • Se crea el grupo local {SourceNetBIOSDom} $$$.
  • TcpipClientSupport en el controlador principal de dominio de origen o el emulador del controlador principal de dominio está activado.
  • Auditoría en ambos dominios está activada.
De manera opcional, ADMT puede reparar cualquiera de estas dependencias que no se han establecido. Para reparar o configurar estos valores, la cuenta que se utiliza para ejecutar ADMT debe tener suficientes permisos en cada dominio respectivo para llevar a cabo las tareas.

Tenga en cuenta que únicamente el asistente realiza estas comprobaciones y correcciones. La línea de comandos y las interfaces de secuencias de comandos no realizan estas comprobaciones y no funcionan sin la 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 que la herramienta de migración no se enlaza a un extremo RPC en el controlador principal de dominio de origen. Las posibles causas se incluyen:
  • TcpipClientSupport en el controlador principal de dominio de origen o el emulador del controlador principal de dominio no se ha activado.
  • El controlador principal de dominio o el emulador del controlador principal de dominio no se reinició después de configurar TcpipClientSupport.
  • Resolución de nombres DNS o NetBIOS no funciona.
No se pudo comprobar la auditoría y TcpipClientSupport en los dominios. No podrá migrar del Sid. El grupo local especificado no existe.
Este error normalmente indica que ya existe un usuario o un grupo universal o global con el nombre {SourceNetBIOSDom} $$$. Por lo general, ADMT 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 los dominios. No podrá migrar del Sid. Se denegó el acceso.
Este error normalmente indica que la cuenta de usuario que se utiliza para ejecutar ADMT no tiene permisos suficientes para realizar la migración en uno o ambos de los dominios.
Error en la búsqueda de nombres de dominio, rc = 1332. Se ha efectuado ninguna asignación entre los nombres de cuenta y los identificadores 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 de migración de confianza para asignar la confianza del dominio de origen y, a continuación, replicar las relaciones en el dominio de destino.

Información adicional de sIDHistory

SIDHistory es un atributo multivalor de principales de seguridad en Active Directory que puede contener hasta 850 valores. Para proporcionar compatibilidad con controladores de dominio que ejecutan versiones anteriores de Windows, el atributo sIDHistory sólo está disponible en los dominios que operan en el nivel funcional del modo nativo de Windows 2000 o posterior.

Algunos productos de otros proveedores que permita activar sIDHistory en dominios de modo mixto. Estas exigencias no representan el uso legítimo de las API públicas. Los administradores de dominio que utilizan estas herramientas 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. Por este motivo, los objetos migrados conservan los datos de identificación importantes, incluido objectGUID y la contraseña. No es el caso de las migraciones entre bosques, que llaman a DSAddSidHistory para llenar el atributo del dominio de destino. Migración de contraseñas puede activarse para la clonación entre bosques, pero objectGUID siempre se pierde durante este tipo de migración.

En ambos casos, los objetos migrados se asignan a un nuevo sID, el dominio de destino. El sID original se agrega al atributo sIDHistory del objeto migrado en el nuevo dominio. Una vez que esto ocurre, el atributo sIDHistory puede no modificarse o eliminado mediante las herramientas de administración estándares de Active Directory. Esto no está permitido porque el atributo sIDHistory es propiedad de SAM. Es posible borrar el atributo sIDHistory con una secuencia de comandos o una herramienta interna de Microsoft no públicos.


Tenga en cuenta que sIDHistory es una herramienta provisional y no está destinado a existir asociada indefinidamente a las entidades principales de seguridad. Aunque la migración de sIDHistory significativamente puede facilitar y simplificar el proceso de migración del dominio, existen ramificaciones de seguridad importantes que deben tenerse en cuenta antes de implementar sIDHistory en producción.

Un token de seguridad de Windows 2000 puede contener un máximo de 1.023 SID, incluidos sIDHistory y los SID de grupo. Kerberos también está limitada porque Kerberos de Windows 2000 tiene un búfer de 73 sID. Después de aplicar Windows 2000 Service Pack 2 (SP2), se puede duplicar este tamaño por un cambio en el registro de toda la empresa. Excedan estos límites infringe la restricción MaxTokenSize y puede dar lugar a resultados impredecibles, incluidos errores de autenticación Kerberos y aplicación errónea o inexistente de directivas. Para evitar estos problemas, utilice conversió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.
Propiedades

Id. de artículo: 322970 - Última revisión: 17 ene. 2017 - Revisión: 2

Comentarios