[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Impostantando OpenLDAP su server Debian 9 (e client Debian 10)



Salve,

ho trascorso diverse ore questo fine settimana ad installare OpenLDAP sul mio server Debian 9, visto che ho diversi dispositivi in casa tra figli, etc. Il server sembra funzionare egregiamente visto che quando faccio il seguente dal client:

ldapsearch -x -LLL -h 192.168.25.25 -b "dc=mercury,dc=home" 'uid=user1'

ottenendo la risposta attesa con tutti i relativi dettagli dell'utente (user1).

Ho impostato due utenti sul server OpenLDAP:

Dopo un po' di ostacoli, sono riuscito a fare il login da terminale sul client con l'utente user2. Inizialmente, LDAP mi ha fatto cambiare la password e mi ha fatto rifare il login con la nuova password, quindi e' andato a buon fine. Ho poi verificato sul server LDAP che la password fosse veramente cambiata ed infatti corrispondeva alla password che avevo appena immesso sul client.

ldapwhoami -vvv -h 192.168.25.25 -D "uid=user2,ou=people,dc=mercury,dc=home" -x -W

Ho quindi provato a fare il login con l'utente user1 sul client. Prima di installare OpenLDAP, sul client usavo Password1 per l'utente user1 mentre sul server LDAP ho impostato una nuova password (Password2). Mi sarei aspettato che quando facevo il login sul client, il cliente avrebbe richiesto la password dal server LDAP e quindi chiedendomi Password2. In realta', mi ha fatto fare il login on Password1. Ho pensato che questo fosse perche' user1 aveva la password registrata in /etc/passwd and /etc/shadow. Ho quindi deciso di cancellare le relative linee in questi file e ho ritentato il login da terminale. Questa volta il client mi ha consentito il login con Password2.

Ho riavviato il client e la finestra KDE Plasma del login non compariva (schermo nero con solo la freccia del mouse visibile). Ho quindi aggiunto di nuovo le linee per user1 nei file /etc/passwd and /etc/shadow e tutto funzionava come prima.

La domanda e' quindi come fare per far si che anche per l'utente user1 venga interrogato il server LDAP, senza compromettere il sistema? Chiaramente, cancellare le linee per l'utente user1 in /etc/passwd and /etc/shadow non e' l'approccio giusto. Ho seguito questa guide.

Questo e' il mio file /etc/libnss-ldap.conf :

base dc=mercury,dc=home
uri ldap://192.168.25.24
ldap_version 3
rootbinddn cn=admin,dc=mercury,dc=home

Ecco /etc/pam_ldap.conf :

base dc=mercury,dc=home
uri ldap://192.168.25.24
ldap_version 3
rootbinddn cn=admin,dc=mercury,dc=home
port 389
scope sub
bind_timelimit 30
idle_timelimit 3600
pam_filter objectClass=posixAccount
pam_login_attribute uid

Infine, ecco /etc/nsswitch.conf :

passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

Ho anche cambiato la password PAM authentication, editando il file /etc/pam.d/common-password. Ho rimosso l'opzione use_authtok sulla password per la configurazione del modulo pam_ldap come indicato sotto.

password [success=1 user_unknown=ignore default=die] pam_ldap.so try_first_pass

Infine, ho editato la configurazione della sessione PAM  /etc/pam.d/common-session e ho aggiunto pam_mkhomedir come sotto.

session optional pam_mkhomedir.so skel=/etc/skel umask=077

Avete qualche suggerimento sul perche' lo schermo login di KDE Plasma non carica all'avvio se cancello user1 da etc/passwd and /etc/shadow? In pratica sembra che debba indicare al cliente di ignorare i setting locali e fare riferimento solo al server LDAP.

SI puo ' impostare il client in modo tale che se e' disponibile il server LDAP, usa quello e fa il caching locale della password (per X giorni) nel caso in cui il server fosse giu' (non vorrei dipendere dal fatto che il server sia online al 100% visto che e' una rete domestica)?

Stavo inoltre cercando di capire se la password sono scambiate in chiaro sulla rete. Mi pare di capire che il TLS sia impostato di default?

A presto e grazie

-- 


Respect your privacy and that of others, don't give your data to big corporations.
Use alternatives like Signal (https://whispersystems.org/) for your messaging or 
Diaspora* (https://joindiaspora.com/) for your social networking.

Reply to: