Fallou a confianza do dominio tras un mes sen conexión? Comprobe primeiro

Un portátil pasa seis semanas fóra da VPN, volve, e o usuario non pode iniciar sesión cunha conta de dominio. O erro menciona unha relación de confianza, así que alguén restablece a conta de equipo ou forza o usuario ao túnel completo, e o problema parece desaparecer. Ningunha das dúas accións demostrou que estaba roto. Un membro de Windows pode permanecer sen conexión moito máis alá do intervalo habitual de contrasinal da máquina sen perder a confianza automaticamente, así que a primeira tarefa é separar un fallo de accesibilidade dunha discrepancia real do segredo.

O erro parece de confianza, pero tres estados parécense

Un usuario pode iniciar sesión con información de dominio na caché, a estación de traballo pode non localizar ningún controlador de dominio, ou o membro e o dominio poden discrepar de verdade sobre a conta de equipo. Só o terceiro é unha relación de confianza rota en sentido estrito.

O estado da replicación de AD é unha cuarta observación, e non trata en absoluto desta estación de traballo. Describe o acordo entre controladores de dominio, e un panel de replicación saudable non demostra que o segredo local desta máquina coincida coa súa conta de equipo.

O coñecido valor predeterminado de 30 días é unha política de cambio, non un prazo de caducidade sen conexión. A explicación de Microsoft sobre o contrasinal da conta de equipo describe un proceso de cambio coordinado, e unha organización pode configurar un intervalo distinto.

Unha icona de VPN non demostra nada sobre o canal seguro

A conectividade debe ser o bastante boa para alcanzar os servizos de dominio antes de que calquera proba signifique algo. Iso significa o solucionador DNS de dominio previsto, un controlador localizable, servizos de autenticación accesibles e un reloxo o bastante próximo para Kerberos.

O túnel completo pode ser un deseño perfectamente válido aquí. Pasar ao túnel dividido non é un requisito previo para unha relación de dominio saudable, e tratalo como tal converte un diagnóstico nun cambio de arquitectura. Comprobe que controlador escolle realmente a estación de traballo e conserve ese nome xunto ao erro.

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

Anote o servidor DNS, o controlador resolto e o texto exacto do erro. Un cliente VPN que informa de que está conectado di que o túnel existe, non que a ruta ao dominio funcione. Un controlador que responde no porto Kerberos pero non no porto de directorio é un achado de devasas, non un achado de confianza.

Probe o membro antes de reparalo

Nun membro de dominio Windows autorizado, Test-ComputerSecureChannel -Verbose é unha comprobación de só lectura do canal entre a máquina e o dominio. Execútea no contexto da máquina que investiga, non desde un controlador de dominio, que ten outro papel e outras regras de recuperación. Capture a saída e o estado de saída en lugar da palabra pasa ou falla. Se falta o cmdlet nesa compilación, o módulo é un problema aparte.

O resultado segue necesitando contexto. Se a máquina non pode alcanzar ou autenticarse ante o controlador elixido, unha proba fallida non é proba independente de que un contrasinal sen conexión caducase. Conserve o erro real e o controlador utilizado, e repita a proba cando a ruta sexa coñecida como boa.

Correlacione os eventos de Netlogon no membro e no controlador correspondente arredor do incidente. Conserve o nome da máquina, o enderezo de orixe, a hora e calquera evidencia de cambio de conta. Un inicio de sesión correcto doutro usuario, ou un panel de controlador saudable, non poden substituír o intercambio desta máquina.

Repare só a relación que demostrou

Unha vez que a conectividade é estable e un administrador confirmou que unha reparación é adecuada, o modo -Repair do cmdlet con credenciais autorizadas é unha operación admitida para unha estación de traballo membro. Cambia a relación, e non é outra proba de só lectura.

Teña dispoñible unha conta local de recuperación aprobada e unha ruta de administración antes do cambio. Os controladores de dominio teñen outro papel de recuperación e este procedemento non debe tratalos como estacións de traballo ordinarias. Use o fluxo de recuperación da organización en lugar de executar varias ferramentas de restablecemento en secuencia e esperar que unha sexa a correcta.

Tras a reparación, verifique unha proba nova do canal seguro e a operación de dominio orixinal. Conserve os perfís de usuario e o estado das aplicacións, e non faga que quitar e volver unir sexa a primeira acción sen explicación.

Que comprobar cando o fallo volve

Se o fallo volve, mire a reversión, a identidade duplicada e o momento dos cambios de conta en lugar de restablecer a mesma conta outra vez. Unha imaxe restaurada, unha instantánea, unha identidade de máquina clonada ou un restablecemento de conta de equipo feito noutro lugar merecen todos investigación.

Un restablecemento exitoso temporal é unha evidencia de recuperación útil, pero non é proba de que unha VPN intermitente causase a discrepancia orixinal. A seguinte aparición é a que lle di se a causa chegou a eliminarse.

Escriba o controlador, o servidor DNS e a saída da proba no ticket. Ese rexistro é o que distingue un fallo de confianza real dun portátil que simplemente non puido atopar o dominio.