[Samba-it] Account utenti e macchine spirati

[Luigi Iotti]

> From: samba-it-admin at xsec.it [mailto:samba-it-admin at xsec.it]On Behalf Of
> simo
> Sent: Wednesday, January 24, 2007 11:26 PM
> To: samba-it at xsec.it
> Subject: Re: [Samba-it] Account utenti e macchine spirati
> 
> 
> On Wed, 2007-01-24 at 23:07 +0100, Luigi Iotti wrote:
> > Salve a tutti
> > 
> > Ho una CentOS 4 in un sito remoto con samba 3.0.14a che fa anche da  
> > DC. Il backend degli utenti è su OpenLDAP 2.2.13.
> > Stasera mi chiama un utente, sostenendo che da nessun PC si riesce più  
> > a fare logon al dominio.
> > L'unica cosa che riesco a vedere da remoto è che, con pdbedit, le  
> > password di tutti gli acocunt utenti e macchina sono spirati (Password  
> > must change attorno a dicembre 2006).
> > Naturalmente se provo a usare smbclient sulla macchina stessa con  
> > qualche utente, ottengo NT_STATUS_PASSWORD_MUST_CHANGE .
> > Resetto la password dell'utente, smbclient funziona. Il client con  
> > questo utente non riesce ancora a fare logon al dominio, ma se entra  
> > sul PC in locale poi fa \\samba riesce a collegarsi.
> > Allora suppongo che l'account macchina, pure con passowrd spirata, sia  
> > il responsabile. Provo a modificarne la data con pdbedit  
> > --pwd-must-change-time, ma non ottengo miglioramenti.
> 
> reboot del client dopo aver cambiato la data direi.

Alla fine ho scoperto che il problema è in ldap. Vedi sotto. Sarei interessato cmq a sapere qualcosa di più su cosa fanno i client membri del dominio con la loro password. Darò un'occhiata al TOSHARG, c'è qualche altro suggerimento?

> > Domattina vado ad indagare meglio sul posto, ma ho il sospetto che mi  
> > toccherà togliere i client dal dominio per poi rifarne il join.
> 
> E' sicuramente evitabile.

Suppongo tu intendessi che non c'è da fare nulla, o suggerisci qualcosa di diverso?
 
> > Potrei evitarlo? Oppure, potrei fare qualche tipo di backup che in  
> > futuro mi aiuti in casi analoghi?
> 
> Un backup non cambia le date di expire :)

Sì, intendevo che poichè tutte le date (e suppongo anche gli hash delle password) sembrano essere tornati a dicembre 2006, recuperando il backup potrei riportare lo stato a quello attuale o di qualche giorno fa. Ho il backup dei file grezzi di ldap, ripensandoci uno slapcat sarebbe più maneggiabile.

> Il problema e' che i client dovrebbero cambiarsi la data regolarmente
> (una volta a settimana) per cui le password non dovrebbero mai spirare
> per gli account macchina (modulo bachi, e so che ne sono stati corretti
> alcuni in quell'area recentemente).
> 
> sicuro che l'albero ldap sia integro btw?

Infatti. ho scoperto dopo il post che per qualche motivo il db ldap si è corrotto. Per fortuna un colpo di db_recover ha riportato le date di expiry a qualcosa di attuale. Spero che sia risolutivo, lo verifico domani e posto.
Sta di fatto che non è la prima volta che il db ldap mi si corrompe, niente di irreparabile per fortuna. E googlando vedo che non succede solo a me. Commentando senza filtri e al di là del caso specifico, dico che mettere in piedi tutto un sistema raffinato basato su un servizio di directory al posto di un file di testo (penso al vecchio smbpasswd) con tutto quello che ne consegue come gestione, per poi ritrovarsi a piedi magari perchè la macchina è stata spenta brutalmente, è un po' singolare, pensando che oggi possiamo avere i journal sia nei file system sia nei database. Certamente questa è un'altra storia, e so bene che ldap lo si sceglie perchè offre molte funzionalità in più. Ma limitatamente al fatto dei blocchi, è un punto a sfavore nei confronti della vecchia gestione via file di testo delle informazioni di autenticazione.
Vorrei quindi approfittare dell'occasione per avere commenti su come minimizzare questi malfunzionamenti dovuti a ldap (se sono troppo OT cassatemi pure).

Saluti e grazie
Luigi