Controladores de Dominio: Copia de Seguridad y Recuperar (Domain Controllers Backup – Restore) – Restore – Parte 5 de …

Continuando con esta serie de notas sobre el tema de copias de seguridad (Backup) de Controladores de Dominio, y las diferentes formas de recuperación, en esta vamos a ver cómo podemos recuperar una cuenta de usuario eliminada accidentalmente, pero a diferencia del caso anterior, en este contamos con una copia (Backup) del Estado del Sistema (System State)

Así que comencemos, voy a borrar la cuenta de “Usuario Dos”. Es de aclarar que esta cuenta pertenece al grupo Global-1

Esta es la prueba :)

¿Cómo recuperamos la cuenta de usuario eliminada? Bien, recordemos que de notas anteriores habíamos dejado programada una copia del Estado del Sistema (System State) sobre una carpeta compartida de red, así que la recuperaremos desde ese lugar.

La copia de seguridad (Backup) de nuestro Active Directory, como hemos visto, se puede hacer con el Controlador de Dominio en funcionamiento. Pero para recuperar la copia (Restore) no se puede.
Debemos reiniciar al Controlador de Dominio, y durante el arranque pulsar la tecla F8 para que nos muestre las opciones avanzadas de arranque.

Dentro de las mismas seleccionamos la opción “Directory Service Restore Mode”

Hará un arranque similar al Modo Seguro (Safe Mode)

Atención a lo que sigue ¿Recuerda la contraseña que puso durante el proceso de promoción a Controlador de Dominio del servidor? Esa es justamente la que necesita. Por motivos de seguridad, esta contraseña, además de que no tiene relación con la del administrador del Dominio, debería ser diferente

Y segundo a tener en cuenta, es que como tenemos un único Controlador de Dominio en nuestro Dominio de pruebas, no hay quien pueda validar la cuenta de administrador del Dominio, así que deberemos obligatoriamente usar la cuenta de “administrador local”, lo cual indicaremos escribiendo en el nombre de usuario: “.\Administrator” y la contraseña antes mencionada

Ingresamos a la aplicación de Copia de Seguridad (Backup), elegimos Recover, y como la copia la hemos hecho en una carpeta de red marcamos la opción: “A backup stored on another location”

Y seguimos el asistente como indican las figuras

Como nos había avisado el sistema cuando elegimos hacer la copia en una carpeta de red, sólo está disponible la última versión

Recordemos que lo que queremos recuperar es el Estado del Sistema (System State)

Detengámosnos un momento y observervemos una opción, que no marcaré en este caso, pero que se denomina “Perform an authoritative restore of Active Directory Files”. Describiré su uso al final de la nota.

Siguen varias advertencias. Tenerlas en cuenta

Y comienza a recuperar

Como habíamos marcado la opción para que reincie automáticamente al finalizar, lo hace, y nos muestra un mensaje indicando que ha completado la recuperación

Verificamos que hemos recuperado la cuenta de usuario “User Dos”, y que además se ha recuperado la pertenencia al grupo

Final feliz del proceso de recuperación de la cuenta de usuario borrada accidentalmente :)

 

Pero vamos a ver para qué casos se debe utilizar la opción que nombrábamos hace un rato (“Perform an authoritative restore of Active Directory Files”)

En este caso tenemos un único Controlador de Dominio, pero ¿qué sucedería si tuviéramos más de uno?
Supongamos que hacemos la copia de seguridad programa a las 2 de la madrugada (2 AM), se resguarda como está todo en ese momento.
Luego a las 9 de la mañana, borramos la cuenta de usuario, y por supuesto ese cambio se replica a otro/s Controladores de Dominio.

Luego que nosotros recuperamos desde nuestra copia de seguridad de la hora (2 AM) y reinciamos el servidor, va a haber otro Controlador de Domino, que dirá “yo tengo cambios más recientes: a las 9 AM el administrador borró la cuenta de este usuario”.
La consecuencia es inmediata, nuestro usuario de prueba es nuevamente eliminado :(

Se soluciona fácil. Cuando marcamos que la restauración es Autoritaria (Authoritative), significa que “esto vale”. Y por lo tanto lo que hemos recuperado va a replicarse al resto de los Controladores de Domino

Esta nueva forma de hacer un “Authoritative Restore” es novedad en Windows Server 2008-R2. En sistemas anteriores no aparece esta opción, aunque por supuesto puede hacerse de otra manera que describiré brevemente a continuación.

La comento porque puede solucionarnos, aún con Windows 2008-R2, alguna situación específica.

Marcando la opción en el asistente, implica que todos los objetos de nuestro dominio son “autoritarios” (valen por sobre los otros), y se puede presentar la situación donde sólo queramos marcar como “autoritarios” sólo un objeto, o sólo el contenido de una Unidad Organizativa.

En este caso, no debemos marcar la opción antes nombrada, y tampoco hacer que reincie automáticamente.
Luego de la recuperación, abrir la línea de comandos (CMD.EXE), ejecutar

NTDSUTIL.EXE
ACTIVATE INSTANCE NTDS
AUTHORITATIVE RESTORE

RESTORE OBJECT … o RESTORE SUBTREE …
De acuerdo a quieran marcar como “autoritario” un objeto en particular, o toda una Unidad Organizativa
Dejo la sintaxis a vuestro cargo :)

Resumiendo, hemos podido recuperar desde una copia de seguridad (Backup) del Estado del Sistema (System State), un objeto borrado accidentalmente, y de forma totalmente análoga si en lugar de ser un objeto hubiera sido una Unidad Organizativa con todo su contenido

Anuncios
Post a comment or leave a trackback: Trackback URL.

Comentarios

  • Oscar Chavez  On 22/09/2014 at 20:14

    Hola, eres una pistola (eres grande, el mejor púes) como decimos en México, felicidades sigue con tus aportaciones, de verdad que nos sacan de muchas apuros y dudas.

  • Jesús Rodríguez  On 04/01/2015 at 18:29

    Cuando te logeas (.\administrador) realmente no debes poner la contraseña de AD? y no es independiente haya o no más controladores? eso he entendido en otros documentos.

    • Guillermo Delprato  On 05/01/2015 at 06:47

      Hola Jesús, todo depende si puedes usar el administrador del Dominio, o no :)
      Si hay otro Controlador de Dominio funcionando entonces sí, puedes iniciar sesión con un administrador de Dominio, aunque depende también si hubieran credenciales “cacheadas” (esto no lo he probado)
      De otra forma, debes usar una cuenta local “Administrator” o “Administrador”, y la contraseña DSRM (“Directory Service Restore/Repair Mode”) que se ha asignado en dicho Controlador de Dominio, durante la promoción ¿la recuerdas? ;)

  • Camilo  On 05/09/2015 at 15:37

    Hola Guillermo, primero felicitarte por este grandioso blog, el cual tiene excelente información.

    Actualmente tengo una duda y he buscado en muchas partes, pero no he logrado resolverla completamente…mi duda está enfocada específicamente sobre restaurar el “System State”

    Empecemos…hacer la restauración del estado del sistema de un controlador de dominio, digamos que “no tiene ciencia”, el problema que he encontrado es cuando quiero hacerlo en una infraestructura que tiene más de un DC. He realizado varios laboratorios donde tengo 2 DCs y el “System State” lo hago sobre el DC principal, luego del backup elimino una OU y algunas políticas, hago la replicación manual o espero a que replique automáticamente, o sea que ambos DC saben que se eliminaron objetos del directorio y gpo; estos son los resultados que he obtenido, para esto voy a decir que DC1 es el ppal y DC2 es el secundario:

    1. Si ambos DC están en línea, cuando hago una restauración autoritativa en el DC1 (Windows Server Backup) e ingreso al equipo, el resultado es que en el DC1 no aparecen los objetos eliminados y tampoco las GPO, pero las políticas en el sysvol\dominio\policies si fueron resturadas…

    2. Antes de empezar con la restauración desconecto la conexión de red del DC1, hago la restauración autoritativa o no autoritativa (WSB) e ingreso al equipo, el resultado es que puedo ver tanto los objetos del directorio, como las GPO eliminadas, pero cuando conecto nuevamente la conexión de red del DC1, recibe una replica del DC2, eliminando todo nuevamente.

    3. Hago la restauración autoritativa o no autoritativa (WSB), luego de terminada la restauración, hago restauración autoritativa (NTDSUTIL) e ingreso al equipo, el resultado es que los objetos del directorio se mantienen, pero las GPO no. Para hacerlo de esta manera, es necesario conocer la cadena LDAP que se quiere restaurar, pero qué pasa si no se conoce? lo digo por que intenté usando la del dominio y saca error, me imagino que es porque sólo puedo dar la cadena de un objeto que realmente no exista.

    Hay alguna forma de hacer realmente una restauración autoritativa, donde pueda preservar los objetos del AD y las GPO? o necesariamente debo usar el ntdsutil y restaurar las políticas, mediante un backup de las GPO.

    Sólo me falta probar el segundo escenario, pero realizando una restauración autoritativa del dominio, sólo que nunca lo he hecho usando DFRS, por lo que he visto es totalmente diferente a como se hacía cuando se usa FRS.

    Espero haber sido lo suficientemente claro, saludos y muchas gracias.

    • Guillermo Delprato  On 07/09/2015 at 08:02

      Hola Camilo, ¡gracias por tu comentario” son los que dan ánimo para seguir con estas notas :)

      Vamos ahora a las preguntas
      La necesidad de hacer una restauración autoritativa, creo que eso esta claro, es poder hacer que un cambio “mas viejo” prevalezca sobre uno “más nuevo”. O sea, supongamos a la hora 1 haces la copia, a la hora 2 borras, y luego restauras una copia de la hora 1 y quieres que no se ejecuten los cambios de la hora 2
      Como aclaración nada más: no hace falta cuando se va a recuperar que esté desconectado de la red

      Te comento un “casi error” o bug que he encontrado hace poco al estar creando las prácticas para el tema de capacitación que estoy haciendo desde el blog, sobre OUs y usuarios
      Aunque está para marcar en la interfaz gráfica de tomar la restauración como autoritativa, no funciona como se espera. La única forma real de que lo tome como autoritativo es marcándo lo que se quiere conservar con NTDSUTIL ¿lo haz hecho así? Y por supuesto antes de reiniciar
      Creo que en el caso de las GPOs, lo que hay que hacer es marcar la opción de restauración autoritativa en la interfaz gráfica, además del NTDSUTIL
      Otra opción es que en la consola de administración de GPOs, se puede hacer copia de seguridad (“Backup”) individualmente de cada GPO
      Es interesante lo que planteas, no he tenido tiempo de probar con las GPOs, esta semana estoy complicado de tiempo pero voy a probarlo y agregaré el tema en la nota

      Si no conoces el DN (“Distinguished Name), o cadena LDAP como lo llamas, no hay forma de recuperar autoritativamente, aunque hay otras opciones, como son el uso de LDP o inclusive la papelera de reciclaje de AD
      En W2008 la papelera se activa solamente a través de PowerShell, y no como en W2012 que se puede hacer con la interfaz grácia
      Revisa estos dos artículos
      Windows Server 2012 (R2): Crear un Dominio – Recuperar un Borrado Accidental sin Copia de Seguridad ni Papelera de Reciclaje | WindowServer:
      https://windowserver.wordpress.com/2014/12/23/windows-server-2012-r2-crear-un-dominio-recuperar-un-borrado-accidental-sin-copia-de-seguridad-ni-pepelera-de-reciclaje/
      Windows Server 2012 (R2): Crear un Dominio – Recuperar un Borrado Accidental Usando la Papelera de Reciclaje | WindowServer:
      https://windowserver.wordpress.com/2014/12/18/windows-server-2012-r2-crear-un-dominio-recuperar-un-borrado-accidental-usando-la-papelera-de-reciclaje/

      A causa de estas mejoras que se fueron agregando, para recuperaciones de borrados accidentales yo usaría mucho más cualquiera de estos dos procedimientos, por sobre el System State, el cual dejaría sólo para recuperación de otros servicios o reparación del servidor. Estos procedimientos son válidos no sólo para W2012, sino que funcionan igual en W2008

      • Camilo  On 07/09/2015 at 15:09

        Hola Guillermo,

        Muchas gracias por tomarte el tiempo de responder!

        Te mencionaba lo de desconectar la red, simplemente porque he visto que la única forma de que el DC conserve la restauración, es cuando no “ve” otro controlador de dominio, es decir, que el DC1 no puede alcanzar el DC2; es la manera más sencilla que se me ocurrió, pero podría ser cualquier método que hiciera que el DC1 no tenga contacto con el DC2, incluso no sé si funcione simplemente deshabilitando el ICMP, esto sería similar a una restauración de un solo DC, donde sólo se restaura el estado del sistema y ya.
        Esto lo menciono porque si yo simplemente quisiera que el DC1 no replicara con el DC2, hago que cuando el DC1 suba nuevamente, lo haga con el servicio “DFS Replication” deshabilitado, pero aún así, sólo con el hecho de que el DC1 sepa que hay otro DC en la red, no es capaz de conservar la restauración (el tema es algo complejo, espero me haya hecho entender :] )

        Referente a lo que mencionas del bug, es la razón por la que estoy consultando, porque también lo he notado y sé que no funciona como debería ser, pero con lo que me has dicho creo que me has dado a entender que sí es como estaba pensando, hacer la restauración por el WSB, luego mediante el NTDSUTIL y luego restaurar políticas desde un backup, lo cual está mal, desde mi punto de vista… :(

        Con respecto a usar otros métodos ante borrado accidental, en vez de la restauración del estado del sistema, estoy totalmente de acuerdo contigo, pero te cuento…. hace poco empecé un proyecto parecido al tuyo, sólo que no tengo blog, lo que hago es hacer videos de TI y subirlos a YouTube, y pues tenía en mente hacer uno sobre este proceso que me parece muy importante y normalmente todos hacen este proceso para un DC, lo cual no tiene ningún inconveniente. De hecho eres la única persona de habla hispana que he visto que mencione que la restauración autoritativa no funciona como debe ser, lo cual agradezco :) porque confirma mis sospechas.

        Tengo dos pruebas en mente:
        1. Restaurar en DC1 mediante Windows Server Backup, hacer que DC1 y DC2 no se “vean” y antes de hacer que se “vean”, hacer un cambio en el AD del DC1, con el fin de que me actualice la base de datos del directorio, a ver si es capaz de replicar desde DC1 a DC2 y no al contrario.
        2.Restaurar en DC1 mediante Windows Server Backup, hacer que DC1 y DC2 no se “vean” y antes de hacer que se “vean”, hacer una restauración autoritativa del dominio, es decir usando el ADSI Edit, ya que estoy usando DFSR.

        Si gustas…te cuento cómo me va con estas pruebas.

        Nuevamente mil gracias y ánimo porque tu blog es realmente excelente.

      • Guillermo Delprato  On 07/09/2015 at 17:04

        No hace falta desconectar de la red durante la recuperación, porque al haber arrancado en modo DSRM no estan activos los servicios de Active Directory, y por lo tanto hasta que no se reinicie en modo normal no hay replicación
        ICMP que yo sepa no tiene ninguna relación con la replicación de AD :)

        Cuando arranca en modo “normal” entonces ahí sí, se produce la replicación. Pero si sobre-escribe lo restaurado, es porque el “autoritativo” no fue así
        ¿Cuando marcaste el “autoritativo” con NTDSUTIL no dio ningún error seguro?

        Habrás visto que desde el blog, comencé con el tema capacitación, tengo muchos años como MCT (Microsoft Certified Trainer) y estuve preparando prácticas sobre máquinas virtuales para que los asistentes a los cursos, puedan hacer la ejercitación
        Justamente ahí ha saltado el problema de que la marca en la interfaz gráfica no funciona como debe, pero haciendo uso del NTDSUTIL funciona sin ningún problema (¡Probado! :))

        Con las pruebas que queires hacer, cuidado que puede haber problemas, porque no funciona como piensas. Mientras esté en ADRM no podrás hacer ningún cambio sobre el AD, no está funcionando el servicio. No es cuestión de que se vean o no

      • Camilo  On 07/09/2015 at 18:38

        Hola Guillermo,

        Tendría que mostrarte para poder hacerme entender bien. Lo que mencionas del modo DSRM es claro, pero como te mencioné no se trata de replicación, porque como te dije si yo en el modo DSRM le digo al servidor que suba con el servicio “DFS Replication” deshabilitado, el DC1 no puede ver nada de lo que se restauró, mientras que si no está en contacto con otro DC (es decir como si fuera el único) ve todos los objetos restaurados; y lo del ICMP no lo mencionaba por el tema de replicación, si no por el tema de que no tengan contacto los DC.
        Si es posible haz esta prueba, dos DC, en el principal saca backup al “system state”, luego eliminas algo y cuando vayas a restaurar apagas el otro DC y vas a ver que en el DC1 puedes ver todo lo eliminado (es como si estuviera solo), mientras si lo haces con ambos servidores en línea y en el DC2 está detenido el servicio “DFS Replication”, el DC1 no puede ver los objetos que se restauraron.

        Para aclarar, el NTDSUTIL yo lo hice y no me generó error, que esa fue la prueba 3, en la que mencionaba que los objetos del AD si se conservan, pero no las políticas.

        Lo de la prueba 1, es claro que no lo voy a hacer en modo DSRM, lo voy a hacer con los equipos en modo normal, pero el servicio de replicación lo voy a detener en alguno de los servidores.

        Muchas Gracias!

      • Guillermo Delprato  On 08/09/2015 at 07:29

        Hola Camilo, como te comenté yo ya hice la prueba con dos DCs y funciona bien tal cual como te digo
        Y no le veo utilidad, además que se podrían hacer mil combinaciones posibles deteniendo algunos servicios como nombras
        Si te interesan las pruebas, adelante, pero por mi lado el objetivo es la recuperación de datos en una situación dada

      • Camilo  On 08/09/2015 at 10:21

        Hola Guillermo, te agradezco la ayuda.

Trackbacks

Este espacio es para comentarios sobre la nota. No es un sitio de soporte

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: