[Samba-it] samba pdc e ldap.

[Luigi Iotti]

> From: samba-it-bounces at xsec.it [mailto:samba-it-bounces at xsec.it]On
> Behalf Of Mauro Sanna

> > Fatto questo, quando ti serve un utente lo aggiungi in ldap, e diventa
> > automaticamente anche un "utente del server".
> 
> Si ma scusa se sono un po duro, in ldap aggiungo gli utenti utilizzando
> gli smbldap-tools, questi utenti vanno poi anche configurati fisicamente
> nel server coem utenti di sistema o no? 

Non colgo il senso del "fisicamente", ma a parte questo la risposta è NO. Cosa manterresti gli utenti in LDAP a fare, se poi devi duplicarli in quanche altro backend, ad esempio il solito passwd? Guarda che se configuri le cose per bene (e se non configuri le cose per bene, non ti funziona pressochè niente) gli utenti LDAP diventano essi stessi utenti di sistema, ne più ne meno di quelli definiti in passwd. Quindi sparisce la distinzione tra utenti di sistema ed utenti definiti in LDAP. Certo, gli utenti devono essere dei PosixAccounts, ad esempio, ma se hai seguito i pdf distribuiti col sorgente di samba non c'è problema. 
Esisterebbe anche la possibilità di mantenere in LDAP solo gli attributi Samba dell'utente, e lasciare la parte Unix (l'uid, la home, ecc) in altro backend, tipo passwd ad esempio. Suppongo che non sia questo il tuo intento. 

> O vanno lasciati solo nel
> database ldap.

Si. A meno che tu non voglia il setup strano che dicevo appena sopra.

> Il comando getent passwd mi fa vedere sia gli utenti che stanno
> fisicamente sul server, root, ecc. che quelli che stanno solo su ldap.

Ah bene, se è già così sei quasi a posto. Almeno hai passato la parte complicata.

> Questi che stanno su ldap li devo anche aggiungere coem utenti di
> sistema sul server?

Eh no. Vedi sopra.
Piccola digressione OT, semplificata, incompleta, sicuramente fallace, ma se ce ne fosse bisogno: una volta i sistemi Unix erano delle macchine dipartimentali. Gli utenti erano definiti in un file di testo, /etc/passwd, accessibile solo nell'ambito della macchina stessa. Finchè le macchine erano dipartimentali, il classico PDP-11 ad es., non c'era problema. Con le reti, ha iniziato a porsi il problema di definire un utente in un solo posto ma di poterlo usare, con gli stessi attributi (uid, gruppi...) su macchine diverse. Il problema è l'analogo di quello risolto dai Domain Controller in casa M$: gestire centralmente gli utenti. È nato Yellow Pages, o NIS, dove tu definivi gli utenti in un solo posto e te li ritrovavi su N sistemi UNIX, come se fossero utenti di sistema. 
Passo successivo: L'idea è grandiosa, ma NIS fa ca..re, usiamo un altro tipo di DB per mantenere gli utenti. Cosa possiamo usare? DB SQL di vario tipo, LDAP, Berkeley db, file di testo diversi da quelli di default... Insomma, tante possibilità. Ideona: rendiamo le API Unix che trattano gli utenti modulari rispetto al backend in cui le info sugli utenti sono mantenute. È nato l'nsswitch, che configuri in /etc/nsswitch.conf . È l'analogo, ma non la stessa cosa, di PAM per l'autenticazione. 
Quindi tu cosa fai? Configuri LDAP per contenere gli attributi per gli utenti (gli oggetti PosixAccount) poi configuri l'nsswitch per prendere gli utenti di sistema sia dai file "storici" (il famoso passwd) che dal nuovo backend, ldap appunto. In pratica, usi nss_ldap, che è il modulo per nsswitch che legge da ldap.

> > Perchè questi utenti definiti in ldap siano utilizzabili da samba, oltre
> > alle configurazioni corrette, devono avere gli attributi 
> specifici di samba,
> > me se hai seguito la documentazione questo non lo puoi sbagliare direi.
> > 
> 
> Veramente questa sezione non l'ho trovata, devo aggiungere l'utente con
> relativa password col comando smbpasswd?

Bè guarda, mi è sfuggito il documento che segui. Attenzione perchè in giro c'è un sacco di documentazione approssimativa. Usala come fonte di ispirazione, ma con spirito critico. Se ti manda nel fosso, tu fermati prima (cioè: cerca di capire cosa ti fa fare). Io ti consiglio i PDF che sono inclusi nel sorgente di Samba. 
In breve, ogni utente per essere anche utilizzabile via samba deve essere anche un sambaSamAccount . Che tool usi poi per inizializzarne la password dipende dai tuoi gusti.

> >  che risiedano solo su ldap?
> > 
> > Il discorso è concettualmente molto simile a quello degli utenti, quindi
> > ogni macchina del dominio deve avere il suo uid unix visibile con getent
> > passwd (ebbene sì, è così; anche se ricordo che all'inizio 
> l'idea di avere i
> > miei account unix "mescolati" a account macchina mi faceva storcere
> > qualcosa.. comunque li riconosci perchè gli account macchina 
> vengono creati
> > con un $ finale nel nome). La differenza "procedurale" è che non devi
> > necessariamente definirli tu a mano perchè se configuri 
> correttamente un add
> > machine script in smb.conf, questo viene automaticamente invocato quando
> > aggiungi la macchina al dominio. 
> 
> Infatti ho lo script su smb.conf che va proprio questo.
> La macchina pero' viene aggiunta solo su ldap, come per gli utenti devo
> anche qui aggiungere un account fisico sul server?

No. Come direbbe Simo, doppia bacchettata carpiata sulle mani prone. Lo script deve già di per se fare tutto il necessario (mi viene da dire: sennò, se non se la sbriga lo script da solo e devi intervenire a mano ogni volta, tanto vale che fai tutto tu, no?). 
Tieni presente che scopo dello script è proprio creare l'account di sistema, cioè l'utente unix che ha come nome il nome della macchina col $ finale. Naturalmente, per quanto scritto sopra, questo account utente, che in realtà rappresenta una macchina, vorrai crearlo in ldap. Per questo userai uno script che agisca appunto su ldap (scusa la prolissità).
Se dopo che lo script è stato eseguito da Samba per aggiungere l'account della macchina pc-pino, per dire, tu fai getent passwd e ti trovi la riga iniziante in pc-pino$ , allora questa parte è a posto. Se non la trovi, allora o lo script fallisce, o stai usando nscd che fa cache, o nss_ldap non pesca i tuoi utenti dal posto giusto, includendo cioè la porzione dell'albero ldap in cui lo script definisce l'account computer.