Los Servicios de dominio de Active Directory (AD DS) se han convertido en un componente central de la infraestructura de TI de su empresa maravillosamente fiable, altamente escalable y tolerante a fallos. Generalmente funciona bastante bien sin requerir mucha atención. Pero el administrador de AD DS debe realizar un trabajo extra para llevar el servicio de un nivel de "buen funcionamiento en el día a día" a un nivel de "fiabilidad a prueba de balas cuando surge algún tipo de situación inusual". Cuando esta situación inusual ocurre (y fíjate que he dicho "cuando", no "si"), hay una serie de malas configuraciones y malas prácticas que pondrán tu dominio o bosque AD DS en riesgo de pérdida de datos, fallo del controlador de dominio (DC), o incluso fallo del dominio o bosque. Algunos de estos puntos pueden parecer elementales, pero te sorprendería saber lo comunes que son en realidad.
Lecturas relacionadas
Todavía tienes DCs de Windows Server 2003. Windows Server 2003 fue un sistema operativo excelente en su día... pero su día ya ha pasado. Y lo que es más importante, es un sistema operativo vulnerable y sin parches. ¿Por qué arriesgar su empresa? Siga adelante.
Todos tus DC y copias de seguridad están en una única ubicación física. Muchas cosas malas pueden suceder en una sola ubicación. Es bueno que tengas más de un DC, pero si todos están en el mismo centro de datos, tu bosque sigue siendo vulnerable a cualquier cosa que pueda acabar con ese centro de datos. Y eso obviamente también se aplica a las copias de seguridad de tu bosque. No hay excusa para no estar preparado ante una catástrofe natural de evolución lenta como el huracán Sandy en la costa este de Estados Unidos. Pero también he sabido de incendios externos de rápida propagación que han causado daños significativos a un centro de datos y, como mínimo, lo han dejado indisponible si no muy dañado. Moraleja: busque todos los puntos vulnerables en su entorno AD DS.
La papelera de reciclaje no está habilitada. Todos los administradores respiramos aliviados cuando la Papelera de reciclaje de Active Directory estuvo disponible por primera vez en Windows Server 2008 R2. Sin embargo, pasó un tiempo antes de que esta utilidad de restauración de objetos tan necesaria se utilizara ampliamente, ya que requiere un nivel funcional de bosque mínimo de Windows Server 2008 R2. Y para conseguirlo es necesario actualizar todos los DC del bosque desde versiones anteriores, especialmente Windows Server 2003. Debido a que un número vergonzosamente grande de organizaciones acaban de poner sus DC de Windows Server 2003 en un merecido descanso, muchas de estas empresas tampoco han habilitado la Papelera de reciclaje. Ya sabes quién eres; ¡ponte a ello!
No está siguiendo las mejores prácticas de virtualización. Si tiene DC anteriores a Windows Server 2012, no comprenden los entornos virtualizados. En concreto, se recuperan mal de las restauraciones basadas en imágenes en las que la base de datos de AD se ha restaurado a un momento anterior sin activador. Asegúrese de que usted (y especialmente sus administradores de virtualización) sigue las mejores prácticas de Microsoft para virtualizar AD DS.
No se monitoriza la salud del DC / DNS de forma regular. Una de las formas más comunes de que Active Directory tenga problemas es porque nadie le presta atención. Si usted es una organización pequeña, entiendo que puede que no tenga los fondos para una solución de monitorización extensa (aunque hay excelentes soluciones gratuitas para pequeñas y medianas empresas como SpiceWorks). Todo lo que se necesita para realizar una monitorización básica es un script programado que ejecute DCDIAG /s: /E y lo escriba en un archivo. Revíselo cada mañana. Si encuentras errores de replicación, por ejemplo, tienes a tu disposición la herramienta gratuita ADREPLSTATUS.
Está ejecutando múltiples roles en un DC. Ejecutar múltiples roles en un DC compromete tanto la seguridad como la recuperabilidad. En la era de las máquinas virtuales fáciles de crear, no hay razón para no tener servidores dedicados a esta tarea.
Nunca se cambian las contraseñas de las cuentas de servicio. Este es un pequeño y sucio secreto que la mayoría de los departamentos de TI no quieren admitir: las cuentas de servicio de muchos de sus principales servicios de infraestructura no se han actualizado en años. Antes de Windows Server 2008 R2, cambiar la contraseña de una cuenta de servicio significaba incurrir en tiempo de inactividad en el servicio (por ejemplo, una base de datos SQL Server en una aplicación de línea de negocio de varios niveles). Por lo tanto, nunca se cambiaba. En una gran organización que conocí, la contraseña de la cuenta de servicio SMS era conocida por al menos tres generaciones de administradores de sistemas. Esta vulnerabilidad se ha rectificado, primero con las cuentas de servicio administradas (MSA) en Windows Server 2008 R2 y luego con las MSA de grupo en Windows Server 2012. ¿Has hecho algo al respecto?
Demasiados administradores. Esto debería quitarte el sueño. Muchas, muchas organizaciones tienen demasiadas cuentas administrativas porque quien construyó su AD DS nunca se tomó el tiempo extra de crear un modelo de administración delegada. Como resultado, conceder amplios derechos es la forma más rápida de cerrar un ticket de servicio. Esta es la forma más rápida que conozco de conseguir que tu empresa aparezca en los titulares de las noticias de seguridad de SC Magazine o algo peor.
No se engañe. Si tiene alguna de estas condiciones en su entorno AD DS, es su responsabilidad mostrar a la dirección por qué corregirlas debe ser una prioridad para la seguridad de su empresa.
