Fine Agosto 2026, la scuola si prepara alla riapertura. Sai cosa ti aspetta: dovrai creare centinaia di account in massa, aggiungerli ai gruppi, e dare i giusti accessi a tutti, ma sei tranquillo perché da qualche anno hai i tuoi script fatti con Google Apps Script pronti e funzionanti e hai semplificato le cose a livello di accessi. Accendiamo le macchine rimaste spente per alcune settimane, facciamo gli ultimi aggiornamenti, e improvvisamente: la finestra di login di Google Credential Provider for Windows (GCPW) si apre e si chiude immediatamente. Nessuno riesce a fare login. È il genere di problema che lascia anche il più esperto system administrator a grattarsi la testa per ore, finché non scopri che la causa non è dove pensi.
Sono un assistente di laboratorio informatico e sistemista libero professionista, e questo è il racconto di come io e miei colleghi abbiamo diagnosticato un bug di GCPW che ha colpito decine e decine di PC Windows in agosto 2026. Spoiler: la colpa non era della nostra infrastruttura locale, ma di una convergenza tra un aggiornamento di Google e una policy cloud che nessun IT specialist poteva aspettarsi.
Il Problema: Finestra di Login di GCPW che Scompare all’Istante
Come system administrator scolastico, ho visto accadere questo scenario esatto su centinaia di macchine Windows distribuite su due plessi in pochi minuti:
- Schermata di login di Windows
- Selezioniamo “Accedi con il tuo account di lavoro”
- La finestra di autenticazione di Google si apre per una frazione di secondo
- Si chiude immediatamente
- Niente login possibile — il PC rimane bloccato
Il problema colpiva sia le macchine nuove che quelle che avevano funzionato regolarmente fino a luglio. Un malfunzionamento sistemico, non un caso isolato. Per un IT specialist scolastico che da qui a pochi giorni avrà la scuola di nuovo a pieno regime è una situazione di emergenza totale.
Il Primo Sospetto: Policy di Dominio e Aggiornamenti WSUS
La reazione istintiva di ogni system administrator, quando accendi 150 PC in una scuola e tutti hanno lo stesso problema di autenticazione, è pensare alla policy di dominio. Come ho già spiegato in un precedente articolo, pur utilizzando GCPW, continuiamo a gestire le macchine in dominio Windows, per poter applicare ai PC le Group Policy. Nel nostro caso, come sistemista con Active Directory locale, il sospetto era ovvio: “Avrà fatto qualcosa di strano l’aggiornamento delle policy di WSUS, o magari c’è una policy di sicurezza locale che blocca GCPW”.
Ho controllato tutto quello si poteva controllare:
- Versione di Chrome → Aggiornata (come previsto via WSUS)
- Policy di dominio (GPO) → Nulla di strano
- GCPW versione → 150.0.7871.100 (rilasciata il 14 luglio 2026)
- Event Viewer → Nessun errore critico locale
- Registro di sistema → Intatto
Tutto sembrava in ordine dal punto di vista dell’infrastruttura locale. Eppure il problema persisteva. Allora ho provato la soluzione classica: disinstallare completamente GCPW e reinstallarlo. Non ha funzionato. Questo era il primo indizio che il problema veniva da fuori.
Il Dettaglio che Ha Cambiato Tutto: Un PC Spento da Due Mesi
Mentre stavamo investigando, abbiamo acceso un PC che era rimasto spento esattamente dal giorno della chiusura estiva. Era un test perfetto — uno scenario controllato.
Alla prima accensione, PRIMA di avere il tempo di scaricare le policy cloud, il login con GCPW funzionava perfettamente.
Poi, dopo pochi secondi, nel momento esatto in cui il PC si è connesso alla rete e ha scaricato gli aggiornamenti e le policy di Google Workspace, il problema è ricomparso. La finestra di login è tornata a scomparire.
Questo dettaglio era cruciale: il problema non era una corruzione locale sulla macchina stessa. Non era un driver rotto, non era un file di configurazione danneggiato. Arrivava da fuori — da Google.
La Scoperta Cruciale: Test in un altro plesso
Ho contattato il collega tecnico informatico che lavora in un altro plesso, completamente slegato dal nostro dominio Active Directory locale. Né WSUS condiviso, né policy di dominio comune, né infrastruttura locale in comune. Niente che avessero in comune se non il fatto di usare Google Workspace e GCPW.
Eppure aveva esattamente lo stesso problema sulle sue macchine, negli stessi giorni, con gli stessi sintomi.
A quel punto era cristallino: non era un problema locale di dominio Windows Server. Non era colpa delle nostre policy di dominio. Era qualcosa che veniva direttamente da Google.
La Diagnosi Finale: GCPW v150 + Policy di Google Workspace
Dopo ore di ricerca su Reddit, forum di sysadmin, e community dedicate a tecnici informatici e system administrator, ho finalmente trovato il vero colpevole: una convergenza tra due fattori che Google ha introdotto pressappoco nello stesso periodo, senza coordinamento apparente.
Fattore 1: GCPW v150 Cambia il Flusso di Autenticazione
Google Credential Provider for Windows versione 150 (rilasciato il 14 luglio 2026) introduce il supporto alle chiavi di sicurezza FIDO2 per l’autenticazione hardware. Per implementare questa nuova funzionalità, il flusso di autenticazione cambia in modo sostanziale e richiede di accedere a URL interni del browser gestito, con prefisso chrome://.
Fattore 2: Google Workspace Inasprisce le Policy di Sicurezza a Metà 2026
Nel medesimo periodo, Google ha introdotto automaticamente (senza comunicazione esplicita ai system administrator) un inasprimento delle direttive di sicurezza sui browser gestiti. Tra queste, una policy di blocco che inibisce l’accesso agli URL interni di Chrome (schema chrome://) per motivi di protezione da manipolazioni.
Il risultato della convergenza? GCPW v150 ha bisogno critico di accedere a chrome://, ma la policy cloud li blocca. La finestra di login tenta di caricarsi, intercetta il blocco della policy, e si chiude immediatamente senza possibilità di autenticazione.
Perché il PC Spento da Due Mesi Funzionava “al Primo Accesso”
Come system administrator, questo è il dettaglio che mi ha aiutato a capire il meccanismo esatto:
Quando il PC si è acceso, aveva ancora installata la versione vecchia di GCPW (che non richiedeva gli URL chrome:// per il login). Nel breve momento prima di connettersi alla rete di dominio e scaricare gli aggiornamenti, il login funzionava perfettamente.
Nel momento esatto in cui il PC si è connesso e ha scaricato simultaneamente:
- L’aggiornamento a GCPW v150 (che richiede
chrome://) - La policy di Google Workspace aggiornata (che blocca
chrome://)
→ Bang. Il login ha smesso di funzionare per sempre dopo quel momento.
La Soluzione: Modificare la Policy di Blocco degli URL in Google Admin Console
Una volta compresa la causa, la soluzione era immediata anche se non banale da trovare — richiede accesso a Google Admin Console e capacità di navigare correttamente le policy di sicurezza.
Come system administrator, ecco il percorso esatto nella Google Admin Console (dove parlo per esperienza diretta di IT specialist scolastico):
- Accedere a Google Admin Console (admin.google.com) come amministratore di dominio
- Nel menu di sinistra, selezionare Impostazioni
- Cliccare su Utenti e browser
- Nella sezione Blocco degli URL, cercare eventuali policy che bloccano gli URL interni di Chrome (schema
chrome://) - Disabilitare il blocco generico, oppure aggiungere un’allowlist specifica per questi URL di autenticazione:
- chrome://auth-provider
- chrome://identity
- chrome://signin
- chrome://chrome-signin
- chrome://inline-signin
- Salvare le modifiche
- Attendere qualche minuti per la propagazione della policy verso tutti i dispositivi
- Riavviare un PC di test per verificare
- Tentare il login con GCPW → Funziona ✅
Personalmente, essendo a ridosso dell’inizio della scuola, con quasi un migliaio di utenti pronti ad accedere con GCPW ho preferito non inserire una whitelist ma disabilitare direttamente la policy in attesa di un fix completo da parte di Google stessa.
Dopo il fix, tutte le macchine sono tornate operative consentendo il normele accesso con il proprio account Google
Lezioni Imparate da un Sistemista
Questo problema ha insegnato qualcosa di importante a qualsiasi system administrator, IT specialist o tecnico informatico che lavori con Google Workspace e GCPW in ambienti scolastici o aziendali:
- Gli aggiornamenti di GCPW cambiano le dipendenze critiche. Quando Google rilascia una versione major (come la v150 con FIDO2), le policy cloud potrebbero non essere ancora allineate per il lancio. Per un system administrator è cruciale testare prima di distribuire in produzione.
- Le policy cloud e i client desktop devono essere coordinati. Un aggiornamento di GCPW può richiedere un cambio di policy in Google Admin Console. Google non sempre comunica questo chiaramente ai propri clienti.
- I PC spenti a lungo sono il “canary in the coal mine” per ogni IT specialist. Se hai macchine rimaste offline per settimane, quando le accendi ricevono tutto insieme (aggiornamenti software + policy cloud). Sono il primo indicatore affidabile di problemi di compatibilità tra aggiornamenti di diverse componenti.
- La causa potrebbe non essere dove pensi, come ogni tecnico informatico sa. Il nostro primo istinto come systemista era colpevole locale (WSUS, policy AD, driver) quando in realtà il problema veniva da Google Workspace. Testare in ambienti isolati aiuta a isolare la vera causa.
- L’escalation cross-team è utile. Contattare un altro system administrator in un’infrastruttura totalmente diversa ci ha confermato che il problema non era locale. È una tecnica diagnostica spesso sottovalutata.
Bicchiere mezzo pieno: GCPW è vivo e il supporto continua
Quando abbiamo deciso di passare a Google Credential Provider for Windows eravamo abbastanza convinti che per il nostro ambiente e per la nostra infrastruttura fosse un’ottima soluzione. Notavamo però un rilascio di aggiornamenti piuttosto contenuto, con releases che a volte si sono intervallate anche a distanza di 3 anni l’una dall’altra. La paura era quella di vedere Google abbandonare il progetto proprio mentre noi avevamo fatto una scelta abbastanza radicale verso quella soluzione. I rilasci annuali (2024-2025) e il doppio rilascio di quest’estate 2026 hanno quantomeno confermato la volontà di Google di proseguire nel supporto a GCPW. Nonostante quindi i problemi causati, questo rassicura per il futuro.
Domande Frequenti per IT Specialist e Sistemisti
Se la tua scuola o azienda usa Google Workspace + GCPW, e dopo agosto 2026 gli utenti non riescono a fare login (la finestra di GCPW si apre e chiude subito), prova a disabilitare il blocco degli URL interni in Google Admin Console > Impostazioni > Utenti e browser > Blocco degli URL. Se risolve in 5 minuti, è lo stesso problema.
Dipende dalle tue esigenze di sicurezza. Se vuoi proteggere gli utenti da chrome://settings e chrome://extensions, usa un URL Blocklist più specifico (che blocca solo quelle). Oppure abilita tutti gli URL interni e proteggi a monte con DNS filtering (Pi-hole, OpenDNS) e policy di contenuto web. Bloccare gli url solo in chrome può avere senso per i Chromebook, meno per Windows, Linux o Mac dove l’utente può utilizzare semplicemente un browser diverso per bypassare le restrizioni.
No, nella maggior parte dei casi il reinstall non serve. Il problema non è una corruzione locale del software, ma l’interazione tra la versione v150 e la policy cloud di Google Workspace. Devi modificare la policy cloud, non il software locale.
Controlla in questo ordine: 1) La versione di GCPW (se è 148+, sei nel caso descritto). 2) La policy di blocco URL in Google Admin Console. 3) Event Viewer locale per errori di autenticazione.
Non ufficialmente da Google. La diagnostica rimane manuale: accendi una macchina offline, prova login (funziona?). Poi connettila online e aspetta gli aggiornamenti (funziona ancora?). Se il comportamento cambia al momento della connessione, è questo problema. Con Powershell si possono eventualmente controllare le chiavi di registro o i registri eventi di Windows, ma non esiste nulla di ufficiale.
