Mappare una condivisione file VPN con l’account Samba che il server conosce

Connetti il tunnel e la condivisione chiede ancora una password che l’utente ritiene corretta. In un’installazione Samba autonoma il login VPN e il login SMB sono credenziali non correlate: uno autorizza il tunnel, l’altro viene verificato dal file server. Mappare l’unità con l’account VPN fallisce quindi anche quando la password è giusta e il percorso di rete è perfetto. Questa distinzione spiega la maggior parte dei fallimenti di mappatura su una VPN.

La soluzione non è reimpostare l’account VPN. È indicare un’identità che il server Samba conosce davvero, poi verificare che la stessa identità abbia diritti sulla condivisione e sulla directory.

Il login VPN e il login SMB sono identità diverse

Un account VPN viene valutato dal gateway VPN secondo la sua politica. Risponde se questo client può entrare nella rete privata. Non dice nulla su quale account SMB esista su un file server all’interno di quella rete.

Un account Samba risiede nel backend di autenticazione del server, con il proprio database delle password e il proprio nome. Due macchine possono avere entrambe un utente chiamato alice senza condividere un sistema di identità, una password o un identificatore utente. I nomi coincidono; gli account no.

Un server Samba integrato nel dominio cambia il quadro: l’identità proviene dalla directory e da Kerberos, non da un elenco locale di account. In tal caso usa l’identità della directory e la configurazione SMB supportata invece di creare duplicati locali per imitare l’appartenenza al dominio. Verifica quale modello usa il server prima di creare qualsiasi account.

Scopri quale identità sta usando Windows davvero

Windows memorizza le connessioni per server. Se una sessione esistente verso lo stesso server è stata aperta con un altro account, una nuova mappatura può riutilizzare quella sessione o fallire con un errore di autenticazione che nomina l’utente sbagliato. Ecco come una password corretta sembra sbagliata. Ispeziona le connessioni attuali prima di cambiare le credenziali.

net use
cmdkey /list
klist

Il primo comando mostra le unità mappate e le sessioni aperte, il secondo mostra le credenziali salvate che possono essere applicate automaticamente, e il terzo mostra i ticket Kerberos quando è in uso un dominio. Una credenziale salvata può sovrascrivere silenziosamente l’account che intendevi digitare.

Rimuovi solo la connessione o la credenziale che appartiene a questo problema. Disconnettere tutte le unità o sostituire il nome del server con un indirizzo IP nasconde la scelta dell’identità e può rompere la firma o le policy basate sui nomi.

Mappa la condivisione con l’account che il server riconosce

Indica l’account nella forma che il server si aspetta e lascia che Windows chieda la password, così il segreto non finisce nella cronologia dei comandi o in uno script:

net use Z: \\files.corp.example\team * /user:FILESERVER\alice /persistent:no

Il componente server prima della barra rovesciata è il contesto di identità del server Samba, non il gateway VPN. L’asterisco richiede un prompt interattivo della password, e /persistent:no tiene la mappatura fuori dal successivo accesso. Scegli una lettera di unità libera.

Se il server è integrato nel dominio, il componente utente può essere invece un nome di directory o un’identità qualificata dal dominio. Usa la forma documentata dall’amministratore; inventare un account locale con lo stesso nome crea una seconda identità e una seconda password da mantenere.

Validità dell’account, accesso alla condivisione e diritti del filesystem sono tre controlli

Samba verifica se l’identità si autentica, se la definizione della condivisione la ammette, e se il filesystem concede l’operazione richiesta. Superare il primo controllo non implica gli altri due. Una condivisione può essere visibile e comunque rifiutare le scritture perché i permessi della directory dicono così.

Una condivisione limitata con valid users ammette solo gli account o i gruppi elencati. L’account può autenticarsi correttamente e comunque essere rifiutato da quella riga. Verifica la definizione della condivisione prima di concludere che la password sia sbagliata.

Lato filesystem contano sia il processo Samba sia l’identità mappata. Una directory di proprietà di root con modo 700 non accetterà scritture da un account ordinario anche quando la definizione della condivisione lo consente. Prova con una lettura e poi una scrittura in una directory che l’account dovrebbe usare.

Risolvi una sessione in conflitto senza infrangere la policy

Quando la causa è una sessione obsoleta, chiudi quella singola connessione e mappa di nuovo con l’account previsto. Se una credenziale salvata continua a ripresentarsi, rimuovi quella credenziale invece dell’intero elenco di unità. Poi conferma la nuova sessione con net use.

Mantieni la firma SMB, la cifratura e la policy degli account richieste. Un server che rifiuta una sessione non firmata o non cifrata sta applicando la policy, non leggendo male la password, e indebolirlo perché la mappatura riesca scambia sicurezza con un sintomo.

Annota il nome del server, la forma esatta dell’account e i diritti di condivisione e directory che hanno funzionato. Altrimenti la prossima persona che mapperà l’unità proverà prima il login VPN, perché sono le credenziali con cui ha raggiunto la rete.