Autenticazione LDAP

Il vantaggio di usare LDAP è che tutte le informazioni su utenti e gruppi possono essere tenute su un server che è gestito centralmente.

La prima cosa da fare è installare l’estensione php ldap sul vostro sistema linux:

apt-get install php5.6-ldap

o

apt-get install php7.x-ldap

Poi, per abilitare il supporto LDAP Lizmap, devi cambiare il metodo di autenticazione nella configurazione come segue.

Abilitare LDAP

Nel localconfig.ini.php, devi impostare questi parametri:

[modules]
ldapdao.access=1

[coordplugin_auth]
driver=ldapdao

Questi parametri abilitano il modulo ldapdao di Lizmap. Se hai copiato localconfig.ini.php da localconfig.ini.php.dist, hai già questi parametri ma sono commentati.

Poi devi aggiungere una sezione [ldap:lizmapldap] nel tuo profiles.ini.php, con alcune impostazioni che permettono di connettersi al tuo server ldap, e di cercare utenti nel ldap. La sezione potrebbe già esistere se hai copiato profiles.ini.php dal profiles.ini.php.dist.

[ldap:lizmapldap]
hostname=localhost
port=389
adminUserDn="cn=admin,ou=lizmap,dc=com"
adminPassword=""
searchUserBaseDN="dc=XY,dc=fr"
searchUserFilter="(&(objectClass=posixAccount)(uid=%%LOGIN%%))"
bindUserDN="uid=%?%,ou=users,dc=XY,dc=fr"
searchAttributes="uid:login,givenName:firstname,sn:lastname,mail:email,organization:organization,street:street,postcode:postcode,city:city"
searchGroupFilter=
searchGroupProperty="cn"
searchGroupBaseDN=""

Vedi i dettagli per come impostare questi parametri in una sezione sottostante.

Nota

questi parametri potrebbero essere nella sezione ldapdao dei file di configurazione auth.coord.ini.php, ma non è consigliabile modificare questi file, poiché quando si fa l’aggiornamento, si dovrebbe fare nuovamente la modifica in essi.

Per finire di abilitare il modulo, esegui php lizmap/install/installer.php

Impostazioni ldap

Proprietà di configurazione per i dati utente

Per verificare la password, o per registrare l’utente in Lizmap la prima volta che si autentica, il plugin ha bisogno di alcuni dati sull’utente.

Dovreste indicare quali attributi ldap può recuperare e quali campi del database riceveranno i valori degli attributi ldap.

Si indicano tali informazioni nella proprietà searchAttributes. Essa è una coppia di nomi, <ldap attribute>:<table field>, separati da una virgola.

In questo esempio, searchAttributes="uid:login,firstname,sn:lastname,mail:email,dn:":

  • il valore dell’attributo ldap uid sarà memorizzato nel campo login.
  • il valore dell’attributo ldap sn sarà memorizzato nel campo lastname.
  • il valore dell’attributo ldap firstname sarà memorizzato in un campo che ha lo stesso nome, poiché non esiste un nome di campo né :.
  • non ci sarà una mappatura per la proprietà dn. C’è un : senza nome del campo. Sarà letta da ldap, e può essere usata nel modello DN di bindUserDN. (vedi sotto).

L’elenco dei campi possibili in Lizmap sono: login, email, firstname, lastname, organizzazione, phonenumber, street, postcode, city, country. Solo il login e la email sono richiesti. Gli altri sono opzionali.

Proprietà di configurazione per l’autenticazione

Prima di provare ad autenticare l’utente con ldap, il plugin recupera le proprietà dell’utente. Utilizza due parametri di configurazione: searchUserFilter e searchAttributes.

Il searchUserFilter dovrebbe contenere la query ldap e un segnaposto %%LOGIN%% che sarà sostituito dal login fornito dall’utente.

Esempio: searchUserFilter="(&(objectClass=posixAccount)(uid=%%LOGIN%%))"

Puoi anche indicare il DN di base per la ricerca, in searchUserBaseDN. Esempio: searchUserBaseDN="ou=ADAM users,o=Microsoft,c=US".

Nota che puoi indicare diversi filtri di ricerca, se hai una struttura ldap complessa. Usa [] per indicare un elenco di elementi:

searchUserFilter[]="(&(objectClass=posixAccount)(uid=%%LOGIN%%))"
searchUserFilter[]="(&(objectClass=posixAccount)(cn=%%LOGIN%%))"

Per verificare la password, il plugin ha bisogno del DN (Distinguished Name) corrispondente all’utente. Costruisce il DN da un «modello» indicato nella proprietà bindUserDN e da vari dati. Questi dati possono essere il login dato o uno degli attributi ldap dell’utente.

  • Building the DN from the login given by the user: bindUserDN should contain a DN, with a %%LOGIN%% placeholder that will be replaced by the login.

    Esempio: bindUserDN="uid=%%LOGIN%%,ou=users,dc=XY,dc=fr". Se l’utente dà john.smith come login, l’autenticazione sarà fatta con il DN bindUserDN="uid=john.smith,ou=users,dc=XY,dc=fr".

    Per alcuni LDAP, il DN potrebbe essere una semplice stringa, per esempio un’email. Si potrebbe quindi impostare bindUserDN="%%LOGIN%%@company.local". O anche bindUserDN="%%LOGIN%%" se il login può digitare il valore completo del DN o un’email o altro… (Probabilmente non è raccomandato permettere ad un utente far digitare in modo autonomo il suo DN completo, può essere un problema di sicurezza)

  • Costruire il DN da uno degli attributi ldap dell’utente. In questo caso, il plugin prima interroga la directory ldap con il filtro searchUserFilter, per recuperare gli attributi ldap dell’utente. Poi, in bindUserDN, si può indicare un DN in cui alcuni valori saranno sostituiti dai valori di alcuni attributi, oppure si può indicare un singolo nome di attributo, corrispondente a un attributo che contiene il DN completo dell’utente.

    Per il primo caso, bindUserDn dovrebbe contenere un DN, con alcuni segnaposto %?% che saranno sostituiti dal valore degli attributi corrispondenti. Esempio: bindUserDN="uid=%?%,ou=users,dc=XY,dc=fr". Qui sostituisce il %?% con il valore dell’attributo uid letto dagli attributi dell’utente. Il nome dell’attributo dovrebbe essere presente nella proprietà di configurazione searchAttributes, anche senza mappatura dei campi. Es: ...,uid:,.... Vedi sopra.

    Per il secondo caso, basta indicare il nome dell’attributo, preceduto da un $. Esempio: bindUserDN="$dn". Qui prende l’attributo dn letto dalla ricerca, e usa il suo valore completo come DN per il login con il server LDAP. È utile per alcuni server LDAP come a volte Active Directory che hanno bisogno di un DN completo specifico per ogni utente. Il nome dell’attributo dovrebbe essere presente nella proprietà di configurazione searchAttributes, anche senza mappatura dei campi. Es: ...,dn:,.... Vedi sopra.

Nota che puoi indicare diversi modelli dn, se hai una struttura ldap complessa. Usa [] per indicare un elenco di elementi:

bindUserDN[]="uid=%?%,ou=users,dc=XY,dc=fr"
bindUserDN[]="cn=%?%,ou=users,dc=XY,dc=fr"

Proprietà di configurazione per i diritti dell’utente

Se avete configurato i diritti dei gruppi in Lizmap, e se questi gruppi corrispondono ai vostri gruppi ldap, potete indicare al plugin di mettere automaticamente l’utente nei gruppi dell’applicazione, secondo i gruppi ldap dell’utente.

Dovresti poi indicare in searchGroupFilter la query ldap che recupererà i gruppi dell’utente.

Esempio: searchGroupFilter="(&(objectClass=posixGroup)(member=%%USERDN%%))"

%%USERDN%% viene sostituito dal dn dell’utente. %%LOGIN%% viene sostituito dal login. Puoi anche usare qualsiasi attributo ldap che indichi in searchAttributes, tra %%. Esempio: searchGroupFilter="(&(objectClass=posixGroup)(member=%%givenName%%))

Attenzione: l’impostazione di searchGroupFilter rimuoverà l’utente da qualsiasi altro gruppo di applicazioni che non corrisponde al gruppo ldap. Se non vuoi una sincronizzazione dei gruppi, lascia searchGroupFilter vuoto.

Con searchGroupProperty, dovete indicare l’attributo ldap che contiene il nome del gruppo. Es: searchGroupProperty="cn".

Puoi anche indicare il DN di base per la ricerca, in searchGroupBaseDN. Esempio: searchGroupBaseDN="ou=Groups,dc=Acme,dc=pt".

Debugging

Se l’autenticazione non funziona, potete avere maggiori dettagli su ciò che è sbagliato. Per vedere questi dettagli, dovresti attivare i traces per ldapdao.

Nel tuo var/config/localconfig.ini.php, imposta questi parametri

[logger]
auth=file

[fileLogger]
auth=auth.log

Poi, in var/log/auth.log, avrete alcuni messaggi dal connettore ldap. Rimuovi queste impostazioni quando non ne hai bisogno, per evitare un enorme file auth.log.