Guido Grillenmeier

[Actualizado el 14 de febrero de 2024; publicado originalmente el 29 de noviembre de 2021]. El número y el alcance de las confusas y arriesgadas configuraciones de seguridad en Active Directory son cada vez más conocidos con cada nuevo ciberataque. Muchas de estas vulnerabilidades pueden atribuirse a configuraciones arriesgadas que se han acumulado en entornos heredados a lo largo del tiempo. Pero los equipos de TI todavía tienen que vigilar las configuraciones problemáticas que vienen de fábrica en Windows Server 2022. Por desgracia, lo mismo ocurre con el próximo Windows Server 2025. Una configuración de Active Directory que todos los equipos de TI deben abordar de inmediato es el grupo de Acceso compatible con Windows 2000 prepoblado con el principio de seguridad Usuarios autenticados. Esta configuración puede dejar una puerta abierta a los intrusos, como voy a demostrar.

Para entender por qué la configuración de Acceso compatible anterior a Windows 2000 es tan problemática, echemos un vistazo a la historia de la delegación de permisos y la asignación de directivas en Active Directory. De este modo, podrá tomar una decisión informada sobre cómo manejar esta configuración en su organización.

Lectura relacionada: ¿Qué es la seguridad de Active Directory?

Ser o no ser... ¿compatible con Windows NT?

Hay una buena razón por la que últimamente no se habla mucho de Windows NT. Es historia. Es tecnología del siglo pasado.

Windows NT fue un gran paso adelante para Microsoft y supuso la entrada de la empresa en el mercado empresarial en 1993. Pero el sistema operativo ha sido sustituido por versiones más nuevas y seguras desde el lanzamiento de Windows 2000 a principios de este siglo. En cuanto a los servidores, Microsoft ha mantenido la norma de denominación de añadir el año más próximo a la fecha de lanzamiento.

Mientras escribo esta actualización, Windows Server 2022 es el último sistema operativo de Microsoft. Pero en enero de 2024, el nombre de la próxima versión "vNext" se confirmó (como era de esperar) como Windows Server 2025. Esperamos que la nueva versión del sistema operativo se publique antes de finales de 2024.

¿Qué ha cambiado en Windows 2000?

Un cambio clave en Windows 2000 fue la sustitución del concepto de dominio de Windows NT -que era un directorio plano para autenticar usuarios y máquinas en la red de una empresa- por el de Active Directory, mucho más escalable y seguro. Junto al concepto de dominios, Active Directory introdujo árboles y bosques de dominios. También permitió crear una estructura jerárquica de unidades organizativas (OU) para los objetos de un dominio. Esta estructura resultaba útil para delegar permisos y asignar políticas específicas.

Otra diferencia clave era igual de importante. Active Directory introdujo la capacidad de establecer permisos no sólo a nivel de objeto (por ejemplo, usuarios, grupos, ordenadores), sino también a nivel de atributo (por ejemplo, departamento, número de teléfono, pertenencia a grupos) de cada objeto. Ahora, los administradores pueden diferenciar entre "leer" o "escribir" todos los atributos de un determinado objeto de Active Directory o sólo los atributos relevantes para una tarea determinada.

La clave del principio del menor privilegio

Esta capacidad fue clave para permitir a las empresas seguir el mantra del mínimo privilegio de cualquier buen plan de seguridad: Conceda a sus usuarios sólo los permisos que necesiten para hacer su trabajo. No concedas a los usuarios más permisos para acceder a datos que no necesitan. De lo contrario, un usuario -especialmente uno comprometido- podría hacer un mal uso de esos permisos y perjudicar a la empresa.

En cualquier servidor de archivos o estructura SharePoint que comparta documentos para usuarios de toda la empresa, el enfoque más natural sería seguir esa regla del menor privilegio. Por ejemplo, los usuarios deben ser miembros de un grupo de seguridad adecuado para poder ver documentos que contengan datos financieros o confidenciales de la empresa, o incluso para saber de la existencia del archivo.

También puede optar por poner a disposición de todos los usuarios datos específicos y no confidenciales a través de algún recurso compartido de documentos público al que todos los usuarios tengan acceso, sin necesidad de añadirlos a un grupo especial. Ese acceso se otorgaría normalmente a tu grupo de Usuarios de Dominio o incluso a los usuarios autenticados o a todos los principales de seguridad.

Por desgracia, la mayoría de las empresas no tratan Active Directory de esta manera. Parte de la razón se debe a los permisos por defecto con los que Microsoft ha desplegado -y sigue desplegando- nuevos dominios de Active Directory.

¿Qué es el grupo de Acceso Compatible Pre-Windows 2000?

Por ejemplo, el grupo de acceso compatible anterior a Windows 2000. Microsoft decidió introducir este grupo (que sería más apropiado denominar grupo de permisos menos seguros de Windows NT) cuando lanzó Windows 2000. El problema: incluso en un nuevo despliegue de un nuevo bosque de Active Directory en servidores Windows Server 2022 -y sí, servidores Windows Server 2025- Microsoft rellena previamente el grupo Acceso compatible pre-Windows 2000 con la entidad de seguridad Usuarios autenticados.

Pertenencia por defecto al grupo de Acceso Compatible Pre-Windows 2000 en un dominio de Directorio Activo recién desplegado en Windows 2025 Server
Pertenencia por defecto al grupo de Acceso Compatible Pre-Windows 2000 en un dominio de Directorio Activo recién desplegado en Windows 2025 Server

¿Por qué es importante y por qué debería importarle?

Como su nombre indica, el grupo Acceso compatible pre-Windows 2000 se creó para ser compatible con Windows NT. En otras palabras, el grupo permite conceder permisos a nivel de objeto sobre objetos de Active Directory que son compatibles con el menos seguro Windows NT, en lugar de utilizar permisos más granulares a nivel de atributo. Microsoft no oculta las implicaciones potencialmente arriesgadas en la descripción del grupo: "Un grupo de compatibilidad con versiones anteriores que permite el acceso de lectura en todos los usuarios y gruposdel dominio".

La descripción del grupo de acceso compatible con Windows 2000 no oculta su finalidad
La descripción del grupo de acceso compatible con Windows 2000 no oculta su finalidad

Y como Microsoft quiere "ayudarte" con esa compatibilidad con versiones anteriores en la medida de lo posible, concede permisos de LECTURA completos para los objetos respectivos (usuarios y grupos) justo en la parte superior de cada dominio de tu bosque, lo que le permite heredar hacia abajo toda la jerarquía de OU.

Permisos en la raíz de cada dominio
Permisos en la raíz de cada dominio

Estos permisos predeterminados están establecidos, aunque Microsoft ya no le pregunta si desea desplegar su nuevo bosque AD de forma compatible con las versiones de Windows anteriores a Windows 2000 (es decir, Windows NT). Esta opción estaba disponible en los sistemas operativos anteriores cuando se promocionaba un nuevo bosque AD. Si hubiera elegido esta opción hace unos años, incluso habría añadido Usuarios anónimos y Todo el mundo al grupo Acceso compatible con versiones anteriores a Windows 2000, concediendo así a esos principales de seguridad un potente acceso de lectura a su Directorio Activo. ¡Los usuarios ni siquiera necesitarían autenticarse para leer su AD! Ciertamente espero que ya hayas limpiado esos permisos heredados, sobre los que cualquier comprobación de seguridad te habría advertido a estas alturas.

¿Puede dejar Usuarios Autenticados en el grupo Acceso Compatible Pre-Windows 2000?

Sí, debe eliminar Usuarios autenticados de los grupos de Acceso compatible con versiones anteriores a Windows 2000 en todos los dominios de su bosque de AD, aunque Microsoft siga añadiéndolo como valor predeterminado para las nuevas implementaciones de AD. Dejar Usuarios Autenticados en el grupo otorga permisos de LECTURA completos, permitiendo a cualquier usuario y equipo unido al dominio leer los datos respectivos en cualquier objeto de este tipo.

Tenga en cuenta que cada equipo unido a un dominio es también un usuario autenticado en su bosque de Active Directory. Incluso si ningún usuario ha iniciado sesión en esos equipos, un proceso -posiblemente un troyano- que se ejecuta en el contexto del sistema de un equipo unido a un dominio tiene el mismo acceso a Active Directory que sus usuarios.

Para comprender mejor el impacto, debemos profundizar un poco más y comprobar qué permisos se conceden por defecto a los Usuarios Autenticados en todos los objetos de usuario y grupo de su dominio. Después de todo, cada vez que se crea un objeto, Active Directory añade al nuevo objeto el descriptor de seguridad predeterminado para el objeto en cuestión. Estos permisos se conceden explícitamente al objeto (es decir, no se heredan). Como tales, tienen la máxima prioridad cuando se determinan los permisos generales del objeto. Tenga en cuenta que esta configuración también otorga a esos permisos predeterminados una prioridad más alta que un permiso de denegación heredado, lo que a menudo confunde a los administradores.

Permisos sobre objetos de grupo

Para los objetos de grupo, los permisos de Acceso Compatible Pre-Windows 2000 no suponen ninguna diferencia. A los usuarios autenticados se les concede LECTURA completa en todos los objetos de grupo.

Permisos por defecto para los objetos GROUP
Permisos por defecto para objetos de grupo

Aunque elimine Usuarios autenticados del grupo Acceso compatible con versiones anteriores a Windows 2000, todos los usuarios podrán leer los miembros de todos los grupos del bosque de Active Directory. A menos que elimine ese permiso de los grupos seleccionados, cualquier usuario del bosque, incluido un intruso potencial, puede determinar fácilmente quién es miembro de cualquier grupo del dominio. Para los grupos más sensibles de AD, como los administradores de dominio o los administradores de empresa, necesitará algunos pasos adicionales para eliminar este permiso READ. (Estos grupos se controlan mediante permisos en un objeto especial denominado AdminSDholder. Puede obtener más información sobre AdminSDholder y la seguridad de Active Directory en este libro blanco).

Permisos sobre objetos de usuario

Sin embargo, la situación es bastante diferente para los objetos de usuario. Los permisos por defecto concedidos a los usuarios autenticados sobre los objetos de usuario también son bastante amplios, incluyendo la lectura de todos los atributos de información general y personal. Sin embargo, los permisos son menos generalizados que permitir la lectura de todos los atributos de los usuarios.

Permisos por defecto en objetos USER
Permisos por defecto en objetos de usuario

Esto significa que los usuarios autenticados NO pueden acceder a varios atributos de usuario sensibles a través de esos permisos de objeto predeterminados. Estos incluyen userAccountControl, memberOf y todos los atributos relacionados con el inicio de sesión, como el último inicio de sesión o cuándo se cambió la contraseña por última vez. Tenga en cuenta que cuando se le concede acceso de lectura al atributo userAccountControl , se le permite averiguar qué usuarios tienen configurado el indicador PasswordNotRequired y otra información que podría permitir el descubrimiento de objetos no seguros en su bosque de AD. Los usuarios configurados con el indicador PasswordNotRequired pueden haber sido creados hace mucho tiempo para alguna aplicación y pueden no tener contraseña si el administrador de Active Directory decidió configurarlo de esta forma. Como tal, son un cebo fácil para un intruso.

Por lo tanto, si elige mantener Usuarios autenticados en su grupo de Acceso compatible anterior a Windows 2000, a cada usuario y equipo del dominio se le asignan automáticamente los permisos de ese grupo al iniciar sesión. Y con esta asignación, cualquier proceso -incluyendo código malicioso que un intruso pudiera ejecutar en un cliente unido al dominio sin ningún usuario conectado- puede enumerar cualquier atributo de usuario en su dominio.

Aunque los intrusos suelen utilizar herramientas y scripts específicos para explorar Active Directory y encontrar vulnerabilidades, no piense que a sus usuarios normales les resultaría difícil hacer lo mismo. Incluso sin derechos de administrador en su cliente, pueden descargar la última versión de Sysinternals AD explorer de Microsoft(https://docs.microsoft.com/en-us/sysinternals/downloads/adexplorer) y husmear alegremente en su bosque de Active Directory. Las siguientes imágenes muestran lo fácil que es.

Inicio de sesión en Sysinternals AD Explorer con una cuenta de dominio simple
Inicio de sesión en Sysinternals AD Explorer con una cuenta de dominio simple
Visor de objetos y atributos de Sysinternals AD Explorer con Auth Users todavía en Pre-Win2Kgroup
Visor de objetos y atributos de Sysinternals AD Explorer con Usuarios Autenticados todavía en el grupo de Acceso Compatible Pre-Windows 2000
Visor de objetos y atributos de Sysinternals AD Explorer con Auth Users eliminados de pre-Win2Kgroup
Visor de objetos y atributos de Sysinternals AD Explorer con Usuarios Autenticados eliminados del Acceso Compatible Pre-Windows 2000 grupo

Eliminación de usuarios autenticados del grupo Acceso compatible pre-Windows 2000 grupo

Este paso es sólo uno de los muchos que hay que dar para aumentar la seguridad de Active Directory. Hoy en día no es necesario mantener la compatibilidad con el modelo de seguridad de Windows NT.

Tus usuarios no necesitan los permisos concedidos por el grupo de Acceso Compatible Pre-Windows 2000. Podrán seguir conectándose. Los equipos y servidores unidos a un dominio tampoco necesitan los permisos; seguirán funcionando en su dominio sin problemas. Este cambio tampoco afecta al procesamiento de directivas de grupo. Los administradores de Active Directory tampoco necesitan estos permisos, ya que por lo demás se les conceden los mismos y más permisos.

No obstante, la eliminación de los usuarios autenticados del grupo de acceso compatible anterior a Windows 2000 no es un cambio que se pueda realizar rápidamente en Active Directory un lunes por la mañana. En primer lugar, compruebe el impacto potencial del cambio en su propio entorno. Es posible que esté utilizando herramientas o soluciones que esperen que esos permisos anteriores a Windows 2000 estén configurados en su AD y que los esté utilizando por razones legítimas.

Ejemplos de soluciones o tareas que utilizan por defecto los permisos concedidos a través de Usuarios Autenticados en el grupo Acceso Compatible Pre-Windows 2000:

  • Algunas herramientas de escaneo de seguridad que no se ejecutan con una cuenta privilegiada o que se ejecutan en el contexto de seguridad de una máquina pueden tener dificultades para leer los atributos de usuario sensibles a la seguridad discutidos en este artículo. Como resultado, esas herramientas podrían no advertirle si un usuario está configurado con el indicador PasswordNotRequired . Puede elegir agregar la cuenta de servicio respectiva utilizada por la herramienta o su cuenta de equipo al grupo de Acceso Compatible Pre-Windows 2000, o puede otorgar los permisos requeridos por separado.
  • Tenga cuidado con las aplicaciones que se vinculan a Active Directory a través de LDAP para enumerar los miembros del grupo para la seguridad dentro de la aplicación.
  • Si utiliza los Servicios de Federación de AD (ADFS), dependiendo de su configuración podría afectar a la Autenticación de WebForms, lo que podría tener que abordarse con permisos de lectura dedicados para sus servidores ADFS o utilizando el Grupo de Acceso de Autorización de Windows (WAAG).
  • Cuando se utiliza la pestaña Acceso efectivo en la configuración de seguridad avanzada de los servidores de archivos para comprobar qué permiso puede tener un usuario determinado en una carpeta, el servidor utiliza su cuenta de equipo para leer la pertenencia a grupos del usuario. Este proceso fallará después de eliminar Usuarios Autenticados del grupo Acceso Compatible Pre-Windows 2000. El valor real de la pestaña Acceso efectivo es generalmente cuestionable, ya que no considera adecuadamente los grupos anidados. Sin embargo, si aún desea utilizarla, puede volver a agregar las cuentas de equipo del servidor de archivos al grupo Acceso compatible pre-Windows 2000 o conceder de otro modo los permisos de lectura respectivos en los objetos de usuario.
  • El cliente Ivanti File Director tiene problemas para leer los atributos homeDirectory y userAccountAttribute. Los usuarios no podrán iniciar sesión en este software a menos que añada la cuenta de servicio que utiliza al grupo Pre-Windows 2000 Compatible Access o conceda los permisos adecuados directamente en sus objetos de usuario.

Un beneficio adicional de vaciar su grupo de Acceso Compatible Pre-Windows 2000: Hacerlo le habría protegido de la vulnerabilidad PrintNightmare antes de parchear sus controladores de dominio con el parche crítico CVE-2021-1675 del verano de 2021. Del mismo modo, vaciar el grupo le protegerá de otras vulnerabilidades de Día Cero que utilizan estos permisos predeterminados en Active Directory.

En cualquier caso, para un funcionamiento normal y seguro de su Directorio Activo, no es necesario que los Usuarios Autenticados sean miembros del grupo Acceso Compatible Pre-Windows 2000. Tampoco lo es Everyone o Anonymous Users. Mantener el grupo vacío, o al menos poblado sólo con los pocos usuarios y equipos dedicados que podrían necesitarlo, ayudará sin duda a reducir la superficie de ataque de su Directorio Activo. Esta configuración hace que sea mucho más difícil para los intrusos enumerar cuentas débiles y extraer otros datos sensibles de seguridad de su AD.

Cómo solucionar este problema en un entorno grande

Escribir sobre la necesidad de mejorar la seguridad es fácil. Pero cambiar realmente la pertenencia a un grupo por defecto que Microsoft ha decidido dejar en su lugar, incluso en su última versión del sistema operativo, puede ser todo un reto, especialmente en entornos grandes.

Como ya se ha mencionado, empieza por proteger tus grupos más críticos (por ejemplo, Domain Admin, Enterprise Admin) para que no puedan ser leídos por todo el mundo. Después de todo, no hacerlo facilita enormemente a los intrusos la planificación de rutas de ataque adecuadas contra los objetos de usuario más sensibles de su bosque de Active Directory. Esta tarea se aborda mejor actualizando la plantilla AdminSDholder, que se utiliza para actualizar los permisos de todos estos objetos sensibles.

En entornos más pequeños, "limpiar" el grupo de Acceso Compatible con Pre-Windows 2000 podría ser posible en un fin de semana, con algunas pruebas iniciales de los sistemas empresariales principales para confirmar que todo sigue funcionando como se esperaba. Pero este enfoque puede ser un poco desalentador en las grandes empresas. Después de todo, no querrás causar un impacto mayor en el negocio simplemente porque estabas reforzando la seguridad de tu Directorio Activo.

Como con cualquier tarea grande, recomiendo dividir el trabajo. Aunque la elección es, en última instancia, binaria (los usuarios autenticados están o no en el grupo de acceso compatible anterior a Windows 2000), los permisos de este grupo se heredan a diferentes objetos del bosque de Active Directory desde la raíz de cada dominio de ese bosque. Por lo tanto, tienes la opción de bloquear OUs individuales:

  1. Deshabilitar la herencia en las OUs
  2. Copiar todos los permisos existentes
  3. Eliminando sólo el grupo de Acceso Compatible Pre-Windows 2000 del conjunto resultante de permisos explícitos.

Para los objetos de la OU correspondiente, el efecto es el mismo que si hubiera eliminado Usuarios autenticados del grupo en la raíz del dominio. En otras palabras, el grupo Acceso Compatible Pre-Windows 2000 ya no tiene permisos sobre los objetos de la OU correspondiente.

Naturalmente, querrás probar el impacto de tales cambios de permisos antes de realizarlos. Le sugiero que registre los permisos actuales en cualquier OU que desee modificar. Es útil tener una solución que registre todos los cambios en su Directorio Activo, incluyendo el atributo nTsecurityDescriptor, que esencialmente almacena el permiso del objeto respectivo. Aún mejor sería una solución que también pudiera deshacer dichos cambios. Semperis Directory Service Protector (DSP ) es una herramienta de este tipo, pero también puedes utilizar scripts disponibles públicamente y tus propias capturas de pantalla para documentar tu trabajo.

Lo ideal es disponer de planes de pruebas y partes interesadas preparadas para validar las aplicaciones, herramientas y procesos de gestión de usuarios y clientes más importantes. Tendrá que recopilar información después de realizar el cambio de permisos. Ejecutar las pruebas con los objetos de la primera OU bloqueada le proporcionará información sobre posibles problemas que deberá solucionar antes de bloquear otra OU, y así sucesivamente.

Con el tiempo, estará listo para eliminar por completo el grupo Usuarios autenticados del grupo Acceso compatible pre-Windows 2000. Cuando llegue a ese punto, asegúrese de volver a habilitar la herencia de permisos en las OU que utilizó para las pruebas. Revertirlos a los permisos explícitos anteriores que se concedieron en ese nivel. El uso de las herramientas adecuadas para detectar todos los cambios en su bosque de Active Directory también reducirá sus esfuerzos durante este paso.

Aspectos clave de la configuración de acceso compatible con Windows 2000 en Windows Server 2025 y versiones anteriores

Active Directory está lleno de campos de minas de seguridad que los ciberatacantes pueden explotar. (Para identificar posibles brechas de seguridad en su entorno, descargue Purple Knightuna herramienta gratuita de evaluación de la seguridad de Active Directory que identifica más de 100 indicadores de exposición o compromiso con orientación sobre cómo abordarlos). Pero adoptar Windows Server 2025 o Windows Server 2022 no significa necesariamente dejar atrás todas esas configuraciones heredadas.

Si no hay más remedio, considere la posibilidad de realizar estos cambios en los parámetros de configuración relacionados con la compatibilidad anterior a Windows 2000:

  • No se lo piense dos veces para eliminar Anónimo y Todos del grupo de acceso compatible con versiones anteriores a Windows 2000 en todos los dominios de su bosque AD.
  • Haga lo mismo con los Usuarios Autenticados, pero tenga cuidado con el impacto potencial y esté preparado para repoblar el grupo con sistemas o usuarios que puedan depender de los permisos que les concede.
  • Elimine los permisos de lectura por defecto para Usuarios Autenticados de grupos sensibles para restringir quién puede enumerar sus membresías. Consulte mi blog sobre cómo hacerlo para los grupos de administración de AD integrados.

Debes decidir por ti mismo si eliminas el grupo Usuarios Autenticados para aumentar la seguridad de tu Directorio Activo. Puedes optar por aceptar el riesgo y seguir viviendo con esos viejos permisos tipo Windows NT en tu Directorio Activo. Pero siga ese camino sólo después de entender cuidadosamente el peligro potencial.