Problemas con el SID en virtualización

Escrito en Ago 24, 2011 en Blog, Sistemas Operativos, Virtualización, Windows | 0 comentarios

Problemas con el SID en virtualización

Hace poco estaba preparando unas máquinas virtuales para hospedar un nuevo diseño de Active Directory para la empresa en que trabajo. Así que empecé con una plantilla de Windows Server 2008 R2 que había creado anteriormente. La primera máquina que cloné la convertí en un controlador de dominio, le asigné una nueva dirección IP, nombre de host, luego creé otro clon para un servidor de archivos, hice los cambios respectivos, inicié sesión localmente, la uní al dominio y todo resultó bien.

A continuación intenté crear un dominio hijo, nuevamente hice otro clon, ejecuté dcpromo y antes de terminar el proceso se interrumpió con el siguiente mensaje de error: The service account manager (SAM) has determined that the security identifier (SID) for this computer is already in use in the Forest you want to join. (…) “The specified domain already exists.”. Era evidente que se trataba de un problema con el SID del equipo así que resolví cambiarlo ejecutando sysprep, con lo que se solucionó. Veamos qué pasó.

Cuando ejecutas dcpromo en un equipo para convertirlo en un controlador de dominio (DC), el primer DC usa el SID de la máquina como el SID del dominio; los DC que le sigan tomarán el mismo SID del primer DC pues se trata del mismo dominio. En mi caso el equipo donde planeaba crear el nuevo dominio tenía el mismo SID del dominio que ya estaba en pie, por eso el error.

The service account manager (SAM) has determined that the security identifier (SID) for this computer is already in use in the Forest you want to join. (...) "The specified domain already exists.

El SID de este equipo ya existe en el bosque. Sí, este es un clon.

El SID de usuario tiene dos partes, una parte dominio/equipo y un número de usuario conocido como ID relativo (RID), por ejemplo S-1-2-16-567161855-2578041332-2953840392-66180, donde S-1-2-16-567161855-2578041332-2953840392 es el SDI del dominio (o SID de equipo si es un usuario local) y 66180 es el RID. Esta combinación debería ser un identificador único para ese usuario.

Como podrán imaginar esto no siempre es verdad, y les explico por qué. El ID de usuario de la cuenta Administrador siempre es 500, de forma que en el escenario que puede resultar de clonar máquinas virtuales a partir de una plantilla, tanto el administrador de dominio como un administrador local podrían tener el mismo SID.

También puede suceder que una cuenta de dominio, que no sea la propia cuenta de Administrador, inicia sesión en un clon. Como el SID del dominio y del equipo es el mismo, el sistema operativo asume que se trata de un usuario local, pero no encuentra el RID en la SAMSecurity Account Manager, base de datos donde se almacenan las contraseñas de Windows NT y posteriores, lo que da lugar a multitud de errores. Como les anticipé, esto se resuelve con sysprep.

Otro escenario donde esto puede resultar problemático es en la virtualización de escritorio (VDI). Como deben saber los entendidos en la materia, aunque hay algunas tecnologías disponibles, como VMware View o Citrix XenDesktop para la provisión rápida de máquinas virtuales (VM) al final con todas el resultado sería el mismo ya que el proceso genérico básicamente toma una plantilla de un Windows unido a un dominio, le cambia el ID de la máquina (no el SID), el nombre de equipo y lo une nuevamente al dominio usando cuentas de equipo creadas anticipadamente.

Sucede que si creas 2 máquinas virtuales de Windows 7 a partir de la misma plantilla, e inicias sesión en una de ellas con la cuenta de administrador local, vas a poder acceder al C$Recurso compartido administrativamente para toda la unidad C: en la otra máquina, sin solicitar autenticación. Algo que no debería suceder.

Normalmente se deberían solicitar credencials adicionales, pero no en este caso ya que ambos usuarios son idénticos pues tienen el mismo nombre, SID y contraseña, así que Windows lo “autentica automáticamente”. Si cambian la contraseña de la cuenta, cierran sesión e inician nuevamente sí les solicitará contraseña al intentar acceder al recurso C$. Habiendo visto esto, no me resulta difícil pensar en un virus o gusano diseñado adecuadamente para multiplicarse a través de la red en ambientes VDI.

Además como bien apunta Mark Russinovich, sysprep cambia otros parámetros específicos del equipo, los cuales si se duplican pueden causar problemas en ciertas aplicaciones, así que Microsoft sigue requiriendo que los clones se hagan únicos ejecutando sysprep.

La lección: en la mayoría de casos será necesario ejecutar sysprep para cada máquina virtual clonada para evitar problemas de seguridad y errores de aplicaciones.


Deje una respuesta.

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *