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

Se è attiva l'opzione passdb backend = tdbsam allora le password sono contenute nel file /var/lib/samba/private/passdb.tdb (Samba 4.11), dovrebbe essere sufficiente copiare il file dal server vecchio a quello nuovo (dopo aver fermato il servizio).

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 oppure Windows 10 con login e password:

smbclient -L pc_win -U username%MySecret

si ottiene l'errore:

lp_load_ex: refreshing parameters
Initialising global parameters
params.c:pm_process() - Processing configuration file "/etc/samba/smb.conf"
Processing section "[global]"
added interface eth0 ip=10.0.0.100 bcast=10.0.0.255 netmask=255.255.255.0
Client started (version 3.4.2-47.fc12).
Connecting to 10.0.0.98 at port 445
Doing spnego session setup (blob length=336)
SPNEGO login failed: Invalid parameter
session setup failed: SUCCESS - 0

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

Testato con le seguenti versioni del client Samba:

Pare che Windows 10 (Home, ma forse anche altre versioni) non tentino più l'accesso a condivisioni remote in modalità guest, cioè senza login e password. Cliccando su una risorsa remota si potrebbe ottenere l'errore:

\\server\share is not accessible. You might not have permission to use this network resource.
Contact the administrator of this server to find out if you have access permissions.

The account is not authorized to log in from this station. 

in Italiano:

\\server\share non è accessibile. Non si dispone delle autorizzazioni necessarie
per utilizzare questa risorsa di rete. Contattare l'amministratore del server
per scoprire se si dispone delle autorizzazioni di accesso.

L'account non è autorizzato per accedere da questa stazione. 

La soluzione è da Control Panel, User Accounts, Credential Manager aggiungendo una voce con il nome o l'indirzzo IP del server remoto, un login e una password (eventualmente anche guest/guest). Senza bisogno di riavviare.

Problema con unità disco mappata su risorsa di rete (ad esempio lettera G: mappata su \\server\share) in modo permanente, al riavvio di Windows l'unità di rete risulta disconnessa e cliccando su di essa si ottiene l'errore:

Errore durante la riconnessione di G: a \\server\share
Microsoft Windows Network: Nome di dispositivo locale già in uso.
La connessione non è stata ripristinata.

in inglese:

An error occurred while reconnecting G: to \\server\share
Microsoft Windows Network: The local device name is already in use.
This connection has not been restored.

Non si riesce a trovare una soluzione. Una cosa strana: creando un batch che disconnette e riconnette l'unità di rete, il batch fallisce se viene eseguito poco dopo il logon (ad esempio in esecuzione automatica). Lo stesso batch invece funziona qualche minuto dopo il logon.

net use G: /delete
net use G: \\server\share

Se un PC Windows è unito a un dominio, le credenziali fornite per accedere ad una risorsa condivisa vengono fatte verificare al controllore del dominio stesso.

Ad esempio con il comando:

smbclient -U user%password -L '\\WORKSTATION'

il programma smbclient usa come nome di dominio ciò che è indicato dal parametro workgroup di /etc/samba/smb.conf e quindi la WORKSTATION chiede al controllore del dominio di autenticare l'utente user con la password fornita.

Se si utilizzano le credenziali di un utente locale della WORKSTATION (che non esiste a livello di dominio), il comando fallisce con:

session setup failed: NT_STATUS_LOGON_FAILURE

Per risolvere il problema si può indicare esplicitamente sulla riga di comando smbclient sia il nome del dominio che l'ambito di esistenza dell'utente; quello che fa effettivamente la differenza è l'ambito LOCAL/ aggiunto all'utente:

smbclient -W WORKGROUP -U LOCAL/user%password -L '\\WORKSTATION'

Con i filesyste moderni anche Windows ha l'attributo Lettura ed esecuzione per i file. Se questo attributo è impostato su un file PDF è possibile “eseguirlo” da riga di comando, cioè in generale viene avviato il visualizzatore di PDF con tale documento aperto.

Se il file è esportato da Samba 4.5 dovrebbe bastare dare l'attributo di eseguibilità Unix in maniera opportuna (es. a tutti).

Per forzare l'attributo di eseguibilità a prescindere dagli effettivi attributi Unix è possibile mettere questa direttiva nello share Samba:

[tmp]
    comment = Temporary file space
    path = /tmp
    acl allow execute always = yes
    ...

In questo caso l'attributo di eseguibilità comunque NON risulta da Windows (file, click destro ⇒ Proprietà ⇒ Sicurezza), ma una eventuale richiesta di esecuzione viene consentita.

Avendo configurato la scansione su Network (si intende cartella condivisa Windows) con login e password, durante il test si ottiene l'errore:

ECODE: 0x28242446, -28, STATUS_ACCESS_DENIED

Nel file di log Samba si legge:

Bad SMB2 signature for message

Selezionare il protocollo NTLMv2 sullo scanner non risolve il problema, mentre è risolutivo cambiare protocollo lato Samba con la direttiva:

server max protocol = NT1

Le versioni più recenti di protocollo implementate in Samba (SMB2_10 e SMB3_00) invece non sono compatibili.

Ci sono problemi ad accedere ad uno share Windows 10 se il client GNU/Linux è troppo vecchio (es. Debian 6 Squeeze con Samba 3.5). Con i nuovi aggiornamenti di Windows 10 (a partire dalla versione 1709) non è più disponibile il server SMBv1, vengono supportati in maniera predefinita solo protocolli successivi.

Utilizzando il vecchio protocollo si ottiene l'errore:

smbclient -U guest%guest -m NT1 '\\WIN10DESKTOP\Share'
protocol negotiation failed: NT_STATUS_CONNECTION_RESET

Purtroppo i nuovi protocolli non sono supportati con vecchie versioni di Samba:

smbclient -U guest%guest -m SMB2 '\\WIN10DESKTOP\Share'
Unrecognised protocol level SMB2

La situazione è chiarita dal post Microsoft: SMBv1 is not installed by default in Windows 10 Fall Creators Update and Windows Server, version 1709.

Dal post How to Roll Back Builds and Uninstall Updates on Windows 10 si capisce che disinstallare l'aggiornamento di Windows non è soluzione praticabile.

Per fortuna è ancora possibile abilitare il server SMB 1.0, basta accedere all'impostazione relativa da Pannello di Controllo:

• Pannello di Controllo
  • Programmi
    • Attiva o disattiva funzionalità di Windows (Programmi e funzionalità)
      • Supporto per condivisione file SMB 1.0/CIFS
        • [x] Server SMB 1.0/CIFS

È necessario un reboot (e forse condividere nuovamente la cartella) per ottenere il risultato.

NOTA1: Gli aggiornamenti di Windows possono essere rimossi entro un mese dalla loro applicazione (Windows-I, Aggiornamento e sicurezza), poi i file necessari vengono cancellati.

NOTA2: Dopo l'aggiornamento di sistema, il protocollo SMBv1 viene disattivato se non viene usato per 15 giorni.

Come verificare la versione e il build di Windows:

• Combinazione tasti Windows-I
  • Sistema ⇒ Informazioni su
    • Es. Versione: 1709, Build sistema operativo: 16299.192

In un dominio Windows esistono dei gruppi predefiniti che hanno ruoli ben specifici:

Lato Samba/Unix si definiscono dei gruppi Unix e si mappano i gruppi Windows su quelli Unix:

addgroup --system domadmin
addgroup --system domuser
addgroup --system domguest

net groupmap add ntgroup="Domain Admins" unixgroup=domadmin rid=512 type=domain
net groupmap add ntgroup="Domain Users"  unixgroup=domuser rid=1023 type=domain
net groupmap add ntgroup="Domain Guests" unixgroup=domguest rid=1024 type=domain

Il gruppo Domain Admins è speciale e deve avere RID = 512.

Per vedere i gruppi definiti:

net groupmap list
Domain Guests (S-1-5-21-4236855997-251099150-3575921365-1024) -> domguest
Domain Admins (S-1-5-21-4236855997-251099150-3575921365-512) -> domadmin
Domain Users (S-1-5-21-4236855997-251099150-3575921365-1023) -> domuser

Verificare che il SID corrisponda a quello del dominio:

net getlocalsid
SID for domain DOMAINNAME is: S-1-5-21-4236855997-251099150-3575921365

Gruppi e utenti si gestiscono con i tool Unix, ma si può verificare l'appartenenza di un utente ai gruppi Windows (cioè il mapping di Samba) con:

net user INFO john -U Administrator%password
None
Domain Admins
Domain Users
Domain Guests

Si può chiedere l'elenco dei permessi assegnabili:

net rpc rights list -U Administrator%password

e assegnare, vedere e revocare un privilegio ad un utente:

net rpc rights grant simone SeBackupPrivilege -U Administrator%password
net rpc rights list simone -U Administrator%password
net rpc rights revoke simone SeBackupPrivilege -U Administrator%password

Quando si utilizza come database degli utenti il tdbsam (opzione passdb backend di /etc/samba/smb.conf), è possibile specificare diversi campi per ogni utente, ad esempio il Full Name, che è indipendente dal campo gecos estratto da /etc/passwd in Unix.

Per vedere tutti gli utenti e tutti i loro attributi si usa:

pdbedit -Lv

Ecco ad esempio come modificare un attributo:

pdbedit --fullname="Niccolo Rigacci" -u niccolo

After a Windows 7 update (which upgraded the operating system to Windows 7 Professional 7601 Service Pack 1) a connection from a GNU/Linux host via smbclient stopped working:

smbclient -L pcwindows7 -U username%password
session setup failed: NT_STATUS_INVALID_HANDLE

asking for debug on the smbclient command line showed the usual, useless data:

SPNEGO login failed: Invalid handle

The Event Viewer on the sharing host were showing the expected Logon Type 3 (Network), but the event were immediately followed by a disconnect event.

It turned out theat the user had the Administrator's privileges, removing that and making it a regular user, fixed the problem.

Ecco alcuni esempi di log (ripuliti da informazioni non strettamente necessarie come timestamp, riferimento alla funzione sorgente, ecc.):

_samr_create_user:
    Running the command
    `/usr/sbin/useradd -g machines -c "Machine account" -d /var/lib/samba -s /bin/false myhost$'
    gave 0
Forcing Primary Group to 'Domain Users' for MYHOST$
api_rpcTNP: rpc command: SAMR_QUERYUSERINFO
User:[MYHOST$]
api_rpcTNP: rpc command: SAMR_GETUSERPWINFO
api_rpcTNP: rpc command: SAMR_SETUSERINFO2
Forcing Primary Group to 'Domain Users' for MYHOST$

check_ntlm_password:  Checking password for unmapped user
                      [MYDOMAIN]\[myuser]@[MYHOST] with the new password interface
check_ntlm_password:  mapped user is: [MYDOMAIN]\[myuser]@[MYHOST]
Forcing Primary Group to 'Domain Users' for myuser
check_ntlm_password: sam authentication for user [myuser] succeeded
check_ntlm_password:  authentication for user [myuser] -> [myuser] -> [myuser] succeeded
Forcing Primary Group to 'Domain Users' for myuser

È stato usato un account macchina al posto di un account utente:

check_ntlm_password:  Checking password for unmapped user
                      [MYDOMAIN]\[MYHOST$]@[MYHOST] with the new password interface
check_ntlm_password:  mapped user is: [MYDOMAIN]\[nobody]@[MYHOST]
check_sam_security: Couldn't find user 'nobody' in passdb.
check_ntlm_password:  Authentication for user [MYHOST$] -> [nobody] FAILED with
                      error NT_STATUS_NO_SUCH_USER, authoritative=1