Configurazione di Linux con Kerberos e LDAP
Per configurare il client Linux al fine di autenticare e assegnare i profili all’utente si è agito sul Pluggable Authentication Module (PAM) e sul Name Service Switch (NSS). Come accennato precedentemente, il laboratorio è stato effettuato con un client Linux, ma è possibile effettuare la stessa configurazione anche su tutti quei sistemi Unix che dispongono di entrambi i sottosistemi.
Il sottosistema PAM si occupa di autenticare/autorizzare l’utente, ad esempio con la password, limitandolo, ad esempio, a determinati orari o terminali, mentre NSS permette di reperire le informazioni necessarie all’utente ed al sistema, come ad esempio gli attributi utenti e gli host. Sia Linux che altri ambienti Unix necessitano però delle estensioni necessarie al fine di usare PAM e NSS con Kerberos e LDAP: nel nostro caso useremo il modulo Kerberos per PAM e il modulo LDAP per NSS. Si poteva scegliere di usare un modulo LDAP per PAM per autenticare l’utente: il risultato di autenticazione si sarebbe ottenuto in entrambi i casi (forse con meno sforzo), ma non rientrerebbe nello scopo del laboratorio. Il modulo PAM Kerberos, al contrario di LDAP, permette di ottenere un TGT che consentirà successivamente di non immettere ulteriori utenze e password.
Tutte le distribuzioni Linux e molti vendor Unix includono tra i loro pacchetti i moduli Kerberos e LDAP per PAM e NSS, in Debian rispettivamente libpam-krb5 e libnss-ldap. Nel caso si desiderasse, è possibile scaricare i sorgenti dal sito http://www.padl.com/ (modulo PAM e NSS per LDAP) e http://pam-krb5.sourceforge.net/ (modulo PAM).
I file di configurazione del PAM si trovano generalmente in /etc/pam.d; ognuno si riferisce ad un determinato servizio (ad esempio il file ssh si riferisce all’omonimo servizio e contiene la metodologia di autenticazione). Alcune distribuzioni, come ad esempio RedHat, usano il modulo pam_stack per accentrare la configurazione dei vari servizi in un singolo file. Per praticità si descrive un file di configurazione completo, che contiene sia l’autenticazione che l’accounting e il cambio della password.
Questo file può essere usato come template per tutti i servizi (ad esempio creando dei symlink):
auth sufficient /lib/security/pam_krb5.so forwardable auth sufficient /lib/security/pam_unix.so use_first_pass likeauth nullok md5 shadow auth required /lib/security/pam_deny.so account sufficient /lib/security/pam_unix.so account required /lib/security/pam_deny.so password required /lib/security/pam_cracklib.so retry=3 password sufficient /lib/security/pam_krb5.so use_authok password sufficient /lib/security/pam_unix.so use_first_pass nullok use_authtok md5 shadow password required /lib/security/pam_deny.so session required /lib/security/pam_limits.so session sufficient /lib/security/pam_krb5.so forwardable session required /lib/security/pam_unix.so
Si copi questo file (o si creino i relativi symlink) almeno sui file login e passwd per permettere il login al prompt e il cambio della password. Prima di procedere con la configurazione del Name Service Switch, è necessario modificare i parametri di default relativi ad LDAP. Generalmente il file di configurazione è /etc/ldap.conf, ma su Debian il file dei parametri per il plugin LDAP di NSS è /etc/libnss-ldap.conf. Vediamo come andrebbe configurato per il nostro esempio:
# See ldap.conf(5) for details # This file should be world readable but not world writable. base dc=azienda,dc=it uri ldaps://ldap.azienda.it timelimit 10 bind_timelimit 2 scope sub nss_base_passwd ou=People,dc=azienda,dc=it?one nss_base_shadow ou=People,dc=azienda,dc=it?one nss_base_group ou=Group,dc=azienda,dc=it?one
A questo punto è possibile modificare la configurazione di NSS, ovvero /etc/nsswitch.conf, inserendo i riferimenti a LDAP.
# Example configuration of GNU Name Service Switch functionality. # If you have the `glibc-doc' and `info' packages installed, try: # `info libc "Name Service Switch"' for information about this file. passwd: files ldap group: files ldap shadow: files hosts: files dns networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis
Come test, da root, potremmo ad esempio provare a cercare l’utente mrossi definito in LDAP:
# id mrossi uid=500(mrossi) gid=100(users) groups=100(users)
Il risultato, e i gruppi di appartenenza, viene estrapolato dal server LDAP. Creiamo, a titolo di esempio, una home directory per l’utente. In un ambiente complesso si consiglia di usare NFS con l’automount o anche il mouting della home directory Windows/Samba attraverso un apposito modulo PAM chiamato pam_mount.
# mkdir /home/mrossi # chown mrossi:users /home/mrossi
Prima di provare il logon, sul server zeus, creiamo il principal corrispondente all’utente mrossi, in modo da verificare username e password, ed un principal relativo alla workstation kirk, che servirà alla workstation per validare il ticket dell’utente con il KDC:
# kadmin.local -q “addprinc -pw miapassword3 mrossi@AZIENDA.IT” # kadmin.local -q “addprinc -pw miapassword4 host/kirk.azienda.it@AZIENDA.IT” # kadmin.local -q “ktadd -k /tmp/kirk.key host/kirk.azienda.it@AZIENDA.IT”
L’ultimo comando crea un file /tmp/kirk.key contenente la chiave Kerberos corrispondente alla workstation Linux: è necessario trasferire in modo sicuro (ad esempio tramite ssh) la chiave da zeus a kirk e copiare la stessa sul file /etc/krb5.keytab. A questo punto siamo pronti per provare il log-in con l’utente mrossi. In un nuovo virtual terminal del client Linux, digitiamo la username e la password corrispondente. Se tutto funziona correttamente, ci troveremo collegati al sistema con una shell ed inoltre avremo a disposizione un TGT con cui poterci collegare ad altre macchine, o meglio ad altri servizi. Vediamo il nostro TGT con l’utility klist:
$ klist Ticket cache: FILE:/tmp/krb5cc_500 Default principal: mrossi@AZIENDA.IT Valid starting Expires Service principal 03/10/04 18:13:40 03/11/04 04:13:07 krbtgt/AZIENDA.IT@AZIENDA.IT Kerberos 4 ticket cache: /tmp/tkt500 klist: You have no tickets cached
