Perché una VPN non sistema l’orologio di un portatile unito al dominio

Un lavoratore remoto collega la VPN, il tunnel sale e gli accessi iniziano a fallire con un errore di autenticazione che menziona l’ora. Niente del tunnel è rotto. Una VPN trasporta pacchetti tra reti; non dà a due macchine un orologio comune, e l’autenticazione di dominio, la validazione dei certificati e la correlazione degli audit dipendono tutte da orologi che concordano abbastanza. Ne derivano tre decisioni: chi possiede l’ora nel dominio, che cosa usa davvero il dispositivo e che cosa accade mentre il dispositivo è in roaming.

Un percorso non è un orologio

L’autenticazione Kerberos include dati sensibili al tempo e rifiuta le richieste fuori da una tolleranza configurata, che nei domini Windows è di cinque minuti per impostazione predefinita. I certificati hanno intervalli di validità, quindi un dispositivo con l’orologio sufficientemente avanti tratta un certificato valido come non ancora valido. I record di audit di più macchine si correlano solo se i loro orologi sono vicini, e questo conta la prima volta che una revisione di incidente chiede che cosa sia successo prima.

Quelle tre dipendenze sono indipendenti dal tunnel. Alzare una VPN cambia la raggiungibilità, e la raggiungibilità è ciò che permette a un dispositivo di trovare una fonte di tempo; non è la fonte.

Tenete il fuso orario visualizzato separato dall’orologio stesso. Due portatili che mostrano ore locali diverse possono essere perfettamente sincronizzati, e due che mostrano la stessa ora possono discordare di minuti se le impostazioni del fuso orario differiscono. Cambiare il fuso orario non è una riparazione di un orologio sbagliato, e spostare una data indietro per far funzionare un certificato scaduto rompe ogni altra verifica della macchina che dipende dal tempo.

Decidete chi possiede l’ora nel dominio

I membri Windows uniti al dominio seguono normalmente la gerarchia di tempo di Active Directory invece di interrogare un server pubblico ogni volta. Questa catena termina sull’emulatore PDC della radice della foresta, la cui referenza è la fonte autorevole dell’organizzazione.

Due condizioni decidono la referenza: se i criteri consentono un servizio di tempo esterno e se la rete riesce a raggiungere in modo affidabile una fonte interna approvata da ogni sito. Se entrambe sono poco chiare, la risposta pratica è mantenere intatta la gerarchia e riparare la raggiungibilità invece di puntare i client a un pool pubblico. Una terza condizione decide il percorso di guasto: che cosa deve fare il dispositivo quando nessuna delle due fonti è raggiungibile. Risolverlo in anticipo evita la toppa improvvisata di fissare un server pubblico su un solo portatile.

Questa scelta spetta agli amministratori del dominio e del tempo, non alla progettazione dell’accesso remoto. Un portatile che si configura come autorità di tempo affidabile è un’altra architettura, ed è raramente quella approvata dalla revisione di sicurezza.

Leggete che cosa usa davvero il dispositivo

Due comandi di sola lettura documentano lo stato attuale su un dispositivo Windows gestito, e vale la pena registrarli prima e dopo una modifica:

w32tm /query /source
w32tm /query /status
w32tm /query /configuration

Annotate l’origine selezionata, l’ultima sincronizzazione riuscita e lo stratum o l’identificatore di referenza accanto ai criteri di gestione del dispositivo. Una sincronizzazione manuale riuscita dimostra che il comando funziona, non che i criteri sopravvivano a un riavvio o a un cambio di ruolo.

Se l’origine mostra l’orologio CMOS locale, il dispositivo non si sincronizza affatto, il che di solito significa che il controller di dominio non era raggiungibile all’avvio o che il servizio di tempo è stato disabilitato dai criteri. Se mostra un server pubblico, qualcosa fuori dalla gerarchia del dominio sta vincendo, e questa è una questione di criteri, non di rete.

Decidete che cosa accade in roaming

Quando è disconnesso, un dispositivo si affida al proprio orologio locale e ai fornitori di tempo che riesce a raggiungere. I portatili derivano, e un dispositivo rimasto offline per settimane può derivare abbastanza da far fallire la prima richiesta Kerberos dopo la riconnessione.

Alla riconnessione il dispositivo ha bisogno dell’individuazione del dominio e del percorso previsto verso il servizio di tempo, non solo di una rotta verso una condivisione file. Verificatelo riavviando fuori dalla rete, collegando la VPN e rileggendo l’origine invece di supporre che la gerarchia si sia ristabilita da sola.

Le macchine virtuali aggiungono un altro fornitore. L’integrazione del tempo dell’hypervisor è una fonte legittima in molti progetti, ma il suo ruolo va scelto deliberatamente e coordinato con i criteri del dominio. Due fornitori in disaccordo producono un orologio che sembra stabile ed è sbagliato.

Tenete i criteri dei membri separati dall’autorità

La configurazione ordinaria di un membro e la configurazione del server autorevole sono problemi diversi con controlli delle modifiche diversi. Mescolarli è il modo in cui una modifica di routine ai criteri di un portatile finisce per alterare la referenza dell’intera foresta.

Scrivete la decisione in quattro righe: la fonte autorevole, la gerarchia che la trasporta, il comportamento in roaming e il comando che dimostra lo stato su un dispositivo. Se le prime tre sono documentate e la quarta è ripetibile, un errore di accesso legato al tempo diventa una verifica di cinque minuti invece di una caccia nei log della VPN.