Contraseña de cuentas de computadora

Buenas noches,

1. ¿Cómo verifican que la contraseña de una máquina ha cambiado/no ha cambiado?
2. Es posible que el cambio de contraseña por parte de la máquina también haya sido desactivado...

Un buen artículo sobre el tema: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/machine-account-password-process/ba-p/396026

Atención, no hagan cambios en producción por impulso...
Primero hay que recolectar información para ver si todas las máquinas están afectadas o no, verificar la configuración existente, etc... así que exportar las cuentas de computadora con PowerShell ya permite ver la magnitud del fenómeno.
--> no hagan pruebas en un servidor WSUS... sería una pena arruinar una máquina que despliega actualizaciones.

--
Usar un "compactador" de registro sobre un "limpiador" de registro sería equivalente a enjuagarse la garganta con un sorbo de Jack Daniels después de tragarse una pinta de aceite de serpiente...

Buenas noches,

Esperaba que fueras tú quien respondiera, pero no tan rápido :). Intenté contactarte por mensaje privado, pero sin éxito (tengo varias preguntas que hacerte sobre el AD). Para poder afirmar que la mayoría de los servidores tienen una contraseña sin cambios desde hace más de 15 años, miro el atributo pwdlastset de mis cuentas de máquina (módulo Usuarios y equipos de Active Directory).

Este año implementé una política de contraseña para los usuarios, ninguno la cambiaba y su contraseña nunca superaba los 5 caracteres. He realizado una buena cantidad de cambios en este SI y antes de cada cambio hago una investigación muy amplia.

Tu artículo es muy interesante para entender todos los parámetros que se encuentran en: Configuración del equipo\Plantillas administrativas\Sistema\Netlogon, pero también los diferentes escenarios de solicitud de cambio de contraseña de cuentas de máquina.

Efectivamente, en todos los servidores, el cambio de contraseña de la cuenta de máquina está desactivado. Gracias a tu artículo, aprendo que la política de dominio predeterminada no afecta a las contraseñas de las cuentas de máquina; he verificado las GPO afectadas a mi wsus (módulo de gestión de políticas de grupo) y ninguna afecta a este servidor, por lo que la desactivación debe haberse realizado manualmente.

Tengo experiencia trabajando en nuestro wsus porque fui yo quien lo implementó este año, sé cómo retroceder si es necesario. Antes de su implementación teníamos puestos con W10 en versión 1809.

Después de cambiar este parámetro en el wsus, el atributo pwdlastset de este servidor tenía la fecha del día. Sin embargo, aprendí que no hay cuenta de administrador local en los servidores, solo la cuenta Administrador predeterminada de Windows. Y la contraseña no es idéntica en los servidores y, de hecho, es imposible tenerla para mi wsus, por lo que me llevará tiempo darme cuenta de todos los problemas.

Mi pregunta era saber si existen razones bien conocidas para el problema de renovación de contraseña de las cuentas de máquina, pero aparentemente no. Pero debo asegurarme de que cada servidor pueda ser alcanzado a través de una cuenta local con derechos de administrador para no quedarme bloqueado ante un "Contraseña incorrecta"

Hola,

No miro mis mensajes privados; y es preferible que los intercambios sean abiertos a todos.

La búsqueda del pwdlastset es el método correcto.

-
He implementado una política de contraseñas este año para los usuarios, ninguno la cambiaba y su contraseña nunca superaba los 5 caracteres

A. Estrategia de contraseña: maxpasswordlenght
Es algo muy positivo. Bueno, no vamos a engañarnos, es difícil para los usuarios cambiar sus contraseñas con demasiada frecuencia...
Generalmente aconsejo un mínimo de 15 caracteres; sin embargo, no es posible superar los 14 a través de la GPMC... desde w2016 se puede hacer a través de GPMC más allá de 14, pero los parámetros no se aplican en el dominio (puede haber un parche, pero no he indagado más).
Es necesario pasar por PSO dirigidos a usuarios (o grupos, de hecho) para indicar estrategias de contraseñas de más de 14 caracteres.

¿Por qué 15? La manera en que se gestiona el hash de contraseñas por Lanman (LM/NTLM): se basa en 2 cadenas de 7 caracteres o 14 caracteres; y es "más" vulnerable a herramientas de cracking.
Al superar 14 (por lo tanto, mínimo 15), el hash de la contraseña se coloca en NULL (pero la contraseña no es null por sí misma...), lo que protege contra ataques de fuerza bruta en los hashes.

https://community.broadcom.com/symantecenterprise/communities/community-home/librarydocuments/viewdocument?DocumentKey=762c7cbd-bc00-44b1-8d35-cf42bc7fe2e9&CommunityKey=1ecf5f55-9545-44d6-b0f4-4e4a7f5f5e68&tab=librarydocuments

Bueno, después hay que validar y aceptar eso... no es simple.

B. Estrategia de contraseña: maxpasswordAge
Hagan rotaciones más espaciadas (tipo 3 a 6 meses) en la estrategia de contraseña (maxPasswordAge).
Esto evita que los usuarios anoten las contraseñas en un papel... y sobre todo que hagan contraseñas "previsibles", basadas en el mes del año, por ejemplo...
Es mejor una contraseña robusta no predecible cambiada cada 6 meses que una contraseña anotada en un papel y predecible, aunque se cambie cada mes...

-

Efectivamente en todos los servidores el cambio de contraseña de la cuenta de máquina está desactivado
Hay que asegurarse de que las máquinas están bien almacenadas en una OU (Unidad Organizativa) y no en el contenedor por defecto "computers".
Este contenedor "computers" no permite vincular GPOs... mientras que una OU está hecha para eso.
Por lo tanto, hay que aplicar una GPO en una OU que contenga las máquinas, y que permita reactivar la rotación de contraseñas de las cuentas de máquina. (así que hacer una sub-OU para probar en un lote de máquinas de preproducción, por ejemplo...)
Después conocer la causa, si es histórica... puede ser complicado entender esta elección técnica...
También hay que subir a la parte de aprovisionamiento/instalación de las máquinas y ver si este parámetro se inyecta desde el principio.

-

Sin embargo, he aprendido que no hay cuenta de admin local en los servidores, únicamente la cuenta Administrador por defecto de_windows. Y la contraseña no es idéntica en los servidores

Cualquier máquina Windows miembro de un dominio tiene cuentas locales (base SAM) que le son propias, incluida la cuenta "administrator"
Solo los controladores de dominio son un caso aparte, no tienen "cuentas locales", ya que almacenan las cuentas de dominio en la base NTDS.dit (y ya no tienen base SAM).

Es muy bueno que las cuentas de admin locales sean diferentes para cada máquina; eso evita movimientos laterales en caso de ataque.
Igualmente, quizás se haya implementado LAPS? si no, es algo a considerar, aunque hay que tener cuidado con los prerequisitos.

-

Mi pregunta era saber si existían razones bien conocidas para el problema de renovación de contraseña para las cuentas de máquina, pero aparentemente no. Pero debo asegurarme de que cada servidor pueda ser accesible a través de una cuenta local con derechos de admin para no quedarme bloqueado ante un "Contraseña incorrecta"

Hay problemas relacionados con la conectividad principalmente (firewall en alguna parte), a veces DNS, donde una máquina no puede resolver el nombre del dominio con DNS y por lo tanto no puede contactar con el dominio.

Hola,

No miro mis mensajes privados; y es preferible que los intercambios sean abiertos a todos.

Entiendo, son pequeñas preguntas técnicas que me quedan después de haberme documentado sobre objetos como el adminSDHolder, los protocolos NTFRS y FDSR para la replicación del sysvol, la cuenta krbtgt, etc., sobre todo cuando tengo fuentes que se contradicen. Me molesta un poco abrir un nuevo tema solo por pequeñas preguntas así.

-

Hay que pasar por PSO al dirigir a usuarios (o grupos, por cierto) para indicar estrategias de contraseñas más allá de 14 caracteres.

Eso es lo que he utilizado para la renovación de contraseñas de los usuarios. El número mínimo de caracteres es de 8 y una duración de 6 meses. Con el almacenamiento de las 3 últimas contraseñas para no repetir una demasiado antigua, y con las reglas de complejidad que propone el administrador de AD. Ya ha sido necesario ser combativo para imponer estas condiciones y no imagino a nuestros usuarios recordando una contraseña de 15 caracteres o más.

¿por qué 15? La forma en que se gestiona el hash de contraseñas por Lanman (LM/NTLM): se basa en 2 cadenas de 7 caracteres o 14 caracteres; y es "más" vulnerable para herramientas de cracking.
Al superar los 14 (es decir, mínimo 15), el hash de la contraseña se posiciona en NULL (pero la contraseña no es null por eso...), lo que protege contra ataques de fuerza bruta sobre los hashes.

Es muy interesante, pensaba que toda autenticación en un dominio o para acceder a un dominio se hacía a través del protocolo Kerberos. Pero al parecer es el protocolo NTLM el que se utiliza para los servicios en cuentas locales o acceso a una máquina a través de su IP.

-

Hay que asegurarse de que las máquinas estén bien almacenadas en una OU (Unidad Organizativa) y no en el contenedor por defecto "computers".
Este contenedor "computers" no permite enlazar GPOs... mientras que una OU está hecha para eso.

Todas lo están, y he utilizado el comando "redircmp" para que al llegar máquinas cliente o servidor al dominio, estas sean colocadas en una OU (para que se pueda aplicar una GPO).

-

Es una muy buena cosa que las cuentas de administrador locales sean diferentes para cada máquina; eso evita movimientos laterales en caso de ataque.
¿Tal vez se ha implementado LAPS? si no, es algo a considerar, atención a los requisitos previos sin embargo.

Unos meses después de mi llegada descubrí esta herramienta (LAPS) e hice investigaciones sobre ella para presentarla a mi departamento, pero fue rechazada a pesar de lo que podría haber aportado. También presenté el grupo de usuario protegido y propuse una estrategia de contraseñas más exigente para las cuentas de IT, pero sin éxito.

-

Solo los controladores de dominio son un caso aparte, no tienen "cuentas locales", ya que almacenan las cuentas de dominio en la base NTDS.dit (y ya no tienen base SAM).
...
Hay algunas problemáticas sobre la conectividad principalmente (firewall en alguna parte), a veces DNS, donde un equipo no puede resolver el nombre del dominio con DNS y por lo tanto no puede contactar con el dominio.

Eso es lo que me di cuenta ayer por la tarde, por lo que tendríamos que crear nosotros mismos cuentas de administrador locales para acceder a estos DC en caso de un problema de resolución de nombre de dominio.
Les agradezco por su respuesta y su seguimiento, como decía al principio de la discusión antes de cada cambio me tomo el tiempo necesario para informarme sobre lo que hago y los impactos que eso tendrá, aunque, por supuesto, no se puede prever todo.

Hola,

Me di cuenta de esto ayer por la tarde, por lo que deberíamos crear nosotros mismos cuentas de administrador locales para acceder a estos DC en caso de problemas de resolución de nombres de dominio.

No existe una cuenta local en un DC, ya que la base NTDS.dit reemplaza a la base SAM.

Un DC podrá autenticar sin problemas porque contiene la base de todos los cuentas del dominio.
Además, también contiene las particiones DNS, por lo que hay pocos riesgos de que pierda la resolución DNS.
(aunque hay ciertas restricciones de todos modos)

Sin embargo, estos casos pueden ocurrir, por ejemplo, si los servicios de AD no arrancan, o si el DNS está gestionado por una infraestructura externa y hay un problema de red o de resolución DNS - y no podríamos abrir una sesión local en el DC aislado...
¡Pero no te preocupes! Hay una cuenta llamada "DSRM" que se configura durante la instalación de cada DC.
Es esta cuenta la que hay que utilizar en caso de un gran problema iniciando en modo "Modo de Recuperación de Servicios de Directorio"...

--
Utilizar un "compactador" de registro encima de un "limpiador" de registro sería equivalente a enjuagarse la garganta con un trago de Jack Daniels después de tragar un litro de aceite de serpiente....

Le agradezco por todas estas precisiones.