Windows Server 2025 / Verificare la firma SMB e provare la crittografia di una condivisione

La firma del protocollo Server Message Block (SMB), usato per condividere file in Windows, protegge l'integrità dei messaggi; la crittografia SMB protegge il contenuto trasmesso. Se una connessione a una cartella condivisa non riesce, controlli prima il nome del server, l'identità, le funzionalità supportate e la connessione effettivamente negoziata.

Distinguere firma, crittografia e autorizzazioni

Una connessione firmata non è necessariamente crittografata. Crittografare il traffico non corregge autorizzazioni troppo ampie e non protegge automaticamente i file a riposo sul disco. La documentazione specifica sulla firma SMB distingue il requisito in uscita di Windows Server 2025: quando accede a un altro server, FS1 agisce da client SMB. Non attribuisca lo stesso requisito in ingresso a ogni ruolo server. Gli oggetti Criteri di gruppo (GPO) e il ruolo del computer possono modificare la configurazione effettiva. NTFS significa New Technology File System: le sue autorizzazioni si combinano con quelle della condivisione.

Verificare i requisiti prima di modificarli

Su FS1 apra PowerShell con privilegi elevati. Esamini separatamente il client SMB, che accede ad altri server, e il server SMB, che pubblica i file locali. Usi LabRead dell'esercitazione sulle autorizzazioni SMB e NTFS. Verifichi il percorso reale e che l'utente di prova riesca a leggere un file noto prima di modificare impostazioni. Se la condivisione non esiste o l'accesso iniziale fallisce, risolva prima quel problema:

Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature,EncryptData,RejectUnencryptedAccess
Get-SmbShare -Name 'LabRead' | Select-Object Name,Path,EncryptData

RequireSecuritySignature indica l'obbligo di firma, non lo stato di ogni connessione attiva. EncryptData riguarda il server o la condivisione secondo la query; RejectUnencryptedAccess riguarda il rifiuto di accessi senza supporto alla crittografia nel relativo contesto. Non modifichi questi valori globali durante la prova. La panoramica del rafforzamento della sicurezza SMB riassume le nuove funzioni; per i requisiti di firma per direzione usi la documentazione specifica e le impostazioni effettive. Un ulteriore obbligo di crittografia del client non compare nelle colonne selezionate.

Attivare la crittografia solo sulla condivisione di prova

Proceda solo su LabRead nel laboratorio isolato, con un'identità di dominio valida. Chiuda i file aperti. Esegua prima l'assegnazione a $previousEncryption, ne controlli il valore booleano e lo annoti anche fuori dalla sessione, per poterlo recuperare se la finestra si chiude. Non ripeta l'assegnazione dopo l'attivazione: sovrascriverebbe il valore iniziale. Esegua le righe successive una alla volta, confermi la modifica di LabRead se richiesta e si fermi in presenza di errori:

$previousEncryption = (Get-SmbShare -Name 'LabRead').EncryptData
Set-SmbShare -Name 'LabRead' -EncryptData $true
Get-SmbShare -Name 'LabRead' | Select-Object Name,EncryptData

L'ultima query deve mostrare LabRead con EncryptData=True. La crittografia SMB richiede supporto su entrambi i dispositivi: dichiarare SMB 3.x non dimostra da solo la capacità di crittografia necessaria. Mantenga i criteri globali esistenti, incluso il rifiuto di accessi non crittografati. Se nel laboratorio esiste già un'eccezione che impedisce una verifica attendibile, la esamini prima di continuare. Salvi il lavoro e chiuda solo le connessioni client coinvolte, quindi si ricolleghi usando il normale nome del server. Altre applicazioni potrebbero mantenere una sessione verso FS1: ne coordini la chiusura. Chiudere la sola finestra di Esplora file non garantisce una connessione nuova; non disconnetta indiscriminatamente tutte le unità di rete.

Su CLIENT1 apra \\fs1.ad.example.test\LabRead con la stessa identità di dominio e legga il file noto. Esegua la query seguente su quel client, nel contesto che ha aperto la connessione. Una console avviata con altre credenziali può mostrare sessioni differenti:

Get-SmbConnection | Where-Object ShareName -eq 'LabRead' | Select-Object ServerName,ShareName,Dialect,Encrypted

Controlli ServerName oltre a ShareName: il filtro seleziona soltanto LabRead e può restituire condivisioni omonime di server diversi. Nella riga di fs1.ad.example.test, Dialect deve indicare una versione SMB 3.x supportata ed Encrypted deve essere True. La documentazione di Get-SmbConnection spiega il rapporto tra connessioni, utenti e credenziali. Se la riga manca, verifichi la lettura reale e l'identità della query. Con Encrypted=False la crittografia non è dimostrata: controlli le sessioni rimaste aperte, la destinazione e i criteri. La query non mostra lo stato Signed. I permessi di sola lettura non diventano di scrittura attivando la crittografia.

Distinguere errori di compatibilità e autenticazione

Nel dominio usi il nome corretto del server e, dove appropriato, Kerberos. Non aggiri problemi di identità usando indirizzi IP o alias arbitrari. Per un dispositivo di archiviazione collegato alla rete (Network Attached Storage, NAS) datato, esamini aggiornamenti, account autenticati e supporto di firma e crittografia. Valuti sostituzione o isolamento se non è compatibile. Non disattivi globalmente la firma né abiliti accesso guest non sicuro o SMB1 come soluzione rapida.

Apra Visualizzatore eventi → Registri applicazioni e servizi → Microsoft → Windows. Esamini i canali pertinenti di SMBClient su CLIENT1 e SMBServer su FS1 per lo stesso intervallo del guasto. Annoti codice, messaggio completo, computer, condivisione e account senza pubblicare credenziali. Confronti le informazioni con la tabella: “accesso negato” può derivare dalle autorizzazioni o dalla negoziazione di sicurezza; il solo messaggio non identifica la causa. Colleghi eventi e configurazione prima di correggere una singola condizione e ripetere la stessa lettura.

Ripristinare soltanto la modifica della prova

Terminato il confronto, ripristini esattamente il valore salvato nella medesima sessione PowerShell di FS1. Controlli prima che la variabile conservi il booleano originale. Se è andata persa, recuperi l'annotazione precedente senza indovinare il valore. Una condivisione inizialmente crittografata non deve essere lasciata senza crittografia:

Set-SmbShare -Name 'LabRead' -EncryptData $previousEncryption

Ricontrolli EncryptData con la query precedente e ristabilisca la connessione di CLIENT1 per leggere lo stesso file e verificare Encrypted. Se il valore iniziale era True, deve rimanere True. Se era False, il requisito di crittografia del client o altri criteri possono mantenere crittografata la connessione dopo il ripristino della condivisione. Non allenti criteri globali per forzare un risultato di confronto. Per un impiego reale valuti sensibilità dei dati, compatibilità, prestazioni misurate nell'ambiente e accesso di ripristino. La prova non misura le prestazioni e non sostituisce il controllo delle autorizzazioni.