Perché una condivisione file di Windows a volte funziona e altre volte no — Analizzare Kerberos, NTLM e le credenziali

«Ieri funzionava.» «Esplora file riesce ad aprirlo, l’applicazione no.» «Un riavvio ha risolto.» I problemi con le condivisioni file diventano più difficili da analizzare quando i tentativi sembrano identici.

Anche quando credete di aprire la stessa condivisione, Windows può eseguire operazioni diverse se differiscono il nome di destinazione, l’account di esecuzione o le connessioni esistenti. Trovare quelle differenze è il punto di partenza dell’analisi.

Questa guida diagnostica riunisce i comandi da eseguire, come interpretarne i risultati e dove indagare dopo, anziché attribuire una causa al solo sintomo. Per i protocolli in sé si veda NTLM e Kerberos spiegati. Per la progettazione applicativa si veda Unità di rete e insidie dei percorsi UNC.

1. Si parte da qui: conclusione e indice dei sintomi

Analizzate in quest’ordine: È raggiungibile? → Quale identità si è connessa? → Quali requisiti di autenticazione e protezione si applicano? → Quell’identità può eseguire l’operazione? Registrate queste condizioni nello stesso formato per i tentativi riusciti e per quelli falliti. Un sintomo è un punto di partenza, non una causa accertata.

flowchart TB
    accTitle: Dal sintomo alle prove
    accDescr: Selezionate le piste a partire dal sintomo, confrontate le prove dei tentativi riusciti e falliti, poi scegliete una correzione.
    symptom["Selezionare il sintomo"] --> compare["Confrontare successo e fallimento"]
    compare --> evidence["Restringere le piste con i registri"]
    evidence --> fix["Cambiare una cosa e riprovare"]

Figura 1: Usate i sintomi per avviare l’analisi e scegliete le correzioni solo dopo aver esaminato le prove.

L’ambito sono le condivisioni SMB 2/3 su Windows 11 e Windows Server tramite normali connessioni TCP 445. Gli esempi PowerShell sono rivolti a Windows PowerShell 5.1. È una guida di livello intermedio per chi amministra e sviluppa, ma anche chi non ha accesso amministrativo al server può iniziare raccogliendo informazioni lato client.

Distinguete domini AD, condivisioni Windows in un gruppo di lavoro e account propri di un NAS. Questo articolo tratta il normale Kerberos di AD e le configurazioni tradizionali con account locali; SMB over QUIC, l’autenticazione propria di Azure Files e le singole configurazioni IAKerb o LocalKDC restano fuori. Con DFS annotate anche il server di destinazione finale. Impostazioni e valori predefiniti si basano sulla documentazione ufficiale verificata l’8 settembre 2026; la configurazione reale prevale sulle supposizioni tratte dal nome del sistema operativo.

Stabilite prima quali account la condivisione è configurata ad accettare. AD gestisce in modo centralizzato gli account di un’organizzazione, mentre gli account locali appartengono ai singoli PC. Un NAS può usare account propri o aderire ad AD. Non deducete Kerberos da una LAN aziendale né NTLM dal fatto che il server sia un NAS; chiedete all’amministrazione la configurazione di autenticazione.¹²³

Che il PC appartenga o meno a un dominio e quali credenziali abbia usato questa connessione sono anch’esse domande distinte. Negli esempi seguenti CORP\alice è un account di dominio, mentre FILESRV01\alice è un account locale sul file server. Avere un utente con lo stesso nome sul proprio PC non conferisce necessariamente a quell’utente le stesse autorizzazioni sul server.⁴⁵

Nel diagramma, una linea continua indica una relazione che vale sempre e una linea tratteggiata indica una relazione condizionale (le condizioni sono nella spiegazione di ciascuna relazione nella pagina di dettaglio). L’elenco completo delle relazioni (in totale 19, con evidenza e livello di certezza) e le definizioni dei concetti principali sono raccolti nella pagina di dettaglio della mappa della conoscenza (in giapponese). Dati: JSON-LD / Turtle

2. Separate le fasi nascoste dietro «impossibile connettersi»

Aprire un file comporta stabilire la comunicazione, negoziare i requisiti SMB, autenticare una sessione, connettersi a una condivisione ed eseguire un’operazione su file. Un’autenticazione riuscita non concede l’accesso alla condivisione o al file. Un messaggio che dice che il percorso di rete non è stato trovato può persino essere legato a un accesso guest rifiutato. Non diagnosticate un guasto DNS da quel solo messaggio.⁶⁷

flowchart TB
    accTitle: Fasi prima che si apra un file condiviso
    accDescr: Raggiungibilità, negoziazione SMB, autenticazione, connessione alla condivisione e operazioni su file possono fallire separatamente.
    net["Risoluzione dei nomi e TCP"] --> negotiation["Negoziazione dei requisiti SMB"]
    negotiation --> session["SESSION_SETUP: autenticazione"]
    session --> tree["TREE_CONNECT: condivisione"]
    tree --> file["CREATE e altre operazioni su file"]

Figura 2: Il successo in una fase non dimostra il successo in quella successiva.

Qui successo significa eseguire l’operazione voluta sul file voluto. Vedere un PC sotto «Rete» in Esplora file, vedere un elenco di condivisioni e leggere un determinato file non sono equivalenti. Annotate il percorso UNC e l’operazione che effettivamente falliscono, non solo se un elenco sia visibile.

3. Raccogliete le prove prima di riavviare o cambiare impostazioni

Eliminare subito connessioni o ticket cancella lo stato che volevate confrontare. Annotate prima orario, percorso UNC, utente, sistema operativo e connessioni esistenti sul client. I comandi seguenti leggono lo stato. Quando analizzate un guasto in un servizio, non trattate i risultati di questo terminale interattivo come risultati del servizio stesso.⁴⁸⁹

Get-Date -Format o
whoami /user
whoami /groups
Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption, Version, BuildNumber
net use
cmdkey /list
klist

Raccogliete inoltre quanto segue se avete il permesso di interrogare le connessioni SMB. Un risultato di accesso negato significa «non è stato possibile eseguire l’interrogazione», non «non ci sono connessioni». Contrassegnate con quel contesto di esecuzione qualsiasi risultato raccolto di nuovo come amministratore. Elevare in silenzio l’intera analisi può cambiare la sessione di accesso che state confrontando.⁴¹⁰

Get-SmbConnection | Format-List *

In Get-SmbConnection esaminate Credential oltre a UserName. L’identità dell’accesso locale e le credenziali usate per la connessione alla condivisione possono differire. Confrontare ServerName, ShareName, UserName e Credential fra tentativi riusciti e falliti aiuta a stabilire se state confrontando la stessa connessione.⁴

flowchart TB
    accTitle: Informazioni memorizzate contro stato attivo
    accDescr: Esaminate separatamente credenziali memorizzate, connessioni SMB e ticket Kerberos.
    snapshot["Catturare nello stesso momento"] --> stored["Credenziali memorizzate"]
    snapshot --> connection["Connessioni SMB stabilite"]
    snapshot --> ticket["Cache dei ticket"]
    stored -.-> verify["Confrontare l'uso reale con i registri"]
    connection --> verify
    ticket -.-> verify

Figura 3: Distinguete ciò che è memorizzato da ciò che la connessione in esame ha effettivamente usato.

Questi output contengono nomi utente, nomi di server interni, indirizzi IP e informazioni simili. Limitate l’accesso alle registrazioni raccolte. Prima di condividerle all’esterno, rendetele anonime preservando le corrispondenze necessarie al confronto. Non occorre pubblicare password, hash o i ticket stessi.

4. Verificate prima la risoluzione dei nomi e TCP 445

Quello che segue è un test attivo di raggiungibilità eseguito sul client. Sostituite il nome del server con il nome di connessione reale. Annotate separatamente risoluzione dei nomi e raggiungibilità TCP.¹¹

$Server = 'filesrv01.corp.example.com'
Resolve-DnsName -Name $Server
Test-NetConnection -ComputerName $Server -Port 445 -InformationLevel Detailed

Se TcpTestSucceeded è False, analizzate a quel punto la raggiungibilità prima dell’autenticazione. Verificate IP di destinazione, VPN e instradamento, firewall di client e server e l’endpoint in ascolto sul server. Un ping riuscito o fallito non è una connessione TCP 445 riuscita o fallita. Viceversa, una raggiungibilità TCP riuscita lascia non verificati nome della condivisione, autenticazione, firma e autorizzazioni.¹¹

flowchart TB
    accTitle: Interpretare un test di connessione TCP
    accDescr: Un test TCP 445 fallito porta ad analizzare la raggiungibilità; uno riuscito porta a SMB e alle fasi successive.
    tcp["Testare TCP 445"] --> result{"È riuscito?"}
    result -->|"No"| route["Verificare destinazione, percorso, blocco"]
    result -->|"Sì"| smb["Verificare SMB, autenticazione, accesso"]

Figura 4: Il successo TCP dimostra che potete passare alla fase successiva, non che l’autenticazione sia riuscita.

Quando un nome e un indirizzo IP si comportano diversamente, confrontate RemoteAddress e i risultati della risoluzione dei nomi. Nome breve, FQDN e alias non raggiungono necessariamente lo stesso IP. Anche quando lo fanno, i requisiti di autenticazione della sezione seguente restano a parte. Se cambiare il nome sembra risolvere il problema, annotate che cosa è cambiato.

5. Verificate i prerequisiti Kerberos quando nome e IP divergono

5.1. Lo stesso IP non implica la stessa autenticazione

Per impostazione predefinita Windows non tenta Kerberos quando il nome di destinazione è un indirizzo IP. È possibile configurare eccezioni con TryIPSPN e SPN basati su IP, ma l’approccio di riferimento di questa guida è stabilire il nome DNS e l’identità di servizio corretti. Riuscire con un indirizzo IP è una prova utile per confrontare risoluzione dei nomi, autenticazione e connessioni esistenti; non dimostra una soluzione stabile.¹²

flowchart TB
    accTitle: I requisiti di autenticazione dipendono dal nome di connessione
    accDescr: Verificate i requisiti Kerberos legati al nome per le destinazioni indicate per nome host e tenete conto del comportamento predefinito di non tentare Kerberos per le destinazioni indicate per indirizzo IP.
    unc["Notazione della destinazione nel percorso UNC"] --> name["Nome host o FQDN"]
    unc --> ip["Indirizzo IP"]
    name --> spn["Verificare l'SPN di quel nome"]
    ip --> fallback["Nessun tentativo Kerberos per impostazione predefinita"]

Figura 5: Anche quando due nomi identificano lo stesso dispositivo, cambiare il nome di connessione cambia le condizioni di autenticazione.

Kerberos richiede i ticket usando un identificatore di servizio chiamato SPN. Risolvere un alias DNS e autenticare correttamente il servizio sotto quell’alias sono cose diverse. Inoltre non ogni fallimento di Kerberos comporta un ripiego su NTLM. Usate i registri reali per distinguere se un ripiego sia possibile, se l’autenticazione sia fallita e se NTLM sia limitato.¹³¹

5.2. Separate l’ottenimento del ticket dall’accettazione da parte del server

In un ambiente AD l’amministrazione dovrebbe esaminare la registrazione dell’SPN per il nome usato per connettersi. Le interrogazioni in sola lettura seguenti sono per una macchina di amministrazione in grado di interrogare AD. Assicuratevi di disporre degli strumenti necessari e dei permessi di lettura della directory.¹⁴

setspn -Q cifs/filesrv01.corp.example.com
setspn -Q HOST/filesrv01.corp.example.com

L’assenza di una registrazione esplicita cifs/... non dimostra di per sé che manchi un SPN. Per gli account computer un SPN HOST può sostituire classi di servizio come cifs. Viceversa, trovare una registrazione non esclude problemi come l’appartenenza a un account diverso dall’account di servizio reale o registrazioni duplicate. Gli amministratori AD dovrebbero verificare l’appartenenza prima di modificare registrazioni; non aggiungete un SPN meccanicamente solo perché un’interrogazione non ha restituito nulla.¹⁴

flowchart TB
    accTitle: Che cosa stabiliscono le verifiche di SPN e ticket
    accDescr: Risoluzione dell'SPN, ottenimento del ticket e accettazione da parte del file server sono verifiche distinte.
    lookup["Proprietario dell'SPN e sostituzione HOST"] --> issue["È possibile ottenere un ticket?"]
    issue --> accept["Viene accettato per l'autenticazione SMB reale?"]
    accept --> logs["Confrontare con i registri lato server"]

Figura 6: Ottenere un ticket non garantisce che il file server lo accetti.

Dopo aver conservato lo stato iniziale, potrebbe essere necessario provare klist get cifs/filesrv01.corp.example.com. È un test attivo che richiede un ticket e modifica la cache. Se fallisce, analizzate raggiungibilità del DC, sincronizzazione dell’orario, nomi e SPN. Se riesce, l’accesso SMB non è comunque garantito. Non applicate i risultati sui ticket di un utente interattivo a un problema che si verifica in un servizio.⁸¹

Per un NAS senza dominio o per l’autenticazione con account locali, verificate prima i metodi di autenticazione e le impostazioni degli account che la condivisione supporta, anziché iniziare da riparazioni degli SPN in AD. Anche in ambienti con funzioni di autenticazione più recenti, preferite le registrazioni delle connessioni alle supposizioni tratte dai nomi dei prodotti.

6. Esplora file riesce, l’applicazione fallisce

6.1. Un nome utente uguale non basta

Confrontate account di esecuzione, sessione di accesso, elevazione, percorso UNC e operazione. Un servizio viene eseguito in una sessione diversa da un accesso interattivo, anche se configurato con lo stesso account utente. Anche le mappature delle lettere di unità sono limitate alle sessioni di accesso, quindi distinguete prima Z:\data da \\server\share\data. Passare a un percorso UNC risolve il problema della lettera di unità; non concede in più autenticazione o autorizzazioni.¹⁰

flowchart TB
    accTitle: Esplora file e un servizio usano contesti diversi
    accDescr: Anche sullo stesso PC, confrontate gli accessi interattivi e di servizio come sessioni distinte con credenziali proprie.
    pc["Stesso PC"] --> explorer["Accesso interattivo"]
    pc --> service["Accesso di servizio"]
    explorer --> a["Connessioni e accesso in quella sessione"]
    service --> b["Connessioni e accesso in un'altra sessione"]

Figura 7: Lo stesso PC e lo stesso nome utente non condividono necessariamente lo stesso stato delle connessioni.

Fate registrare all’applicazione che fallisce il proprio ID di processo, l’identità di esecuzione, lo stato di elevazione, il percorso reale, il nome dell’operazione, l’eccezione originale e il codice di errore. Se usa la rappresentazione, catturate anche l’identità effettiva del thread che esegue l’operazione. Non chiudete un’analisi su un servizio solo perché una sessione PowerShell di amministratore è riuscita ad aprire la condivisione.

6.2. Account di servizio e tipi di accesso delle attività

Quando un servizio usa le proprie credenziali predefinite, LocalSystem presenta in rete le credenziali del computer, mentre LocalService presenta credenziali anonime. Per l’accesso di LocalSystem a una condivisione di dominio, le autorizzazioni rilevanti appartengono all’identità effettivamente usata, per esempio l’account computer, non all’utente interattivo. Le implementazioni che usano credenziali esplicite o rappresentazione richiedono verifiche proprie.¹⁵¹⁶

flowchart TB
    accTitle: Privilegi locali contro identità remota
    accDescr: Con le credenziali di rete predefinite, LocalSystem e LocalService presentano identità diverse.
    service["Credenziali predefinite del servizio"] --> system["LocalSystem"]
    service --> local["LocalService"]
    system --> machine["Credenziali del computer"]
    local --> anonymous["Credenziali anonime"]

Figura 8: Ampi privilegi locali non rendono il servizio l’utente interattivo sulla condivisione remota.

In Utilità di pianificazione esaminate il tipo di accesso oltre al nome dell’account. TASK_LOGON_S4U non memorizza alcuna password e non offre accesso alla rete né ai file crittografati. Non presumete che un’attività configurata senza password memorizzata abbia le stesse condizioni di un normale accesso interattivo. Configurate i processi gestionali con un account di servizio adatto, un tipo di accesso appropriato e autorizzazioni minime, anziché dipendere dal fatto che qualcuno apra prima la condivisione in Esplora file.¹⁷

7. Distinguete quattro significati di «non serve la password»

L’assenza di una richiesta non dimostra un accesso non autenticato. Possono essere in uso le credenziali della sessione corrente, credenziali memorizzate o una sessione SMB già stabilita. Una voce in cmdkey /list da sola non stabilisce che la connessione l’abbia usata.⁴⁹

flowchart TB
    accTitle: Che cosa significa l'assenza di una richiesta di password
    accDescr: Non deducete dall'interfaccia un accesso non autenticato; distinguete credenziali, sessione esistente, password vuota e accesso guest.
    prompt["Non compare alcuna richiesta di password"] --> identity["Verificare l'identità effettivamente accettata"]
    identity --> authenticated["Credenziali o sessione esistente"]
    identity --> blank["Account con password vuota"]
    identity --> guest["Guest"]

Figura 9: Interfacce dall’aspetto identico possono nascondere meccanismi di autenticazione diversi.

Quando il file server è Windows e il suo criterio che limita gli account locali con password vuota all’accesso da console è attivo, i normali accessi di rete con quegli account sono limitati. È cosa distinta dall’impostazione che consente l’accesso guest. Se qualcuno afferma che in passato si è connesso un utente con password vuota, verificate prima sul server se quell’account abbia effettivamente autenticato la connessione precedente. Anziché disattivare la restrizione come prima risposta, valutate un account adeguato dotato di password per l’accesso alla condivisione.²³

Se amministrate il file server Windows, eseguite quanto segue in una sessione PowerShell di amministratore su quel server mentre l’accesso funziona. Non confondete Get-SmbConnection, eseguito sul client, con Get-SmbSession, eseguito sul server che accetta la connessione.¹⁸

Get-SmbSession |
    Select-Object SessionId, ClientComputerName, ClientUserName, NumOpens

Usate ClientComputerName e l’orario del tentativo per individuare la sessione pertinente, poi esaminate ClientUserName. Ciò descrive le sessioni SMB attualmente stabilite; non spiega una connessione fallita in precedenza né determina se sia stato usato Kerberos o NTLM. Se lo stesso client ha più sessioni, confrontate anche gli orari delle operazioni dell’applicazione e le registrazioni specifiche di SMB. Se la connessione è già chiusa, passate ai registri della sezione 12.¹⁸

8. Errore 1219 e fallimenti al cambio utente

L’errore 1219 indica un conflitto che coinvolge più connessioni allo stesso server con nomi utente diversi. Le connessioni esistenti verso quel server contano anche quando i nomi delle condivisioni differiscono. Usate prima net use e Get-SmbConnection per esaminare le connessioni verso il server di destinazione. Prima di cambiare credenziali, individuate i file aperti e le applicazioni che usano quelle connessioni.¹⁹²⁰

flowchart TB
    accTitle: Le credenziali possono entrare in conflitto fra condivisioni diverse
    accDescr: Aggiungere dallo stesso contesto di connessione una connessione con un altro utente verso lo stesso server può creare conflitto anche se il nome della condivisione è diverso.
    existing["Già connessi al server come utente A"] --> new["Connettersi a un'altra condivisione come utente B"]
    new --> conflict["Conflitto di credenziali: 1219"]
    conflict --> inspect["Esaminare le connessioni esistenti per server"]

Figura 10: Esaminate insieme server e credenziali, non solo il nome della condivisione.

Quanto segue modifica lo stato delle connessioni. Solo dopo aver interrotto l’uso della destinazione e ottenuto l’approvazione sull’impatto dovreste disconnettere e riconnettere la connessione specifica individuata. Sostituite i nomi di esempio di server, condivisione e account. * richiede una richiesta di password interattiva; non mettete la password direttamente sulla riga di comando.⁵

net use "\\filesrv01.corp.example.com\data" /delete
net use "\\filesrv01.corp.example.com\data" /user:CORP\alice * /persistent:no

Disconnettere una condivisione può lasciare connessioni verso altre condivisioni o utilizzi sullo stesso server. Riesaminate l’elenco e liberate solo le connessioni necessarie verso il server di destinazione. Non fate di net use * /delete né dell’aggiramento indefinito dei conflitti con alias e indirizzi IP la soluzione di riferimento. Verificate poi che l’applicazione reale si connetta con le credenziali previste.

9. Quando un riavvio risolve, chiedetevi che cosa sia cambiato

Poiché un riavvio cambia più condizioni, un miglioramento da solo non può individuare una causa unica. La tabella seguente fornisce assi di confronto, non la garanzia che un’azione reimposti esattamente e soltanto l’ambito indicato.⁴⁸⁹

flowchart TB
    accTitle: Interpretare un espediente di riavvio riuscito
    accDescr: Un riavvio cambia più condizioni, quindi il solo miglioramento non può individuare una causa.
    reboot["Il riavvio ha ripristinato l'accesso"] --> app["Stato dell'applicazione"]
    reboot --> session["Stato di connessioni e accessi"]
    reboot --> network["Rete e altri stati"]
    app --> evidence["Servono prove prima e dopo"]
    session --> evidence
    network --> evidence

Figura 11: Un riavvio può ripristinare il servizio senza dimostrare la causa.

Considerate un esempio ipotetico in cui il tentativo riuscito riutilizzava una connessione SMB con un altro account, mentre quello fallito richiedeva una nuova autenticazione. L’analisi dovrebbe puntare alle credenziali non previste e al motivo del fallimento della nuova autenticazione, non al riavvio in sé. Allineare marche temporali, nomi delle connessioni, contesti di esecuzione e account accettati per entrambi gli esiti rende concreto il passo successivo.

Anche quando riavviare è urgente per ripristinare il servizio, conservate se possibile prima gli output della sezione 3 e l’errore originale. Dopo il riavvio, riprovate la stessa operazione nell’applicazione originale prima di aprire la condivisione in Esplora file. Le operazioni intermedie rendono più difficile distinguere se il riavvio abbia ripristinato l’accesso o se un’altra operazione abbia cambiato le condizioni di connessione. Non è un divieto di riavviare; è una procedura di registrazione che serve sia al ripristino sia alla diagnosi.

klist purge modifica lo stato eliminando ticket. Non riguarda una connessione che non usa Kerberos e può incidere su altri servizi nella stessa sessione di accesso. Evitate il «tanto lo svuoto» prima di aver conservato le prove.⁸

10. Fallimenti dopo aggiornamenti o solo su alcuni PC

10.1. Non confondete firma, accesso guest e blocco di NTLM

La firma SMB protegge dalla manomissione dei messaggi; è un’impostazione distinta dal fatto che l’autenticazione usi Kerberos o NTLM. La guida dedicata di Microsoft alla firma SMB afferma che Windows 11 24H2 nelle edizioni Pro, Enterprise ed Education richiede per impostazione predefinita la firma in entrata e in uscita, mentre Windows Server 2025 richiede la firma in uscita. Verificate edizione e configurazione effettiva, non solo il nome del sistema operativo.⁷

Per Home quella guida dice che la firma non è richiesta, mentre l’elenco delle novità di Windows 11 24H2 include Home fra le edizioni che la richiedono per impostazione predefinita. I documenti quindi divergono. Anziché considerare la firma irrilevante su Home, esaminate il computer in questione con i comandi seguenti.⁷²¹

flowchart TB
    accTitle: Requisiti di protezione SMB da esaminare separatamente
    accDescr: Protocolli di autenticazione, firma SMB e accesso guest sono impostazioni diverse che vanno verificate ciascuna a sé.
    policy["Esaminare il criterio effettivo"] --> auth["Permessi Kerberos e NTLM"]
    policy --> signing["Requisito di firma SMB"]
    policy --> guest["Permesso di accesso guest"]

Figura 12: Verificare un’impostazione non stabilisce che i requisiti restanti siano soddisfatti.

L’accesso guest non supporta né la normale firma SMB né la crittografia. Di conseguenza, consentire i guest da solo può non risolvere il problema se la firma resta richiesta. Preferite configurare sul NAS account autenticati e la firma. Non trattate la disattivazione della firma o l’installazione di SMB1 come un comodo espediente.³

10.2. Leggete la configurazione reale, non solo i valori predefiniti

Raccogliete quanto segue in una sessione PowerShell di amministratore sul client. Ciò legge la configurazione; distinguetelo dalla cattura dello stato delle connessioni di un utente interattivo.⁷²²

$config = Get-SmbClientConfiguration
$config | Format-List RequireSecuritySignature, EnableInsecureGuestLogons
if ($config.PSObject.Properties['BlockNTLM']) {
    $config | Format-List BlockNTLM
} else {
    'La proprietà BlockNTLM non è esposta su questo sistema.'
}

RequireSecuritySignature: False significa che la firma non è richiesta; non dimostra che ogni connessione sia non firmata. Se BlockNTLM manca su un sistema più vecchio, ciò non dimostra l’assenza di altri criteri di restrizione di NTLM. Il blocco di NTLM lato client SMB è disponibile a partire da Windows 11 24H2 e Windows Server 2025 e può essere specificato anche per singole connessioni a condivisioni. Esaminate le opzioni di connessione dell’applicazione e i criteri dell’organizzazione oltre alle impostazioni globali.⁷²²

flowchart TB
    accTitle: Le impostazioni globali non determinano l'intera connessione
    accDescr: Verificate criteri dell'organizzazione, opzioni di connessione e requisiti del server oltre ai valori predefiniti del sistema operativo.
    defaults["Valori predefiniti di sistema ed edizione"] --> effective["Requisiti reali della connessione"]
    organization["Criterio dell'organizzazione e opzioni di connessione"] --> effective
    server["Capacità e requisiti del server"] --> effective
    effective --> log["Cercare nei registri il motivo del rifiuto"]

Figura 13: La coincidenza temporale con un aggiornamento è un indizio; traete la conclusione dalle impostazioni effettive e dai registri di rifiuto.

La deprecazione di NTLM, la rimozione di NTLMv1 e un criterio che rifiuta NTLM non sono la stessa questione. Per la migrazione dei protocolli e la verifica a livello di organizzazione si veda Verifica e migrazione per la dismissione di NTLM. Qui concentratevi sul requisito che ha rifiutato questa connessione.

11. L’autenticazione riesce, ma l’apertura o il salvataggio falliscono

Per una condivisione Windows verificate sia le autorizzazioni della condivisione sia quelle delle cartelle e dei file sottostanti. Entrambe devono consentire la stessa operazione alla stessa identità. Esaminate appartenenze ai gruppi, voci di negazione ed ereditarietà; aggiungere Everyone non significa che ogni accesso debba riuscire. Verificate l’accesso effettivo usando il percorso di archiviazione reale sul server e l’identità effettivamente accettata dal server.²³

flowchart TB
    accTitle: L'autenticazione è diversa dall'autorizzazione
    accDescr: Anche dopo un'autenticazione riuscita, le autorizzazioni di condivisione e di file devono entrambe consentire l'operazione richiesta.
    identity["Identità autenticata"] --> share["Autorizzazioni della condivisione"]
    share --> file["Autorizzazioni del file sottostante"]
    file --> operation["Eseguire l'operazione voluta"]

Figura 14: Stabilire l’identità e decidere che cosa quell’identità possa fare sono passaggi distinti.

Elencare una cartella, leggere un file, creare, sovrascrivere, rinominare ed eliminare sono operazioni diverse. Per un’applicazione che salva creando un file temporaneo e sostituendo l’originale, una lettura riuscita non basta. Oltre ad autenticazione e autorizzazioni, analizzate con l’errore originale anche violazioni di condivisione, capacità, percorsi o file scomparsi.²⁴

Anche File.Exists di .NET restituisce false in condizioni come autorizzazioni insufficienti. Verificate se il messaggio «il file non esiste» dell’applicazione si basi soltanto su quel valore restituito. Il codice diagnostico dovrebbe registrare le eccezioni dell’operazione che dovete effettivamente eseguire.²⁵

$Path = '\\filesrv01.corp.example.com\data\sample.txt'
try {
    Get-Item -LiteralPath $Path -ErrorAction Stop |
        Select-Object FullName, Length, LastWriteTime
} catch {
    $_.Exception.GetType().FullName
    'HRESULT=0x{0:X8}' -f $_.Exception.HResult
    $_.Exception.Message
}

Questo verifica il recupero dei metadati, non la riuscita lettura o scrittura del contenuto. Per provare l’I/O reale, riproducete l’operazione voluta su un file di prova dopo aver verificato autorizzazione e impatto. Conservare gli errori invece di convertirli tutti in «file non trovato» facilita anche l’analisi successiva.

12. Confrontate i registri per circoscrivere la causa

12.1. Distinguete client, file server e DC

Sul client esaminate Microsoft-Windows-SMBClient/Connectivity e Microsoft-Windows-SMBClient/Security nel Visualizzatore eventi. Su un file server Windows, gli eventi di sicurezza 4624 per accesso riuscito e 4625 per accesso fallito aiutano quando il controllo è attivo. Per gli accessi di rete SMB verificate il tipo di accesso 3. Su un NAS usate i suoi registri di autenticazione e condivisione specifici del prodotto.²⁶²⁷²⁸

Il tipo di accesso 3 nell’evento 4624 non è specifico di SMB. Anche quando orario, origine e account coincidono, l’evento da solo non individua una condivisione né una sessione SMB. Confrontatelo con Get-SmbConnection, i registri specifici di SMB e, se necessario, una traccia.²⁷⁴²⁶

flowchart TB
    accTitle: Confrontare i registri di tre punti
    accDescr: Confrontate i registri di client, file server e, se serve, DC usando orario e informazioni di connessione.
    client["Client: registri SMBClient"] --> match["Far coincidere orario, origine e account"]
    server["File server: registri di autenticazione"] --> match
    dc["DC: ticket e convalida delle credenziali"] --> match
    match --> result["Leggerli come prove dello stesso tentativo"]

Figura 15: Senza corrispondenza di luogo e orario potete scambiare i registri di una connessione estranea per la causa.

Eseguite quanto segue sul file server Windows, con il permesso di leggere il registro Sicurezza. Annotate l’orario immediatamente precedente al tentativo in esame e chiedete all’amministrazione di confermare che il controllo di successi e fallimenti necessario sia attivo. Questo esempio estrae gli ultimi dieci minuti e usa nomi di campo XML anziché testi di messaggio localizzati o posizioni dei campi.²⁷²⁸

$Start = (Get-Date).AddMinutes(-10)
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'; Id = 4624, 4625; StartTime = $Start
} -ErrorAction Stop | ForEach-Object {
    $event = $_
    $xml = [xml]$event.ToXml()
    $fields = @{}
    foreach ($item in $xml.Event.EventData.Data) {
        $fields[$item.Name] = [string]$item.'#text'
    }
    if ($fields['LogonType'] -eq '3') {
        [pscustomobject]@{
            Time = $event.TimeCreated
            EventId = $event.Id
            User = $fields['TargetUserName']
            Domain = $fields['TargetDomainName']
            SourceIp = $fields['IpAddress']
            Authentication = $fields['AuthenticationPackageName']
            Status = $fields['Status']
            SubStatus = $fields['SubStatus']
            LogonId = $fields['TargetLogonId']
        }
    }
} | Format-List

Per 4624 leggete l’account di destinazione del nuovo accesso, non il Subject che ha segnalato l’evento. In 4625 il nome utente di destinazione è il nome tentato, non un’identità accettata. Leggete Status e SubStatus insieme come motivo del fallimento. Se AuthenticationPackageName riporta solo Negotiate, ciò da solo non stabilisce se sia stato usato Kerberos o NTLM.²⁷²⁸

12.2. Quando non ci sono registri, o solo un ticket

Non trovare alcun evento non dimostra che non sia avvenuta alcuna autenticazione. Verificate controllo, permessi di lettura, differenze di orologio, se state esaminando il server giusto, il riutilizzo di una sessione esistente e un fallimento precedente all’autenticazione. Riutilizzare una connessione SMB esistente non genera un nuovo 4624 a ogni apertura di file.²⁷⁴

flowchart TB
    accTitle: Interpretare eventi di registro mancanti
    accDescr: Quando manca un evento, verificate le condizioni di raccolta e le sessioni esistenti anziché concludere subito che non sia avvenuta alcuna autenticazione.
    absent["Nessun evento corrispondente"] --> collection["Controllo, permessi, orario, destinazione"]
    absent --> reuse["Riutilizzo di una sessione esistente"]
    absent --> before["Fallimento precedente all'autenticazione"]

Figura 16: Una registrazione mancante non equivale a un’operazione mai avvenuta.

Negli ambienti AD l’evento 4769 del DC aiuta a individuare le richieste di ticket di servizio Kerberos, mentre 4776 aiuta a individuare la convalida di credenziali NTLM. L’emissione di un ticket da sola non dimostra né l’uso né l’accettazione da parte del file server, e 4776 da solo non individua SMB come servizio di destinazione. Combinate orario, origine, account di destinazione e registrazioni lato server. Se resta ambiguità, fate raccogliere a un amministratore una traccia di ambito ristretto.²⁹³⁰

13. Verificate il funzionamento affidabile dopo la correzione

Applicate una correzione alla volta e conservate la motivazione e le prove prima e dopo. Se il nome era sbagliato, correggete nome e destinazione. Se le credenziali differivano, uniformate sull’account previsto. Se la firma non era supportata, occupatevi del supporto sul server. Disattivare insieme funzioni di protezione senza capire la causa non è una progettazione per un funzionamento affidabile.

flowchart TB
    accTitle: Da un tentativo riuscito alla prova di ricorrenza
    accDescr: Dopo aver apportato una modifica, riprovate le condizioni di fallimento originali e le condizioni di riconnessione.
    evidence["Prove che individuano la causa"] --> change["Una correzione mirata"]
    change --> original["Provare l'applicazione e l'operazione originali"]
    original --> reconnect["Riprovare dopo riconnessione o riavvio"]
    reconnect --> record["Registrare differenze e risultati"]

Figura 17: Verificate il successo nelle condizioni di fallimento originali, non solo un singolo tentativo riuscito in Esplora file.

Questo articolo non può individuare univocamente la causa per ogni implementazione e configurazione di rete. Ciononostante, sapere quale fase sia fallita, quali condizioni differissero dal successo e che cosa resti non verificato rende concreta l’analisi successiva. Non fermatevi a «un riavvio risolve». Verificate che l’identità prevista si connetta attraverso il percorso previsto.

Link di riferimento

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Se un riavvio ripristina l'accesso a una condivisione file, questo dimostra che il problema era una cache?

No. Un riavvio cambia insieme applicazione, sessioni di accesso, connessioni SMB, stato della rete e altre condizioni. Prima di riavviare, annotate destinazione, identità di esecuzione, connessioni esistenti, ticket ed errori, poi confrontateli con un tentativo riuscito. Le credenziali memorizzate e le connessioni SMB stabilite sono cose diverse.

Perché posso aprire una condivisione tramite indirizzo IP ma non tramite nome del server?

Verificate prima se entrambe le forme raggiungono lo stesso indirizzo IP di destinazione. Anche in tal caso le condizioni di autenticazione differiscono: per una destinazione espressa come indirizzo IP Windows non tenta Kerberos per impostazione predefinita. Analizzate la risoluzione dei nomi separatamente da SPN e autenticazione. Riuscire con un indirizzo IP non è di per sé una soluzione stabile.

Perché Esplora file accede a una condivisione che la mia applicazione non raggiunge?

Account di esecuzione, sessione di accesso, elevazione, credenziali od operazione richiesta possono differire. Un servizio viene eseguito in una sessione diversa da un accesso interattivo. Nomi utente uguali non stabiliscono condizioni equivalenti: esaminate il processo che fallisce e le registrazioni di autenticazione lato server.

Connettersi senza richiesta di password significa che la connessione usa l'accesso guest?

L'assenza della richiesta non basta a stabilirlo. La connessione può usare le credenziali della sessione corrente, credenziali memorizzate o una connessione SMB esistente. Anche un account locale con password vuota e una connessione guest sono cose diverse. Verificate quale account il server abbia effettivamente accettato.

Se klist mostra un ticket cifs, SMB è connesso tramite Kerberos?

Possedere un ticket e usarlo per la connessione SMB in esame sono fatti distinti. Confrontate i registri lato server con orario di connessione, origine e account. klist get richiede un ticket; non è un'osservazione passiva dello stato iniziale.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.