¿Falló la confianza del dominio tras un mes sin conexión? Compruebe primero

Un portátil pasa seis semanas fuera de la VPN, vuelve, y el usuario no puede iniciar sesión con una cuenta de dominio. El error menciona una relación de confianza, así que alguien restablece la cuenta de equipo o fuerza al usuario al túnel completo, y el problema parece desaparecer. Ninguna de las dos acciones demostró qué estaba roto. Un miembro de Windows puede permanecer sin conexión mucho más allá del intervalo habitual de contraseña de la máquina sin perder la confianza automáticamente, así que la primera tarea es separar un fallo de accesibilidad de una discrepancia real del secreto.

El error parece de confianza, pero tres estados se parecen

Un usuario puede iniciar sesión con información de dominio en caché, la estación de trabajo puede no localizar ningún controlador de dominio, o el miembro y el dominio pueden discrepar de verdad sobre la cuenta de equipo. Solo el tercero es una relación de confianza rota en sentido estricto.

El estado de la replicación de AD es una cuarta observación, y no trata en absoluto de esta estación de trabajo. Describe el acuerdo entre controladores de dominio, y un panel de replicación saludable no demuestra que el secreto local de esta máquina coincida con su cuenta de equipo.

El conocido valor predeterminado de 30 días es una política de cambio, no un plazo de caducidad sin conexión. La explicación de Microsoft sobre la contraseña de la cuenta de equipo describe un proceso de cambio coordinado, y una organización puede configurar un intervalo distinto.

Un icono de VPN no demuestra nada sobre el canal seguro

La conectividad debe ser lo bastante buena para alcanzar los servicios de dominio antes de que cualquier prueba signifique algo. Eso significa el solucionador DNS de dominio previsto, un controlador localizable, servicios de autenticación accesibles y un reloj lo bastante cercano para Kerberos.

El túnel completo puede ser un diseño perfectamente válido aquí. Pasar al túnel dividido no es un requisito previo para una relación de dominio sana, y tratarlo como tal convierte un diagnóstico en un cambio de arquitectura. Compruebe qué controlador elige realmente la estación de trabajo y conserve ese nombre junto al error.

nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verbose

Anote el servidor DNS, el controlador resuelto y el texto exacto del error. Un cliente VPN que informa estar conectado le dice que el túnel existe, no que la ruta al dominio funcione. Un controlador que responde en el puerto Kerberos pero no en el puerto de directorio es un hallazgo de cortafuegos, no un hallazgo de confianza.

Pruebe el miembro antes de repararlo

En un miembro de dominio Windows autorizado, Test-ComputerSecureChannel -Verbose es una comprobación de solo lectura del canal entre la máquina y el dominio. Ejecútela en el contexto de la máquina que investiga, no desde un controlador de dominio, que tiene otro papel y otras reglas de recuperación. Capture la salida y el estado de salida en lugar de la palabra pasa o falla. Si falta el cmdlet en esa compilación, el módulo es un problema aparte.

El resultado sigue necesitando contexto. Si la máquina no puede alcanzar o autenticarse ante el controlador elegido, una prueba fallida no es prueba independiente de que una contraseña sin conexión haya caducado. Conserve el error real y el controlador utilizado, y repita la prueba cuando la ruta sea conocida como buena.

Correlacione los eventos de Netlogon en el miembro y en el controlador correspondiente en torno al incidente. Conserve el nombre de la máquina, la dirección de origen, la hora y cualquier evidencia de cambio de cuenta. Un inicio de sesión correcto de otro usuario, o un panel de controlador saludable, no pueden sustituir el intercambio de esta máquina.

Repare solo la relación que ha demostrado

Una vez que la conectividad es estable y un administrador ha confirmado que una reparación es adecuada, el modo -Repair del cmdlet con credenciales autorizadas es una operación admitida para una estación de trabajo miembro. Cambia la relación, y no es otra prueba de solo lectura.

Tenga disponible una cuenta local de recuperación aprobada y una ruta de administración antes del cambio. Los controladores de dominio tienen otro papel de recuperación y este procedimiento no debe tratarlos como estaciones de trabajo ordinarias. Use el flujo de recuperación de la organización en lugar de ejecutar varias herramientas de restablecimiento en secuencia y esperar que una sea la correcta.

Tras la reparación, verifique una prueba nueva del canal seguro y la operación de dominio original. Conserve los perfiles de usuario y el estado de las aplicaciones, y no haga que quitar y volver a unir sea la primera acción sin explicación.

Qué comprobar cuando el fallo vuelve

Si el fallo vuelve, mire la reversión, la identidad duplicada y el momento de los cambios de cuenta en lugar de restablecer la misma cuenta otra vez. Una imagen restaurada, una instantánea, una identidad de máquina clonada o un restablecimiento de cuenta de equipo hecho en otro lugar merecen todos investigación.

Un restablecimiento exitoso temporal es una evidencia de recuperación útil, pero no es prueba de que una VPN intermitente causara la discrepancia original. La siguiente aparición es la que le dice si la causa llegó a eliminarse.

Escriba el controlador, el servidor DNS y la salida de la prueba en el ticket. Ese registro es lo que distingue un fallo de confianza real de un portátil que simplemente no pudo encontrar el dominio.