WindowServer

Este es un tema que se repite, y no desde hace poco tiempo, con bastante frecuencia, vamos a tratar de que no suceda, y si sucediera cómo solucionarlo

¿Quién no ha recibido nunca cuando va a iniciar sesión, un mensaje que alerta que se ha roto la relación de confianza de la máquina con el Dominio?

Lo importante en realidad es que no suceda, así que primero vamos a conversar un poco sobre el tema

En un ambiente de Dominio Active Directory las máquinas, durante su arranque, se autentican/autentifican en el Dominio, casi como lo hace cualquier cuenta de usuario

Cada máquina usa como nombre de cuenta su propio nombre con el agregado de un signo “$” al final. Por ejemplo, una máquina de nombre SRV1, utiliza la cuenta SRV1$

El por qué usa este caracter diferenciador de cualquier otra cuenta, es una historia muy larga, pero los viejos Dominios con Windows NT no diferenciaban en su estructura (hoy diríamos Esquema) un usuario de una máquina
Así que este carácter era lo que usaba el sistema operativo para diferenciarlos

Esta contraseña de la cuenta de máquina periódicamente se cambia. A lo largo de las diferentes versiones de sistema operativo cambió varias veces, pero actualmente es de 30 días. O sea que cada ese período la máquina cambia su contraseña. Si puede “avisarle” al Controlador de Dominio entonces mejor, pero si no puede, también lo hace

Inclusive a partir de Windows Server 2008, para ayudar a paliar estos problemas, los Controladores de Dominio, no sólo mantienen la última versión de la contraseña, sino también la anterior

Pero de todas formas, a veces sucede el problema

Primero enumeremos algunas de las condiciones que pueden provocarla:

• Máquinas que hace más de 30 días estuvieron sin conectividad con un Controlador de Dominio de su Dominio. Puede ser porque estuvieron apagadas o fuera de la red
• Máquinas recuperadas desde una copia de seguridad (Backup) antiguo
• Máquinas con sistema operativo de escritorio recuperadas desde un punto de restauración
• Máquinas virtuales recuperadas desde un punto de restauración (“Snapshot”) del sistema de virtualización
• Máquinas con dirección de DNS incorrecta. Por ejemplo por no estar configuradas para usar *solamente* el o los servidores DNS que resuelven el Dominio. Nunca, nunca, nunca los del ISP o el "Router"
• Máquinas clonadas sin el correspondiente proceso de SYSPREP

Y seguramente podríamos comentar aún más

¿Y cómo lo soluciona la mayoría? Bueno la mayoría usa el procedimiento que yo llamo “cavernícola” (“Nearthental Process”) 🙂 que consiste en:

1. Sacar la máquina del Dominio a Grupo de Trabajo
2. Reiniciar
3. Borrar la cuenta de máquina en el Dominio
4. Volver a unir la máquina al Dominio
5. Reinciar

Este, el más común, es el peor de todos los procedimientos, porque además del tiempo que lleva (2 reinicios) cuando se une nuevamente la máquina al Dominio se le asigna un nuevo SID (SID = “Security ID”)

Si entrar en detalles, el SID es análogo a un número de documento. El sistema muestra en la interfaz gráfica nombres de máquinas, usuarios y grupos, pero internamente utiliza sus correspondientes SIDs
Análogamente a un número de documento de persona, nunca ese número es reutilizado

Como consecuencia, la máquina, que es la misma, para el Domino es otra totalmente diferente, aunque se llame igual y esté configurada exactamente igual, y sea el mismo hardware, y sea …

Y por lo tanto si se están ejecutando servicios con la cuenta de máquina, o se ha agregado la máquina a algún grupo para darle ciertos privilegios, todos eso se pierde irremediablemente

Si quieren, algo un procedimiento un poco “menos malo” sería igual al anterior pero, en lugar de borrar la cuenta de máquina, darle con botón derecho a la cuenta de máquina y seleccionar “Reset account”
La única ventaja de este método, es que se mantiene el SID, pero es tedioso como el anterior

Si uno busca un poco en la Web hay muchísimas soluciones del más variado tipo: scripts VBS, NLTEST, NETDOM, Powershell, y seguramente más

Los scripts me parecen una solución complicada, salvo que lo tuvieran que ejecutar muy seguido, lo cual implicaría otro problema. Ver las causas posibles al principio de la nota, y qué hay que solucionar

El comando NLTEST estaba en versiones anteriores del sistema operativo, pero en Windows Server 2012 ya no está

Powershell, sinceramente no he podido probarlo pero aparentemente se solucionaría con “Test-ComputerSecureChannel -Repair”
[Agregado] Probado y también funciona sin reiniciar igual que NETDOM

Y todo esto, porque encontré que con NETDOM lo solucionaba muy fácilmente, y muy importante no había que reinciar

Una acotación a tener en cuenta, Microsoft tiene una “mala costumbre” a veces los modificadores de los comandos, cambian o directamente desaparecen. Lo que estoy mostrando es sobre un Windows Server 2012 R2. Si tiene otra versión, y la sintaxis le da error, revise la ayuda con "NETDOM /?"

Me puse con las máquinas de mi laboratorio VMware de pruebas, y recuperé dos máquinas virtuales con “Snapshots” lo más alejados posible en el tiempo para hacer que se produzca el problema. Fueron un Controlador de Dominio (DC1) y un servidor miembro (SRV1)

Creé un usuario nuevo en el Dominio, para asegurarme que no se usaran “cached credentials”, y traté de inciar sesión en SRV1. Acá está el resultado

Entonces inicié sesión con un administrador local del servidor

Inicié una línea de comandos (CMD.EXE) ejecutándola como administrador, y en la misma usé NETDOM con la siguiente sintaxis:

NETDOM RESETPWD /s:<NombreDC> /UserD:<DOMINIO\Administrador> /PasswordD:<Contraseña>

Y ahora lo interesante. Sin reiniciar el servidor pude inciar sesión con el usuario nuevo creado al principio, ya está solucionado el problema, sin cambio de SID y muy rápidamente