INFRASTRUTTURA LOCALE

1. Active Directory c’è, ma solo per le macchine

Nel nostro istituto gestivamo due plessi differenti con due domini locali separati e mai unificati. Invece di imbarcarci in una complessa unificazione dei domini, abbiamo fatto una scelta strategica radicale: mantenere AD, ma svuotarlo della gestione degli utenti. Oggi il dominio locale serve esclusivamente per gestire i computer (deployment software e Group Policy), mentre gli utenti locali e di dominio tradizionali sono stati eliminati. L’autenticazione è interamente demandata a Google Workspace.

INSIGHT SUL CAMPO

2. L’inghippo del Token (GCPW vs Chrome Management)

Google permette di scaricare l’installer di GCPW direttamente dalla Console con un token integrato. Il mio consiglio è di NON usare quella versione se hai già applichi i token di registrazione per i browser Chrome, l’installer pre-configurato crea un conflitto nella Admin Console, impedendo la corretta visibilità dei dispositivi. La soluzione? Scarica l’installer .msi pulito di GCPW e gestisci l’aggancio alla console sfruttando esclusivamente il token di registrazione del browser Chrome. Se invece non gestisci Google Chrome centralmente puoi scaricare l’installer direttamente dalla Admin Console Google.

CONFIGURAZIONE AVANZATA

3. Tweaks del Registro di Sistema via GPO

Per fare in modo che GCPW si comporti esattamente come desideriamo e si integri con i servizi accessori della scuola, applichiamo due chiavi di registro tramite GPO (Criteri di gruppo) direttamente nel registro di sistema di Windows. Chi non avesse un server e un dominio Active Directory dovrà procedere se vorrà a impostare queste chiavi attraverso altre vie (chiavi .reg, script o impostandole su una macchina e clonare l’immagine sulle altre).

Policy 1: use_shorter_account_name (ordine: 1)

Questa è la chiave più importante per il nostro caso d’uso:

Per impostazione predefinita, GCPW genera il nome della cartella profilo locale concatenando nome, cognome e dominio Google (risultato: qualcosa come mario.rossi_tuoistituto.it). Questo crea caos nei percorsi di accesso e rompe le integrazioni con sistemi di terze parti.

Impostando il valore REG_DWORD a 0x1, forziamo GCPW a generare nomi profilo nel formato breve e pulito: mario.rossi. Questo è stato cruciale per la nostra infrastruttura di stampa gestita con PaperCut: il sistema di stampa (che ha accesso alla Directory Google Workspace) riconosce istantaneamente l’utente di Windows basandosi sul nome utente , senza mappature complesse o script di sincronizzazione aggiuntivi. L’utente accede a GCPW, il suo profilo è creato, e immediatamente può stampare con le sue quote e privilegi personali.

Policy 2: domains_allowed_to_login (ordine: 2)

Questa policy implementa il controllo di accesso basato sul dominio:

Tramite questa policy blindiamo completamente i PC della scuola a livello di autenticazione. Inseriamo esclusivamente il dominio istituzionale tuoistituto.it, impedendo categoricamente l’accesso a chiunque possieda account Gmail privatici o domini non autorizzati. La sicurezza è garantita:

• Solo gli utenti con account @tuoistituto.it possono accedere
• Nessun account Google personale può autenticarsi
• Nessun insegnante o studente esterno, per quanto bene intenzionato, può inesorabilmente accedere senza un account istituzionale

Eccezioni temporanee: commissioni e ospiti

La rigidità della policy rimane gestibile grazie alla natura della chiave REG_SZ: supporta valori multipli separati da virgole. Durante gli esami di Stato o le commissioni di maturità, quando commissari esterni accedono ai nostri PC, aggiungiamo temporaneamente i loro domini alla policy:

tuoistituto.it,primoistituto.it,altrodominio.it

I commissari esterni possono ora accedere con le loro credenziali istituzionali. Al termine della commissione, rimuoviamo i domini aggiuntivi e il PC torna in lockdown. Niente account temporanei fragili, niente credenziali condivise: solo accesso pulito e tracciato tramite la gestione dei domini nella GPO.