Criterio di gruppo assente sulla VPN? Verificate l’ambito prima del tunnel

Qualcosa che veniva applicato sulla rete dell’ufficio smette di esserlo la settimana in cui un utente inizia a lavorare via VPN, e il tunnel passa per colpevole prima che qualcuno apra un rapporto. Il criterio di gruppo decide quali impostazioni arrivano all’utente e al computer Windows, recupera il materiale dal dominio ed esegue l’elaborazione lato client, e questi tre passaggi falliscono in tre modi diversi. Il tunnel cambia solo quale percorso ha il client. Percorrere i controlli in ordine evita che un problema di permessi sui file venga inseguito come un problema di instradamento.

Iniziate dall’impostazione, non dal tunnel

Annotate una GPO attesa e un’impostazione concreta al suo interno, poi stabilite se quell’impostazione risiede nella configurazione utente o in quella computer. Questo presuppone un client Windows autorizzato e aggiunto al dominio su una VPN approvata, non un dispositivo non gestito o solo cloud che viene trasformato in membro del dominio. La risposta sull’ambito decide chi può leggere il risultato e se serve l’elevazione, quindi risolvetela prima di eseguire qualsiasi cosa.

Chiedete all’amministratore del dominio quali collegamenti, posizioni degli oggetti, filtri di sicurezza e filtri WMI dovrebbero essere in gioco. Cambiare quei controlli per far passare un test è un altro progetto con un altro responsabile.

Leggete il rapporto con l’account a cui appartiene l’impostazione

Nella sessione dell’utente interessato, eseguite whoami /user e poi gpresult /scope user /r. L’account che ha autenticato la VPN non è automaticamente l’account Windows di cui state leggendo il criterio, e un controllo eseguito da un account amministratore risponde a un’altra domanda. Salvate la linea di base con un nuovo nome file, ad esempio %TEMP%\vpn-policy-user-before.html. Il riferimento di gpresult documenta le opzioni di ambito e di output, e vale la pena sapere che generare un rapporto non aggiorna nulla.

Il criterio computer ha un proprio ambito e un proprio contesto di autorizzazioni, quindi esaminatelo separatamente con l’elevazione necessaria. Unire i due ambiti in un solo rapporto è il modo in cui un’impostazione utente viene dichiarata assente quando non è mai stata in quell’ambito.

La scoperta non è accesso: prima i record SRV, poi SMB

Con la VPN approvata connessa, confermate che il client risolva i controller di dominio attraverso il percorso DNS previsto; un sito web pubblico che si carica non dice nulla sulla scoperta dei controller. Per il dominio illustrativo corp.example, nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example risponde alla domanda che avete davvero. Un record di servizio restituito è solo una prova di scoperta, perché l’indirizzo del controller selezionato deve comunque essere raggiungibile con l’autenticazione richiesta e i servizi di directory consentiti. Il materiale dei criteri arriva poi da SYSVOL, che è una lettura SMB verso quello specifico controller e non un test ICMP.

Una prova più debole viene facilmente scambiata per una prova. Una risposta ICMP da un controller, accanto a una lettura negata di un modello di criterio, produce un rapporto che sembra vuoto per una ragione che nessuno ha ancora collegato.

Mantenete coerenti le autorizzazioni del servizio AD, i percorsi di ritorno e la sincronizzazione oraria della distribuzione, invece di sostituirli con un’apertura indiscriminata del firewall o un server DNS pubblico. I dati dei criteri che differiscono tra i controller sono una questione di replica per il proprietario della directory.

Un aggiornamento, due rapporti, un confronto

Provato il percorso, richiedete l’aggiornamento pertinente con gpupdate /target:user e leggete il risultato invece di darlo per scontato. L’aggiornamento predefinito applica il criterio modificato mentre /force chiede una riapplicazione; nessuno dei due ripara DNS, permessi sui file o filtraggio. Alcune estensioni si completano solo a un accesso successivo o a un altro evento in primo piano, quindi una sola esecuzione non è un verdetto. Aggiungere opzioni di disconnessione o riavvio alla sessione di un utente remoto come diagnostica di routine getta via ciò che aveva aperto.

Generate un secondo rapporto con un nome file diverso e confrontate il tempo di elaborazione, la GPO attesa, il suo stato applicato o negato e l’impostazione stessa. Un rapporto di una sessione precedente riuscita non dimostra nulla su questo aggiornamento. Un criterio filtrato indica l’applicabilità più che il trasporto, il che cambia chi possiede il passo successivo.

Legate il guasto a una singola attività

Nel Visualizzatore eventi, iniziate dall’avviso o dall’errore dei criteri di gruppo nel registro di sistema, poi passate al registro operativo GroupPolicy sotto Registri applicazioni e servizi. Filtrate quel registro operativo per l’identificatore di attività dell’aggiornamento appena eseguito, perché un nuovo aggiornamento ottiene un nuovo identificatore e mescolarlo agli eventi di ieri produce una conclusione sicura e sbagliata. Annotate l’ora, il contesto utente o computer, il controller selezionato, la GPO, il codice di errore e la dipendenza non riuscita.

Quella nota è ciò su cui il proprietario della rete o della directory può agire. Essere connessi alla VPN e aver eseguito gpupdate più volte non sono prove, e nessuna delle due sopravvive a un passaggio di consegne.

Mantenete privati i rapporti HTML, perché espongono nomi interni, appartenenze ai gruppi e configurazione di sicurezza. Una volta confermata l’impostazione, rimuovete le autorizzazioni temporanee che avete aggiunto invece di lasciarle al loro posto.