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

[Marco Gaiarin]

Mandi! Antonio
  In chel di` si favelave...

> Mi rimane a capire una paio di cosette adesso:
> a) capire se la comunicazione tra server LDAP e client avviene cifrato
> con TLS

In /etc/default/slapd c'è una variabile che inidica dove 'ascolta' il
servizio; la mia impostazione è:

SLAPD_SERVICES="ldapi:/// ldap://127.0.0.1/ ldaps:///"

ovvero ldapi:// su socket, non-ssl solo su localhost, ssl per il resto.


> b) fare il caching delle password cosi che possa abilitare LDAP anche
> per i portatili. Ovviamente, il portatile non mi deve cercare il server
> LDAP quando sono fuori casa. C'è poi la questione che non ho redundancy
> del server e se si frigge, non voglio rimanere tagliato fuori da tutte
> le macchine.

Esistono 'libnss-db' e 'pam-ccred', ma non ho mai avuto esperienze
esaltanti...


> c) fare si che anche i login SSH si autenticano al server LDAP.

Se hai configurato correttamente pam (eg, hai usato pam-auth-update),  già
così.

-- 
  Si dice che se fai girare un cd di installazione di Windows al contrario
  nel lettore cd si sentono messaggi satanici. Questo è niente: fallo
  andare nel verso giusto e installa Windows!   (?)

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

[Antonio]

Indovina, indovina ... funziona!

E' il tipico esempio dell'orrore da principiante ...

In pratica, quando eliminavo le righe in /etc/passwd e /etc/shadow per
l'utente /user1, /cancellavo inavvertitamene anche le riga che stava
sopra a quella di /user1. /Tale riga era quella dell'utente SDDM ed e'
per questo che SDDM si presentava con schermo nero, probabilmente
perché' non veniva concesso alcuna autorizzazione all'eseguibile in
questione.

Adesso tutto risolto. SDDM presenta tutti gl'utenti presenti sul server
LDAP, compreso l'utente /user1./

Mi rimane a capire una paio di cosette adesso:

a) capire se la comunicazione tra server LDAP e client avviene cifrato
con TLS

b) fare il caching delle password cosi che possa abilitare LDAP anche
per i portatili. Ovviamente, il portatile non mi deve cercare il server
LDAP quando sono fuori casa. C'è poi la questione che non ho redundancy
del server e se si frigge, non voglio rimanere tagliato fuori da tutte
le macchine.

c) fare si che anche i login SSH si autenticano al server LDAP.

Consigli in merito sono sempre ben accetti.

A presto

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.

Il 31/03/20 00:44, Sabrewolf ha scritto:
> Nel link che hai indicato prima c'era una discussione dove un utente
> suggeriva di forzare l'avvio della rete prima del login manager. Se è
> questo che stai cercando di fare devi modificare le unità di systemd.
>
> Se hai il sospetto che il login manager viene avviato troppo presto
> allora fermalo e riavvialo manualmente. Esegui:
>
> systemctl isolate multi-user.target
>
> Poi una volta che il display manager è chiuso controlli che i servizi di
> rete di cui parlavi prima siano attivi. Infine ritorni al login grafico:
>
> systemctl isolate graphical.target
>
> Se il problema persiste allora la causa va cercata altrove e non nel
> fatto che il display manager venga avviato troppo presto rispetto ai
> servizi di rete che usi.
>
>
> Il 31/03/20 00:02, Antonio ha scritto:
>
>> Ma io voglio che SDDM parta e mi consenta di fare il login.
>>
>

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

[Sabrewolf]

Nel link che hai indicato prima c'era una discussione dove un utente
suggeriva di forzare l'avvio della rete prima del login manager. Se è
questo che stai cercando di fare devi modificare le unità di systemd.

Se hai il sospetto che il login manager viene avviato troppo presto
allora fermalo e riavvialo manualmente. Esegui:

systemctl isolate multi-user.target

Poi una volta che il display manager è chiuso controlli che i servizi di
rete di cui parlavi prima siano attivi. Infine ritorni al login grafico:

systemctl isolate graphical.target

Se il problema persiste allora la causa va cercata altrove e non nel
fatto che il display manager venga avviato troppo presto rispetto ai
servizi di rete che usi.


Il 31/03/20 00:02, Antonio ha scritto:


Ma io voglio che SDDM parta e mi consenta di fare il login.

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

[Antonio]

Ma io voglio che SDDM parta e mi consenta di fare il login. Deve essere
un problem di configurazione di SDDM. In fatti, mi fa vedere l'utente
/user2/ ma non mi consente di cliccarci sopra per immettere la password.
Chissa' che non dipenda dal fatto che l'utente /user2/ non ha mai
eseguito un login graphico. Anche se fosse questo il problema, resta
comunque una limitazione perche' se cosi' fosse non mi consentirebbe il
login di nuovi utenti. Not ideal!

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.

Il 30/03/20 22:18, Sabrewolf ha scritto:
> Forse come target predefinito hai graphical.target ? In questo caso il
> display manager dovrebbe partire senza abilitarlo esplicitamente. Se
> invece passi al target multi-user allora systemd non dovrebbe piu'
> avviare sddm.
>
> systemctl set-default multi-user.target
>
> Il 30/03/20 22:52, Antonio ha scritto:
>>
>> Il problema e' che vorrei aggiungere sddm.service in
>> /etc/systemd/system usando il metodo Debian. E poi, visto sddm parte,
>> systemd lo sta' facendo gia' partire senza che vi sia un file in
>> /etc/systemd/system come suggerito dal link di cui sopra.
>>
>> Credo che sia la pista giusta ma c'e' bisogno di qualche altra dritta
>>  continuo ad investigare.
>>
>>
>

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

[Sabrewolf]

Forse come target predefinito hai graphical.target ? In questo caso il
display manager dovrebbe partire senza abilitarlo esplicitamente. Se
invece passi al target multi-user allora systemd non dovrebbe piu'
avviare sddm.

systemctl set-default multi-user.target

Il 30/03/20 22:52, Antonio ha scritto:


Il problema e' che vorrei aggiungere sddm.service in
/etc/systemd/system usando il metodo Debian. E poi, visto sddm parte,
systemd lo sta' facendo gia' partire senza che vi sia un file in
/etc/systemd/system come suggerito dal link di cui sopra.

Credo che sia la pista giusta ma c'e' bisogno di qualche altra dritta
 continuo ad investigare.

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

[Antonio]

Interessante. Pare che tua abbia ragione. Vedi
https://unix.stackexchange.com/questions/222626/allow-username-input-sddm-ldap-kerberos

Il problema e' che vorrei aggiungere sddm.service in /etc/systemd/system
usando il metodo Debian. E poi, visto sddm parte, systemd lo sta'
facendo gia' partire senza che vi sia un file in /etc/systemd/system
come suggerito dal link di cui sopra.

Credo che sia la pista giusta ma c'e' bisogno di qualche altra dritta
 continuo ad investigare.

Non sono neache sicuro al 100% ch il problema sia collegato al fatto che
non vi sia rete quando parte sddm. Infatti, che faccio Alt+F2 (apro
terminale), riesco a fare il login con l'utente /user2 /che esiste solo
su LDAP.

Vi tengo aggiornato

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.

Il 29/03/20 22:45, Marco Gaiarin ha scritto:
> Mandi! Antonio
>   In chel di` si favelave...
>
>> ||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.
> Cosa hai usato per far 'vedere' gli utenti? Suppongo libnss-ldapd e
> libpam-ldapd, giusto?
>
> A naso il problema è che quando il desktop manager è partito NON erano
> partiti slapd e/o nslcd; questo implica che il tuo DM ''non sapeva'' che
> esistevano gli utenti.
>
> Alcuni dm (mi pare 'lightdm') si 'ricordano' gli utenti che hanno fatto
> login; altri, devono per forza essere fatti partire dopo slapd/nslcd.
>
> Gioca con systemd...
>

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

[Marco Gaiarin]

Mandi! Antonio
  In chel di` si favelave...

> ||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.

Cosa hai usato per far 'vedere' gli utenti? Suppongo libnss-ldapd e
libpam-ldapd, giusto?

A naso il problema è che quando il desktop manager è partito NON erano
partiti slapd e/o nslcd; questo implica che il tuo DM ''non sapeva'' che
esistevano gli utenti.

Alcuni dm (mi pare 'lightdm') si 'ricordano' gli utenti che hanno fatto
login; altri, devono per forza essere fatti partire dopo slapd/nslcd.

Gioca con systemd...

-- 
  Internet it's the largest equivalence class in the reflexive
  transitive symmetric closure of the relationship:
  ``can be reached by an IP packet from''.  (Seth Breidbart)

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

[Antonio]

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:

  * un utente che esiste gia' sul client (*/user1/*)
  * un nuovo utente che non esiste sul client (*/user2/*)

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 questaguide
.


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.