Ha fallat la confiança del domini després d’un mes fora de línia? Comproveu primer

Un portàtil passa sis setmanes fora de la VPN, torna, i l’usuari no pot iniciar sessió amb un compte de domini. L’error esmenta una relació de confiança, així que algú restableix el compte d’equip, o força l’usuari a fer servir el túnel complet, i el problema sembla desaparèixer. Cap de les dues accions no va demostrar què estava trencat. Un membre de Windows pot estar fora de línia molt més enllà de l’interval habitual de contrasenya de la màquina sense perdre automàticament la confiança, així que la primera feina és separar un error d’abast d’una discrepància real del secret.

L’error sembla de confiança, però tres estats s’assemblen

Un usuari pot iniciar sessió amb informació de domini en memòria cau, l’estació de treball pot no trobar cap controlador de domini, o el membre i el domini poden discrepar de debò sobre el compte d’equip. Només el tercer és una relació de confiança trencada en sentit estricte.

La salut de la replicació d’AD és una quarta observació, i no tracta gens d’aquesta estació de treball. Descriu l’acord entre controladors de domini, i un tauler de replicació saludable no demostra que el secret local d’aquesta màquina coincideixi amb el seu compte d’equip.

El conegut valor per defecte de 30 dies és una política de canvi, no un termini de caducitat fora de línia. L’explicació de Microsoft sobre la contrasenya del compte d’equip descriu un procés de canvi coordinat, i una organització pot configurar un interval diferent.

Una icona de VPN no demostra res sobre el canal segur

La connectivitat ha de ser prou bona per arribar als serveis de domini abans que qualsevol prova signifiqui res. Això vol dir el resolutor DNS de domini previst, un controlador localitzable, serveis d’autenticació accessibles i un rellotge prou a prop per a Kerberos.

El túnel complet pot ser un disseny perfectament vàlid aquí. Canviar a túnel dividit no és cap prerequisit per a una relació de domini saludable, i tractar-lo com a tal converteix un diagnòstic en un canvi d’arquitectura. Comproveu quin controlador tria realment l’estació de treball i conserveu aquest nom amb l’error.

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

Anoteu el servidor DNS, el controlador resolt i el text exacte de l’error. Un client VPN que informa que està connectat us diu que el túnel existeix, no que el camí al domini funcioni. Un controlador que respon al port Kerberos però no al port de directori és una troballa de tallafoc, no una troballa de confiança.

Proveu el membre abans de reparar-lo

En un membre de domini Windows autoritzat, Test-ComputerSecureChannel -Verbose és una comprovació només de lectura del canal entre la màquina i el domini. Executeu-la en el context de la màquina que investigueu, no des d’un controlador de domini, que té un paper i unes regles de recuperació diferents. Captureu la sortida i l’estat de sortida en lloc de la paraula passa o falla. Si el cmdlet falta en aquesta compilació, el mòdul és un problema a part.

El resultat encara necessita context. Si la màquina no pot arribar al controlador triat ni autenticar-s’hi, una prova fallida no és prova independent que una contrasenya fora de línia hagi caducat. Conserveu l’error real i el controlador utilitzat, i repetiu la prova quan el camí sigui conegut com a bo.

Correlacioneu els esdeveniments de Netlogon al membre i al controlador pertinent al voltant de l’incident. Conserveu el nom de la màquina, l’adreça d’origen, l’hora i qualsevol evidència de canvi de compte. Un inici de sessió correcte d’un altre usuari, o un tauler de controlador saludable, no poden substituir l’intercanvi d’aquesta màquina.

Repareu només la relació que heu demostrat

Un cop la connectivitat és estable i un administrador ha confirmat que una reparació és adequada, el mode -Repair del cmdlet amb credencials autoritzades és una operació compatible per a una estació de treball membre. Canvia la relació, i no és una altra prova només de lectura.

Tingueu un compte local de recuperació aprovat i un camí de gestió disponibles abans del canvi. Els controladors de domini tenen un paper de recuperació diferent i aquest procediment no els ha de tractar com a estacions de treball ordinàries. Utilitzeu el flux de recuperació de l’organització en lloc d’executar diverses eines de restabliment en seqüència i esperar que una sigui la correcta.

Després de la reparació, verifiqueu una prova nova del canal segur i l’operació de domini original. Conserveu els perfils d’usuari i l’estat de les aplicacions, i no feu que treure i tornar a unir sigui la primera acció sense explicació.

Què cal comprovar quan la fallada torna

Si la fallada torna, mireu la reversió, la identitat duplicada i el moment dels canvis de compte en lloc de restablir el mateix compte una altra vegada. Una imatge restaurada, una instantània, una identitat de màquina clonada o un restabliment de compte d’equip fet en un altre lloc mereixen tots investigació.

Un restabliment reeixit temporal és una evidència de recuperació útil, però no és prova que una VPN intermitent causés la discrepància original. La propera ocurrència és la que us diu si la causa es va arribar a eliminar.

Escriviu el controlador, el servidor DNS i la sortida de la prova al tiquet. Aquest registre és el que distingeix una fallada de confiança real d’un portàtil que simplement no va poder trobar el domini.