Perché un portatile con Protected Users ha bisogno della VPN prima dell’accesso

Un portatile, un account funzionante e una rete alberghiera formano un ciclo di accesso che nessun nuovo tentativo spezza. L’account è in Protected Users, il che impedisce a Windows di memorizzare il verificatore che gli servirebbe per autenticare l’utente offline. Qualsiasi piano del tipo «prima accedi, poi collega il tunnel» ha l’ordine invertito, e la protezione fa esattamente ciò che promette. Quanto segue presuppone un account Active Directory tradizionale su un host Windows supportato.

Che cosa rimuove davvero la protezione

Normalmente Windows memorizza un verificatore nella cache perché un account di dominio possa accedere mentre un controller di dominio non è raggiungibile. Protected Users lo blocca per l’account, il che elimina l’accesso al dominio offline come possibilità invece di renderlo inaffidabile.

Non è il solito problema della cache obsoleta, e i rimedi abituali non si applicano. Accedere ripetutamente online, cambiare di nuovo la password o alzare il conteggio degli accessi memorizzati non ripristineranno la capacità, perché nessuna di queste azioni crea il verificatore che il criterio rifiuta di memorizzare. L’account si comporta come progettato, e il progetto presuppone che la rete sia presente quando Windows la chiede. Trattare il sintomo come un guasto della cache è il modo in cui i team finiscono per ricostruire un profilo che non era mai stato rotto.

Perché il tunnel deve esistere prima del desktop

Il dispositivo deve raggiungere l’autenticazione di dominio nel momento in cui Windows la chiede, cioè prima che esista qualsiasi sessione utente. Un client VPN che si avvia solo dopo la comparsa del desktop lascia un nuovo accesso in attesa di un percorso che non arriva mai. La dipendenza appartiene alla macchina, non a un utente che non ha ancora effettuato l’accesso.

Usate una soluzione di pre-accesso supportata e concordata con i responsabili degli endpoint e dell’identità. Un tunnel di dispositivo Always On VPN autenticato con un certificato del computer è idoneo quando il dispositivo gestito soddisfa i prerequisiti di quella distribuzione. L’integrazione supportata di una schermata di accesso da parte di un fornitore è un’altra opzione. Un normale profilo utente con un trigger automatico non è né l’una né l’altra, per quanto simile appaia nell’interfaccia del client.

Quel percorso richiede risoluzione dei nomi per il dominio, un controller di dominio raggiungibile e i protocolli di autenticazione che l’account può usare, e nessun indicatore «connesso» fornisce nulla di tutto ciò. Le sue route e i suoi filtri devono trasportare i servizi di identità e nient’altro che non sia necessario, perché quell’elenco di prefissi è la superficie che un portatile rubato ottiene prima che qualcuno acceda. Le decisioni di tunnel diviso prese per il tunnel utente non valgono per il tunnel del dispositivo, quindi esaminateli separatamente.

La raggiungibilità non è compatibilità di autenticazione

Un tunnel può trasportare i pacchetti perfettamente mentre l’autenticazione di dominio fallisce, perché il meccanismo tentato è uno che l’account non può usare. In un dominio che applica le restrizioni del gruppo, NTLM non è disponibile per i membri e Kerberos richiede un account e una configurazione compatibili con AES. Un percorso di pacchetti non può riparare nessuno dei due. Per questo un ping pulito a un controller di dominio non è prova che l’accesso funzionerà.

Possono essere in gioco anche due sistemi di credenziali. La VPN può autenticarsi presso un provider di identità mentre Windows ha bisogno separatamente di un accesso al dominio, e l’accettazione del primo non dice nulla del secondo. «La VPN è connessa» e «l’utente ha effettuato l’accesso» sono osservazioni distinte, e correggere l’una non implica l’altra.

Leggete le prove di autenticazione

Raccogliete eventi dal client e da un controller di dominio per lo stesso tentativo, non solo da un lato. I registri di Protected Users si trovano sotto Applications and Services Logs\Microsoft\Windows\Authentication, e un amministratore potrebbe dover attivare un registro prima che registri qualcosa. Correlate le marche temporali con il registro di connessione del tunnel stesso, perché un errore di ordine sembra un guasto delle credenziali da entrambi i lati.

Il primo comando qui sotto elenca ogni registro di autenticazione esposto dal dispositivo, così leggete quello che esiste e non quello nominato da un post di un blog. Il secondo legge le voci recenti una volta noto il nome. Cercate il pacchetto di autenticazione, l’account e la condizione di errore, perché un percorso di rete mancante e un meccanismo rifiutato lasciano prove diverse e solo una delle due è un problema VPN. Se il tunnel è salito dopo il tentativo, l’ordine era sbagliato qualunque cosa dicano quelle voci.

Get-WinEvent -ListLog *Authentication*
Get-WinEvent -LogName Microsoft-Windows-Authentication/Operational -MaxEvents 20

Dimostrate il limite da un avvio a freddo

Eseguite il test da uno stato disconnesso o appena avviato con un account limitato, e tenete aperta una via di ripristino approvata prima di cambiare qualcosa per gli utenti privilegiati. Un test su un desktop già in esecuzione non esercita nessuna parte del percorso di codice che conta, e questo spiega la maggior parte delle segnalazioni di una correzione che ha tenuto fino al riavvio successivo. Poi percorrete i quattro passi in questo ordine.

1. Confermate che il dispositivo può trovare un controller di dominio prima che qualcuno acceda, con nltest /dsgetdc:corp.example.com.
2. Tentate l’accesso al dominio, poi chiedete se è stato ottenuto un ticket, con klist.
3. Leggete il registro di autenticazione che il dispositivo registra, con i due comandi qui sopra, e annotate il pacchetto e la condizione di errore.
4. Confermate che la credenziale di ripristino approvata funziona ancora dalla schermata di accesso, perché è l’unica via di ritorno se il test del limite fallisce.

Aprire una condivisione file con credenziali fornite non crea nemmeno un accesso interattivo offline, quindi non sostituisce nessuno dei passi qui sopra. Se l’organizzazione ha davvero bisogno dell’accesso senza connessione, la risposta è una progettazione compatibile di account ed endpoint scelta deliberatamente. Togliere l’account dal gruppo, o mantenere un accesso di emergenza senza restrizioni su ogni portatile, è una decisione di politica dell’identità che un cambiamento della VPN non può prendere per voi.

La documentazione di Protected Users descrive sia il comportamento del verificatore sia le restrizioni di dominio da cui dipende questo progetto. Pianificate il processo di ripristino prima che qualcuno viaggi, perché il test di avvio a freddo è l’unico luogo in cui viene esercitato.