Samba e condivisione con MS-Windows

Durante l'installazione creato il file con le password di Samba: /var/lib/samba/passdb.tdb. Cioè si utilizza come backend per le password il trivial database invece del vecchio formato smbpasswd.

Questi i comandi per elencare il contenuto del database password in formato nativo oppure in un formato compatibile col vecchio file /etc/samba/smbpasswd. Nel terzo esempio viene selezionato un backend specifico, diverso da quello di default in uso dal demone Samba:

pdbedit -L
pdbedit -L -w -b
pdbedit -L -w -b smbpasswd:/backup/samba/smbpasswd

I backend riconosciuti sono smbpasswd, tdbsam, ldapsam, nisplussam e mysql, la sintassi è spiegata in smb.conf(5).

Per far entrare una macchina Samba in un dominio Windows (da verificare):

# net ads join member -U Administrator
Administrator's password:
Joined 'SAMBA1' to realm 'DOMAIN.NET.'

Installare Windws XP. Durante l'installazione scegliere l'installazione a WORKGROUP, il join al dominio si effattua successivamente. Come nome host scegliere quello che sarà aggiunto a dominio, come nome di workgroup si può indicare quello del domino, ma lo si potrà anche modificare durante il join.

Con regedit cambiare la seguente chiave del registry da “1” a “0”:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
"requiresignorseal"=dword:00000000

In alternativa al regedit si può passare da Pannello di Controllo:

• Pannello di controllo, Strumenti di amministrazione
• Criteri di protezione locali
• Impostazioni di protezione
• Criteri locali
• Opzioni di protezione
• Membro di dominio: aggiunta crittografia o firma digitale ai dati del canale protetto (sempre): Disattivato

La modifica al registry serve a far comportare XP come un 2000 (rispetto alla crittografia) e quindi renderlo comprensibile da Samba.

• Pannello di controllo, Visualizzazione classica, Sistema
• Nome computer, Cambia (Per rinominare il computer o aggiungerlo a un dominio)
• Nome (non lo si può cambiare e deve esistere già nel dominio)
• Dominio (immettere il nome)
• Credenziali per aggiungere al dominio: Administrator/password

Se il controllore di dominio non si trova sulla LAN (raggiungibile in broadcast), bisogna appoggiarsi ad un server WINS eventualmente attivato sul PDC stesso. Il WINS client si attiva da:

• Pannello di controllo
• Connessioni di rete
• Connessione alla rete locale LAN
• Proprietà Protocollo Internet (TCP/IP), Avanzate

Il profilo utente viene per forza sincronizzato sul server di dominio! Qualche chiave di registry per disattivare questa porcata?

Le entità da migrare sono:

• account di sistema (di solito senza password)
• account samba, eventualmente migrando le password da un backend ad un altro
• account host, con password come per gli utenti
• SID dominio
• SID host?
• SID utenti?
• SID gruppi?
• RID utenti?

Che cos'è il SID? All Windows network machines (servers and workstations), users, and groups are identified by their respective SID. All desktop profiles are also encoded with user and group SIDs that are specific to the SID of the domain to which the user belongs.

Che cos'è il RID? Each user and group also needs a SID, and this is made up of both the Doamin SID and a RID 'Relitive Identifier'. Ad esempio:

Il SID di dominio corrisponde al SID di host del controllore di dominio (PDC).

Per scoprire il SID di host con un server Samba-2 in esecuzione si può usare:

# rpcclient <PDC_NAME> -U administrator
INFO: Debug class all level = 3   (pid 27528 from pid 27528)
Enter Password:
session setup ok
Domain=[ITFVMIL] OS=[Unix] Server=[Samba 2.2.3a-15 for Debian]
rpcclient $> lsaquery
domain ITFVMIL has sid S-1-5-21-408567135-360756301-4015389932

Con Samba 2.2.9 o successivo dovrebbe funzionare anche il comando smbpasswd -S. In alternativa in un domain controller Samba-2 ci dovrebbe essere il file /etc/samba/MACHINE.SID.

Su un domain controller Samba-3 invece dovrebbero funzionare questi comandi per vedere il SID di host e quello di dominio:

net GETLOCALSID
net GETLOCALSID <DOMAIN>

Come interrogare il PDC per farsi dire il SID completo (SID di dominio + RID) di un utente oppure di un host (ricordarsi che il nome di host termina con il carattere “$”):

# rpcclient SRVMIL -U administrator
INFO: Debug class all level = 3   (pid 28175 from pid 28175)
Enter Password:
session setup ok
Domain=[ITFVMIL] OS=[Unix] Server=[Samba 2.2.3a-15 for Debian]
rpcclient $> lookupnames amarchi
amarchi S-1-5-21-408567135-360756301-4015389932-3004 (1)
rpcclient $> lookupnames wkmil38$
wkmil38$ S-1-5-21-408567135-360756301-4015389932-3326 (1)

Su un server Samba-2 il RID utente (e gruppo) viene generato a partire dallo UID Unix con questo calcolo:

User RID = (UID * 2) + 1000
Group RID = (UID * 2) + 1001

Anche su un server Samba-3 pare che valga il calcolo di cui sopra, ma forse si può modificare a piacimento il RID e memorizzarlo in secrets.tdb?

Per cambiare SID di host in Samba-3:

net SETLOCALSID S-1-5-21-408567135-360756301-4015389932

Ma così non si cambia il SID di dominio, come fare? Funzionato questo metodo orribile:

• Fermato Samba
• Messo il vecchio file /etc/samba/MACHINE.SID
• Cancellato /var/lib/samba/secrets.tdb
• Riavviato Samba

Il MACHINE.SID pare che venga migrato automaticamente come host SID e domain SID in /var/lib/samba/secrets.tdb, probabilmente il file originale può essere successivamente eliminato.

In Samba-3 il SID del dominio, quello degli utenti e degli host viene memorizzato in /var/lib/samba/secrets.tdb. Per vedere il contenuto di un tdb (Trivial Database) si usa il comando tdbdump dal pacchetto Debian tdb-tools.

In un dominio NT ogni utente ha un RID (relative identifier), il RID è utilizzato per impostare il controllo di accesso (ACL) sugli oggetti di sistema: file, ecc. Nei profili roaming salvati sul PDC (ntuser.dat) ci sono delle ACL che fanno riferimento ar RID, purtroppo il metodo con cui Samba genera il RID differisce tra Windows NT, Samba-2 e Samba-3. Quindi con la semplice copia si ottiene un profile non utilizzabile a causa di problemi con i permessi.

E' possibile impostare la validità massima delle password samba (ad esempio 6 mesi) con il comando:

pdbedit --account-policy="maximum password age" -C 15768000

La policy diventa effettiva per tutti gli utenti, si controlla lo stato della password di un utente con:

pdbedit -v -u username

Con Samba 3 lo storage predefinito per le password etc. è il Trivial DataBase memorizzato in /var/lib/samba/secrets.tdb. È possibile manipolarne il contenuto con le utility fornite dal pacchetto tdb-tools. In particolare tdbtool fornisce una shell interattiva. Ecco una sessione in cui si apre il database, se ne elenca le chiavi contenute e se ne elimina una:

tdb> open /var/lib/samba/secrets.tdb
tdb> keys
key 16 bytes: SECRETS/SID/GRML
key 20 bytes: SECRETS/SID/INTRANET
key 67 bytes: SECRETS/LDAP_BIND_PW/cn=samba_servers,ou=People,dc=soluzioni,dc=per
tdb> delete SECRETS/SID/GRML
tdb> quit

Il contenuto completo del database può essere visualizzato con il comando tdbdump:

tdbdump /var/lib/samba/secrets.tdb

Cercando di accedere con smbclient ad una condivisione di un PC Windows 7 si ottiene l'errore:

SPNEGO login failed: invalid parameter

La spiegazione è nel bug 7577: una nuova funzionalità introdotta da Microsoft Live Sign-in Assistant causa un'incompatibilità con Samba.

Il problema dovrebbe essere risolto con samba 3.5.5 e successivi, in alternativa è necessario disinstallare la componente di Windows 7. Da Pannello di Controllo, Programmi e funzionalità la componente da rimuovere può chiamarsi Windows Live Essentials 2011 oppure Microsoft Live Sign-in Assistant.

Altra accortezza: l'accesso con utente senza password probabilmente fallisce perché viene interpretato da Windows 7 come accesso anonimo.