Uso de DsAddSidHistory

La función DsAddSidHistory obtiene el identificador de seguridad (SID) de la cuenta principal de una entidad de seguridad de un dominio (el dominio de origen) y lo agrega al atributo sIDHistory de una entidad de seguridad en otro dominio (de destino) en un bosque diferente. Cuando el dominio de origen está en modo nativo de Windows 2000, esta función también recupera los valores sIDHistory de la entidad de seguridad de origen y los añade al sIDHistory de la entidad de seguridad de destino.

La adición de SIDs al sIDHistory de una entidad de seguridad es una operación sensible a la seguridad que concede efectivamente a la entidad de seguridad de destino acceso a todos los recursos accesibles a la entidad de seguridad de origen, siempre que existan confianzas desde los dominios de recursos aplicables al dominio de destino.

En un dominio Windows 2000 en modo nativo, el inicio de sesión de un usuario crea un token de acceso que contiene el SID de la cuenta principal del usuario y los SID de grupo, así como el sIDHistory del usuario y el sIDHistory de los grupos de los que el usuario es miembro. Tener estos antiguos SID (valores sIDHistory) en el token del usuario garantiza al usuario el acceso a recursos protegidos por listas de control de acceso (ACL) que contienen los antiguos SID.

Esta operación facilita ciertos escenarios de implementación de Windows 2000. En concreto, admite un escenario en el que se crean cuentas en un nuevo bosque Windows 2000 para usuarios y grupos que ya existen en un entorno de producción Windows NT 4.0. Al colocar el SID de la cuenta de Windows NT 4.0 en el sIDHistory de la cuenta de Windows 2000, se conserva el acceso a los recursos de red para el usuario que inicia sesión en su nueva cuenta de Windows 2000.

DsAddSidHistory también admite la migración de servidores de recursos (o DC y servidores miembro en un dominio Windows 2000 en modo nativo) de controladores de dominio de copia de seguridad (BDC) de Windows NT 4.0 a un dominio Windows 2000 como servidores miembro. Esta migración requiere la creación, en el dominio Windows 2000 de destino, de grupos locales de dominio que contengan, en su sIDHistory, los SID primarios de los grupos locales definidos en el BDC (o grupos locales de dominio referenciados en ACL en los servidores Windows 2000) en el dominio de origen. Al crear un grupo local de destino que contenga el sIDHistory y todos los miembros del grupo local de origen, se mantiene para todos los miembros el acceso a los recursos del servidor migrado, protegidos por ACL que hacen referencia al grupo local de origen.

Nota:

El uso de DsAddSidHistory requiere una comprensión de sus implicaciones administrativas y de seguridad más amplias en estos y otros escenarios. Para obtener más información, consulte el libro blanco "Planificación de la migración de Windows NT a Microsoft Windows 2000" ("Planning Migration from Windows NT to Microsoft Windows 2000"), entregado como Dommig.doc en las Herramientas de soporte de Windows 2000. Esta documentación también se puede encontrar en el CD del producto en \support\tools.

Requisitos de autorización

DsAddSidHistory requiere privilegios de administrador en los dominios de origen y destino. En concreto, la persona que llama a esta API debe ser miembro del grupo Administradores de dominio en el dominio de destino. Se realiza una comprobación codificada de esta pertenencia. Además, la cuenta proporcionada en el parámetro SrcDomainCreds debe ser miembro del grupo Administradores o Administradores de dominio en el dominio de origen. Si se pasa NULL en SrcDomainCreds la persona que llama a la API debe ser miembro del grupo Administradores o Administradores de dominio en el dominio de origen.

Requisitos de dominio y confianza

DsAddSidHistory requiere que el dominio de destino esté en modo nativo de Windows 2000 o posterior, ya que solo este tipo de dominio admite el atributo sIDHistory. El dominio de origen puede ser Windows NT 4.0 o Windows 2000, modo mixto o nativo. Los dominios de origen y destino no deben estar en el mismo bosque. Por definición, los dominios de Windows NT 4.0 no se encuentran en un bosque. Esta restricción entre bosques garantiza que los SID duplicados, ya aparezcan como SID primarios o como valores sIDHistory, no se creen en el mismo bosque.

DsAddSidHistory requiere una confianza externa del dominio de origen al dominio de destino en los casos que se indican en la siguiente tabla.

Caso	Descripción
El dominio de origen es Windows 2000.	El atributo sIDHistory de origen, disponible solo en dominios de origen Windows 2000, solo puede leerse mediante LDAP, que requiere esta confianza para la protección de la integridad.
El dominio de origen es Windows NT 4.0 y SrcDomainCreds es NULL.	La suplantación, necesaria para admitir las operaciones del dominio de origen utilizando las credenciales de la persona que realiza la llamada, depende de esta confianza. La suplantación también requiere que el controlador de dominio de destino tenga habilitada la opción "De confianza para delegación" de forma predeterminada en los controladores de dominio.

Sin embargo, no se requiere confianza entre los dominios de origen y destino si el dominio de origen es Windows NT 4.0 y SrcDomainCreds no es NULL.

Requisitos del controlador de dominio de origen

DsAddSidHistory requiere que el controlador de dominio, seleccionado como destino de las operaciones en el dominio de origen, sea el PDC en dominios Windows NT 4.0 o el PDC Emulator en dominios Windows 2000. La auditoría del dominio de origen se genera mediante operaciones de escritura, por lo tanto, el PDC es necesario en los dominios de origen de Windows NT 4.0, y la restricción de solo PDC garantiza que las auditorías de DsAddSidHistory se generen en un único equipo. Esto reduce la necesidad de revisar los registros de auditoría de todos los DC para supervisar el uso de esta operación.

Nota:

En los dominios de origen de Windows NT 4.0, el PDC (destino de las operaciones en el dominio de origen) debe ejecutar el Service Pack 4 (SP4) y versiones posteriores para garantizar un soporte de auditoría adecuado.

El siguiente valor de registro debe crearse como un valor REG_DWORD y establecerse en 1 en el controlador de dominio de origen para los CD de origen de Windows NT 4.0 y Windows 2000.

HKEY_LOCAL_MACHINE
   System
      CurrentControlSet
         Control
            Lsa
               TcpipClientSupport

Este valor habilita las llamadas RPC a través del transporte TCP. Esto es necesario porque, por defecto, las interfaces SAMRPC son removibles solo en tuberías con nombre. El uso de tuberías con nombre da como resultado un sistema de gestión de credenciales adecuado para usuarios conectados de forma interactiva que realizan llamadas en red, pero no es flexible para un proceso del sistema que realiza llamadas de red con credenciales proporcionadas por el usuario. RPC sobre TCP es más adecuado para ese propósito. Establecer este valor no disminuye la seguridad del sistema. Si se crea o cambia este valor, el controlador de dominio de origen debe reiniciarse para que esta configuración surta efecto.

Se debe crear un nuevo grupo local, "<SrcDomainName>$$$", en el dominio de origen con fines de auditoría.

Auditoría

Las operaciones DsAddSidHistory se auditan para garantizar que tanto los administradores del dominio de origen como los del dominio de destino puedan detectar cuándo se ha ejecutado esta función. La auditoría es obligatoria tanto en el dominio de origen como en el de destino. DsAddSidHistory verifica que el modo de auditoría esté activado en cada dominio y que la auditoría de la gestión de cuentas de los eventos de éxito/fracaso esté activada. En el dominio de destino, se genera un evento de auditoría "Add Sid History" único para cada operación DsAddSidHistory correcta o fallida.

En los sistemas Windows NT 4.0 no se dispone de eventos de auditoría únicos "Agregar el historial de Sid". Para generar eventos de auditoría que reflejen inequívocamente el uso de DsAddSidHistory contra el dominio de origen, realiza operaciones en un grupo especial cuyo nombre es el identificador único en el registro de auditoría. Se debe crear un grupo local, "<SrcDomainName>$$$", cuyo nombre esté compuesto por el nombre NetBIOS del dominio de origen junto con tres signos de dólar ($) (código ASCII = 0x24 y Unicode = U+0024), en el controlador de dominio de origen antes de llamar a DsAddSidHistory. Cada usuario de origen y grupo global que es un objetivo de esta operación se agrega y luego se elimina de la membresía de este grupo. Esto genera eventos de auditoría Agregar miembro y Eliminar miembro en el dominio de origen, que se pueden supervisar buscando eventos que hagan referencia al nombre del grupo.

Nota:

Las operaciones DsAddSidHistory en grupos locales en un dominio de origen de modo mixto Windows NT 4.0 o Windows 2000 no se pueden auditar porque los grupos locales no se pueden convertir en miembros de otro grupo local y, por lo tanto, no se pueden agregar al grupo local especial "<SrcDomainName>$$$". Esta falta de auditoría no supone un problema de seguridad para el dominio de origen, ya que el acceso a los recursos del dominio de origen no se ve afectado por esta operación. Agregar el SID de un grupo local de origen a un grupo local de destino no otorga acceso a los recursos de origen, protegidos por ese grupo local, a ningún usuario adicional. La adición de miembros al grupo local de destino no les concede acceso a los recursos de origen. Los miembros añadidos solo tienen acceso a los servidores del dominio de destino migrados desde el dominio de origen, que pueden tener recursos protegidos por el SID del grupo local de origen.

Seguridad en la transmisión de datos

DsAddSidHistory aplica las siguientes medidas de seguridad:

• Si se llama desde una estación de trabajo Windows 2000, las credenciales de la persona que llama se utilizan para autenticar y proteger la privacidad de la llamada RPC al controlador de dominio de destino. Si SrcDomainCreds no es NULL, tanto la estación de trabajo como el DC de destino deben admitir cifrado de 128 bits para proteger la privacidad de las credenciales. Si el cifrado de 128 bits no está disponible y se proporciona SrcDomainCreds, la llamada debe realizarse en el DC de destino.
• El controlador de dominio de destino se comunica con el controlador de dominio de origen utilizando SrcDomainCreds o las credenciales de la persona que realiza la llamada para autenticarse mutuamente y proteger la integridad de la lectura del SID de la cuenta de origen (mediante una búsqueda SAM) y el sIDHistory (mediante una lectura LDAP).

Modelos de amenazas

La siguiente tabla enumera las amenazas potenciales asociadas con la llamada DsAddSidHistory y aborda las medidas de seguridad pertinentes a la amenaza en particular.

Amenaza potencial	Medida de seguridad
Ataque de tipo "Man in the middle" Un usuario no autorizado intercepta la llamada de retorno al SID de búsqueda del objeto de origen, sustituyendo el SID del objeto de origen por un SID arbitrario para su inserción en un SIDhistorial del objeto de destino.	El SID de búsqueda del objeto de origen es un RPC autenticado, que utiliza las credenciales de administrador de la persona que realiza la llamada, con protección de mensajes de integridad de paquetes. Esto asegura que la llamada de retorno no puede ser modificada sin detección. El controlador de dominio de destino crea un evento de auditoría único "Add SID History" que refleja el SID añadido a la cuenta de destino sIDHistory.
Dominio de origen troyano Un usuario no autorizado crea un dominio de origen "Caballo de Troya" en una red privada que tiene el mismo SID de dominio y algunos de los mismos SID de cuenta que el dominio de origen legítimo. A continuación, el usuario no autorizado intenta ejecutar DsAddSidHistory en un dominio de destino para obtener el SID de una cuenta de origen. Esto se hace sin necesidad de las credenciales del Administrador del dominio de origen real y sin dejar un rastro de auditoría en el dominio de origen real. El método del usuario no autorizado para crear el dominio de origen del Caballo de Troya podría ser uno de los siguientes: Obtener una copia (copia de seguridad BDC) del SAM del dominio de origen. Crear un nuevo dominio, alterando el SID del dominio en el disco para que coincida con el SID del dominio de origen legítimo y, a continuación, crear suficientes usuarios para instanciar una cuenta con el SID deseado. Crear una réplica de BDC. Esto requiere credenciales de administrador del dominio de origen. A continuación, el usuario no autorizado lleva la réplica a una red privada para implementar el ataque.	Aunque hay muchas formas de que un usuario no autorizado recupere o cree un SID de objeto de origen deseado, el usuario no autorizado no puede utilizarlo para actualizar el sIDHistory de una cuenta sin ser miembro del grupo de Administradores de dominio de destino. Debido a que la comprobación, en el controlador de dominio de destino, de la pertenencia al grupo de Administradores de dominio está codificada, en el DC de destino, no existe ningún método para realizar una modificación en el disco para cambiar los datos de control de acceso que protegen esta función. Un intento de clonar una cuenta de origen Trojan Horse se audita en el dominio de destino. Este ataque se mitiga reservando la pertenencia al grupo de Administradores de dominio solo a individuos de alta confianza.
Modificación en disco del historial de SID Un usuario no autorizado sofisticado, con credenciales de Administrador de dominio y con acceso físico a un DC en el dominio de destino, podría modificar el valor de sIDHistory de una cuenta en disco.	Este intento no está habilitado por el uso de DsAddSidHistory. Este ataque se mitiga impidiendo el acceso físico a los controladores de dominio a todos excepto a los administradores de alta confianza.
Código malicioso utilizado para eliminar protecciones Un usuario no autorizado o un administrador deshonesto con acceso físico al código del Servicio de directorio podría crear un código deshonesto que: Elimine la comprobación de pertenencia al grupo Administradores de dominio en el código. Cambie las llamadas en el controlador de dominio de origen que apunta el SID a un LookupSidFromName que no se audita. Elimine las llamadas del registro de auditoría.	Alguien con acceso físico al código DS y con conocimientos suficientes para crear código rogue tiene la capacidad de modificar arbitrariamente el atributo sIDHistory de una cuenta. La API DsAddSidHistory no incrementa este riesgo de seguridad.
Recursos vulnerables a SID robados Si un usuario no autorizado ha conseguido utilizar uno de los métodos descritos aquí para modificar un sIDHistory de cuenta, y si los dominios de recursos de interés confían en el dominio de cuenta del usuario no autorizado, entonces el usuario no autorizado puede obtener acceso no autorizado a los recursos del SID robado, potencialmente sin dejar un rastro de auditoría en el dominio de cuenta del que se robó el SID.	Los administradores de dominios de recursos protegen sus recursos estableciendo solo aquellas relaciones de confianza que tienen sentido desde el punto de vista de la seguridad. El uso de DsAddSidHistory está restringido, en el dominio de destino de confianza, a los miembros del grupo Administradores de dominio que ya disponen de amplios permisos dentro del ámbito de sus responsabilidades.
Dominio de destino no autorizado Un usuario no autorizado crea un dominio Windows 2000 con una cuenta cuyo sIDHistory contiene un SID que ha sido robado de un dominio de origen. El usuario no autorizado utiliza esta cuenta para acceder sin autorización a los recursos.	El usuario no autorizado necesita credenciales de administrador para el dominio de origen a fin de utilizar DsAddSidHistory, y deja un rastro de auditoría en el controlador de dominio de origen. El dominio de destino no autorizado obtiene acceso no autorizado solo en otros dominios que confían en el dominio no autorizado, lo que requiere privilegios de Administrador en esos dominios de recursos.

Restricciones operativas

En esta sección se describen las restricciones operativas del uso de la función DsAddSidHistory.

El SID de SrcPrincipal no debe existir ya en el bosque de destino, ni como SID de cuenta principal ni en el sIDHistory de una cuenta. La excepción es que DsAddSidHistory no genera un error cuando se intenta añadir un SID a un sIDHistory que contiene un SID idéntico. Este comportamiento permite que DsAddSidHistory se ejecute varias veces con la misma entrada, lo que resulta en el éxito y un estado final coherente, para la facilidad de uso del desarrollador de herramientas.

Nota:

La latencia de replicación del Catálogo global puede proporcionar una ventana durante la cual se pueden crear SID duplicados. Sin embargo, un administrador puede eliminar fácilmente los SID duplicados.

SrcPrincipal y DstPrincipal deben ser uno de los siguientes tipos:

• Usuario

• Grupo habilitado para seguridad, incluyendo:

  Grupo local Grupo global Grupo local de dominio (solo en modo nativo de Windows 2000) Grupo universal (solo en modo nativo de Windows 2000)

Los tipos de objeto de SrcPrincipal y DstPrincipal deben coincidir.

• Si SrcPrincipal es un Usuario, DstPrincipal debe ser un Usuario.
• Si SrcPrincipal es un grupo local o local de dominio, DstPrincipal debe ser un grupo local de dominio.
• Si SrcPrincipal es un grupo global o universal, DstPrincipal debe ser un grupo global o universal.

SrcPrincipal y DstPrincipal no pueden ser uno de los siguientes tipos: (DsAddSidHistory falla con un error en estos casos)

• Equipo (estación de trabajo o controlador de dominio)

• Confianza entre dominios

• Cuenta duplicada temporal (función prácticamente no utilizada, un legado de LANman)

• Cuentas con SID bien conocidos. Los SID bien conocidos son idénticos en todos los dominios; por lo tanto, añadirlos a un sIDHistory violaría el requisito de unicidad de SID de un bosque Windows 2000. Las cuentas con SID bien conocidos incluyen los siguientes grupos locales:

  Operadores de cuenta Administradores Operadores de copia de seguridad Invitados Operadores de impresión Operadores de servidor Replicador Usuarios

Si SrcPrincipal tiene un identificador relativo bien conocido (RID) y un prefijo específico de dominio, es decir, Administradores de dominio, Usuarios de dominio y Equipos de dominio, entonces DstPrincipal debe poseer el mismo RID bien conocido para que DsAddSidHistory tenga éxito. Las cuentas con RID conocidos incluyen los siguientes usuarios y grupos globales:

• Administrador
• Invitado
• Administradores de dominio
• Invitados de dominio
• Usuarios del dominio

Configuración del valor de registro

El siguiente procedimiento muestra cómo establecer el valor de registro TcpipClientSupport.

Para establecer el valor de registro TcpipClientSupport

1. Cree el siguiente valor de registro como un valor REG_DWORD en el controlador de dominio de origen y establezca su valor en 1.

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\TcpipClientSupport

2. A continuación, reinicie el controlador de dominio de origen. Este valor del registro hace que el SAM escuche en TCP/IP. DsAddSidHistory fallará si este valor no está establecido en el controlador de dominio de origen.

Activación de la auditoría de eventos de gestión de usuarios/grupos

El siguiente procedimiento muestra cómo habilitar la auditoría de eventos de administración de usuarios/grupos en un dominio de origen o de destino de Windows 2000 o Windows Server 2003.

Para habilitar la auditoría de eventos de administración de usuarios/grupos en un dominio de origen o de destino de Windows 2000 o Windows Server 2003

1. En el complemento MMC Usuarios y equipos de Active Directory, seleccione el contenedor Controladores de dominio del dominio de destino.
2. Haga clic con el botón secundario en Controladores de dominio y seleccione Propiedades.
3. Haga clic en la pestaña Directiva de grupo.
4. Seleccione la directiva Controladores de dominio predeterminados y haga clic en Editar.
5. En Configuración del equipo\Configuración de Windows\Configuración de seguridad\Políticas locales\Política de auditoría}, haga doble clic en Administración de cuentas de auditoría.
6. En la ventana Gestión de cuentas de auditoría, seleccione Auditoría correcta y Auditoría incorrecta. Las actualizaciones de la política surten efecto tras un reinicio o una actualización.
7. Verifique que la auditoría esté habilitada visualizando la política de auditoría efectiva en el complemento MMC de la Política de grupo.

El siguiente procedimiento muestra cómo habilitar la auditoría de eventos de administración de usuarios/grupos en un dominio Windows NT 4.0.

Para habilitar la auditoría de eventos de gestión de Usuarios/Grupos en un dominio Windows NT 4.0

1. En Administrador de usuarios para dominios, haga clic en el menú Directivas y seleccione Auditoría.
2. Seleccione Auditar estos eventos.
3. En Gestión de usuarios y grupos, marque Acierto y error.

El siguiente procedimiento muestra cómo habilitar la auditoría de eventos de administración de Usuarios/Grupos en un dominio de origen Windows NT 4.0, Windows 2000 o Windows Server 2003.

Para habilitar la auditoría de eventos de gestión de usuarios/grupos en un dominio de origen Windows NT 4.0, Windows 2000 o Windows Server 2003

1. En el Administrador de usuarios para dominios, haga clic en el menú Usuario y seleccione Nuevo grupo local.
2. Introduzca un nombre de grupo compuesto por el nombre NetBIOS del dominio de origen junto con tres signos de dólar ($), por ejemplo, FABRIKAM$$$. El campo de descripción debe indicar que este grupo se utiliza para auditar el uso de DsAddSidHistory o las operaciones de clonación. Asegúrese de que no hay miembros en el grupo. Haga clic en OK.

La operación DsAddSidHistory falla si las auditorías de origen y destino no están habilitadas como se describe aquí.

Configure la confianza si es necesario

Si se cumple una de las siguientes condiciones, se debe establecer una confianza desde el dominio de origen hasta el dominio de destino (esto debe ocurrir en un bosque diferente):

• El dominio de origen es Windows Server 2003.
• El dominio de origen es Windows NT 4.0 y SrcDomainCreds es NULL.