Windows Server

Reanimación de objetos de desecho de Active Directory

Gil Kirkpatrick

 

Resumen:

  • Almacenamiento de objetos eliminados en Active Directory
  • Uso de LDP y ADRESTORE para buscar y restaurar objetos de desecho
  • Atributos de objeto y systemFlags

Aunque posiblemente no sea su tema favorito, las pérdidas accidentales de datos son un hecho de la vida y, como profesional de TI, hay que estar preparado para todo tipo de escenarios de recuperación. En el número de abril 2007 de TechNet Magazine, se trató la importancia de tener un plan

con el fin de recuperar usuarios y grupos de Active Directory ®. En ese artículo, disponible en technetmagazine.com/issues/2007/04/ADRecovery, se trataron las mecánicas de la vinculación, replicación, supresión y restauraciones autoritativas de objetos. Lamentablemente, la función de restauraciones autoritativas requiere que el inicio de un controlador de dominio (DC) en el modo de restauración del servicio de directorio (DSRM). Esto hace que el DC no estará disponible durante la operación de restauración.

Hay otro método que debería conocer. La reanimación de objetos de desecho (que no tiene nada que ver con objetos zombie) ofrece la única manera de recuperar objetos eliminados sin tener que interrumpir la conexión del DC, y es la única manera de recuperar la información de identidad de un objeto eliminado, como por ejemplo, la información de los atributos objectGUID y objectSid. Resuelve ordenadamente el problema de tener que volver a crear un usuario o grupo eliminados y tener que corregir todas las referencias a las listas de control de acceso (ACL) anteriores, las cuales contienen el objectSid del objeto eliminado. Simplemente tenga presente que la reanimación de objetos de desecho tiene sus propias limitaciones, que se tratarán en este artículo. Por lo tanto, es recomendable tener en cuenta las restauraciones autoritativas.

La reanimación de objetos de desecho se presentó en Active Directory de Windows Server ® 2003 para simplificar los diversos escenarios de la recuperación de datos. Esta característica saca partido del hecho de que Active Directory mantiene los objetos eliminados en la base de datos durante un periodo de tiempo antes de quitarlos físicamente. En este artículo proporcioné una descripción detallada de cómo Active Directory elimina y reanima objetos y cómo pueden recuperarse estos objetos eliminados con las herramientas estándar de Microsoft.

¿Qué es un objeto de desecho?

Cuando Active Directory elimina un objeto del directorio, no lo quita físicamente de la base de datos. En cambio, Active Directory marca el objeto como eliminado al configurar el atributo isDeleted del objeto en TRUE. Dicha acción elimina la mayor parte de los atributos del objeto, cambia su nombre y luego mueve el objeto a un contenedor especial en el contexto de nomenclatura (NC) del objeto denominado CN=Deleted Objects. El objeto, ahora denominado objeto de desecho, es invisible para las operaciones habituales del directorio. No aparece en ningún complemento de Microsoft ® Management Console (MMC) y la mayoría de las utilidades LDAP no tienen constancia de su existencia. En efecto, el objeto de desecho ha desaparecido. Los datos, sin embargo, están todavía allí, sólo que son invisibles. Pero, ¿por qué mantiene Active Directory objetos de desecho, que son objetos eliminados, en la base de datos?

Aunque sea invisible para otros procesos, un objeto de desecho es visible para el proceso de replicación de Active Directory. Para asegurarse de que la eliminación se realiza en todos los DC que hospedan el objeto que se está eliminando, Active Directory replica el objeto de desecho en los otros controladores de dominio. De este modo, el objeto de desecho se usa para la replicación de la eliminación en todo el entorno de Active Directory.

Vigencia de un objeto de desecho

Active Directory normalmente elimina un objeto del directorio en respuesta a una operación de eliminación de protocolo LDAP o de eliminación del Administrador de cuentas de seguridad (SAM). Esta operación se denomina la eliminación original y es diferente de las operaciones de eliminación que realiza el proceso de replicación de Active Directory. Observe que en este artículo no se tienen en cuenta los objetos dinámicos, que tienen un mecanismo de eliminación diferente y Active Directory los elimina directamente cuando expire su tiempo de vida (TTL).

Cuando Active Directory recibe la operación de eliminación, primero pasa por una lista de comprobación para asegurarse de que el objeto se puede eliminar. Este proceso es asombrosamente completo, ya que asegura que los criterios siguientes son todos verdaderos:

  • El atributo isDeleted del objeto ya no está establecido en TRUE (no se puede eliminar un objeto ya eliminado).
  • El marcador de control de descriptor de seguridad de recursos "objeto privado" no se establece en el descriptor de seguridad del objeto (esto parece ser una "característica" sin documentar. El marcador de objeto privado es el bit 1 del byte Sbz1 de la estructura del descriptor de seguridad).
  • El bit "disallow delete" (0x80000000) no está establecido en el atributo systemFlags del objeto.
  • El atributo isCriticalSystemObject del objeto no está establecido en TRUE.
  • El descriptor de seguridad del objeto concede al usuario los derechos adecuados de acceso para eliminar el objeto (más concretamente, el usuario puede eliminar el objeto en sí y puede eliminar un elemento secundario del objeto principal).
  • El objeto no es un objeto de referencia cruzada (objectClass = crossRef) para un contexto de nomenclatura (NC) existente.
  • El objeto no tiene ningún objeto subordinado (si la operación de eliminación LDAP incluye el identificador de objeto de control "eliminación de árboles" LDAP, Active Directory eliminará automáticamente todos los objetos subordinados también, a menos que el conjunto de atributos isCriticalSystemObject esté establecido en TRUE. Esto impide la eliminación inesperada de objetos críticos del sistema como parte de una operación de eliminación de árboles. Por supuesto, es posible eliminar estos objetos de forma individual).
  • El objeto no es un objeto interno crítico (por ejemplo, no es el objeto nTDSDSA para el DC ni los objetos de marcador de posición para antecesores de los encabezados NC).

Además de que estos criterios sean ciertos, Active Directory debe encontrarse también en un estado apropiado para procesar la operación de eliminación. Por ejemplo, si Active Directory está cambiando el nombre de un dominio, no eliminará ninguna cuenta de dominio de confianza ni ningún objeto crossRef.

Si se determina que en realidad el objeto puede eliminarse, Active Directory procede con la conversión del objeto en un objeto de desecho. En primer lugar, Active Directory elimina los atributos innecesarios del objeto y deja los que se especifican en la figura 1 y los definidos en el esquema para su retención en el objeto de desecho (consulte la sección "Recuperación de atributos de objetos" para obtener más información acerca de este tema). A continuación, cambia el nombre distintivo relativo (RDN) del objeto a CN=<old RDN>\0ADEL:<objectGUID>, donde \0A indica el carácter de salto de línea ASCII y <objectGUID> es el objectGUID expresado como una cadena. A continuación, el atributo lastKnownParent se establece en el nombre distintivo (DN) del contenedor principal del objeto y el atributo isDeleted se establece en TRUE. Luego, Active Directory quita todos los atributos de vínculos de hacia delante o hacia atrás del objeto. Por último, si el atributo systemFlag del objeto no tiene establecido el bit "disallow move on delete", Active Directory moverá el objeto al contenedor CN=Deleted Objects para el NC (para obtener más información acerca este tema, consulte la barra lateral "Comportamiento del atributo systemFlags y de los objetos").

Figure 1 Atributos guardados en un objeto de desecho

Codificación que debe guardarse
attributeID
attributeSyntax
dnReferenceUpdate
dNSHostName
flatName
governsID
groupType
instanceType
lDAPDisplayName
legacyExchangeDN
mS-DS-CreatorSID
mSMQOwnerID
nCName
objectClass
objectGUID
objectSid
oMSyntax
proxiedObejctName
replPropertyMetaData
sAMAccountName
securityIdentifier
sIDHistory
subClassOf
systemFlags
trustPartner
trustDirection
trustType
trustAttributes
userAccountControl
uSNChanged
uSNCreated
whenCreated
Guardado debido a la configuración de searchFlags
msDS-AdditionalSam­AccountName
msDS-Auxiliary-Classes
msDS-Entry-Time-To-Die
msDS-IntId
msSFU30NisDomain
nTSecurityDescriptor
uid

Debe tener en cuenta que la carpeta CN=Deleted Objects es plana y que no tiene ninguna jerarquía de objetos. Puede creer que esta circunstancia provoque conflictos de nombres si elimina dos objetos diferentes con el mismo CN. Sin embargo, no es así. Dado que el objectGUID está incorporado en el RDN de todos los objetos de desecho, el RDN de cada objeto de desecho es exclusivo dentro del contenedor CN=Deleted Objects.

Por supuesto, los objetos no permanecen en el contenedor CN=Deleted Objects para siempre. La vigencia predeterminada de un objeto de desecho es de 60 días para bosques generados inicialmente con Windows® 2000 y Windows Server 2003, y de 180 días para los bosques generados inicialmente con Windows Server 2003 SP1. La vigencia del objeto de desecho se puede cambiar si configura el atributo tombstoneLifetime del objeto CN=Directory Service, CN=Windows NT, CN=Services,CN=Configuration, DC=<root domain>.

Cada 12 horas, todos los controladores de dominio inician un proceso de recopilación de elementos no usados (esto puede modificarse si configura un valor nuevo para el atributo garbageCollPeriod del objeto CN=Directory Service, CN=Windows NT, CN=Services, CN=Configuration, DC= <root domain>). Esta recopilación de elementos no usados examina todos los objetos de desecho del DC y elimina físicamente cualquiera que sea anterior a la vigencia del objeto de desecho.

Uso de LDP para buscar objetos de desecho

LDP es una utilidad parecida a Explorador de Windows que se usa para trabajar con Active Directory. Originalmente, el equipo de desarrollo de Active Directory diseñó LDP para probar su código LDAP mientras Active Directory estaba en proceso desarrollo. Ahora, como parte de las herramientas de soporte de Windows Server 2003, LDP ha evolucionado para convertirse en una herramienta sólida a la hora de trabajar con Active Directory.

Aunque los objetos de desecho sean invisibles para las operaciones normales del directorio, se pueden buscar en Active Directory mediante operaciones de búsqueda LDAP y extensiones especiales LDAP denominadas controles. Los controles son un mecanismo, definidos en el estándar LDAP, que se usan para extender el protocolo LDAP y proporcionar una funcionalidad adicional más allá de la que se define en el estándar LDAP sin perder compatibilidad con otro software compatible con LDAP. Active Directory admite 22 controles, incluido el control Return Deleted Objects. Cuando se usa para extender una operación de búsqueda LDAP, este control recupera objetos eliminados que de otro modo serían invisibles.

Para demostrar cómo funciona, se inicia sesión en el dominio foo.local con credenciales de administrador de empresa y, a continuación, se usa el complemento MMC de Usuarios y equipos de Active Directory (ADUC) para crear un objeto de usuario (CN=John Smith,CN=Users,DC=foo, DC=local), tal como se muestra en la figura 2. A continuación, se elimina el objeto de usuario, otra vez con ADUC.

Figura 2 Uso de ADUC para crear un usuario

Figura 2** Uso de ADUC para crear un usuario **(Hacer clic en la imagen para ampliarla)

Ahora se puede ejecutar el programa LDP y usarse para mostrar el objeto de desecho para el usuario eliminado. Este primer paso sirve para conectar LDP a un DC específico y autenticarlo con las credenciales apropiadas. Para conectarse al DC, simplemente se selecciona la opción Connect del menú Connection. Dado que se está ejecutando LDP en el DC, simplemente se hace clic en OK para conectarlo al DC local. Si se ejecuta LDP de forma remota, debe especificar el nombre del DC al que desea conectarse. Una vez establecida la conexión, LDP muestra los atributos rootDSE. Esto contiene los atributos que describen el estado y la configuración del DC (consulte la figura 3).

Figura 3 LDP conectado a un DC

Figura 3** LDP conectado a un DC **(Hacer clic en la imagen para ampliarla)

Ahora, para autenticar al DC con el dominio o las credenciales de administrador de empresa, se selecciona Bind desde el menú Connection. Dado ya se inició sesión como administrador de empresa para el bosque (de forma predeterminada, los administradores de dominio y administradores de empresa dispone de derechos para incluir objetos en una lista y reanimarlos en el contenedor CN=Deleted Objects); simplemente se deja el nombre de usuario y la contraseña en el cuadro de diálogo Bind y se hace clic en OK. De lo contrario, podría especificar las credenciales adecuadas en el cuadro de diálogo Bind.

A continuación, se incluye enumera el contenido del contenedor CN=Deleted Objects,DC=foo,DC=local. En general, nunca se ve el contenedor CN=Deleted Objects porque el propio contenedor está marcado como eliminado. La única manera en la que se puede buscar el CN=Objects Deleted para usar el contenedor es mediante el control LDAP Return Deleted Objects.

Para usar este control con LDP, vaya al menú Browse y seleccione Search. Aparecerá el cuadro de diálogo de búsqueda de la figura 4. El campo Base Dn permite especificar dónde empezar la búsqueda en el árbol del directorio. Se especifica el DN del contenedor Deleted Objects para el dominio (en este ejemplo, el DN es CN=Deleted Objects,DC=foo,DC=local).

Figura 4 Cuadro de diálogo de búsqueda de LDP

Figura 4** Cuadro de diálogo de búsqueda de LDP **

En el campo Filter, se especifican los criterios de búsqueda que LDP va a usar. El valor predeterminado es (objectClass=*), el cual proporciona instrucciones para que la búsqueda devuelva todos los objetos que tienen un valor para el atributo objectClass. Debido a que incluso los objetos eliminados en Active Directory tienen un valor para objectClass, el filtro predeterminado devolverá todos los objetos dentro del ámbito de la búsqueda. En este ejemplo, se cambia el filtro a (objectClass=user), lo que limitará la búsqueda a objetos de usuario. Esto hará que sea más fácil encontrar el usuario eliminado John Smith entre los posibles miles de objetos de desecho del contenedor CN=Deleted Object.

Se puede encontrar con que hay más objetos en el contenedor CN=Deleted Objects de los que Active Directory devolverá en una única operación de búsqueda. Para controlar este problema, normalmente usaría una búsqueda paginada LDAP, que devuelve un grupo de resultados cada vez. Sin embargo, LDP no permite especificar una búsqueda paginada y ampliada. Por lo tanto, deberá ajustar el filtro LDAP para localizar el objeto deseado.

Los botones de opción Scope permiten especificar la cantidad del árbol de directorio en la que se debe buscar. Una búsqueda de base sólo devolverá el objeto especificado por el campo Base Dn. Una búsqueda de un solo nivel devolverá objetos que son inmediatamente subordinados al objeto Base Dn. Además, una búsqueda de subárbol devolverá todos los objetos subordinados al objeto Base Dn. Dado que la carpeta CN=Deleted Objects es plana, se usará una búsqueda de un solo nivel para recuperar todos los objetos de desecho.

Hasta ahora, solamente he descrito la búsqueda LDAP convencional. Si tuviese que ejecutarla ahora, LDP mostraría un error e indicaría que CN=Deleted Objects,DC=foo,DC=com no existe porque está marcado como eliminado. Todavía falta incluir el control LDAP Return Deleted Objects con la operación de búsqueda. Para ello, se hace clic en el botón Options del cuadro de diálogo Search y se selecciona Extended para la opción Search Call Type, tal como se muestra en la figura 5. Esta opción permite especificar los controles para la operación de búsqueda. Aquí, también se cambia la lista de atributos a *. De este modo, LDP mostrará todos los atributos normales para cada objeto que recupera, en vez del conjunto predeterminado de atributos LDP.

Figura 5 Búsqueda LDP Cuadro de diálogo de opciones

Figura 5** Búsqueda LDP Cuadro de diálogo de opciones **

Ahora se hace clic en el botón Controls para que aparezca el cuadro de diálogo correspondiente. El cuadro de diálogo Controls de LDP es un poco complicado. Por lo tanto, al realizar esta tarea, asegúrese de seguir estos pasos cuidadosamente para agregar el control Return Deleted Objects.

Abra la lista desplegable Load Predefined, seleccione la opción Return deleted objects y haga clic en el botón Check. Esto agregará el identificador de objeto (OID) para el control Return Deleted Objects (1.2.840.113556.1.4.417) a la lista Active Controls, tal como se muestra en la figura 6. A continuación, LDP agrega el control a todas las operaciones de búsqueda ampliadas subsiguientes. Haga clic en OK para guardar la configuración del control y vuelva a hacer clic en OK para cerrar el cuadro de diálogo Search Options.

Figura 6 Adición del control Return Deleted Objects

Figura 6** Adición del control Return Deleted Objects **

El cuadro de diálogo Controls tiene un comportamiento peculiar. Concretamente, aunque aparece un OID en la lista Active Controls, no significa necesariamente que el control esté realmente vigente. A veces se tiene que desproteger un control y luego volver a protegerlo para asegurarse de que el control se usará en la operación LDAP siguiente.

Ahora estamos listos para ejecutar la búsqueda. Al hacer clic en el botón OK del cuadro de diálogo LDP Search, LDP recupera todos los objetos de usuario desde el contenedor CN=Deleted Objects para el dominio. La figura 7 muestra los resultados obtenidos.

Figura 7 Resultados desde el contenedor CN=Deleted Objects

Figura 7** Resultados desde el contenedor CN=Deleted Objects **(Hacer clic en la imagen para ampliarla)

Análisis de los resultados LDP

La búsqueda devolvió dos objetos de desecho. En primer lugar, se puede consultar el DN del primer objeto de desecho: CN=John Smith\0ADEL:41800281-6bc4-42c3-a99b-b283022b3af8,CN=Deleted Objects,DC=foo,DC=local. El objectGUID del objeto eliminado se representa como una cadena (41800281-6bc4-42c3-a99b-b283022b3af8). Debajo del DN hay una lista de atributos que muestra los valores para objectClass, cn, distinguishedName, etcétera. Puede observar que el valor del atributo isDeleted es TRUE, lo que significa que el objeto fue de hecho eliminado. También verá que objectSid se conservó en el objeto de desecho; esto es importante para recuperar los objetos de desecho de usuario y grupo, como veremos más adelante. El atributo lastKnownParent, que representa el DN del objeto que contenía el objeto eliminado antes de convertirse en un objeto de desecho, también es muy importante a la hora de recuperar objetos de desecho.

En el ejemplo, LDP mostró dos objetos de desecho, ambos objetos de usuario denominados CN=John Smith que procedían originalmente del contenedor CN=Users,dc=foo,dc=local. ¿Cómo pueden dos objetos independientes con el mismo RDN proceder del mismo contenedor? La explicación es bastante sencilla. Antes de ejecutar LDP para buscar objetos de desecho, se creó el objeto de usuario CN=John Smith en el contenedor CN=Users,DC=foo,DC=local y se eliminó. A continuación, se creó otro objeto de usuario con todos los mismos atributos y también se eliminó. Dado que ya se había eliminado el primer objeto de usuario CN=John Smith, era perfectamente razonable crear un segundo, aunque tuviera el mismo nombre. Pero se trata de objetos independientes y exclusivos, distinguidos por sus objectGUID. Dado que Active Directory incorpora objectGUID en el DN del objeto de desecho, éstos aparecen como objetos independientes en el contenedor CN=Deleted Objects.

Reanimación de un objeto de desecho

Active Directory ofrece un mecanismo para restaurar un objeto de desecho y convertirlo de nuevo en un objeto normal. Se trata efectivamente de una función para recuperar objetos eliminados. Esta función es una operación LDAP especialmente formada para modificar los objetos y debe incluir dos modificaciones concretas del atributo: debe quitar el atributo isDeleted (no sólo establecerlo en FALSE) y debe mover el objeto a otro contenedor y cambiar su distinguishedName. Normalmente (aunque no necesariamente), el distinguishedName nuevo usa el atributo lastKnownParent como el contenedor y conserva el mismo RDN menos el 0ADEL:<objectGUID> que Active Directory agregó al crear el objeto de desecho.

Antes de reanimar el objeto de desecho, Active Directory se asegura que algunas de las condiciones que son necesarias sean todas verdaderas. El usuario debe tener el derecho de acceso ampliado de reanimación de objetos de desecho definido en el encabezado NC del NC que contiene el objeto de desecho. El usuario no puede reanimar su propio objeto. El atributo isDeleted del objeto de desecho debe establecerse en TRUE. Además, el identificador de seguridad de propietario (SID) del objeto, tal como se define en el descriptor de seguridad, debe tener un SID de uno de los dominios del bosque o de un dominio de confianza.

Si el objeto en cuestión está en los NC de configuración o de esquema, los bits FLAG_CONFIG_ALLOW_RENAME y FLAG_ CONFIG_ALLOW_MOVE deben establecerse en el atributo systemFlags del objeto de desecho. Si el objeto está en los NC de configuración o esquema y se establece el marcador FLAG_CONFIG_ALLOW_LIMITED_MOVE, el objeto sólo puede moverse a un contenedor que tiene la misma entidad primaria principal; es decir, el objeto debe retener su entidad primaria principal superior después del desplazamiento. Además, si el objeto se encuentra en un dominio NC o en una partición de aplicación, entonces los bits lFLAG_DOMAIN_DISALLOW_RENAME y FLAG_DOMAIN_DISALLOW_MOVE no deben establecerse en el atributo systemFlags del objeto de desecho.

El usuario debe disponer de los derechos, tal como se define en el descriptor de seguridad, para modificar el RDN (generalmente el CN, pero no siempre) y para agregar el objeto al contenedor primario nuevo. Asimismo, el contenedor primario nuevo debe ser un posible superior para el objectClass del objeto de desecho, tal como se define en el esquema. Aunque normalmente no se permiten los desplazamientos dentro o fuera del contenedor System (a menos que el valor del Registro del subárbol de sistema Unlock no sea un valor cero), se permite la reanimación de un objeto de desecho en el contenedor System.

La reanimación de un objeto de esquema no se permite nunca. Esto, sin embargo, no es realmente un problema ya que no se puede eliminar legítimamente un objeto desde el NC de esquema.

Si todas las comprobaciones se realizan correctamente y se cumplen los requisitos necesarios, Active Directory realiza los pasos siguientes sobre el objeto de desecho para reanimarlo:

  • El atributo isDeleted se quita.
  • Si no se recomienda lo contrario en la operación de modificación, objectCategory se establece en el objectClass más específico indicado en el objeto de desecho.
  • El RDN se cambia y el objeto se escribe en el contenedor primario nuevo.

Después de la reanimación, el objeto tiene los mismos atributos objectGUID y objectSid que tenía originalmente. Esto significa que las referencias externas al objeto, por ejemplo en las listas de control de acceso, no tienen que restablecerse como cuando se vuelve a recrear un objeto eliminado. El objeto reanimado tiene el mismo aspecto que antes de su eliminación y actúa del mismo modo. Sin embargo, hay una diferencia importante: el objeto restaurado pierde los atributos que no estaban guardados en el objeto de desecho.

Uso de LDP para reanimar objetos de desecho

Atributo systemFlags y comportamiento del objeto

El atributo systemFlags es un atributo opcional definido para la parte superior de la clase, que hace que systemFlags sea un atributo opcional para todas las clases de Active Directory. Se trata de una máscara de bits de números enteros de 32 bits que controla el comportamiento de los desplazamientos y las eliminaciones del objeto. A continuación se incluye un resumen de marcadores importantes.

FLAG_DISALLOW_DELETE (0x80000000)

Si se establece este marcador, el sistema no permitirá la eliminación del objeto ni su desplazamiento a otro dominio.

FLAG_CONFIG_ALLOW_RENAME (0x40000000)

Los NC de configuración y de esquema no pueden cambiar de nombre salvo que este marcador se establezca en el atributo systemFlags.

FLAG_CONFIG_ALLOW_MOVE (0x20000000)

Los objetos de los NC de configuración y de esquema no pueden moverse a menos que este marcador se establezca en el atributo systemFlags.

FLAG_CONFIG_ALLOW_LIMITED_MOVE (0x10000000)

Los objetos de los NC de configuración y de esquema no pueden moverse a menos que este marcador se establezca en el atributo systemFlags. Este marcador impone una limitación adicional en el contenedor de destino de la operación de desplazamiento; el contenedor de destino debe tener la misma entidad primaria principal que el contenedor actual.

FLAG_DOMAIN_DISALLOW_RENAME (0x08000000)

De forma predeterminada, los objetos en un dominio NC o aplicación NC pueden cambiar el nombre. Sin embargo, si este marcador se establece en el atributo systemFlags del objeto, el sistema no permitirá que el objeto cambie de nombre.

FLAG_DOMAIN_DISALLOW_MOVE (0x04000000)

De forma predeterminada, los objetos en un dominio NC o aplicación NC pueden moverse a otro contenedor. Sin embargo, si este marcador se establece en el atributo systemFlags del objeto, el sistema no permitirá mover el objeto.

FLAG_DISALLOW_MOVE_ON_DELETE (0x02000000)

Si se establece este marcador, el sistema no permitirá mover el objeto al contenedor CN=Deleted Objects de su contexto de nomenclatura. Simplemente se establecerá el atributo isDeleted, cambiará el nombre del objeto y se eliminarán los atributos no designados en el esquema para que se guarden. Esto significa que no todos los objetos eliminados aparecen en el CN=Deleted Objects para el contexto de nomenclatura; algunos se quedan en el contenedor principal de origen.

Ahora que hemos visto cómo todos los detalles del funcionamiento de la reanimación de objetos de desecho, me gustaría demostrar cómo se puede usar LDP para restaurar el usuario CN=John Smith que se eliminó. Primero hay que conectarse a un DC y autenticarse. A continuación, ya se podrá realizar una operación de modificación con LDP. En los parámetros de modificación, se puede quitar el atributo isDeleted y especificar un DN nuevo al mismo tiempo.

Dado que se está trabajando un objeto de desecho, se debe especificar el control LDAP Return Deleted Objects. Para establecer este control para la operación de modificación en LDP, seleccione Controls desde el menú de opciones, seleccione Return deleted objects de la lista desplegable Load Predefined, haga clic en el botón Check in y, a continuación, en OK para guardar la configuración del control.

Ahora se selecciona Modify del menú Browse para abrir el cuadro de diálogo Modify y escribir el DN del objeto de desecho que se desea restaurar. La manera más fácil de hacerlo es copiar y pegar el DN desde los resultados de la operación de búsqueda que se realizó anteriormente.

A continuación, se debe especificar una lista de las operaciones de atributos que se van a realizar. La reanimación de un objeto de desecho requiere dos operaciones de atributo: eliminar el atributo isDeleted y reemplazar el atributo distinguishedName con el DN deseado del objeto de desecho reanimado. Por lo tanto, se escribe isDeleted en el campo Attribute y se selecciona el botón de opción Delete. Al presionar el botón Intro, la operación de atributo se agrega a la lista Entry, tal como se muestra en la figura 8.

Figura 8 Especificación de las operaciones de atributo que se van a realizar

Figura 8** Especificación de las operaciones de atributo que se van a realizar **

A continuación se especifica distinguishedName en el campo Attribute, se selecciona el botón de opción Replace y se escribe el DN nuevo del objeto en el campo Values. En este caso, se usa el distuiguishedName original del usuario, CN=John Smith,CN=Users,DC=foo,DC=local. Al presionar el botón Intro, la operación de modificación se agrega a la lista Entry.

Dado que falta incluir el control LDAP Return Deleted Objects con la operación de modificación, debe usarse una modificación LDPA ampliada. Para ello, se activa la casilla Extended. Una vez que se haya establecido todo, tal como se muestra en la figura 9, se hace clic en el botón Run para realizar los cambios. LDP muestra los resultados en una ventana grande de texto.

Figura 9 Cambio de distinguishedName

Figura 9** Cambio de distinguishedName **

Al volver al complemento MMC de Usuarios y equipos de Active Directory y buscar en el contenedor CN=Users, se encontrará el objeto de usuario que se había eliminado en su lugar de origen. Sin embargo, el objeto tendrá algunas diferencias importantes con respecto a su estado original, las cuales veremos dentro de un momento.

Uso de ADRESTORE para reanimar objetos de desecho

Una vez que se ha resuelto cómo usar LDP, la reanimación de un objeto de desecho no es una acción muy difícil. No obstante, tampoco es muy cómoda. Afortunadamente, el equipo de Sysinternals (compañía que ahora forma parte de Microsoft) desarrolló una herramienta en la línea de comandos que permite simplificar el proceso de reanimación. Esta herramienta, llamada ADRESTORE, está disponible desde el sitio web de Microsoft en la dirección microsoft.com/technet/ sysinternals/utilities/AdRestore.mspx. La instalación es sencilla. Simplemente copie los archivos ejecutables en un directorio adecuado del equipo, por ejemplo, el directorio C:\WINDOWS\SYSTEM32.

ADRESTORE se ejecuta de dos modos. Si se ejecuta sin parámetros, incluirá una lista con todos los objetos de desecho en el contenedor CN=Deleted Objects del dominio predeterminado. Puede agregar una cadena de búsqueda a la línea de comandos para seleccionar los objetos que desee mostrar, por ejemplo:

C:\> adrestore John

Esto mostrará todos los objetos de desecho en el contenedor CN=Deleted Objects que contienen la cadena "John" en su CN o atributo OU: usa los filtros de búsqueda LDAP cn=*John* y ou=*John*. Ésta no es exactamente la manera más flexible de buscar objetos de desecho, pero es muy adecuado para la mayoría de las situaciones. La figura 10 muestra el resultado de la búsqueda que devuelve ADRESTORE.

Figura 10 Atributos guardados en un objeto de desecho

Figura 10** Atributos guardados en un objeto de desecho **(Hacer clic en la imagen para ampliarla)

Si desea reanimar un objeto de desecho y no sólo buscarlo, entonces deberá especificar el modificador de comandos –r junto con una cadena opcional, tal como se muestra a continuación:

C:\> adrestore –r John

Este comando solicitará la reanimación de todos los objetos que coincidan con el objeto de desecho. ADRESTORE siempre reanima el objeto en el contenedor indicado por el atributo lastKnownParent del objeto de desecho. No hay ninguna manera de especificar un contenedor diferente.

ADRESTORE proporciona una interfaz de línea de comandos para usar la funcionalidad de reanimación de Active Directory. Aunque no es muy flexible, es algo más fácil de usar que LDP. Aún así, ADRESTORE no evita dos problemas importantes que se dan en la reanimación de objetos de desecho: recuperar los atributos quitados del objeto cuando se eliminó por primera vez y recuperar los objetos eliminados del NC de configuración.

Recuperación de atributos de objeto

Desde el punto de vista de la recuperación de datos, la reanimación de objetos de desecho presenta más ventajas que realizar una restauración autoritativa: La reanimación de objetos de desecho no requiere la interrupción de la conexión del DC. Además, es mucho mejor que simplemente volver a crear una versión nueva de un objeto eliminado. Al volver a crear un objeto, se obtiene siempre sendos atributos objectGUID y objectSid nuevos (si se trata de una entidad principal de seguridad como, por ejemplo, un usuario). Como resultado, deberán actualizarse las referencias externas al objeto, por ejemplo las ACL, para reflejar la nueva identidad del objeto. Esto puede ser un auténtico dolor de cabeza.

Algunos atributos se quitan al eliminarse un objeto y no se recuperan con la reanimación de los objetos de desecho. Pero Active Directory guarda algunos atributos clave en el objeto de desecho, el más importante de los cuales son atributos relacionados con la identidad, como por ejemplo, objectGUID y objectSid. También guarda muchos otros atributos de forma predeterminada (consulte la figura 1). La mayoría de los atributos que se codifican para guardarse no es muy importante, especialmente en un análisis acerca de la recuperación de objetos de usuario eliminados. Pero se pueden especificar atributos adicionales para que se guarden en el objeto de desecho si se configura el bit 3 (0x00000008) del atributo searchFlags del objeto attributeSchema correspondiente en el esquema de Active Directory. Algunos atributos ya tienen este bit establecido en el esquema en Windows Server 2003 R2 (estos se muestran también en la figura 1).

La instalación de ciertas aplicaciones puede cambiar el bit 3 de searchFlags de los atributos existentes o incluso agregar atributos nuevos que tiene el bit 3 establecido. Exchange Server, por ejemplo, configura varios atributos adicionales que se van a guardar en el objeto de desecho.

Active Directory no guardará los atributos de vínculos hacia adelante o vínculos hacia atrás en el objeto de desecho, incluso si se especifica que se haga así en el atributo searchFlags del objeto del esquema. Concretamente, Active Directory no guarda elementos tal como el atributo de miembro de un grupo o el atributo memberOf de un usuario. De esta manera, la reanimación de objetos de desecho no ofrece una solución a la hora de recuperar las pertenencias a grupos en Active Directory. Para ello, consulte el artículo "Recuperación de desastres: Usuarios y grupos de Active Directory" en technetmagazine.com/issues/2007/04/ADRecovery. Por lo tanto, aún será necesario proporcionar un mecanismo alternativo para recuperar esta información al reanimar objetos de desecho.

Si desea usar la reanimación de objetos de desecho como parte de la estrategia de recuperación de datos, deberá asegurarse de que los atributos importantes se guarden en el objeto de desecho o bien deberá proporcionar otra manera de guardar y recuperar atributos importantes, tal como el uso LDIFDE u otro esquema de copia de seguridad y restauración. Otras opciones incluyen productos de recuperación de datos de Active Directory de terceros que ofrecen un mecanismo automatizado para realizar copias de seguridad y restaurar los atributos que no se guardar en objetos de desecho ni se recuperan de éstos.

Reanimación de objetos desde el contexto de nomenclatura de configuración

Otra limitación substancial de la reanimación de objetos de desecho es que, en términos generales, no se pueden reanimar objetos eliminados desde el NC de configuración. Estos objetos están sujetos a reglas especiales relacionadas con los desplazamientos y los cambios de nombre, tal como se define mediante el atributo systemFlags del objeto. Salvo que se especifique lo contrario mediante el atributo systemFlags, los objetos en el NC de configuración no pueden desplazarse ni cambiar de nombre, lo que significa que sus objetos de desecho no se pueden reanimar. Active Directory aplica algunos valores para el atributo systemFlags al crear objetos de clases específicas, tal como se define en la figura 11. Observe que Active Directory aplica la operación OR lógica bit a bit a estos valores en combinación con cualquier valor de systemFlags especificado en la operación de adición. De este modo, incluso si la aplicación especifica un valor diferente para el atributo systemFlags, los bits necesarios se establecerán correctamente.

Figure 11 Configuración predeterminada de systemFlags

Clase Configuración predeterminada
server FLAG_DISALLOW_MOVE_ON_DELETE FLAG_CONFIG_ALLOW_RENAME FLAG_CONFIG_ALLOW_LIMITED_MOVE
site FLAG_DISALLOW_MOVE_ON_DELETE
serversContainer FLAG_DISALLOW_MOVE_ON_DELETE
nTDSDSA FLAG_DISALLOW_MOVE_ON_DELETE
siteLink FLAG_CONFIG_ALLOW_RENAME
siteLinkBridge FLAG_CONFIG_ALLOW_RENAME
nTDSConnection FLAG_CONFIG_ALLOW_RENAME

Los únicos objetos de NC de configuración que se pueden reanimar en circunstancias normales son objetos de servidor. Curiosamente, cuando Active Directory elimina un objeto de servidor, el objeto de desecho no se mueve al contenedor CN=Deleted Objects para el NC de configuración, ya que se queda simplemente donde está el objeto. Esto permite que el comprobador de coherencia de la información (KCC), que es el proceso responsable de calcular la topología de replicación de Active Directory, para recuperar algunos escenarios automáticamente en los que los objetos de servidor eliminados podrían inhibir una replicación necesaria. Por lo tanto, si se encuentra intentando reanimar un objeto de servidor, recuerde que no lo encontrará en el contenedor CN=Deleted Objects.

Reanimación dentro del plan de recuperación

La reanimación de objetos de desecho debe ser una parte clave del kit de herramientas de la recuperación de datos. Este mecanismo es la única manera de recuperar objetos eliminados sin tener que interrumpir la conexión del DC e, igualmente importante, es la única manera de recuperar información de identidad de un objeto eliminado. Resuelve ordenadamente el problema de volver a crear un usuario o grupo de usuarios eliminados y de tener que corregir todas las referencias anteriores de las listas de control de acceso (ACL).

Sin embargo, la reanimación de objetos de desecho es una solución incompleta. Deberá proporcionar su propio mecanismo de recuperación de los atributos que Active Directory no retiene en los objetos de desecho, y su capacidad para recuperar objetos eliminados a partir del NC de configuración es limitada. Recuerde que si decide reanimar un usuario o un grupo eliminado, aún deberá recuperar las pertenencias a grupos y cualquier otro atributo vinculado que se pudiese necesitar.

Gil Kirkpatrick es Director general de tecnología de NetPro y desarrolla software para Active Directory desde 1996. Junto con Guido Grillenmeier de HP, imparte los conocidos talleres de recuperación de desastres de Active Directory. También es el fundador de la Conferencia de expertos en directorios (www.dec2007.com).

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.