Fiducia del dominio persa dopo un mese offline? Controllate prima

Un portatile resta sei settimane fuori dalla VPN, torna, e l’utente non riesce ad accedere con un account di dominio. L’errore menziona una relazione di trust, così qualcuno reimposta l’account computer, oppure forza l’utente sul tunnel completo, e il problema sembra sparire. Nessuna delle due azioni ha dimostrato cosa fosse rotto. Un membro Windows può restare offline ben oltre il normale intervallo della password macchina senza perdere automaticamente la fiducia, quindi il primo compito è separare un guasto di raggiungibilità da una vera discrepanza del segreto.

L’errore sembra di fiducia, ma tre stati si somigliano

Un utente può accedere con informazioni di dominio memorizzate nella cache, la stazione di lavoro può non trovare un controller di dominio, oppure il membro e il dominio possono davvero non essere d’accordo sull’account computer. Solo il terzo è una relazione di trust rotta in senso stretto.

Lo stato della replica AD è una quarta osservazione, e non riguarda affatto questa stazione di lavoro. Descrive l’accordo tra controller di dominio, e una dashboard di replica sana non dimostra che il segreto locale di questa macchina corrisponda al suo account computer.

Il noto valore predefinito di 30 giorni è una politica di modifica, non una scadenza offline. La spiegazione di Microsoft sulla password dell’account macchina descrive un processo di modifica coordinato, e un’organizzazione può configurare un intervallo diverso.

Un’icona VPN non dimostra nulla sul canale sicuro

La connettività deve essere abbastanza buona da raggiungere i servizi di dominio prima che qualsiasi test significhi qualcosa. Questo significa il resolver DNS di dominio previsto, un controller individuabile, servizi di autenticazione raggiungibili e un orologio abbastanza vicino per Kerberos.

Il tunnel completo può essere un progetto del tutto valido qui. Passare al tunnel diviso non è un prerequisito per una relazione di dominio sana, e trattarlo come tale trasforma una diagnosi in un cambio di architettura. Verificate quale controller sceglie davvero la stazione di lavoro, e conservate quel nome insieme all’errore.

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

Annotate il server DNS, il controller risolto e il testo esatto dell’errore. Un client VPN che dichiara di essere connesso vi dice che il tunnel esiste, non che il percorso verso il dominio funziona. Un controller che risponde sulla porta Kerberos ma non sulla porta della directory è un riscontro del firewall, non un riscontro di trust.

Provate il membro prima di ripararlo

Su un membro di dominio Windows autorizzato, Test-ComputerSecureChannel -Verbose è un controllo di sola lettura del canale tra la macchina e il dominio. Eseguitelo nel contesto della macchina che state esaminando, non da un controller di dominio, che ha un altro ruolo e altre regole di ripristino. Registrate l’output e lo stato di uscita invece della parola superato o fallito. Se il cmdlet manca in quella build, il modulo è un problema separato.

Il risultato necessita ancora di contesto. Se la macchina non riesce a raggiungere o ad autenticarsi sul controller scelto, un test fallito non è una prova indipendente che una password offline sia scaduta. Conservate l’errore reale e il controller usato, e ripetete il test quando il percorso è noto come buono.

Correlate gli eventi Netlogon sul membro e sul controller interessato intorno all’incidente. Conservate il nome della macchina, l’indirizzo di origine, l’ora e qualsiasi prova di modifica dell’account. Un accesso riuscito di un altro utente, o una dashboard del controller sana, non possono sostituire lo scambio di questa macchina.

Riparate solo la relazione che avete dimostrato

Una volta che la connettività è stabile e un amministratore ha confermato che una riparazione è appropriata, la modalità -Repair del cmdlet con credenziali autorizzate è un’operazione supportata per una stazione di lavoro membro. Cambia la relazione, e non è un altro test di sola lettura.

Tenete disponibili un account di ripristino locale approvato e un percorso di gestione prima della modifica. I controller di dominio hanno un altro ruolo di ripristino e questa procedura non deve trattarli come stazioni di lavoro ordinarie. Usate il flusso di ripristino dell’organizzazione invece di eseguire in sequenza diversi strumenti di reimpostazione sperando che uno sia quello giusto.

Dopo la riparazione, verificate un nuovo test del canale sicuro e l’operazione di dominio originale. Preservate i profili utente e lo stato delle applicazioni, e non fate della rimozione e riaggiunta la prima azione inspiegata.

Cosa controllare quando il guasto ritorna

Se il guasto ritorna, guardate al rollback, all’identità duplicata e al momento delle modifiche dell’account invece di reimpostare di nuovo lo stesso account. Un’immagine ripristinata, uno snapshot, un’identità macchina clonata o una reimpostazione dell’account computer eseguita altrove meritano tutti un’indagine.

Una reimpostazione riuscita temporanea è una prova di ripristino utile, ma non è prova che una VPN intermittente abbia causato la discrepanza originale. L’occorrenza successiva è quella che vi dirà se la causa è mai stata rimossa.

Scrivete il controller, il server DNS e l’output del test nel ticket. È quella registrazione che distingue un vero guasto di fiducia da un portatile che semplicemente non riusciva a trovare il dominio.