Cómo realizar una migración de dominio de Active Directory para Dell Security Server

• Dell Security Management Server (anteriormente Dell Data Protection | Enterprise Edition) se levanta y se une el dominio.
• Se agregó un dominio existente a la sección “domain” en la consola WebUI.
• Las terminales se han activado contra el servidor.
• Se requiere una migración de dominio.
• También planeamos migrar el historial de SID de los objetos de AD.
• Los terminales tienen conectividad completa con el servidor y pueden recuperar políticas en el dominio antiguo antes de iniciar el proceso de migración del dominio.
• Los datos cifrados en las terminales son totalmente accesibles, las terminales está activadas y es posible desactivarlas y reactivarlas. Podemos confirmar que las activaciones se están realizando sin ningún problema mediante un rápido WSDeactivate de cualquier terminal.

Los pasos generales no son demasiado complejos, pero es necesario comprender que si todo el proceso no se realiza de forma correcta, se pueden perder datos o se podría requerir una recuperación de las máquinas. Por último, aunque este proceso se puede realizar en cualquier versión de Dell Security Management Server y el cliente, Dell Technologies recomienda tener al menos un cliente 8.3.0 y un servidor 8.5 instalados, ya que se han realizado varias mejoras desde entonces, lo que facilita el proceso general de migración en el lado de Dell Security Management Server. A continuación, se presenta una visión general de cómo funciona el proceso general y algunas de las preguntas más preocupantes.

El primer paso es comprender si se requiere una migración de dominio. Hay situaciones como cuando una empresa está transicionando, por ejemplo, a Office 365, en las que es suficiente agregar un alias y configurarlo como el UPN principal para los usuarios de AD. Esta no es una migración de dominio real y no se requiere ninguna otra acción en el servidor Dell Data Protection | Enterprise Edition aparte de agregar el nuevo alias a la lista de alias de dominio en Settings, la sección Domain Alias List. Si se crea un nuevo dominio y los objetos de AD se deben transferir del dominio desactivado antiguo al nuevo, aquí es cuando se debe planificar una migración de dominio.

Cada vez que se planifica una migración de dominio, el primer paso también es considerar la migración del historial de SID. Para que la migración de dominio se realice con éxito en el lado de Dell Security Management Server, es necesario conservar el historial de SID; de lo contrario, los objetos de AD se consideran nuevos en nuestro Dell Security Management Server y, por lo tanto, después de la reactivación, no se podrán aprovechar las mismas claves de cifrado. Dell necesita migrar el historial de SID. No vamos a dedicar tiempo en mostrar cómo se realiza una migración de dominio, ya que no se trata de una tarea de Dell Data Protection | Encryption, pero existen varias herramientas como ADMT de Microsoft que permiten a una organización migrar de un dominio A a un dominio B. Como se indicó antes, se requiere una migración de historial de SID para mantener la persistencia en términos de claves. La migración del historial de SID significa que estamos agregando al atributo de historial de SID en AD de la migración previa del SID del usuario anterior, lo que garantiza la continuidad en los objetos migrados.

Como regla en el lado de AD:

• Cuando se cambia el nombre de cualquier objeto, el valor del atributo objectSID (el SID) no se cambia. Cuando transfiere un objeto de un dominio a otro, el objectSID debe cambiar, ya que parte de él es específico de su dominio, y el SID antiguo se agrega al SIDHistory atributo (suponiendo que se migra). Puede ver SIDHistory mediante ADSI Edit (puede ver en hexadecimal o decimal). Si no hay valores, no hay ningún historial de SID o el objeto nunca se transfirió de otro dominio.
• SIDhistory solo está disponible cuando se migran cuentas entre dominios o bosques.

A continuación, se muestra una captura de pantalla de cómo determinar si el SIDHistory se migró mediante el editor de atributos:

Una vez que hayamos confirmado que los SIDHistory de los usuarios y las máquinas migrados también se transfirieron, podemos seguir adelante con la configuración de Dell Security Management Server. Si se requiere más información sobre cómo realizar una migración de dominio y cómo conservar el historial de SID, consulte la siguiente documentación de Microsoft:

• https://www.microsoft.com/en-us/download/details.aspx?id=19188
• https://technet.microsoft.com/en-us/library/cc974332(v=ws.10).aspx
• https://technet.microsoft.com/en-us/library/cc974384(v=ws.10).aspx

A continuación, se muestra lo que sucede durante una migración de dominio en el lado de Dell Security Management Server.

1. En el lado del cliente:
   • Resolvemos el UPN de los usuarios en el SID. Buscamos su SID en el archivo vault. No lo encontramos.
   • Decidimos que se trata de un nuevo usuario y nos comunicamos con el servidor de seguridad, mediante la entrega de la contraseña de UPN como una solicitud de activación típica.
2. En el lado del servidor:
   • Obtenemos la solicitud de activación. Nos comunicamos con Active Directory y buscamos el UPN. Luego, realizamos un triage del usuario. Como parte de este proceso de triage, observamos que el SID en la tabla Entity no coincide con el SID en AD. Examinamos el SIDHistory para comprobar el SID en nuestra tabla Entity. Si no lo encontramos, se produce una excepción y la activación falla, ya que ya tenemos esa SCID implementada. Cuando encontramos el SID, actualizamos la tabla Entity con el nuevo SID (en la parte UID, la primera parte es el dominio y lo actualizamos y, también, actualizamos la parte del dominio del terminal).
   • Luego, le transmitimos al cliente las claves antiguas, la política, DCID, etc. (como si fuera una reactivación).
3. De vuelta en el cliente:
   • El terminal recibe esta información y agrega una entrada en el archivo credsys.vlt, que indica que el usuario está activado y que el usuario en ese punto inició sesión de manera normal.

Un punto clave del lado de Dell Security Management Server es la comprensión de si se debe agregar un nuevo dominio a la WebUI para que todo funcione con los usuarios nuevos y antiguos mientras se activan o reactivan.

En una migración de dominio, no agregamos el nuevo dominio a la consola de Dell Security Management Server SI el dominio raíz primario del dominio migrado antiguo y nuevo se encuentra en esa ubicación. Es suficiente agregar el dominio nuevo en forma de alias en la sección “Settings”, “Domain Alias List”. (Y suponemos que existe una confianza bidireccional entre el dominio primario y el nuevo dominio secundario). La cuenta de servicio para el dominio raíz se debe configurar posiblemente en el dominio primario. Si, en su lugar, estamos migrando de un dominio A.local a B.local y los dos dominios no son secundarios del mismo dominio raíz o pertenecen a un bosque diferente, necesitamos un nuevo dominio que se agregue en nuestra consola, ya que debemos vincular los terminales existentes con el nuevo dominio y una nueva cuenta de servicio.

La comprensión de lo anterior sobre la configuración correcta de Dell Security Management Server es un punto clave, ya que, de lo contrario, nos enfrentamos a varios problemas posteriores a la migración. También es fundamental comprender el tipo de confianza existente entre esos dominios y sus dominios raíz (si los hay) y cuál es su lista de dominios actuales en la consola de Dell Security Management Server. La regla es simple, si tiene algún tipo de confianza entre el elemento primario o secundario, entonces tener el dominio raíz y los alias configurados en el servidor Dell Data Protection | Enterprise Edition es suficiente. De lo contrario, debemos agregar tantos dominios secundarios en Dell Security Management Server como sus subdominios reales y esta regla también se aplica a la migración de dominios.

Por último, como regla más general, *nunca* debemos agregar un dominio secundario y primario de forma simultánea, ya que tener al mismo usuario potencialmente visible en ambos niveles interrumpe el funcionamiento para nosotros. Además, la eliminación del dominio (aún) no es una tarea soportada por completo en el lado de Dell Security Management Server.

Si el cliente está en v8.2.1 o anterior y el servidor está en v8.3.1 o anterior, WSDeactivate es un paso necesario ya que no cambiamos el nombre de la parte del dominio del terminal en el lado del servidor automáticamente. Esto no se aplica a las compilaciones más recientes de Dell Security Management Server o terminales.

Los dominios antiguos no se pueden eliminar de la base de datos de Dell Security Management Server de forma manual ni mediante la consola. Esto se debe a que Dell Security Management Server busca un usuario o grupo y luego determina su membresía al dominio. Por eso, lo que debe suceder cuando se elimina un dominio, es que también se deberían eliminar todos los objetos que forman parte de ese dominio. Ninguna opción se soporta en esta etapa. Dell está investigando para cambiar este comportamiento en futuras compilaciones de Dell Security Management Server, aunque en esta etapa esta no es una tarea soportada o viable. Por otra parte, si optamos por marcar (de forma manual) el dominio como eliminado en la base de datos, comenzamos a recibir un error que se produce en los registros del servidor cada 15 minutos para todos los usuarios y los grupos huérfanos asociados.

En caso de que Shield se desinstale en una terminal migrada, los mismos pasos que se necesitan para aplicar una reactivación normal (sin dominio) contra el mismo ID de Shield se necesitan aquí también. En los archivos cifrados comunes, debemos aplicar la misma DCID en el registro antes de permitir que el terminal se reactive contra Dell Data Protection | Enterprise Edition Server o Dell Security Management Server. Si tiene alguna pregunta, comuníquese con el equipo de soporte técnico para obtener más ayuda.

No, no se requiere una nueva licencia de dominio a partir de Dell Data Protection | Enterprise Edition Server 8.x. En versiones anteriores de Dell Data Protection | Enterprise Edition Server, aún se requiere una licencia nueva. Comuníquese con el equipo de soporte técnico para obtener más información.