Abbiamo collegato un Active Directory di laboratorio a un GLPI 11: 7 utenti importati in 1,4 secondi, ognuno con il profilo giusto in base al gruppo dell'AD e accesso con la password di rete. Fin qui, tutto come previsto. Il problema è emerso quando abbiamo disattivato un dipendente uscito dall'azienda nell'AD: in GLPI è rimasto attivo, con lo stesso profilo. E modificare la configurazione in seguito non ha risolto, perché GLPI applica la regola di uscita solo la prima volta che rileva la cessazione.
Usate Microsoft Entra ID (Azure AD) e volete il single sign-on nel browser? Vedete SSO con Microsoft Entra ID in GLPI. Questo articolo tratta l'AD locale, tramite LDAP.
Cosa fa l'integrazione con l'AD
- Accesso con la password di rete: l'utente entra in GLPI con lo stesso nome utente e la stessa password di Windows. La password non viene mai salvata in GLPI.
- Importazione dei dati: nome, cognome, e-mail, telefono, ruolo e altri campi arrivano dall'AD.
- Profilo per gruppo: le regole di autorizzazione assegnano il profilo e l'entità in base al gruppo dell'AD (tecnico, responsabile, utente).
- Sincronizzazione: le modifiche nell'AD, come un cambio di telefono, di ruolo o un'uscita dall'azienda, arrivano in GLPI tramite la sincronizzazione pianificata.
Il laboratorio
Abbiamo configurato un domain controller Samba (compatibile con Active Directory) con il dominio ACME.TEST, l'azienda fittizia Acme, tre gruppi (GLPI-Tecnicos, GLPI-Gestores, GLPI-Usuarios) e otto utenti: sette attivi e uno disattivato in una OU dei cessati. Dall'altra parte, un GLPI 11.0.7 di test.
Passo 1: la directory LDAP
In Configurazione > Autenticazione > Directory LDAP:
| Campo | Cosa abbiamo usato | Perché |
|---|---|---|
| Server e porta | il domain controller, 389 (636 con LDAPS) | In produzione, preferite LDAPS o StartTLS |
| BaseDN | OU=Acme,DC=acme,DC=test |
Partite dalla OU delle persone, non dalla radice del dominio |
| RootDN e password | un account di servizio in sola lettura | Mai l'account di un amministratore |
| Filtro di connessione | (&(objectClass=user)(objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2))) |
Solo persone e solo account attivi |
| Campo login | samaccountname |
Il nome di accesso breve di Windows |
| Campo di sincronizzazione | objectguid |
Non cambia se l'utente cambia nome o OU |
| Gruppi | tipo di ricerca "Negli utenti", attributo memberof |
Per usare il gruppo dell'AD nelle regole |
Il pulsante Prova verifica la connessione prima di importare qualsiasi cosa.
Passo 2: il profilo in base al gruppo dell'AD
In Amministrazione > Regole > Regole di assegnazione delle autorizzazioni, una regola per gruppo:
Se l'utente proviene da questa directory e memberOf contiene |
Riceve il profilo | Nell'entità |
|---|---|---|
CN=GLPI-Tecnicos, |
Technician | quella dell'azienda |
CN=GLPI-Gestores, |
Supervisor | quella dell'azienda |
CN=GLPI-Usuarios, |
Self-Service | quella dell'azienda |
Le autorizzazioni assegnate tramite regola sono dinamiche: se la persona esce dal gruppo nell'AD, il profilo viene rimosso alla sincronizzazione successiva.
Passo 3: importare e sincronizzare
Dall'interfaccia (Importa nuovi utenti) o dalla riga di comando, che è ciò che serve per la pianificazione:
php bin/console ldap:synchronize_users --ldap-server-id=1 --deleted-user-strategy=1,0,1
Nel laboratorio, l'importazione ha portato i 7 utenti attivi in 1,4 secondi, e quello disattivato è stato escluso dal filtro. Nome, e-mail e telefono sono arrivati dall'AD, e ognuno ha ricevuto il profilo del proprio gruppo. L'accesso con la password dell'AD ha funzionato, e con la password sbagliata è stato negato.
Cosa è successo quando abbiamo disattivato un dipendente uscito
Abbiamo disattivato un utente nell'AD ed eseguito la sincronizzazione, prima con la configurazione predefinita.
| Test | Risultato in GLPI |
|---|---|
| Disattivato nell'AD, sincronizzazione predefinita | GLPI rileva l'uscita, ma non fa nulla: utente attivo, stesso profilo |
| Stesso utente, sincronizzazione successiva con "disabilita" | Non cambia nulla: era già stato contrassegnato come eliminato da LDAP |
| Un altro utente uscito, con "disabilita" già alla prima sincronizzazione | Utente disattivato e profili dinamici rimossi |
| Utente riattivato nell'AD, sincronizzazione con "abilita" | Torna attivo |
Due conclusioni:
- Il comportamento predefinito di GLPI è non fare nulla con chi esce dall'AD (strategia "0,0,0"). Un ex dipendente mantiene un account attivo in GLPI finché qualcuno non se ne accorge.
- La strategia vale nel momento in cui GLPI rileva l'uscita. Se la prima sincronizzazione è stata eseguita con il predefinito, modificare la configurazione in seguito non recupera chi è già stato contrassegnato. Occorre gestire questi utenti a mano.
Configurate l'azione per gli utenti eliminati da LDAP prima della prima sincronizzazione (in Configurazione > Autenticazione, oppure con --deleted-user-strategy nel comando). La combinazione che consigliamo è "1,0,1": disabilitare l'account, mantenere i gruppi (per lo storico) e rimuovere le autorizzazioni dinamiche.
Per il rientro, la strategia di ripristino "3" riabilita l'account quando la persona viene riattivata nell'AD.
Un dettaglio sul profilo predefinito
Tutti gli utenti importati hanno ricevuto anche il profilo predefinito di GLPI (nel nostro caso, Self-Service), oltre al profilo della regola. Per i tecnici non è un problema, ma compare nel cambio di profilo. Se non lo volete, verificate qual è il profilo predefinito di GLPI prima di importare.
Checklist
- Account di servizio in sola lettura per il RootDN.
- LDAPS o StartTLS in produzione.
- BaseDN sulla OU delle persone e filtro che esclude gli account disattivati.
objectguidcome campo di sincronizzazione.- Regole di autorizzazione per gruppo dell'AD, con entità definita.
- Azione per gli utenti eliminati da LDAP configurata prima della prima sincronizzazione ("1,0,1").
- Sincronizzazione pianificata (cron) con
ldap:synchronize_users, almeno giornaliera. - Test con un utente fittizio: crearlo, cambiargli gruppo, disattivarlo e riattivarlo nell'AD, e verificare GLPI a ogni passo.
Vi serve aiuto con l'integrazione o con l'audit degli accessi? Parlate con il team. Per capire profili e permessi, vedete profili e permessi in GLPI.
Test di NexTool del 4 ottobre 2026: domain controller Samba (compatibile con Active Directory) con utenti fittizi e GLPI 11.0.7 di test. Il laboratorio è stato eliminato alla fine. Comportamento della sincronizzazione verificato nel comando stesso di GLPI.
Commenti
I commenti di questo articolo provengono da GitHub (giscus). Caricandoli, il Suo browser si collega a GitHub, che riceve il Suo indirizzo IP e può salvare cookie propri.
Per caricarli automaticamente, attivi i cookie funzionali