El error en la relación de confianza entre la estación de trabajo y el dominio principal es un problema común en entornos Windows que puede causar desconexiones y afectar la productividad. En esta guía, te mostramos cómo identificar las causas y solucionarlo paso a paso para que tu red vuelva a funcionar correctamente
Los primeros años que me encontré con este error, seguía los pasos que tantas páginas indican como solución a este problema, y que por supuesto funcionan al 100% (por ejemplo, esta página de proyectoa.com), que consiste en sacar el equipo del dominio y volverlo a unir.
Pero, al realizar estos pasos, aparece el momento más traumático para mí. El usuario que utiliza el equipo indica que no tiene ningún documento en el escritorio, ni en Mis Documentos. Y además nos dice que ya no tiene la configuración de Outlook con su cuenta…
Esto ocurre porque el SID que se asigna al volver a unir la máquina al dominio es distinto al que tenía, y para el controlador de dominio es como un equipo nuevo. Por esta razón, al iniciar sesión un usuario habitual del equipo, crea un perfil completamente nuevo.
Finalmente, he encontrado la solución al problema!
A través de esta página encontré el comando de como devolver la relación del equipo. Es el siguiente y se debe ejecutar en el equipo cliente:
NETDOM RESETPWD /s:<NombreDC> /UserD:<DOMINIO\Administrador> /PasswordD:<Contraseña>Aún así, detecté que no me funcionaba debido que al ejecutar el comando, no encontraba el ejecutable NETDOM.
No te preocupes, también te voy a contar como instalarlo sin tener que buscar en Google como tuve que hacer yo.
El ejecutable NETDOM está incluido en las «Herramientas de administración remota del servidor para Windows 10» que se puede descargar desde aquí.
Una vez instalado en el equipo cliente, ejecuta el comando en este equipo y ya tendrás establecida la relación de confianza con el controlador de dominio.
Recuerda, que si tienes alguna sugerencia en algún tema concreto que pueda escribir un post, no dudes en indicármelo.
No hace falta, sencillamente sacandola a grupo de trabajo «TEMP» y sin reiniciar siquiera, metiendola de nuevo en el dominio, tienes la faena solucionada. Restablece la confianza en el dominio.
El programador de Microsoft le falto un cafe de mas para este bug temporal.
Hola Xavier,
Si no recuerdo mal, una vez al menos te pide reiniciar.
Aún así, haciendo lo que indicas, estas creando un SID distinto del equipo, porque estás creando un equipo nuevo en el dominio.
Igualmente, muchas gracias por comentar mi artículo!!
Buenas tardes, tengo el mismo problema cuando trato de autenticar usuarios administradores para realizar una instalacion, en maquinas que estan fuera de la red, en casa de los usuarios. Al agregar el password del usuario local, o de los usuarios de red administradores del dominio, ninguno de puede autenticar, y al mrevisar el modulo de usuarios y grupos en la maquina local, no aparecer los nosmbres de usuario sino una cadena de caracteres S-x-x-x…xxxx.
El usuario local es gestionado por LAPS, pero al presentarse el error, ese password no se actualizo, y la maquina no puede ser intervenida. Este procedimiento del NETDOM aplica para este escenario? Muchas gracias
La verdad que me faltan datos para asegurarte si sería o no.
De lo que yo he visto, es que los equipos que están unidos al dominio pero no pueden validarse en el AD (siempre hablo de local no en la nube) lo que aparece es que no encuentra un servidor para iniciar sesión.
En tu caso, lo que haría, sería con un hirens boot habilitar un usuario local administrador para arrancar una sesión y hacer los pasos del post, pero siempre que el equipo llegue al AD para hablarse