Limpiando roña del Directorio Activo

  • Article

Hola

Como cualquier almacén de datos, el Directorio Activo puede convertirse en un lugar poco recomendable donde acumular toda clase de roña, sobre todo si las operaciones que se llevan a cabo sobre el mismo se descuidan.

Agregar objetos es particularmente sencillo, y esto es precisamente la base de su diseño y su funcionalidad para hacer posible que muchos productos se apoyen en su capacidad de servir todo tipo de información. Sin embargo la eliminación de lo que ya no nos sirve es algo que en ocasiones se deja para luego o se hace de aquella manera. A mayor complejidad de la arquitectura del AD en lo tocante a numero de Dominios, Sites y controladores de dominio, más pueden acentuarse este tipo de problemas y mayor será la necesidad de definir y respetar una buena guía de operaciones para el Directorio Activo.

Lo complicado en este punto es definir que es lo que entendemos por roña. En este post nos vamos a centrar en tres tipos:

  • Usuarios/equipos que estuvieron y ya no están, pero cuyas cuentas siguen repartidas por nuestra estructura de Unidades Organizativas, o lo que es peor, no sabemos si deben seguir ahí o si las podemos borrar tranquilamente.
  • Controladores de Dominio, o incluso dominios enteros, que desaparecieron sin más. En ocasiones los equipos se apagan para siempre cuando ya no se necesitan más y por unas razones u otras no recordamos que en el caso de los DCs es muy conveniente hacer un DCPROMO que elimine la información correctamente de la estructura de AD, y que traspase los roles de manera amable y ordenada a otro DC de la red.
  • Objetos que han sido borrados del directorio activo, pero cuya desaparición ha pasado desapercibida para un DC que ha estado mucho tiempo sin replicar con los demás o desconectado de la red.

1.- Identificar cuentas de usuario y equipos en desuso

Las cuentas de usuario/servicios deberían borrarse en el momento de que el usuario o aplicación que las ha estado utilizando no la necesiten más. Igualmente la cuentas de las máquinas debería hacerse desaparecer sacando al equipo del dominio antes de proceder a reconfigurarlo/reinstalarlo/eliminarlo. Sin embargo las prisas hacen que esto se deje demasiado a menudo para luego, y que llegue el momento de preocuparse cuantos de mis miles de objetos de usuario/equipo solo están ocupando espacio y haciendo al AD más gordito y pesadote.

Salvo que a alguien se le ocurra algo mejor, lo que se suele utilizar para detectar estos objetos olvidados es buscar un atributo que sepamos que haya cambiado seguro la última vez que el usuario/equipo las utilizaron y que no cambie salvo que sea vuelto a utilizar. Esto sucede cada vez que un alguien (usuario o equipo) inicia sesión. En ese momento el controlador de dominio encargado de llevar a cabo la operación de autenticación actualiza un par de atributos de la cuenta en particular con la fecha y la hora en la que se ha iniciado sesión. Si lo que queremos es hacer una operación de borrado masiva de este tipo de roña, deberemos establecer una fecha límite a partir de la cual, todo objeto que no haya iniciado sesión será considerado en desuso. El último inicio de sesión se almacena en dos atributos presentes tanto en la cuentas de usuarios como de los equipos: LastLogonTimeStamp y LastLogon.

  • LastLogonTimeStamp solo está presente en el Directorio Activo si su nivel funcional es 2003 Nativo o posterior. Este atributo se replica al resto de DCs, por lo que si nuestra replicación está funcionando como debe, cuando un DC actualiza el atributo se actualiza en los demás, manteniéndose el valor consistente a lo largo de todo el dominio
  • LastLogon está presente en todas los niveles funcionalidades de AD, en particular en 2000 y 2003 Mixto, pero tiene el inconveniente de que no se replica entre los diferentes DCs del dominio, sino que solo permanece en el DC que realizó la autenticación. Si usamos este valor como base, deberemos comprobar el valor de este atributo en todos los DCs del dominio

El valor de estos atributos almacena los tiempos en un tipo de dato especial llamado Integer8, que almacena el número de intervalos de 100 nanosegundos desde el 1 de enero de 1601. Para realizar la conversión de una fecha/hora a este formato es conveniente tener a mano herramientas como esta. El paso contrario es sencillo, pues basta con usar w32time /ntte.

Veamos como podemos sacar fácilmente esta información:

  • Con la herramienta DSQUERY, que hace amablemente por nosotros queries LDAP al AD sin que tengamos que ser un mago del *. Esta herramienta usa LastLogonTimeStamp, lo que significa que solo podremos usarlas contra directorios en niveles funcionales 2003 o superior. Simplemente deberemos definir el número de semanas que utilizaremos como criterio para detectar usuarios o equipos inactivos
    • DSQUERY user –inactive <nº de semanas>
    • DSQUERY computer –inactive <nº de semanas>
  • Para administradores frikis, podemos lanzar las siguientes queries LDAP (el valor corresponde al 1 de Agosto de 2008). Esto queda muy bonito en el apartado “Saved Queries” de la MMC de Usuarios y Equipos del Directorio Activo:
    • Equipos: (objectCategory=computer)(|(lastLogonTimestamp<=128442204000000000)(!(lastLogonTimestamp=*))
    • Usuarios: : (objectCategory=user)(|(lastLogonTimestamp<=128442204000000000)(!(lastLogonTimestamp=*))
    • Usuarios y equipos a la vez: (|(objectCategory=user)(objectCategory=computer))(|(lastLogonTimestamp<=128442204000000000)(!(lastLogonTimestamp=*)))
  • Para organizaciones basadas en Directorios Activos del pasado (perdón), deberemos usar las queries anteriores, pero usando el atributo LasLogon en lugar de LastLogonTimeStamp, y deberemos hacerlo contra todos los DCs del dominio para posteriromente sacar una especie de factor común y saber que se puede borrar y qué no.

Si buscáis por Internet sobre estos atributos, obtendreis un montón de referencias a scripts basados en VBS, powershell, etc que hacen esto mismo

2.- Dominios / Controladores de Dominio perdidos en combate

Esto sucede cuando no se ha utilizado DCPROMO para eliminar los DCs de un dominio, y en el caso de los dominios cuando hemos olvidado la graciosa casilla “este es el ultimo DC del dominio”. Es decir, apagar DCs y borrar ramas del DNS no es ni mucho menos equivalente a eliminar dominios del AD:

El proceso de eliminar del AD este tipo de objetos huérfanos se llama Metadata Cleanup, y suele incluir también un proceso de “seize” de los roles que tuvieran los DCs perdidos y que no han sido reasignados. Los paso a seguir están bien documentados en estos dos artículos de la Knowledge Base:

  • KB216498: How to remove data in Active Directory after an unsuccessful domain controller demotion
  • KB230306: How to remove orphaned domains from Active Directory

3.- Lingering Objects

Lo cierto es que a mi este nombre siempre me ha hecho gracia, ya que dando una enorme patada al diccionario de la lengua de Shakespeare, lo de los “objetos en paños menores” representa bien lo que son. Cuando borramos un objeto, por ejemplo como hemos hecho en el primer punto, no desaparece realmente de la base de datos sino que se le pone a TRUE el valor de su atributo IsDeteled, lo que se conoce como ponerle un tombstone. Los objetos así marcados serán borrados cada cierto tiempo (60 días en 2000 y 2003, o 180 días en 2003 SP1) mediante un proceso que hace las veces de camión de la basura (“garbage collection"). Pues bien, supongamos que hemos tenido un controlador de dominio parado o sin replicar por algún tipo de problema durante más tiempo que lo definido en el “Tombstone Lifetime”. Pues bien, en ese DC, los objetos borrados y eliminados están más frescos que una rosa, y se quedan en ahí, en paños menores, ya que el resto de DCs no quieren saber nada de ellos. dado que el camión de la basura ya pasó, no queda más remedio que llevarlos personalmente al vertedero:

Todo esto así contado parece fácil de entender, pero en el fondo no lo es tanto ya que la forma en la que replica el Directorio Activo tiene su aquel. Así es que nunca está de más tener a mano la información de How the Active Directory Replication Model Works.

Agradecimientos especiales a mis compañeros del grupo de soporte de Directorio Activo, quienes estarán encantados de responder a todas vuestras preguntas a través de su blog, que me ayudaron a acotar lo que podía caer bajo la categoría de “roña” en AD, y en especial a Javier Rama que encima tuvo la paciencia de ponerlo por escrito. En su correo me decía que tenía la sensación de que se nos olvidaba algo, y yo de hecho estoy seguro de que si (de hecho, no hemos hablado nada de NTFRS ni de sus colisiones, grupos vacíos, objetos de políticas de grupo…).

¿Que más roña te has encontrado tu en un AD?

Saludos

David Cervigón