Implementación de modelos administrativos de menor privilegio

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 y Windows Server 2012.

El siguiente extracto procede de la Guía de planeación de seguridad de cuentas de administrador, publicada por primera vez el 1 de abril de 1999:

"La mayoría de los cursos de formación relacionados con la seguridad y la documentación analizan la implementación de un principio de privilegios mínimos, pero las organizaciones rara vez lo siguen. El principio es sencillo y el impacto de aplicarlo correctamente aumenta considerablemente su seguridad y reduce el riesgo. El principio indica que todos los usuarios deben iniciar sesión con una cuenta de usuario que tenga los permisos mínimos absolutos necesarios para completar la tarea actual y nada más. Esto proporciona protección contra código malintencionado, entre otros ataques. Este principio se aplica a los equipos y a los usuarios de esos equipos. "Una razón por la que este principio funciona tan bien es que te obliga a realizar alguna investigación interna. Por ejemplo, debe determinar los privilegios de acceso que realmente necesita un equipo o usuario y, a continuación, implementarlos. Para muchas organizaciones, esta tarea podría parecer inicialmente una gran cantidad de trabajo; sin embargo, es un paso esencial para proteger correctamente el entorno de red. "Debe conceder a todos los usuarios de administrador de dominio sus privilegios de dominio bajo el concepto de privilegios mínimos. Por ejemplo, si un administrador inicia sesión con una cuenta con privilegios y ejecuta accidentalmente un programa de virus, el virus tiene acceso administrativo al equipo local y a todo el dominio. Si el administrador hubiera iniciado sesión en su lugar con una cuenta no privada (no administrativa), el ámbito del virus de daño solo sería el equipo local porque se ejecuta como usuario de equipo local. "En otro ejemplo, las cuentas a las que se conceden derechos de administrador de nivel de dominio no deben tener derechos elevados en otro bosque, incluso si hay una relación de confianza entre los bosques. Esta táctica ayuda a evitar daños generalizados si un atacante logra poner en peligro un bosque administrado. Las organizaciones deben auditar periódicamente su red para protegerse frente a la elevación no autorizada de privilegios".

El siguiente extracto procede del Kit de recursos de Microsoft Seguridad de Windows, publicado por primera vez en 2005:

"Piense siempre en la seguridad en términos de conceder la menor cantidad de privilegios necesarios para llevar a cabo la tarea. Si una aplicación que tiene demasiados privilegios debe estar en peligro, es posible que el atacante pueda expandir el ataque más allá de lo que haría si la aplicación hubiera estado bajo la menor cantidad de privilegios posible. Por ejemplo, examine las consecuencias de un administrador de red abriendo involuntariamente un archivo adjunto de correo electrónico que inicia un virus. Si el administrador ha iniciado sesión con la cuenta de administrador de dominio, el virus tendrá privilegios de administrador en todos los equipos del dominio y, por lo tanto, el acceso sin restricciones a casi todos los datos de la red. Si el administrador ha iniciado sesión con una cuenta de administrador local, el virus tendrá privilegios de administrador en el equipo local y, por tanto, podrá acceder a los datos del equipo e instalar software malintencionado, como el software de registro de trazos de claves en el equipo. Si el administrador ha iniciado sesión con una cuenta de usuario normal, el virus tendrá acceso solo a los datos del administrador y no podrá instalar software malintencionado. Mediante el uso de los privilegios mínimos necesarios para leer el correo electrónico, en este ejemplo, se reduce considerablemente el ámbito potencial del riesgo".

El problema de privilegios

Los principios descritos en los extractos anteriores no han cambiado, pero al evaluar las instalaciones de Active Directory, invariablemente encontramos un número excesivo de cuentas a las que se han concedido derechos y permisos mucho más allá de los necesarios para realizar el trabajo diario. El tamaño del entorno afecta a los números sin procesar de cuentas con privilegios excesivos, pero no los directorios medianas proporcionales pueden tener docenas de cuentas en los grupos con más privilegios, mientras que las instalaciones grandes pueden tener cientos o incluso miles. Con pocas excepciones, independientemente de la sofisticación de las habilidades y el arsenal de un atacante, los atacantes suelen seguir el camino de la menor resistencia. Aumentan la complejidad de sus herramientas y enfoques solo si y cuando los mecanismos más simples fallan o son frustrados por los defensores.

Desafortunadamente, el camino de la menor resistencia en muchos entornos ha demostrado ser el uso excesivo de cuentas con privilegios amplios y profundos. Los privilegios amplios son derechos y permisos que permiten a una cuenta realizar actividades específicas en una gran sección transversal del entorno; por ejemplo, al personal del departamento de soporte técnico se les pueden conceder permisos que les permitan restablecer las contraseñas en muchas cuentas de usuario.

Los privilegios profundos son privilegios eficaces que se aplican a un segmento estrecho de la población, como conceder a un ingeniero derechos de administrador en un servidor para que puedan realizar reparaciones. Ni el privilegio amplio ni el privilegio profundo son necesariamente peligrosos, pero cuando se conceden permanentemente muchos privilegios amplios y profundos, si solo una de las cuentas está en peligro, se puede usar rápidamente para volver a configurar el entorno a los propósitos del atacante o incluso para destruir grandes segmentos de la infraestructura.

Los ataques pass-the-hash, que son un tipo de ataque de robo de credenciales, son omnipresentes porque las herramientas para realizarlas están disponibles de forma gratuita y fácil de usar, y porque muchos entornos son vulnerables a los ataques. Sin embargo, los ataques pass-the-hash no son el problema real. La crux del problema es dos veces:

  1. Normalmente, es fácil que un atacante obtenga privilegios profundos en un solo equipo y, a continuación, propague ese privilegio ampliamente a otros equipos.
  2. Normalmente hay demasiadas cuentas permanentes con altos niveles de privilegios en todo el panorama informático.

Incluso si se eliminan los ataques pass-the-hash, los atacantes simplemente usarían tácticas diferentes, no una estrategia diferente. En lugar de plantar malware que contiene herramientas de robo de credenciales, podrían plantar malware que registra pulsaciones de teclas o aprovechar cualquier número de otros enfoques para capturar credenciales que son eficaces en todo el entorno. Independientemente de las tácticas, los objetivos siguen siendo los mismos: cuentas con privilegios amplios y profundos.

La concesión de privilegios excesivos no solo se encuentra en Active Directory en entornos en peligro. Cuando una organización ha desarrollado el hábito de conceder más privilegios de lo necesario, normalmente se encuentra en toda la infraestructura, como se describe en las secciones siguientes.

En Active Directory

En Active Directory, es habitual encontrar que los grupos ea, DA y BA contienen un número excesivo de cuentas. Normalmente, el grupo ea de una organización contiene los miembros más pequeños, los grupos de DA suelen contener un multiplicador del número de usuarios del grupo ea y los grupos administradores suelen contener más miembros que las poblaciones de los otros grupos combinados. Esto suele deberse a una creencia de que los administradores son de alguna manera "menos privilegiados" que las entidades de certificación o entidades de certificación. Aunque los derechos y permisos concedidos a cada uno de estos grupos difieren, deben considerarse eficazmente grupos igualmente poderosos porque un miembro de uno puede hacerse miembro de los otros dos.

En servidores miembros

Cuando recuperamos la pertenencia de grupos de administradores locales en servidores miembros en muchos entornos, encontramos pertenencias que van desde una serie de cuentas locales y de dominio, hasta docenas de grupos anidados que, cuando se expanden, revelan cientos, incluso miles, de cuentas con privilegios de administrador local en los servidores. En muchos casos, los grupos de dominio con pertenencias grandes se anidan en los grupos de administradores locales de los servidores miembros, sin tener en cuenta el hecho de que cualquier usuario que pueda modificar las pertenencias de esos grupos en el dominio puede obtener el control administrativo de todos los sistemas en los que el grupo se ha anidado en un grupo de administradores local.

En estaciones de trabajo

Aunque las estaciones de trabajo suelen tener muchos menos miembros en sus grupos de administradores locales que los servidores miembros, en muchos entornos, a los usuarios se les concede la pertenencia al grupo administradores local en sus equipos personales. Cuando esto ocurre, incluso si UAC está habilitado, esos usuarios presentan un riesgo elevado a la integridad de sus estaciones de trabajo.

Importante

Debe considerar cuidadosamente si los usuarios requieren derechos administrativos en sus estaciones de trabajo y, si lo hacen, un mejor enfoque puede ser crear una cuenta local independiente en el equipo que sea miembro del grupo Administradores. Cuando los usuarios requieren elevación, pueden presentar las credenciales de esa cuenta local para la elevación, pero dado que la cuenta es local, no se puede usar para poner en peligro otros equipos o acceder a los recursos de dominio. Sin embargo, al igual que con las cuentas locales, las credenciales de la cuenta con privilegios locales deben ser únicas; Si crea una cuenta local con las mismas credenciales en varias estaciones de trabajo, exponga los equipos para ataques pass-the-hash.

En aplicaciones

En los ataques en los que el destino es la propiedad intelectual de una organización, las cuentas a las que se les han concedido privilegios eficaces dentro de las aplicaciones se pueden destinar para permitir la filtración de datos. Aunque las cuentas que tienen acceso a datos confidenciales pueden haber recibido privilegios elevados en el dominio o en el sistema operativo, las cuentas que pueden manipular la configuración de una aplicación o el acceso a la información que proporciona la aplicación presentan riesgos.

En repositorios de datos

Como sucede con otros destinos, los atacantes que buscan acceso a la propiedad intelectual en forma de documentos y otros archivos pueden dirigirse a las cuentas que controlan el acceso a los almacenes de archivos, las cuentas que tienen acceso directo a los archivos, o incluso grupos o roles que tienen acceso a los archivos. Por ejemplo, si se usa un servidor de archivos para almacenar documentos de contrato y se concede acceso a los documentos mediante el uso de un grupo de Active Directory, un atacante que puede modificar la pertenencia del grupo puede agregar cuentas comprometidas al grupo y acceder a los documentos del contrato. En los casos en los que las aplicaciones como SharePoint proporcionan acceso a documentos, los atacantes pueden dirigirse a las aplicaciones, como se ha descrito anteriormente.

Reducción de privilegios

Cuanto más grande y complejo sea un entorno, más difícil será administrar y proteger. En pequeñas organizaciones, revisar y reducir privilegios puede ser una propuesta relativamente sencilla, pero cada servidor adicional, estación de trabajo, cuenta de usuario y aplicación en uso en una organización agrega otro objeto que se debe proteger. Dado que puede ser difícil o incluso imposible proteger correctamente todos los aspectos de la infraestructura de TI de una organización, debe centrar los esfuerzos primero en las cuentas cuyos privilegios crean el mayor riesgo, que suelen ser las cuentas y grupos con privilegios integrados en Active Directory y las cuentas locales con privilegios en estaciones de trabajo y servidores miembros.

Protección de cuentas de administrador local en estaciones de trabajo y servidores miembros

Aunque este documento se centra en proteger Active Directory, como se ha descrito anteriormente, la mayoría de los ataques contra el directorio comienzan como ataques contra hosts individuales. No se pueden proporcionar instrucciones completas para proteger grupos locales en sistemas miembros, pero se pueden usar las siguientes recomendaciones para ayudarle a proteger las cuentas de administrador locales en estaciones de trabajo y servidores miembros.

Protección de cuentas de administrador local

En todas las versiones de Windows actualmente en soporte estándar, la cuenta de administrador local está deshabilitada de forma predeterminada, lo que hace que la cuenta no se pueda usar para ataques pass-the-hash y otros ataques de robo de credenciales. Sin embargo, en dominios que contienen sistemas operativos heredados o en los que se han habilitado las cuentas de administrador local, estas cuentas se pueden usar como se ha descrito anteriormente para propagar el riesgo entre servidores miembros y estaciones de trabajo. Por este motivo, se recomiendan los siguientes controles para todas las cuentas de administrador locales en sistemas unidos a un dominio.

Se proporcionan instrucciones detalladas para implementar estos controles en el Apéndice H: Protección de cuentas y grupos de administrador local. Sin embargo, antes de implementar esta configuración, asegúrese de que las cuentas de administrador local no se usan actualmente en el entorno para ejecutar servicios en equipos o realizar otras actividades para las que no se deben usar estas cuentas. Pruebe esta configuración exhaustivamente antes de implementarla en un entorno de producción.

Controles para cuentas de administrador local

Las cuentas de administrador integradas nunca deben usarse como cuentas de servicio en servidores miembros, ni deben usarse para iniciar sesión en equipos locales (excepto en Caja fuerte modo, que se permite incluso si la cuenta está deshabilitada). El objetivo de implementar la configuración que se describe aquí es evitar que la cuenta de administrador local de cada equipo se pueda usar a menos que los controles de protección se reviertan primero. Al implementar estos controles y supervisar las cuentas de administrador para los cambios, puede reducir significativamente la probabilidad de éxito de un ataque dirigido a cuentas de administrador locales.

Configuración de GPO para restringir cuentas de administrador en sistemas de Domain-Joined

En uno o varios GPO que cree y vincule a unidades organizativas de servidor miembro y estación de trabajo en cada dominio, agregue la cuenta de administrador a los siguientes derechos de usuario en Configuración del equipo\Directivas\Windows Configuración\Security Configuración\Directivas locales\Asignaciones de derechos de usuario:

  • Denegar el acceso desde la red a este equipo
  • Denegar el inicio de sesión como trabajo por lotes
  • Denegar el inicio de sesión como servicio
  • Denegar inicio de sesión a través de Servicios de Escritorio remoto

Al agregar cuentas de administrador a estos derechos de usuario, especifique si va a agregar la cuenta de administrador local o la cuenta de administrador del dominio mediante la etiqueta de la cuenta. Por ejemplo, para agregar la cuenta de administrador del dominio NWTRADERS a estos derechos de denegación, escribiría la cuenta como NWTRADERS\Administrator, o vaya a la cuenta administrador del dominio NWTRADERS. Para asegurarse de restringir la cuenta de administrador local, escriba Administrador en esta configuración de derechos de usuario en el editor de objetos de directiva de grupo.

Nota

Incluso si se cambia el nombre de las cuentas de administrador local, las directivas se seguirán aplicando.

Esta configuración garantizará que la cuenta de administrador de un equipo no se pueda usar para conectarse a los demás equipos, incluso si está habilitada de forma involuntaria o malintencionada. Los inicios de sesión locales que usan la cuenta de administrador local no se pueden deshabilitar por completo, ni debe intentar hacerlo, ya que la cuenta de administrador local de un equipo está diseñada para usarse en escenarios de recuperación ante desastres.

Si un servidor miembro o una estación de trabajo se desconectan del dominio sin otras cuentas locales con privilegios administrativos concedidos, el equipo se puede arrancar en modo seguro, se puede habilitar la cuenta de administrador y, a continuación, se puede usar la cuenta para aplicar reparaciones en el equipo. Cuando se completan las reparaciones, la cuenta de administrador debe deshabilitarse de nuevo.

Protección de cuentas y grupos con privilegios locales en Active Directory

Número de ley Seis: un equipo solo es tan seguro como el administrador es de confianza. - Diez leyes inmutables de seguridad (versión 2.0)

La información que se proporciona aquí está pensada para proporcionar instrucciones generales para proteger las cuentas y grupos integrados con privilegios más altos en Active Directory. También se proporcionan instrucciones detalladas paso a paso en el Apéndice D: Protección de cuentas de administrador de Built-In en Active Directory, Apéndice E: Protección de grupos de administradores de Enterprise en Active Directory, Apéndice F: Protección de grupos de administradores de dominio en Active Directory y en apéndice G: Protección de grupos de administradores en Active Directory.

Antes de implementar cualquiera de estas configuraciones, también debe probar todas las configuraciones exhaustivamente para determinar si son adecuadas para su entorno. No todas las organizaciones podrán implementar esta configuración.

Protección de cuentas de administrador integradas en Active Directory

En cada dominio de Active Directory, se crea una cuenta de administrador como parte de la creación del dominio. Esta cuenta es de forma predeterminada miembro de los grupos Administradores de dominio y Administrador del dominio y, si el dominio es el dominio raíz del bosque, la cuenta también es miembro del grupo administradores de Enterprise. El uso de la cuenta de administrador local de un dominio solo debe reservarse para las actividades de compilación iniciales y, posiblemente, para escenarios de recuperación ante desastres. Para asegurarse de que se puede usar una cuenta de administrador integrada para aplicar reparaciones en caso de que no se pueda usar ninguna otra cuenta, no debe cambiar la pertenencia predeterminada de la cuenta de administrador en ningún dominio del bosque. En su lugar, debe seguir las instrucciones para ayudar a proteger la cuenta de administrador en cada dominio del bosque. Se proporcionan instrucciones detalladas para implementar estos controles en el Apéndice D: Protección de cuentas de administrador de Built-In en Active Directory.

Controles para cuentas de administrador integradas

El objetivo de implementar la configuración descrita aquí es evitar que se pueda usar la cuenta de administrador de cada dominio (no un grupo) a menos que se revierta un número de controles. Al implementar estos controles y supervisar las cuentas de administrador para los cambios, puede reducir significativamente la probabilidad de un ataque correcto aprovechando la cuenta de administrador de un dominio. Para la cuenta de administrador de cada dominio del bosque, debe configurar las siguientes opciones.

Habilite la marca "La cuenta es confidencial y no se puede delegar" en la cuenta.

De forma predeterminada, se pueden delegar todas las cuentas de Active Directory. La delegación permite a un equipo o servicio presentar las credenciales de una cuenta que se haya autenticado en el equipo o servicio en otros equipos para obtener servicios en nombre de la cuenta. Al habilitar la cuenta es confidencial y no se puede delegar el atributo en una cuenta basada en dominio, las credenciales de la cuenta no se pueden presentar a otros equipos o servicios de la red, lo que limita los ataques que aprovechan la delegación para usar las credenciales de la cuenta en otros sistemas.

Habilite la marca "Tarjeta inteligente para el inicio de sesión interactivo" en la cuenta.

Cuando se habilita la tarjeta inteligente para el atributo de inicio de sesión interactivo en una cuenta, Windows restablece la contraseña de la cuenta a un valor aleatorio de 120 caracteres. Al establecer esta marca en cuentas de administrador integradas, asegúrese de que la contraseña de la cuenta no solo es larga y compleja, pero no se conoce a ningún usuario. No es técnicamente necesario crear tarjetas inteligentes para las cuentas antes de habilitar este atributo, pero, si es posible, se deben crear tarjetas inteligentes para cada cuenta de administrador antes de configurar las restricciones de cuenta y las tarjetas inteligentes deben almacenarse en ubicaciones seguras.

Aunque la configuración de la tarjeta inteligente es necesaria para la marca de inicio de sesión interactiva restablece la contraseña de la cuenta, no impide que un usuario con derechos restablezca la contraseña de la cuenta estableciendo la cuenta en un valor conocido y usando el nombre de la cuenta y la nueva contraseña para acceder a los recursos de la red. Por este motivo, debe implementar los siguientes controles adicionales en la cuenta.

Configuración de GPO para restringir las cuentas de administrador de dominios en sistemas de Domain-Joined

Aunque deshabilitar la cuenta de administrador en un dominio hace que la cuenta sea eficazmente inutilizable, debe implementar restricciones adicionales en la cuenta en caso de que la cuenta esté habilitada accidentalmente o malintencionadamente. Aunque estos controles pueden revertirse en última instancia por la cuenta de administrador, el objetivo es crear controles que ralentizan el progreso de un atacante y limitan el daño que puede causar la cuenta.

En uno o varios GPO que cree y vincule a unidades organizativas de servidor miembro y estación de trabajo en cada dominio, agregue la cuenta de administrador de cada dominio a los siguientes derechos de usuario en Configuración del equipo\Directivas\Windows Configuración\Security Configuración\Directivas locales\Asignaciones de derechos de usuario:

  • Denegar el acceso desde la red a este equipo
  • Denegar el inicio de sesión como trabajo por lotes
  • Denegar el inicio de sesión como servicio
  • Denegar inicio de sesión a través de Servicios de Escritorio remoto

Nota

Al agregar cuentas de administrador locales a esta configuración, debe especificar si va a configurar cuentas de administrador locales o cuentas de administrador de dominio. Por ejemplo, para agregar la cuenta de administrador local del dominio NWTRADERS a estos derechos de denegación, debe escribir la cuenta como NWTRADERS\Administrator o ir a la cuenta de administrador local para el dominio NWTRADERS. Si escribe Administrador en esta configuración de derechos de usuario en el Editor de objetos de directiva de grupo, restringirá la cuenta de administrador local en cada equipo al que se aplique el GPO.

Se recomienda restringir las cuentas de administrador locales en servidores miembros y estaciones de trabajo de la misma manera que las cuentas de administrador basadas en dominio. Por lo tanto, por lo general, debe agregar la cuenta de administrador para cada dominio del bosque y la cuenta de administrador de los equipos locales a esta configuración de derechos de usuario.

Configuración de GPO para restringir cuentas de administrador en controladores de dominio

En cada dominio del bosque, se debe modificar la directiva Controladores de dominio predeterminados o una directiva vinculada a la unidad organizativa Controladores de dominio para agregar la cuenta de administrador de cada dominio a los siguientes derechos de usuario en Configuración del equipo\Directivas\Windows Configuración\Seguridad Configuración\Directivas locales\Asignaciones de derechos de usuario:

  • Denegar el acceso desde la red a este equipo
  • Denegar el inicio de sesión como trabajo por lotes
  • Denegar el inicio de sesión como servicio
  • Denegar inicio de sesión a través de Servicios de Escritorio remoto

Nota

Esta configuración garantizará que la cuenta de administrador local no se pueda usar para conectarse a un controlador de dominio, aunque la cuenta, si está habilitada, puede iniciar sesión localmente en controladores de dominio. Dado que esta cuenta solo debe habilitarse y usarse en escenarios de recuperación ante desastres, se prevé que el acceso físico a al menos un controlador de dominio estará disponible o que se puedan usar otras cuentas con permisos para acceder a controladores de dominio de forma remota.

Configurar la auditoría de cuentas de administrador integradas

Cuando haya protegido la cuenta de administrador de cada dominio y la haya deshabilitado, debe configurar la auditoría para supervisar los cambios en la cuenta. Si la cuenta está habilitada, se restablece su contraseña o se realizan otras modificaciones en la cuenta, las alertas se deben enviar a los usuarios o equipos responsables de la administración de AD DS, además de los equipos de respuesta a incidentes de su organización.

Protección de administradores, administradores de dominio y grupos de administradores de Enterprise

Protección de grupos de administración de Enterprise

El grupo administradores de Enterprise, que se hospeda en el dominio raíz del bosque, no debe contener usuarios día a día, con la posible excepción de la cuenta de administrador local del dominio, siempre que esté protegido como se ha descrito anteriormente y en el Apéndice D: Proteger Built-In cuentas de administrador en Active Directory.

Cuando se requiere acceso de EA, los usuarios cuyas cuentas requieren derechos y permisos de EA deben colocarse temporalmente en el grupo administradores de Enterprise. Aunque los usuarios usan las cuentas con privilegios elevados, sus actividades se deben auditar y, preferiblemente, realizarlas con un usuario que realice los cambios y otro usuario que observe los cambios para minimizar la probabilidad de un uso incorrecto accidental o una configuración incorrecta. Una vez completadas las actividades, las cuentas deben quitarse del grupo ea. Esto se puede lograr a través de procedimientos manuales y procesos documentados, software de administración de identidades y acceso con privilegios de terceros (PIM/PAM) o una combinación de ambos. Las directrices para crear cuentas que se pueden usar para controlar la pertenencia a grupos con privilegios en Active Directory se proporcionan en Cuentas atractivas para el robo de credenciales y se proporcionan instrucciones detalladas en el Apéndice I: Crear cuentas de administración para cuentas protegidas y grupos en Active Directory.

Enterprise administradores son, de forma predeterminada, miembros del grupo administradores integrado en cada dominio del bosque. Quitar el grupo de administradores de Enterprise de los grupos Administradores de cada dominio es una modificación inapropiada porque, en caso de un escenario de recuperación ante desastres de bosque, es probable que se necesiten derechos de EA. Si el grupo administradores de Enterprise se ha quitado de los grupos administradores de un bosque, se debe agregar al grupo Administradores de cada dominio y se deben implementar los siguientes controles adicionales:

  • Como se ha descrito anteriormente, el grupo administradores de Enterprise no debe contener usuarios diariamente, con la posible excepción de la cuenta de administrador del dominio raíz del bosque, que se debe proteger como se describe en el Apéndice D: Proteger Built-In cuentas de administrador en Active Directory.
  • En los GPO vinculados a unidades organizativas que contienen servidores miembros y estaciones de trabajo de cada dominio, el grupo de EA debe agregarse a los siguientes derechos de usuario:
    • Denegar el acceso desde la red a este equipo
    • Denegar el inicio de sesión como trabajo por lotes
    • Denegar el inicio de sesión como servicio
    • Denegar el inicio de sesión localmente
    • Denegar el inicio de sesión a través de Servicios de Escritorio remoto.

Esto impedirá que los miembros del grupo ea inicien sesión en servidores y estaciones de trabajo miembros. Si los servidores de salto se usan para administrar controladores de dominio y Active Directory, asegúrese de que los servidores de salto se encuentran en una unidad organizativa a la que los GPO restrictivos no están vinculados.

  • La auditoría debe configurarse para enviar alertas si se realizan modificaciones en las propiedades o la pertenencia del grupo ea. Estas alertas se deben enviar, como mínimo, a los usuarios o equipos responsables de la administración de Active Directory y la respuesta a incidentes. También debe definir procesos y procedimientos para rellenar temporalmente el grupo ea, incluidos los procedimientos de notificación cuando se realiza la población legítima del grupo.

Protección de grupos de administradores de dominio

Como sucede con el grupo de administradores de Enterprise, la pertenencia a grupos administradores de dominio solo debe ser necesaria en escenarios de compilación o recuperación ante desastres. No debe haber cuentas de usuario diarias en el grupo DA con la excepción de la cuenta de administrador local para el dominio, si se ha protegido como se describe en el Apéndice D: Proteger Built-In cuentas de administrador en Active Directory.

Cuando se requiere acceso DA, las cuentas que necesitan este nivel de acceso deben colocarse temporalmente en el grupo da para el dominio en cuestión. Aunque los usuarios usan las cuentas con privilegios elevados, las actividades se deben auditar y, preferiblemente, realizarlas con un usuario que realice los cambios y otro usuario que observe los cambios para minimizar la probabilidad de un uso incorrecto accidental o una configuración incorrecta. Una vez completadas las actividades, las cuentas deben quitarse del grupo Administradores de dominio. Esto se puede lograr a través de procedimientos manuales y procesos documentados, a través del software de administración de identidades y acceso con privilegios de terceros (PIM/PAM) o una combinación de ambos. Las directrices para crear cuentas que se pueden usar para controlar la pertenencia a grupos con privilegios en Active Directory se proporcionan en el Apéndice I: Creación de cuentas de administración para cuentas protegidas y grupos en Active Directory.

Los administradores de dominio son, de forma predeterminada, miembros de los grupos de administradores locales en todos los servidores miembros y estaciones de trabajo de sus respectivos dominios. Este anidamiento predeterminado no debe modificarse porque afecta a la compatibilidad y a las opciones de recuperación ante desastres. Si los grupos administradores de dominio se han quitado de los grupos de administradores locales en los servidores miembros, deben agregarse al grupo Administradores en cada servidor miembro y estación de trabajo del dominio a través de la configuración de grupo restringida en GPO vinculados. También se deben implementar los siguientes controles generales, que se describen en profundidad en el Apéndice F: Protección de grupos de administradores de dominio en Active Directory .

Para el grupo Administradores de dominio de cada dominio del bosque:

  1. Quite todos los miembros del grupo DA, con la posible excepción de la cuenta de administrador integrada para el dominio, siempre que se haya protegido tal y como se describe en el Apéndice D: Proteger Built-In cuentas de administrador en Active Directory.

  2. En los GPO vinculados a unidades organizativas que contienen servidores miembros y estaciones de trabajo de cada dominio, el grupo da debe agregarse a los siguientes derechos de usuario:

    • Denegar el acceso desde la red a este equipo
    • Denegar el inicio de sesión como trabajo por lotes
    • Denegar el inicio de sesión como servicio
    • Denegar el inicio de sesión localmente
    • Denegar inicio de sesión a través de Servicios de Escritorio remoto

    Esto impedirá que los miembros del grupo DA inicien sesión en servidores miembros y estaciones de trabajo. Si los servidores de salto se usan para administrar controladores de dominio y Active Directory, asegúrese de que los servidores de salto se encuentran en una unidad organizativa a la que los GPO restrictivos no están vinculados.

  3. La auditoría debe configurarse para enviar alertas si se realizan modificaciones en las propiedades o la pertenencia del grupo da. Estas alertas se deben enviar, como mínimo, a los usuarios o equipos responsables de la administración y la respuesta a incidentes de AD DS. También debe definir procesos y procedimientos para rellenar temporalmente el grupo da, incluidos los procedimientos de notificación cuando se realiza la población legítima del grupo.

Protección de grupos de administradores en Active Directory

Como sucede con los grupos ea y DA, la pertenencia al grupo Administradores (BA) solo debe ser necesaria en escenarios de compilación o recuperación ante desastres. No debe haber cuentas de usuario diarias en el grupo Administradores con la excepción de la cuenta de administrador local para el dominio, si se ha protegido como se describe en el Apéndice D: Proteger Built-In cuentas de administrador en Active Directory.

Cuando se requiere acceso de administradores, las cuentas que necesitan este nivel de acceso deben colocarse temporalmente en el grupo Administradores para el dominio en cuestión. Aunque los usuarios usan las cuentas con privilegios elevados, se deben auditar las actividades y, preferiblemente, realizar con un usuario que realice los cambios y otro usuario que observe los cambios para minimizar la probabilidad de un uso incorrecto accidental o una configuración incorrecta. Cuando se hayan completado las actividades, las cuentas deben quitarse inmediatamente del grupo Administradores. Esto se puede lograr a través de procedimientos manuales y procesos documentados, a través del software de administración de identidades y acceso con privilegios de terceros (PIM/PAM) o una combinación de ambos.

Los administradores son, de forma predeterminada, los propietarios de la mayoría de los objetos de AD DS en sus respectivos dominios. La pertenencia a este grupo puede ser necesaria en escenarios de compilación y recuperación ante desastres en los que se requiere la propiedad o la capacidad de tomar posesión de los objetos. Además, las entidades de dominio y las entidades de certificación heredan una serie de sus derechos y permisos en virtud de su pertenencia predeterminada al grupo Administradores. No se debe modificar el anidamiento de grupos predeterminados para grupos con privilegios en Active Directory y se debe proteger el grupo administradores de cada dominio, como se describe en el Apéndice G: Protección de grupos de administradores en Active Directory y en las instrucciones generales siguientes.

  1. Quite todos los miembros del grupo Administradores, con la posible excepción de la cuenta de administrador local para el dominio, siempre que se haya protegido tal y como se describe en el Apéndice D: Proteger Built-In cuentas de administrador en Active Directory.

  2. Los miembros del grupo Administradores del dominio nunca deben tener que iniciar sesión en servidores miembros o estaciones de trabajo. En uno o varios GPO vinculados a estaciones de trabajo y unidades organizativas de servidor miembro en cada dominio, el grupo Administradores debe agregarse a los siguientes derechos de usuario:

    • Denegar el acceso desde la red a este equipo
    • Denegar el inicio de sesión como un trabajo por lotes,
    • Denegar el inicio de sesión como servicio
    • Esto impedirá que los miembros del grupo Administradores se usen para iniciar sesión o conectarse a servidores miembros o estaciones de trabajo (a menos que se infrinjen primero varios controles), donde sus credenciales se podrían almacenar en caché y, por tanto, poner en peligro. Una cuenta con privilegios nunca debe usarse para iniciar sesión en un sistema con menos privilegios y aplicar estos controles ofrece protección contra una serie de ataques.
  3. En la unidad organizativa de controladores de dominio de cada dominio del bosque, al grupo Administradores se le deben conceder los siguientes derechos de usuario (si aún no tienen estos derechos), lo que permitirá a los miembros del grupo Administradores realizar funciones necesarias para un escenario de recuperación ante desastres de todo el bosque:

    • Obtener acceso a este equipo desde la red
    • Permitir el inicio de sesión local
    • Permitir inicio de sesión a través de Servicios de Escritorio remoto
  4. La auditoría debe configurarse para enviar alertas si se realizan modificaciones en las propiedades o la pertenencia del grupo Administradores. Estas alertas deben enviarse, como mínimo, a los miembros del equipo responsables de la administración de AD DS. Las alertas también se deben enviar a los miembros del equipo de seguridad y se deben definir procedimientos para modificar la pertenencia del grupo Administradores. En concreto, estos procesos deben incluir un procedimiento por el que se notifica al equipo de seguridad cuando se va a modificar el grupo Administradores para que cuando se envíen alertas, se esperan y no se genera una alarma. Además, los procesos para notificar al equipo de seguridad cuando se ha completado el uso del grupo Administradores y se deben implementar las cuentas usadas del grupo.

Nota

Al implementar restricciones en el grupo Administradores en GPO, Windows aplica la configuración a los miembros del grupo de administradores locales de un equipo además del grupo Administradores del dominio. Por lo tanto, debe tener precaución al implementar restricciones en el grupo Administradores. Aunque se recomienda prohibir los inicios de sesión de red, por lotes y servicios para los miembros del grupo Administradores siempre que sea factible implementar, no restrinja los inicios de sesión o los inicios de sesión locales a través de servicios de Escritorio remoto. El bloqueo de estos tipos de inicio de sesión puede bloquear la administración legítima de un equipo por parte de los miembros del grupo de administradores locales. En la captura de pantalla siguiente se muestran las opciones de configuración que bloquean el uso indebido de cuentas locales y de administrador de dominio integradas, además del uso indebido de grupos de administradores de dominio o locales integrados. Tenga en cuenta que el derecho de usuario Denegar inicio de sesión a través de Servicios de Escritorio remoto no incluye el grupo Administradores, ya que incluirlo en esta configuración también bloquearía estos inicios de sesión para las cuentas que son miembros del grupo Administradores del equipo local. Si los servicios de los equipos están configurados para ejecutarse en el contexto de cualquiera de los grupos con privilegios descritos en esta sección, la implementación de esta configuración puede hacer que se produzcan errores en los servicios y las aplicaciones. Por lo tanto, al igual que con todas las recomendaciones de esta sección, debe probar exhaustivamente la configuración de aplicabilidad en su entorno.

least privilege admin models

controles de acceso de Role-Based (RBAC) para Active Directory

Por lo general, los controles de acceso basado en rol (RBAC) son un mecanismo para agrupar usuarios y proporcionar acceso a los recursos en función de las reglas de negocio. En el caso de Active Directory, la implementación de RBAC para AD DS es el proceso de creación de roles a los que se deleguen derechos y permisos para permitir que los miembros del rol realicen tareas administrativas diarias sin concederles privilegios excesivos. RBAC para Active Directory se puede diseñar e implementar a través de herramientas e interfaces nativas, aprovechando el software que ya puede poseer, mediante la compra de productos de terceros o cualquier combinación de estos enfoques. En esta sección no se proporcionan instrucciones paso a paso para implementar RBAC para Active Directory, pero en su lugar se describen los factores que debe tener en cuenta para elegir un enfoque para implementar RBAC en las instalaciones de AD DS.

Enfoques nativos de RBAC para Active Directory

En la implementación de RBAC más sencilla, puede implementar roles como grupos de AD DS y derechos delegados y permisos para los grupos que les permiten realizar la administración diaria dentro del ámbito designado del rol.

En algunos casos, los grupos de seguridad existentes en Active Directory se pueden usar para conceder derechos y permisos adecuados a una función de trabajo. Por ejemplo, si los empleados específicos de su organización de TI son responsables de la administración y mantenimiento de las zonas y registros DNS, delegar esas responsabilidades puede ser tan simple como crear una cuenta para cada administrador dns y agregarla al grupo Administradores de DNS en Active Directory. El grupo Administradores de DNS, a diferencia de los grupos con más privilegios, tiene pocos derechos eficaces en Active Directory, aunque los miembros de este grupo han sido permisos delegados que les permiten administrar DNS y aún están sujetos a riesgos y abusos podrían dar lugar a la elevación de privilegios.

En otros casos, es posible que tenga que crear grupos de seguridad y delegar derechos y permisos en objetos de Active Directory, objetos del sistema de archivos y objetos del Registro para permitir que los miembros de los grupos realicen tareas administrativas designadas. Por ejemplo, si los operadores del departamento de soporte técnico son responsables de restablecer las contraseñas olvidadas, ayudar a los usuarios con problemas de conectividad y solucionar problemas de configuración de la aplicación, es posible que tenga que combinar la configuración de delegación en objetos de usuario de Active Directory con privilegios que permitan a los usuarios conectarse de forma remota a los equipos de los usuarios para ver o modificar las opciones de configuración de los usuarios. Para cada rol que defina, debe identificar:

  1. Qué tareas realizan los miembros del rol diariamente y qué tareas se realizan con menos frecuencia.
  2. En qué sistemas y en qué aplicaciones se deben conceder derechos y permisos a los miembros de un rol.
  3. A qué usuarios se les debe conceder la pertenencia a un rol.
  4. Cómo se realizará la administración de las pertenencias a roles.

En muchos entornos, la creación manual de controles de acceso basado en roles para la administración de un entorno de Active Directory puede ser difícil de implementar y mantener. Si tiene roles y responsabilidades claramente definidos para la administración de la infraestructura de TI, es posible que desee aprovechar las herramientas adicionales para ayudarle a crear una implementación RBAC nativa administrable. Por ejemplo, si Forefront Identity Manager (FIM) está en uso en su entorno, puede usar FIM para automatizar la creación y el rellenado de roles administrativos, lo que puede facilitar la administración continua. Si usa Microsoft Endpoint Configuration Manager y System Center Operations Manager (SCOM), puede usar roles específicos de la aplicación para delegar funciones de administración y supervisión, así como aplicar una configuración y auditoría coherentes en todos los sistemas del dominio. Si ha implementado una infraestructura de clave pública (PKI), puede emitir y requerir tarjetas inteligentes para el personal de TI responsable de administrar el entorno. Con FIM Credential Management (FIM CM), incluso puede combinar la administración de roles y credenciales para el personal administrativo.

En otros casos, puede ser preferible que una organización considere la posibilidad de implementar software RBAC de terceros que proporciona funcionalidad "predeterminada". Las soluciones comerciales, fuera del estante (COTS) para RBAC para Active Directory, Windows y directorios no Windows y sistemas operativos se ofrecen por varios proveedores. Al elegir entre soluciones nativas y productos de terceros, debe tener en cuenta los siguientes factores:

  1. Presupuesto: al invertir en el desarrollo de RBAC mediante software y herramientas que puede que ya posea, puede reducir los costos de software implicados en la implementación de una solución. Sin embargo, a menos que tenga personal que tenga experiencia en la creación e implementación de soluciones nativas de RBAC, es posible que tenga que interactuar con recursos de consultoría para desarrollar la solución. Debe ponderar cuidadosamente los costos previstos de una solución desarrollada personalizada con los costos para implementar una solución "lista para usar", especialmente si su presupuesto es limitado.
  2. Composición del entorno de TI: si el entorno está compuesto principalmente por Windows sistemas, o si ya está aprovechando Active Directory para la administración de cuentas y sistemas no Windows, las soluciones nativas personalizadas pueden proporcionar la solución óptima para sus necesidades. Si la infraestructura contiene muchos sistemas que no ejecutan Windows y no están administrados por Active Directory, es posible que tenga que tener en cuenta las opciones de administración de sistemas que no son Windows por separado del entorno de Active Directory.
  3. Modelo de privilegios en la solución: si un producto se basa en la colocación de sus cuentas de servicio en grupos con privilegios elevados en Active Directory y no ofrece opciones que no requieren que se conceda privilegios excesivos al software RBAC, no ha reducido realmente la superficie expuesta a ataques de Active Directory, solo ha cambiado la composición de los grupos con más privilegios en el directorio. A menos que un proveedor de aplicaciones pueda proporcionar controles para las cuentas de servicio que minimicen la probabilidad de que las cuentas se pongan en peligro y se usen malintencionadamente, es posible que desee tener en cuenta otras opciones.

Privileged Identity Management

Privileged Identity Management (PIM), a veces denominado administración de cuentas con privilegios (PAM) o administración de credenciales con privilegios (PCM) es el diseño, la construcción y la implementación de enfoques para administrar cuentas con privilegios en la infraestructura. Por lo general, PIM proporciona mecanismos por los que se conceden derechos temporales y permisos necesarios para realizar funciones de corrección de compilación o interrupción, en lugar de dejar los privilegios asociados permanentemente a las cuentas. Tanto si la funcionalidad de PIM se crea manualmente como si se implementa a través de la implementación de software de terceros, una o varias de las siguientes características pueden estar disponibles:

  • Credenciales "almacenes", donde las contraseñas de las cuentas con privilegios se "desprotegerán" y asignaron una contraseña inicial y, a continuación, "proteger" cuando se han completado las actividades, en cuyo momento las contraseñas se restablecen de nuevo en las cuentas.
  • Restricciones limitadas de tiempo en el uso de credenciales con privilegios
  • Credenciales de uso único
  • Concesión de privilegios generada por el flujo de trabajo con supervisión e informes de actividades realizadas y eliminación automática de privilegios cuando las actividades se completan o el tiempo asignado ha expirado.
  • Reemplazo de credenciales codificadas de forma rígida, como nombres de usuario y contraseñas en scripts con interfaces de programación de aplicaciones (API) que permiten recuperar las credenciales de los almacenes según sea necesario.
  • Administración automática de credenciales de cuenta de servicio

Crear cuentas sin privilegios para administrar cuentas con privilegios

Uno de los desafíos para administrar cuentas con privilegios es que, de forma predeterminada, las cuentas que pueden administrar cuentas y grupos con privilegios y grupos tienen privilegios y cuentas protegidas. Si implementa las soluciones de RBAC y PIM adecuadas para la instalación de Active Directory, las soluciones pueden incluir enfoques que le permiten despoblar eficazmente la pertenencia de los grupos con más privilegios en el directorio, rellenando los grupos solo temporalmente y cuando sea necesario.

Sin embargo, si implementa RBAC nativo y PIM, debe considerar la posibilidad de crear cuentas que no tengan privilegios y con la única función de rellenar y despopular grupos con privilegios en Active Directory cuando sea necesario. Apéndice I: La creación de cuentas de administración para cuentas protegidas y grupos en Active Directory proporciona instrucciones paso a paso que puede usar para crear cuentas con este fin.

Implementación de controles de autenticación sólidos

Law Number Six: hay alguien ahí afuera tratando de adivinar sus contraseñas. - 10 Leyes inmutables de administración de seguridad

Los ataques pass-the-hash y otros ataques de robo de credenciales no son específicos de Windows sistemas operativos, ni son nuevos. El primer ataque pass-the-hash se creó en 1997. Históricamente, sin embargo, estos ataques requerían herramientas personalizadas, eran aciertos o errores en su éxito, y requerían que los atacantes tuvieran un grado relativamente alto de habilidad. La introducción de herramientas disponibles de forma gratuita y fácil de usar que extrae de forma nativa las credenciales ha provocado un aumento exponencial del número y el éxito de los ataques de robo de credenciales en los últimos años. Sin embargo, los ataques de robo de credenciales no son los únicos mecanismos por los que las credenciales están dirigidas y comprometidas.

Aunque debe implementar controles para ayudarle a protegerse frente a ataques de robo de credenciales, también debe identificar las cuentas de su entorno que probablemente sean objetivo de los atacantes e implementar controles de autenticación sólidos para esas cuentas. Si sus cuentas con más privilegios usan autenticación de un solo factor, como nombres de usuario y contraseñas (ambos son "algo que sabe", que es un factor de autenticación), esas cuentas están protegidas de forma débil. Todo lo que un atacante necesita es conocer el nombre de usuario y el conocimiento de la contraseña asociada a la cuenta, y los ataques pass-the-hash no son necesarios para que el atacante pueda autenticarse como el usuario en cualquier sistema que acepte credenciales de factor único.

Aunque la implementación de la autenticación multifactor no le protege frente a ataques pass-the-hash, la implementación de la autenticación multifactor en combinación con los sistemas protegidos puede. Se proporciona más información sobre la implementación de sistemas protegidos en Implementación de hosts administrativos seguros y las opciones de autenticación se describen en las secciones siguientes.

Controles de autenticación generales

Si aún no ha implementado la autenticación multifactor, como tarjetas inteligentes, considere la posibilidad de hacerlo. Las tarjetas inteligentes implementan la protección forzada por hardware de las claves privadas en un par de claves pública-privada, lo que impide que se acceda a la clave privada de un usuario o se use a menos que el usuario presente el PIN, el código de acceso o el identificador biométrico adecuados a la tarjeta inteligente. Incluso si un registrador de pulsación de teclas intercepta el PIN o el código de acceso de un usuario en un equipo en peligro, para que un atacante reutilice el PIN o el código de acceso, la tarjeta también debe estar físicamente presente.

En los casos en los que las contraseñas complejas largas han demostrado ser difíciles de implementar debido a la resistencia del usuario, las tarjetas inteligentes proporcionan un mecanismo por el que los usuarios pueden implementar PIN relativamente simples o códigos de acceso sin que las credenciales sean susceptibles a ataques de fuerza bruta o de tabla arco iris. Los PIN de tarjeta inteligente no se almacenan en Active Directory ni en bases de datos SAM locales, aunque los hashes de credenciales pueden almacenarse en memoria protegida de LSASS en equipos en los que se han usado tarjetas inteligentes para la autenticación.

Controles adicionales para cuentas VIP

Otra ventaja de implementar tarjetas inteligentes u otros mecanismos de autenticación basados en certificados es la capacidad de aprovechar La garantía del mecanismo de autenticación para proteger los datos confidenciales a los usuarios vip. Authentication Mechanism Assurance está disponible en dominios en los que el nivel funcional está establecido en Windows Server 2012 o Windows Server 2008 R2. Cuando está habilitada, Authentication Mechanism Assurance agrega una pertenencia de grupo global designada por el administrador al token Kerberos de un usuario cuando las credenciales del usuario se autentican durante el inicio de sesión mediante un método de inicio de sesión basado en certificados.

Esto permite a los administradores de recursos controlar el acceso a los recursos, como archivos, carpetas e impresoras, en función de si el usuario inicia sesión con un método de inicio de sesión basado en certificados, además del tipo de certificado usado. Por ejemplo, cuando un usuario inicia sesión con una tarjeta inteligente, el acceso del usuario a los recursos de la red se puede especificar como diferente de lo que es el acceso cuando el usuario no usa una tarjeta inteligente (es decir, cuando el usuario inicia sesión escribiendo un nombre de usuario y una contraseña). Para obtener más información acerca de Authentication Mechanism Assurance, consulte authentication Mechanism Assurance for AD DS in Windows Server 2008 R2 Step-by-Step Guide( Guía paso a paso sobre el mecanismo de autenticación para AD DS en Windows Server 2008 R2.

Configuración de la autenticación de cuenta con privilegios

En Active Directory para todas las cuentas administrativas, habilite la tarjeta inteligente para el atributo de inicio de sesión interactivo y audite los cambios en (como mínimo), cualquiera de los atributos de la pestaña Cuenta de la cuenta (por ejemplo, cn, name, sAMAccountName, userPrincipalName y userAccountControl) objetos de usuario administrativos.

Aunque establecer la tarjeta inteligente Requerir inicio de sesión interactivo en cuentas restablece la contraseña de la cuenta a un valor aleatorio de 120 caracteres y requiere tarjetas inteligentes para inicios de sesión interactivos, el atributo todavía se puede sobrescribir por los usuarios con permisos que les permitan cambiar contraseñas en las cuentas, y las cuentas se pueden usar para establecer inicios de sesión no interactivos solo con nombre de usuario y contraseña.

En otros casos, dependiendo de la configuración de cuentas en Active Directory y la configuración del certificado en Servicios de certificados de Active Directory (AD CS) o en una PKI de terceros, los atributos de nombre principal de usuario (UPN) para las cuentas administrativas o VIP se pueden destinar a un tipo específico de ataque, como se describe aquí.

Secuestro de UPN para suplantación de certificado

Aunque una explicación exhaustiva de los ataques contra infraestructuras de clave pública (PKIs) está fuera del ámbito de este documento, los ataques contra los PKIs públicos y privados han aumentado exponencialmente desde 2008. Las infracciones de las PKIs públicas se han publicizado ampliamente, pero los ataques contra la PKI interna de una organización pueden ser incluso más prolíficos. Un ataque de este tipo aprovecha Active Directory y los certificados para permitir que un atacante oculte las credenciales de otras cuentas de una manera que pueda ser difícil de detectar.

Cuando se presenta un certificado para la autenticación en un sistema unido a un dominio, el contenido del atributo Subject o subject Alternative Name (SAN) del certificado se usa para asignar el certificado a un objeto de usuario en Active Directory. Según el tipo de certificado y cómo se construye, el atributo Subject de un certificado normalmente contiene el nombre común (CN) de un usuario, como se muestra en la captura de pantalla siguiente.

Screenshot that shows the Subject attribute in a certificate typically contains a user's common name.

De forma predeterminada, Active Directory construye el CN de un usuario mediante la concatenación del nombre de la cuenta + " "+ apellidos. Sin embargo, los componentes CN de los objetos de usuario de Active Directory no son obligatorios ni se garantiza que sean únicos, y mover una cuenta de usuario a otra ubicación en el directorio cambia el nombre distintivo de la cuenta (DN), que es la ruta de acceso completa al objeto en el directorio, como se muestra en el panel inferior de la captura de pantalla anterior.

Dado que no se garantiza que los nombres de firmante del certificado sean estáticos o únicos, el contenido del nombre alternativo del firmante se suele usar para localizar el objeto de usuario en Active Directory. El atributo SAN para los certificados emitidos a los usuarios de entidades de certificación empresariales (CA integradas en Active Directory) normalmente contiene el UPN o la dirección de correo electrónico del usuario. Dado que se garantiza que los UPN son únicos en un bosque de AD DS, la localización de un objeto de usuario por UPN se realiza normalmente como parte de la autenticación, con o sin certificados implicados en el proceso de autenticación.

Los atacantes pueden aprovechar el uso de UPN en atributos SAN en certificados de autenticación para obtener certificados fraudulentos. Si un atacante ha puesto en peligro una cuenta que tiene la capacidad de leer y escribir UPN en objetos de usuario, el ataque se implementa de la siguiente manera:

El atributo UPN en un objeto de usuario (como un usuario VIP) se cambia temporalmente a otro valor. El atributo de nombre de cuenta SAM y CN también se pueden cambiar en este momento, aunque normalmente esto no es necesario por los motivos descritos anteriormente.

Cuando se ha cambiado el atributo UPN de la cuenta de destino, se cambia una cuenta de usuario obsoleta, habilitada o un atributo UPN de la cuenta de usuario recién creada al valor que se asignó originalmente a la cuenta de destino. Las cuentas de usuario obsoletas y habilitadas son cuentas que no han iniciado sesión durante largos períodos de tiempo, pero que no se han deshabilitado. Están dirigidos por atacantes que pretenden "ocultarse a simple vista" por los siguientes motivos:

  1. Dado que la cuenta está habilitada, pero no se ha usado recientemente, es poco probable que el uso de la cuenta desencadene alertas de la manera en que se puede habilitar una cuenta de usuario deshabilitada.
  2. El uso de una cuenta existente no requiere la creación de una nueva cuenta de usuario que el personal administrativo pueda observar.
  3. Las cuentas de usuario obsoletas que aún están habilitadas suelen ser miembros de varios grupos de seguridad y se les concede acceso a los recursos de la red, lo que simplifica el acceso y la "fusión" a un rellenado de usuarios existente.

La cuenta de usuario en la que se ha configurado el UPN de destino ahora se usa para solicitar uno o varios certificados de Servicios de certificados de Active Directory.

Cuando se han obtenido certificados para la cuenta del atacante, los UPN de la cuenta "nueva" y la cuenta de destino se devuelven a sus valores originales.

El atacante ahora tiene uno o varios certificados que se pueden presentar para la autenticación en recursos y aplicaciones como si el usuario fuera el usuario VIP cuya cuenta se modificó temporalmente. Aunque una explicación completa de todas las formas en que los atacantes pueden dirigirse a certificados y PKI está fuera del ámbito de este documento, este mecanismo de ataque se proporciona para ilustrar por qué debe supervisar las cuentas con privilegios y VIP en AD DS para los cambios, especialmente para los cambios en cualquiera de los atributos de la pestaña Cuenta de la cuenta (por ejemplo, cn, name, sAMAccountName, userPrincipalName y userAccountControl). Además de supervisar las cuentas, debe restringir quién puede modificar las cuentas a un conjunto de usuarios administrativos lo más pequeño posible. Del mismo modo, las cuentas de los usuarios administrativos deben protegerse y supervisarse para detectar cambios no autorizados.