I problemi relativi a client, servizi e programmi possono verificarsi se si modificano le impostazioni di sicurezza e le assegnazioni dei diritti utente

Windows XP

Per aumentare la consapevolezza di impostazioni di sicurezza non configurate correttamente, usare lo strumento Editor oggetti Criteri di gruppo per modificare le impostazioni di sicurezza. Quando si usa Criteri di gruppo Editor oggetti, le assegnazioni dei diritti utente vengono migliorate nei sistemi operativi seguenti:

• Windows XP Professional Service Pack 2 (SP2)

• Windows Server 2003 Service Pack 1 (SP1)

La caratteristica avanzata è una finestra di dialogo che contiene un collegamento a questo articolo. La finestra di dialogo viene visualizzata quando si modifica un'impostazione di sicurezza o un'assegnazione dei diritti utente a un'impostazione che offre meno compatibilità ed è più restrittiva. Se si modifica direttamente la stessa impostazione di sicurezza o l'assegnazione dei diritti utente usando il Registro di sistema o i modelli di sicurezza, l'effetto è lo stesso della modifica dell'impostazione in Criteri di gruppo Editor oggetti. Tuttavia, la finestra di dialogo che contiene il collegamento a questo articolo non viene visualizzata.

Questo articolo contiene esempi di client, programmi e operazioni interessati da specifiche impostazioni di sicurezza o assegnazioni dei diritti utente. Tuttavia, gli esempi non sono rilevanti per tutti i sistemi operativi Microsoft, per tutti i sistemi operativi di terze parti o per tutte le versioni del programma interessate. Non tutte le impostazioni di sicurezza e le assegnazioni dei diritti utente sono incluse in questo articolo.

È consigliabile convalidare la compatibilità di tutte le modifiche alla configurazione correlate alla sicurezza in una foresta di test prima di presentarle in un ambiente di produzione. La foresta di prova deve rispecchiare la foresta di produzione nei modi seguenti:

• Versioni del sistema operativo client e server, programmi client e server, versioni dei Service Pack, aggiornamenti rapidi, modifiche dello schema, gruppi di sicurezza, appartenenze ai gruppi, autorizzazioni per gli oggetti nel file system, cartelle condivise, Registro di sistema, servizio active directory, impostazioni locali e Criteri di gruppo e tipo e posizione del numero di oggetti

• Attività amministrative eseguite, strumenti amministrativi usati e sistemi operativi usati per eseguire attività amministrative

• Operazioni eseguite, ad esempio:

  • Autenticazione di accesso a computer e utenti

  • Reimpostazione della password da parte di utenti, computer e amministratori

  • Navigazione

  • Impostazione delle autorizzazioni per il file system, per le cartelle condivise, per il Registro di sistema e per le risorse di Active Directory utilizzando Editor ACL in tutti i sistemi operativi client in tutti i domini di account o risorse di tutti i sistemi operativi client di tutti i domini di account o risorse

  • Stampa da account amministrativi e non amministrativi

Windows Server 2003 SP1

Diritti utente

L'elenco seguente descrive un diritto dell'utente, identifica le impostazioni di configurazione che possono causare problemi, descrive il motivo per cui applicare il diritto dell'utente e i motivi per cui può essere necessario rimuovere il diritto dell'utente e fornisce esempi di problemi di compatibilità che possono verificarsi quando il diritto dell'utente è configurato.

1. Accedere al computer dalla rete

   1. Priorità bassa
      
      La possibilità di interagire con computer remoti basati su Windows richiede il diritto di accesso al computer dall'utente di rete. Esempi di tali operazioni di rete sono i seguenti:

      • Replica di Active Directory tra controller di dominio in un dominio o una foresta comune

      • Richieste di autenticazione ai controller di dominio da utenti e computer

      • Accesso a cartelle, stampanti e altri servizi di sistema condivisi che si trovano in computer remoti in rete

      
      
      Gli utenti, i computer e gli account di servizio ottengono o perdono il diritto di accesso al computer dall'utente di rete tramite l'aggiunta o la rimozione implicita o esplicita di questo diritto da parte di un gruppo di sicurezza a cui è stato concesso questo diritto. Ad esempio, un account utente o un account computer può essere aggiunto esplicitamente a un gruppo di sicurezza personalizzato o a un gruppo di sicurezza incorporato da un amministratore oppure può essere aggiunto in modo implicito dal sistema operativo a un gruppo di sicurezza calcolato, ad esempio Domain Users, Authenticated Users o Enterprise Domain Controller.
      
      Per impostazione predefinita, agli account utente e agli account computer viene concesso l'accesso al computer dal diritto dell'utente di rete quando i gruppi calcolati come Tutti o, preferibilmente, Utenti autenticati e, per i controller di dominio, il gruppo Controller di dominio Enterprise, sono definiti nei controller di dominio predefiniti Criteri di gruppo Oggetto (GPO).

   2. Configurazioni rischiose
      
      Di seguito sono riportate le impostazioni di configurazione dannose:

      • Rimozione del gruppo di sicurezza Controller di dominio Enterprise da questo diritto dell'utente

      • Rimozione del gruppo Authenticated Users o di un gruppo esplicito che consente a utenti, computer e account del servizio di connettersi a computer in rete

      • Rimozione di tutti gli utenti e i computer da questo utente a destra

   3. Motivi per concedere a questo utente il diritto

      • La concessione dell'accesso al computer dal diritto dell'utente di rete al gruppo Controller di dominio Enterprise soddisfa i requisiti di autenticazione che la replica di Active Directory deve avere per eseguire la replica tra controller di dominio nella stessa foresta.

      • Questo diritto dell'utente consente a utenti e computer di accedere a file condivisi, stampanti e servizi di sistema, incluso Active Directory.

      • Questo diritto dell'utente è necessario per consentire agli utenti di accedere alla posta elettronica usando le versioni precedenti di Microsoft Outlook Web Access (OWA).

   4. Motivi per rimuovere questo diritto dell'utente

      • Gli utenti che possono connettere i propri computer alla rete possono accedere alle risorse nei computer remoti per cui dispongono delle autorizzazioni. Ad esempio, questo diritto dell'utente è necessario per un utente per connettersi alle stampanti condivise e alle cartelle. Se questo diritto utente viene concesso al gruppo Tutti e se alcune cartelle condivise hanno sia autorizzazioni di condivisione che di file system NTFS configurate in modo che lo stesso gruppo abbia accesso in lettura, chiunque può visualizzare i file in tali cartelle condivise. Tuttavia, questa è una situazione improbabile per le nuove installazioni di Windows Server 2003 perché la condivisione predefinita e le autorizzazioni NTFS in Windows Server 2003 non includono il gruppo Everyone. Per i sistemi aggiornati da Microsoft Windows NT 4.0 o Windows 2000, questa vulnerabilità può presentare un livello di rischio superiore perché la condivisione predefinita e le autorizzazioni del file system per questi sistemi operativi non sono restrittive come le autorizzazioni predefinite in Windows Server 2003.

      • Non esiste alcun motivo valido per rimuovere il gruppo di controller di dominio Enterprise da questo diritto dell'utente.

      • Il gruppo Tutti viene generalmente rimosso a favore del gruppo Authenticated Users. Se il gruppo Tutti viene rimosso, al gruppo Authenticated Users deve essere concesso questo diritto utente.

      • I domini Windows NT 4.0 aggiornati a Windows 2000 non concedono esplicitamente l'accesso al computer dai diritti dell'utente di rete al gruppo Everyone, al gruppo Authenticated Users o al gruppo Controller di dominio Enterprise. Pertanto, quando si rimuove il gruppo Everyone dai criteri di dominio di Windows NT 4.0, la replica di Active Directory avrà esito negativo con un messaggio di errore "Accesso negato" dopo l'aggiornamento a Windows 2000. Winnt32.exe in Windows Server 2003 evita questa errata configurazione concedendo al gruppo Controller di dominio Enterprise questo diritto utente quando si esegue l'aggiornamento dei controller di dominio primario (PPC) di Windows NT 4.0. Concedere al gruppo Controller di dominio Enterprise questo diritto utente se non è presente nell'editor di oggetti Criteri di gruppo.

   5. Esempi di problemi di compatibilità

      • Windows 2000 e Windows Server 2003: la replica delle partizioni seguenti avrà esito negativo con errori di "accesso negato", come indicato da strumenti di monitoraggio come REPLMON e REPADMIN o eventi di replica nel registro eventi.

        • Partizione di schema di Active Directory

        • Partizione di configurazione

        • Partizione di dominio

        • Partizione catalogo globale

        • Partizione dell'applicazione

      • Tutti i sistemi operativi di rete Microsoft: l'autenticazione dell'account utente da computer client di rete remota avrà esito negativo a meno che l'utente o un gruppo di sicurezza di cui l'utente è membro non abbia ottenuto questo diritto utente.

      • Tutti i sistemi operativi di rete Microsoft: l'autenticazione dell'account dai client di rete remoti non riesce a meno che l'account o un gruppo di sicurezza di cui è membro non sia stato concesso questo diritto utente. Questo scenario si applica agli account utente, agli account computer e agli account del servizio.

      • Tutti i sistemi operativi di rete Microsoft: la rimozione di tutti gli account da questo diritto utente impedirà a qualsiasi account di accedere al dominio o di accedere alle risorse di rete. Se gruppi calcolati come Controller di dominio Enterprise, Tutti o Utenti autenticati vengono rimossi, è necessario concedere esplicitamente a questo utente il diritto di accedere ad account o gruppi di sicurezza di cui l'account è membro per accedere ai computer remoti tramite la rete. Questo scenario si applica a tutti gli account utente, a tutti gli account computer e a tutti gli account di servizio.

      • Tutti i sistemi operativi di rete Microsoft: l'account amministratore locale usa una password "vuota". La connettività di rete con password vuote non è consentita per gli account amministratore in un ambiente di dominio. Con questa configurazione, si potrebbe ricevere un messaggio di errore "Accesso negato".

2. Consenti accesso locale

   1. Priorità bassa
      
      Gli utenti che provano ad accedere alla console di un computer basato su Windows (usando la scelta rapida da tastiera CTRL+ALT+CANC) e gli account che tentano di avviare un servizio devono disporre dei privilegi di accesso locale nel computer di hosting. Esempi di operazioni di accesso locale includono gli amministratori che accedono alle console dei computer membri o i controller di dominio in tutta l'organizzazione e gli utenti di dominio che accedono ai computer membri per accedere ai propri desktop tramite account non privilegiati. Gli utenti che utilizzano una connessione Desktop remoto o Servizi terminal devono disporre dell'utente Consenti accesso locale direttamente nei computer di destinazione che eseguono Windows 2000 o Windows XP perché queste modalità di accesso sono considerate locali per il computer di hosting. Gli utenti che accedono a un server in cui è abilitato Terminal Server e che non dispongono di questo diritto utente possono comunque avviare una sessione interattiva remota nei domini di Windows Server 2003 se dispongono del diritto utente Consenti accesso tramite Servizi terminal.

   2. Configurazioni rischiose
      
      Di seguito sono riportate le impostazioni di configurazione dannose:

      • Rimozione dei gruppi di sicurezza amministrativi, inclusi operatori degli account, operatori di backup, operatori di stampa o operatori di server, e il gruppo Administrators predefinito dai criteri del controller di dominio predefinito.

      • Rimozione degli account di servizio utilizzati dai componenti e dai programmi nei computer membri e nei controller di dominio nel dominio dai criteri del controller di dominio predefinito.

      • Rimozione di utenti o gruppi di sicurezza che accedono alla console dei computer membri nel dominio.

      • Rimozione degli account di servizio definiti nel database sam (Security Accounts Manager) locale dei computer membri o dei computer del gruppo di lavoro.

      • Rimozione di account amministrativi non predefiniti che eseguono l'autenticazione tramite Servizi terminal in esecuzione su un controller di dominio.

      • Aggiunta di tutti gli account utente nel dominio in modo esplicito o implicito tramite il gruppo Everyone al diritto di accesso negato localmente. Questa configurazione impedirà agli utenti di accedere a qualsiasi computer membro o controller di dominio nel dominio.

   3. Motivi per concedere a questo utente il diritto

      • Gli utenti devono avere il diritto utente Consenti accesso in locale per accedere alla console o al desktop di un computer del gruppo di lavoro, di un computer membro o di un controller di dominio.

      • Gli utenti devono avere questo diritto utente per accedere a una sessione di Servizi terminal in esecuzione su un computer membro o un controller di dominio basato su Windows 2000.

   4. Motivi per rimuovere questo diritto dell'utente

      • Se non si limita l'accesso della console ad account utente legittimi, gli utenti non autorizzati scaricano ed eseguono codice dannoso per modificare i diritti degli utenti.

      • La rimozione del diritto utente Consenti accesso in locale impedisce accessi non autorizzati sulle console dei computer, ad esempio controller di dominio o server applicazioni.

      • La rimozione di questo diritto di accesso impedisce agli account non di dominio di accedere alla console dei computer membri del dominio.

   5. Esempi di problemi di compatibilità

      • Server terminal di Windows 2000: il diritto utente Consenti accesso locale è necessario per consentire agli utenti di accedere ai server terminal di Windows 2000.

      • Windows NT 4.0, Windows 2000, Windows XP o Windows Server 2003: agli account utente deve essere concesso questo diritto utente per accedere alla console dei computer che eseguono Windows NT 4.0, Windows 2000, Windows XP o Windows Server 2003.

      • Windows NT 4.0 e versioni successive: nei computer che eseguono Windows NT 4.0 e versioni successive, se si aggiunge il diritto utente Consenti accesso in locale, ma si concede in modo implicito o esplicito anche il diritto di accesso nega all'accesso locale, gli account non saranno in grado di accedere alla console dei controller di dominio.

3. Bypassare il controllo dell'attraversamento

   1. Priorità bassa
      
      Il diritto utente bypass traverse checking consente all'utente di sfogliare le cartelle nel file system NTFS o nel Registro di sistema senza controllare l'autorizzazione di accesso speciale Traverse Folder. Il diritto utente bypass traverse checking non consente all'utente di elencare il contenuto di una cartella. Permette all'utente di attraversare solo le sue cartelle.

   2. Configurazioni rischiose
      
      Di seguito sono riportate le impostazioni di configurazione dannose:

      • Rimozione di account non amministrativi che accedono ai computer di Servizi terminal basati su Windows 2000 o a computer con Servizi terminal basati su Windows Server 2003 che non dispongono delle autorizzazioni per accedere ai file e alle cartelle nel file system.

      • Rimozione del gruppo Tutti dall'elenco delle entità di sicurezza che hanno questo diritto utente per impostazione predefinita. I sistemi operativi Windows, e anche molti programmi, sono progettati con l'aspettativa che chiunque possa accedere in modo legittimo al computer avrà il diritto di controllo attraversamento bypass utente. Pertanto, la rimozione del gruppo Everyone dall'elenco delle entità di sicurezza che hanno questo diritto utente per impostazione predefinita potrebbe causare instabilità del sistema operativo o un errore del programma. È preferibile lasciare questa impostazione come predefinita.

   3. Motivi per concedere a questo utente il diritto
      
      L'impostazione predefinita per il diritto dell'utente bypass traverse checking è quella di consentire a chiunque di ignorare il controllo dell'attraversamento. Per gli amministratori di sistema windows esperti, questo è il comportamento previsto e configurano di conseguenza gli elenchi di controllo di accesso (SCL) del file system. L'unico scenario in cui la configurazione predefinita può causare un incidente è se l'amministratore che configura le autorizzazioni non comprende il comportamento e prevede che gli utenti che non possono accedere a una cartella padre non saranno in grado di accedere al contenuto delle cartelle figlio.

   4. Motivi per rimuovere questo diritto
      
      dell'utente Per tentare di impedire l'accesso ai file o alle cartelle nel file system, le organizzazioni che sono molto preoccupate per la sicurezza potrebbero essere tentate di rimuovere il gruppo Everyone, o anche il gruppo Users, dall'elenco dei gruppi che hanno il diritto utente bypass traverse checking.

   5. Esempi di problemi di compatibilità

      • Windows 2000, Windows Server 2003: se il diritto utente Bypass traverse checking viene rimosso o non è configurato correttamente nei computer che eseguono Windows 2000 o Windows Server 2003, le impostazioni di Criteri di gruppo nella cartella SYVOL non verranno replicate tra i controller di dominio nel dominio.

      • Windows 2000, Windows XP Professional, Windows Server 2003: i computer che eseguono Windows 2000, Windows XP Professional o Windows Server 2003 registreranno gli eventi 1000 e 1202 e non potranno applicare i criteri e i criteri utente quando le autorizzazioni necessarie per il file system vengono rimosse dall'albero SYSVOL se il diritto dell'utente Bypass traverse checking viene rimosso o non è configurato correttamente.
        
         

      • Windows 2000, Windows Server 2003: nei computer che eseguono Windows 2000 o Windows Server 2003, la scheda Quota in Esplora risorse scomparirà quando si visualizzano le proprietà di un volume.

      • Windows 2000: gli utenti non amministratori che accedono a un server terminal di Windows 2000 potrebbero ricevere il seguente messaggio di errore:

        Userinit.exe errore dell'applicazione. Impossibile inizializzare correttamente l'applicazione 0xc0000142 fare clic su OK per terminare l'app.

      • Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: gli utenti i cui computer eseguono Windows NT 4.0, Windows 2000, Windows XP o Windows Server 2003 potrebbero non essere in grado di accedere alle cartelle condivise o ai file nelle cartelle condivise e potrebbero ricevere messaggi di errore "Accesso negato" se non gli viene concesso il diritto di controllo di attraversamento del bypass.
        
        
         

      • Windows NT 4.0: nei computer basati su Windows NT 4.0, la rimozione del controllo dell'attraversamento del sistema di bypass del diritto dell'utente causerà la caduta di flussi di file da parte di una copia del file. Se si rimuove questo diritto utente, quando un file viene copiato da un client Windows o da un client Macintosh a un controller di dominio windows NT 4.0 che esegue Servizi per Macintosh, il flusso di file di destinazione viene perso e il file viene visualizzato come file di sola testo.

      • Microsoft Windows 95, Microsoft Windows 98: in un computer client che esegue Windows 95 o Windows 98, il comando net use * /home non riesce con un messaggio di errore "Accesso negato" se al gruppo Utenti autenticati non viene concesso il diritto di controllo dell'attraversamento del bypass.

      • Outlook Web Access: gli utenti non amministratori non potranno accedere a Microsoft Outlook Web Access e riceveranno un messaggio di errore "Accesso negato" se non ricevono il diritto dell'utente di controllo dell'attraversamento del bypass.

Impostazioni di sicurezza

L'elenco seguente identifica un'impostazione di sicurezza e l'elenco annidato fornisce una descrizione dell'impostazione di sicurezza, identifica le impostazioni di configurazione che possono causare problemi, descrive il motivo per cui è consigliabile applicare l'impostazione di sicurezza e quindi descrive i motivi per cui è consigliabile rimuovere l'impostazione di sicurezza. L'elenco annidato fornisce quindi un nome simbolico per l'impostazione di sicurezza e il percorso del Registro di sistema dell'impostazione di sicurezza. Infine, vengono forniti esempi di problemi di compatibilità che possono verificarsi quando l'impostazione di sicurezza è configurata.

1. Controllo: arresta immediatamente il sistema se non è possibile registrare i controlli di sicurezza

   1. Sfondo

      • L'impostazione Audit: Shut down system immediately if unable to log security audits determina se il sistema viene arrestato se non è possibile registrare eventi di sicurezza. Questa impostazione è necessaria per la valutazione C2 del programma Trusted Computer Security Evaluation Criteria (TCSEC) e per i criteri comuni per la valutazione della sicurezza informatica per impedire eventi controllabili se il sistema di controllo non riesce a registrare tali eventi. Se il sistema di controllo non riesce, il sistema viene arrestato e viene visualizzato un messaggio di errore irreversibile.

      • Se il computer non è in grado di registrare eventi nel log di sicurezza, prove critiche o informazioni importanti per la risoluzione dei problemi potrebbero non essere disponibili per la revisione dopo un incidente di sicurezza.

   2. Configurazione
      
      rischiosa Di seguito è riportata un'impostazione di configurazione dannosa: l'impostazione Controlla: arresta immediatamente il sistema se non è possibile registrare i controlli di sicurezza è attivata e le dimensioni del registro eventi di sicurezza sono vincolate dall'opzione Non sovrascrivere gli eventi (cancella manualmente il log), dall'opzione Sovrascrivi eventi in base alle esigenze o dall'opzione Sovrascrivi eventi precedenti ai giorni più recenti in Visualizzatore eventi. Vedi la sezione "Esempi di problemi di compatibilità" per informazioni sui rischi specifici per i computer che eseguono la versione originale di Windows 2000, Windows 2000 Service Pack 1 (SP1), Windows 2000 SP2 o Windows 2000 SP3.

   3. Motivi per abilitare questa impostazione
      
      Se il computer non è in grado di registrare eventi nel log di sicurezza, prove critiche o informazioni importanti per la risoluzione dei problemi potrebbero non essere disponibili per la revisione dopo un incidente di sicurezza.

   4. Motivi per disabilitare questa impostazione

      • Abilitazione del controllo: arresta immediatamente il sistema se non è possibile registrare i controlli di sicurezza interrompe il sistema se non è possibile registrare un controllo di sicurezza per qualsiasi motivo. In genere, un evento non può essere registrato quando il log di controllo di sicurezza è pieno e quando il metodo di conservazione specificato è l'opzione Non sovrascrivere gli eventi (cancellare manualmente il log) o Sovrascrivi eventi precedenti ai giorni numerici .

      • L'onere amministrativo dell'abilitazione del controllo: arrestare immediatamente il sistema se non è possibile registrare i controlli di sicurezza può essere molto elevato, soprattutto se si attiva anche l'opzione Non sovrascrivere gli eventi (cancellare manualmente il log) per il log di sicurezza. Questa impostazione fornisce la responsabilità individuale delle azioni degli operatori. Ad esempio, un amministratore può reimpostare le autorizzazioni per tutti gli utenti, i computer e i gruppi di un'unità organizzativa in cui il controllo è stato abilitato usando l'account amministratore incorporato o un altro account condiviso e quindi rifiutare di reimpostare tali autorizzazioni. Tuttavia, abilitando l'impostazione si riduce la robustezza del sistema, perché un server potrebbe essere costretto a spegnersi, soverchiarlo con eventi di accesso e con altri eventi di sicurezza scritti nel log di sicurezza. Inoltre, poiché l'arresto non è normale, possono verificarsi danni irreparabili al sistema operativo, ai programmi o ai dati. Mentre NTFS garantisce che l'integrità del file system viene mantenuta durante un arresto anomalo del sistema, non può garantire che ogni file di dati per ogni programma sarà ancora in forma utilizzabile quando il sistema viene riavviato.

   5. Nome simbolico:
      
      Crashonauditfail

   6. Percorso del Registro di sistema:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CrashOnAuditFail (Reg_DWORD)

   7. Esempi di problemi di compatibilità

      • Windows 2000: a causa di un bug, i computer che eseguono la versione originale rilasciata di Windows 2000, Windows 2000 SP1, Windows 2000 SP2 o Windows Server SP3 potrebbero interrompere la registrazione di eventi prima di raggiungere le dimensioni specificate nell'opzione Dimensione massima registro per il registro eventi di sicurezza. Questo bug è stato risolto in Windows 2000 Service Pack 4 (SP4). Prima di valutare l'abilitazione di questa impostazione, assicurarsi che nei controller di dominio di Windows 2000 sia installato Windows 2000 Service Pack 4.
        
         

      • Windows 2000, Windows Server 2003: i computer che eseguono Windows 2000 o Windows Server 2003 potrebbero bloccarsi e quindi riavviarsi spontaneamente se l'impostazione Controllo: Arresta immediatamente il sistema se non è possibile registrare i controlli di sicurezza è attivata, il log di sicurezza è pieno e non è possibile sovrascrivere una voce del registro eventi esistente. Quando il computer viene riavviato, viene visualizzato il seguente messaggio di errore irreversibile:

        STOP: C0000244 {Audit Failed}
        Tentativo di generare un controllo di sicurezza non riuscito.

        Per il ripristino, un amministratore deve eseguire l'accesso, archiviare il log di sicurezza (facoltativo), cancellare il log di sicurezza e quindi reimpostare questa opzione (facoltativa e in base alle esigenze).

      • Client di rete Microsoft per MS-DOS, Windows 95, Windows 98, Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: gli utenti non amministratori che tentano di accedere a un dominio riceveranno il seguente messaggio di errore:

        L'account è configurato per impedire l'uso del computer. Prova con un altro computer.

      • Windows 2000: nei computer basati su Windows 2000, gli utenti non amministratori non potranno accedere ai server di accesso remoto e riceveranno un messaggio di errore simile al seguente:

        Utente sconosciuto o password non valida

      • Windows 2000: nei controller di dominio di Windows 2000 il servizio Messaggistica tra siti (Ismserv.exe) verrà interrotto e non potrà essere riavviato. DCDIAG segnalerà l'errore come "SERVIZIO ISMserv di test non riuscito" e l'ID evento 1083 verrà registrato nel registro eventi.

      • Windows 2000: nei controller di dominio di Windows 2000 la replica di Active Directory avrà esito negativo e verrà visualizzato un messaggio "Accesso negato" se il registro eventi di sicurezza è pieno.

      • Microsoft Exchange 2000: i server che eseguono Exchange 2000 non potranno montare il database dell'archivio informazioni e l'evento 2102 verrà registrato nel registro eventi.

      • Outlook, Outlook Web Access: gli utenti non amministratori non potranno accedere alla posta elettronica tramite Microsoft Outlook o Microsoft Outlook Web Access e riceveranno un errore 503.

2. Controller di dominio: requisiti di firma server LDAP

   1. Priorità bassa
      
      L'impostazione di sicurezza Controller di dominio: requisiti di firma server LDAP determina se il server LDAP (Lightweight Directory Access Protocol) richiede che i client LDAP negozino la firma dei dati. I valori possibili per questa impostazione dei criteri sono i seguenti:

      • Nessuno: non è necessaria la firma dei dati per eseguire l'associazione con il server. Se il client richiede la firma dei dati, il server lo supporta.

      • Richiedi firma: l'opzione di firma dati LDAP deve essere negoziata a meno che non venga usato Transport Layer Security/Secure Socket Layer (TLS/SSL).

      • non definito: questa impostazione non è abilitata o disabilitata.

   2. Configurazioni rischiose
      
      Di seguito sono riportate le impostazioni di configurazione dannose:

      • Abilitazione della richiesta di accesso in ambienti in cui i client non supportano la firma LDAP o in cui la firma LDAP lato client non è abilitata nel client

      • Applicazione del modello di sicurezza Hisecdc.inf di Windows 2000 o Windows Server 2003 in ambienti in cui i client non supportano la firma LDAP o in cui la firma LDAP lato client non è abilitata

      • Applicazione del modello di sicurezza Windows 2000 o Windows Server 2003 Hisecws.inf in ambienti in cui i client non supportano la firma LDAP o in cui la firma LDAP lato client non è abilitata

   3. Motivi per abilitare questa impostazione
      
      Il traffico di rete non firmato è suscettibile agli attacchi man-in-the-middle in cui un intruso acquisisce i pacchetti tra il client e il server, modifica i pacchetti e li inoltra al server. Quando questo comportamento si verifica su un server LDAP, un utente malintenzionato potrebbe causare a un server di prendere decisioni basate su false query dal client LDAP. È possibile ridurre questo rischio in una rete aziendale implementando misure di sicurezza fisiche complesse per proteggere l'infrastruttura di rete. La modalità di intestazione di autenticazione IPSec (Internet Protocol Security) consente di prevenire attacchi man-in-the-middle. La modalità di intestazione di autenticazione esegue l'autenticazione reciproca e l'integrità dei pacchetti per il traffico IP.

   4. Motivi per disabilitare questa impostazione

      • I client che non supportano la firma LDAP non potranno eseguire query LDAP nei controller di dominio e nei cataloghi globali se viene negoziata l'autenticazione NTLM e se i Service Pack corretti non sono installati nei controller di dominio di Windows 2000.

      • Le tracce di rete del traffico LDAP tra client e server verranno crittografate. In questo modo risulta difficile esaminare le conversazioni LDAP.

      • I server basati su Windows 2000 devono avere Windows 2000 Service Pack 3 (SP3) o installati quando vengono gestiti con programmi che supportano la firma LDAP, eseguiti da computer client che eseguono Windows 2000 SP4, Windows XP o Windows Server 2003.  

   5. Nome simbolico:
      
      LDAPServerIntegrity

   6. Percorso del Registro di sistema:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity (Reg_DWORD)

   7. Esempi di problemi di compatibilità

      • Le associazioni semplici non riusciranno e verrà visualizzato il seguente messaggio di errore:

        Ldap_simple_bind_s() non riuscito: autenticazione avanzata richiesta.

      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: nei client che eseguono Windows 2000 SP4, Windows XP o Windows Server 2003, alcuni strumenti di amministrazione di Active Directory non funzioneranno correttamente nei controller di dominio che eseguono versioni di Windows 2000 precedenti a SP3 quando viene negoziata l'autenticazione NTLM.
        
         

      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: nei client che eseguono Windows 2000 SP4, Windows XP o Windows Server 2003, alcuni strumenti di amministrazione di Active Directory destinati ai controller di dominio che eseguono versioni di Windows 2000 precedenti a SP3 non funzioneranno correttamente se usano indirizzi IP (ad esempio, "dsa.msc /server=x.x.x.x", dove
        x.x.x.x è un indirizzo IP).
        
        
         

      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: nei client che eseguono Windows 2000 SP4, Windows XP o Windows Server 2003, alcuni strumenti di amministrazione di Active Directory destinati ai controller di dominio che eseguono versioni di Windows 2000 precedenti a SP3 non funzioneranno correttamente.
        
         

3. Membro del dominio: chiave di sessione Richiesta forte (Windows 2000 o versione successiva)

   1. Sfondo

      • Il membro del dominio: l'impostazione Richiedi chiave di sessione complessa (Windows 2000 o versione successiva) determina se un canale sicuro può essere stabilito con un controller di dominio che non può crittografare il traffico di canale sicuro con una chiave di sessione a 128 bit complessa. L'abilitazione di questa impostazione impedisce di stabilire un canale sicuro con qualsiasi controller di dominio che non può crittografare i dati del canale sicuro con una chiave complessa. La disabilitazione di questa impostazione consente chiavi di sessione a 64 bit.

      • Prima di abilitare questa impostazione su una workstation membro o su un server, tutti i controller di dominio nel dominio a cui appartiene il membro devono essere in grado di crittografare i dati del canale sicuro con una chiave forte a 128 bit. Ciò significa che tutti questi controller di dominio devono eseguire Windows 2000 o versione successiva.

   2. Configurazione
      
      rischiosa L'abilitazione del membro del dominio: l'impostazione della chiave di sessione Richiedi chiave di sessione strong (Windows 2000 o versione successiva) è un'impostazione di configurazione dannosa.

   3. Motivi per abilitare questa impostazione

      • Le chiavi di sessione utilizzate per stabilire comunicazioni di canale sicure tra computer membri e controller di dominio sono molto più potenti in Windows 2000 rispetto alle versioni precedenti dei sistemi operativi Microsoft.

      • Quando è possibile, è consigliabile sfruttare questi tasti di sessione più potenti per proteggere le comunicazioni dei canali sicure dal intercettazione e dagli attacchi di rete di dirottamento delle sessioni. Il intercettazione è una forma di attacco dannoso in cui i dati di rete sono letti o modificati in transito. I dati possono essere modificati per nascondere o modificare il mittente o per reindirizzarlo.

      Importante Un computer che esegue Windows Server 2008 R2 o Windows 7 supporta solo chiavi complesse quando vengono utilizzati canali sicuri. Questa restrizione impedisce l'attendibilità tra qualsiasi dominio basato su Windows NT 4.0 e qualsiasi dominio basato su Windows Server 2008 R2. Inoltre, questa restrizione blocca l'appartenenza al dominio basata su Windows NT 4.0 dei computer che eseguono Windows 7 o Windows Server 2008 R2 e viceversa.

   4. Motivi per disabilitare questa impostazione
      
      Il dominio contiene computer membri che eseguono sistemi operativi diversi da Windows 2000, Windows XP o Windows Server 2003.

   5. Nome simbolico:
      
      StrongKey

   6. Percorso del Registro di sistema:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireStrongKey (Reg_DWORD)

   7. Esempi di problemi
      
      di compatibilità Windows NT 4.0: nei computer con Windows NT 4.0 la reimpostazione dei canali sicuri di relazioni di trust tra domini Windows NT 4.0 e Windows 2000 con NLTEST non riesce. Viene visualizzato un messaggio di errore "Accesso negato":

      La relazione di trust tra il dominio primario e il dominio attendibile non è riuscita.
      
      Windows 7 e Server 2008 R2: per Windows 7 e versioni successive e Windows Server 2008 R2 e versioni successive, questa impostazione non viene più rispettata e la chiave forte viene usata sempre. Per questo motivo, le attendibilità con i domini Windows NT 4.0 non funzionano più.

4. Membro del dominio: crittografare o firmare digitalmente i dati del canale sicuro (sempre)

   1. Sfondo

      • Abilitazione di un membro del dominio: crittografare o firmare digitalmente i dati del canale sicuro (sempre) impedisce di stabilire un canale sicuro con qualsiasi controller di dominio che non può firmare o crittografare tutti i dati del canale sicuro. Per proteggere il traffico di autenticazione da attacchi man-in-the-middle, attacchi replay e altri tipi di attacchi di rete, i computer basati su Windows creano un canale di comunicazione noto come canale sicuro tramite il servizio Accesso rete per autenticare gli account del computer. I canali sicuri vengono usati anche quando un utente in un dominio si connette a una risorsa di rete in un dominio remoto. Questa autenticazione multidominio, o autenticazione pass-through, consente a un computer basato su Windows che fa parte di un dominio di avere accesso al database degli account utente nel suo dominio e in qualsiasi dominio attendibile.

      • Per abilitare il membro del dominio: crittografare o firmare digitalmente i dati del canale sicuro (sempre) in un computer membro, tutti i controller di dominio del dominio a cui appartiene il membro devono essere in grado di firmare o crittografare tutti i dati del canale sicuro. Questo significa che tutti questi controller di dominio devono eseguire Windows NT 4.0 con Service Pack 6a (SP6a) o versione successiva.

      • Abilitazione del membro del dominio: l'impostazione Crittografa o firma digitalmente i dati del canale sicuro (sempre) abilita automaticamente l'impostazione Domain member: Crittografa o firma digitalmente i dati del canale sicuro (se possibile).

   2. Configurazione
      
      rischiosa Abilitazione del membro del dominio: crittografare o firmare digitalmente i dati del canale sicuro (sempre) nei domini in cui non tutti i controller di dominio possono firmare o crittografare i dati del canale sicuro è un'impostazione di configurazione dannosa.

   3. Motivi per abilitare questa impostazione
      
      Il traffico di rete non firmato è suscettibile agli attacchi man-in-the-middle, in cui un intruso acquisisce i pacchetti tra il server e il client e quindi li modifica prima di inoltrarli al client. Quando questo comportamento si verifica su un server LDAP (Lightweight Directory Access Protocol), l'intruso potrebbe causare a un client di prendere decisioni basate su falsi record dalla directory LDAP. È possibile ridurre il rischio di un attacco di questo tipo a una rete aziendale implementando forti misure di sicurezza fisica per proteggere l'infrastruttura di rete. Inoltre, l'implementazione della modalità di intestazione di autenticazione IPSec (Internet Protocol Security) può contribuire a prevenire gli attacchi man-in-the-middle. Questa modalità esegue l'autenticazione reciproca e l'integrità dei pacchetti per il traffico IP.

   4. Motivi per disabilitare questa impostazione

      • I computer in domini locali o esterni supportano canali sicuri crittografati.

      • Non tutti i controller di dominio nel dominio hanno i livelli di revisione del Service Pack appropriati per supportare i canali sicuri crittografati.

   5. Nome simbolico:
      
      StrongKey

   6. Percorso del Registro di sistema:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireSignOrSeal (REG_DWORD)

   7. Esempi di problemi di compatibilità

      • Windows NT 4.0: i computer membri basati su Windows 2000 non potranno partecipare ai domini Windows NT 4.0 e riceveranno il seguente messaggio di errore:

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

        Per altre informazioni, fare clic sul numero dell'articolo seguente per visualizzare l'articolo della Microsoft Knowledge Base:

        281648 Messaggio di errore: L'account non è autorizzato ad accedere da questa stazione
         

      • Windows NT 4.0: i domini di Windows NT 4.0 non saranno in grado di stabilire un trust di livello inferiore con un dominio di Windows 2000 e riceveranno il seguente messaggio di errore:

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

        Anche i trust esistenti di livello inferiore potrebbero non autenticare gli utenti dal dominio attendibile. Alcuni utenti potrebbero avere problemi ad accedere al dominio e potrebbero ricevere un messaggio di errore che indica che il client non riesce a trovare il dominio.

      • Windows XP: i client di Windows XP che fanno parte di domini di Windows NT 4.0 non saranno in grado di autenticare i tentativi di accesso e potrebbero ricevere il seguente messaggio di errore oppure nel registro eventi potrebbero essere registrati gli eventi seguenti:

        Windows non riesce a connettersi al dominio perché il controller di dominio non è disponibile o non è disponibile oppure perché l'account del computer non è stato trovato

      • Rete Microsoft: i client di rete Microsoft riceveranno uno dei seguenti messaggi di errore:

        Errore di accesso: nome utente sconosciuto o password errata.

        Non esiste una chiave di sessione utente per la sessione di accesso specificata.

5. Client di rete Microsoft: firma digitale delle comunicazioni (sempre)

   1. Priorità bassa
      
      Server Message Block (SMB) è il protocollo di condivisione delle risorse supportato da molti sistemi operativi Microsoft. È la base del sistema di input/output di base di rete (NetBIOS) e di molti altri protocolli. La firma SMB autentica sia l'utente che il server che ospita i dati. Se entrambi i lati non riescono a eseguire il processo di autenticazione, non verrà eseguita la trasmissione dei dati.
      
      L'abilitazione della firma SMB viene avviata durante la negoziazione del protocollo SMB. I criteri di firma SMB determinano se il computer firma sempre digitalmente le comunicazioni client.
      
      Il protocollo di autenticazione SMB di Windows 2000 supporta l'autenticazione reciproca. L'autenticazione reciproca chiude un attacco "man-in-the-middle". Il protocollo di autenticazione SMB di Windows 2000 supporta anche l'autenticazione dei messaggi. L'autenticazione dei messaggi consente di evitare attacchi attivi ai messaggi. Per fornire questa autenticazione, la firma SMB inserisce una firma digitale in ogni SMB. Il client e il server verificano ognuno la firma digitale.
      
      Per utilizzare la firma SMB, è necessario abilitare la firma SMB o richiedere la firma SMB sia sul client SMB che sul server SMB. Se la firma SMB è abilitata su un server, i client abilitati anche per la firma SMB usano il protocollo di firma dei pacchetti durante tutte le sessioni successive. Se la firma SMB è richiesta su un server, un client non può stabilire una sessione a meno che il client non sia abilitato o richiesto per la firma SMB.
      
      
      L'abilitazione della firma digitale nelle reti ad alta sicurezza consente di impedire la rappresentazione dei client e dei server. Questo tipo di rappresentazione è noto come dirottamento di sessione. Un utente malintenzionato che ha accesso alla stessa rete del client o del server utilizza gli strumenti di dirottamento della sessione per interrompere, terminare o rubare una sessione in corso. Un utente malintenzionato potrebbe intercettare e modificare i pacchetti SMB non firmati, modificare il traffico e quindi inoltrarlo in modo che il server possa eseguire azioni indesiderate. In alternativa, l'autore dell'attacco potrebbe presentarsi come server o client dopo un'autenticazione legittima e quindi ottenere l'accesso non autorizzato ai dati.
      
      Il protocollo SMB usato per la condivisione di file e la condivisione della stampa nei computer che eseguono Windows 2000 Server, Windows 2000 Professional, Windows XP Professional o Windows Server 2003 supporta l'autenticazione reciproca. L'autenticazione reciproca chiude gli attacchi di dirottamento della sessione e supporta l'autenticazione dei messaggi. Pertanto, impedisce attacchi man-in-the-middle. La firma SMB fornisce questa autenticazione inserendo una firma digitale in ogni SMB. Il client e il server verificano quindi la firma.
      
      Note

      • Come misura alternativa, è possibile abilitare le firme digitali con IPSec per proteggere tutto il traffico di rete. Esistono acceleratori basati su hardware per la crittografia e la firma IPSec che è possibile usare per ridurre al minimo l'impatto sulle prestazioni della CPU del server. Non sono disponibili acceleratori di questo tipo per la firma SMB.
        
        Per ulteriori informazioni, vedere il capitolo Firma digitale per le comunicazioni server sul sito Web Microsoft MSDN.
        
        Configurare la firma SMB tramite Criteri di gruppo Object Editor perché una modifica a un valore del Registro di sistema locale non ha alcun effetto se è presente un criterio di dominio di override.

      • In Windows 95, Windows 98 e Windows 98 Second Edition, il client servizi directory utilizza la firma SMB quando esegue l'autenticazione con i server Windows Server 2003 tramite l'autenticazione NTLM. Tuttavia, questi client non utilizzano la firma SMB quando eseguono l'autenticazione con questi server utilizzando l'autenticazione NTLMv2. Inoltre, i server Windows 2000 non rispondono alle richieste di firma SMB da questi client. Per ulteriori informazioni, vedere l'elemento 10: "Sicurezza di rete: livello di autenticazione Lan Manager".

   2. Configurazione
      
      rischiosa Di seguito è riportata un'impostazione di configurazione dannosa: lasciando impostato sia il client di rete Microsoft: Firma digitale per le comunicazioni (sempre) che client di rete Microsoft: l'impostazione Firma digitale comunicazioni (se il server accetta) impostata su "Non definita" o disabilitata. Queste impostazioni consentono al redirector di inviare password in testo normale a server SMB non Microsoft che non supportano la crittografia delle password durante l'autenticazione.

   3. Motivi per abilitare questa impostazione
      
      Abilitazione del client di rete Microsoft: la firma digitale delle comunicazioni (sempre) richiede ai client di firmare il traffico SMB quando contattano server che non richiedono la firma SMB. Ciò rende i client meno vulnerabili agli attacchi di dirottamento della sessione.

   4. Motivi per disabilitare questa impostazione

      • Abilitazione del client di rete Microsoft: la firma digitale delle comunicazioni (sempre) impedisce ai client di comunicare con i server di destinazione che non supportano la firma SMB.

      • La configurazione dei computer per ignorare tutte le comunicazioni SMB non firmate impedisce la connessione di programmi e sistemi operativi precedenti.

   5. Nome simbolico:
      
      RequireSMBSignRdr

   6. Percorso del Registro di sistema:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature

   7. Esempi di problemi di compatibilità

      • Windows NT 4.0: non sarà possibile reimpostare il canale sicuro di un trust tra un dominio di Windows Server 2003 e un dominio di Windows NT 4.0 usando NLTEST o NETDOM e verrà visualizzato un messaggio di errore "Accesso negato".

      • Windows XP: la copia di file dai client Windows XP ai server basati su Windows 2000 e ai server basati su Windows Server 2003 può richiedere più tempo.

      • Non sarà possibile eseguire il mapping di un'unità di rete da un client con questa impostazione abilitata e verrà visualizzato il messaggio di errore seguente:

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

   8. Requisiti di
      
      riavvio Riavvia il computer o riavvia il servizio Workstation. A questo scopo, digitare i comandi seguenti al prompt dei comandi. Premere INVIO dopo aver digitato ogni comando.

      net stop workstation
      net start workstation

6. Server di rete Microsoft: firma digitale delle comunicazioni (sempre)

   1. Sfondo

      • Server Messenger Block (SMB) è il protocollo di condivisione delle risorse supportato da molti sistemi operativi Microsoft. È la base del sistema di input/output di base di rete (NetBIOS) e di molti altri protocolli. La firma SMB autentica sia l'utente che il server che ospita i dati. Se entrambi i lati non riescono a eseguire il processo di autenticazione, non verrà eseguita la trasmissione dei dati.
        
        L'abilitazione della firma SMB viene avviata durante la negoziazione del protocollo SMB. I criteri di firma SMB determinano se il computer firma sempre digitalmente le comunicazioni client.
        
        Il protocollo di autenticazione SMB di Windows 2000 supporta l'autenticazione reciproca. L'autenticazione reciproca chiude un attacco "man-in-the-middle". Il protocollo di autenticazione SMB di Windows 2000 supporta anche l'autenticazione dei messaggi. L'autenticazione dei messaggi consente di evitare attacchi attivi ai messaggi. Per fornire questa autenticazione, la firma SMB inserisce una firma digitale in ogni SMB. Il client e il server verificano ognuno la firma digitale.
        
        Per utilizzare la firma SMB, è necessario abilitare la firma SMB o richiedere la firma SMB sia sul client SMB che sul server SMB. Se la firma SMB è abilitata su un server, i client abilitati anche per la firma SMB usano il protocollo di firma dei pacchetti durante tutte le sessioni successive. Se la firma SMB è richiesta su un server, un client non può stabilire una sessione a meno che il client non sia abilitato o richiesto per la firma SMB.
        
        
        L'abilitazione della firma digitale nelle reti ad alta sicurezza consente di impedire la rappresentazione dei client e dei server. Questo tipo di rappresentazione è noto come dirottamento di sessione. Un utente malintenzionato che ha accesso alla stessa rete del client o del server utilizza gli strumenti di dirottamento della sessione per interrompere, terminare o rubare una sessione in corso. Un utente malintenzionato potrebbe intercettare e modificare i pacchetti di Gestione larghezza di banda subnet (SBM) non firmati, modificare il traffico e quindi inoltrarlo in modo che il server possa eseguire azioni indesiderate. In alternativa, l'autore dell'attacco potrebbe presentarsi come server o client dopo un'autenticazione legittima e quindi ottenere l'accesso non autorizzato ai dati.
        
        Il protocollo SMB usato per la condivisione di file e la condivisione della stampa nei computer che eseguono Windows 2000 Server, Windows 2000 Professional, Windows XP Professional o Windows Server 2003 supporta l'autenticazione reciproca. L'autenticazione reciproca chiude gli attacchi di dirottamento della sessione e supporta l'autenticazione dei messaggi. Pertanto, impedisce attacchi man-in-the-middle. La firma SMB fornisce questa autenticazione inserendo una firma digitale in ogni SMB. Il client e il server verificano quindi la firma.

      • Come misura alternativa, è possibile abilitare le firme digitali con IPSec per proteggere tutto il traffico di rete. Esistono acceleratori basati su hardware per la crittografia e la firma IPSec che è possibile usare per ridurre al minimo l'impatto sulle prestazioni della CPU del server. Non sono disponibili acceleratori di questo tipo per la firma SMB.

      • In Windows 95, Windows 98 e Windows 98 Second Edition, il client servizi directory utilizza la firma SMB quando esegue l'autenticazione con i server Windows Server 2003 tramite l'autenticazione NTLM. Tuttavia, questi client non utilizzano la firma SMB quando eseguono l'autenticazione con questi server utilizzando l'autenticazione NTLMv2. Inoltre, i server Windows 2000 non rispondono alle richieste di firma SMB da questi client. Per ulteriori informazioni, vedere l'elemento 10: "Sicurezza di rete: livello di autenticazione Lan Manager".

   2. Configurazione
      
      rischiosa Di seguito è riportata un'impostazione di configurazione dannosa: abilitazione del server di rete Microsoft: firma digitale delle comunicazioni (sempre) nei server e nei controller di dominio a cui accedono computer basati su Windows non compatibili e computer client basati su sistema operativo di terze parti in domini locali o esterni.

   3. Motivi per abilitare questa impostazione

      • Tutti i computer client che abilitano questa impostazione direttamente tramite il Registro di sistema o tramite l'impostazione Criteri di gruppo supportano la firma SMB. In altre parole, tutti i computer client in cui è abilitata questa impostazione eseguono Windows 95 con il client DS installato, Windows 98, Windows NT 4.0, Windows 2000, Windows XP Professional o Windows Server 2003.

      • Se il server di rete Microsoft: la firma digitale delle comunicazioni (sempre) è disabilitata, la firma SMB è completamente disabilitata. La disabilitazione completa di tutte le firme SMB rende i computer più vulnerabili agli attacchi di dirottamento della sessione.

   4. Motivi per disabilitare questa impostazione

      • L'abilitazione di questa impostazione può causare una copia dei file più lenta e prestazioni di rete nei computer client.

      • L'abilitazione di questa impostazione impedirà ai client che non possono negoziare la firma SMB di comunicare con i server e con i controller di dominio. Di conseguenza, le operazioni come i join a un dominio, l'autenticazione di utenti e computer o l'accesso alla rete da parte dei programmi non riescono.

   5. Nome simbolico:
      
      RequireSMBSignServer

   6. Percorso del Registro di sistema:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature (REG_DWORD)

   7. Esempi di problemi di compatibilità

      • Windows 95: i client di Windows 95 in cui non è installato il client Servizi directory non riusciranno a eseguire l'autenticazione di accesso e riceveranno il seguente messaggio di errore:

        La password di dominio fornita non è corretta o l'accesso al server di accesso è stato negato.

      • Windows NT 4.0: i computer client che eseguono versioni di Windows NT 4.0 precedenti al Service Pack 3 (SP3) non riescono ad accedere e riceveranno il seguente messaggio di errore:

        Il sistema non è riuscito ad accedere. Verificare che il nome utente e il dominio siano corretti, quindi digitare di nuovo la password.

        Alcuni server SMB non Microsoft supportano solo gli scambi di password non crittografati durante l'autenticazione. (Questi scambi sono noti anche come scambi di "testo normale". Per Windows NT 4.0 SP3 e versioni successive, il redirector SMB non invia una password non crittografata durante l'autenticazione a un server SMB a meno che non venga aggiunta una voce del Registro di sistema specifica.
        Per abilitare le password non crittografate per il client SMB in Windows NT 4.0 SP 3 e nei sistemi più recenti, modificare il Registro di sistema nel modo seguente: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters
        
        Nome valore: EnablePlainTextPassword
        
        Tipo di dati: REG_DWORD
        
        Dati: 1
        
         

      • Windows Server 2003: per impostazione predefinita, le impostazioni di sicurezza nei controller di dominio che eseguono Windows Server 2003 sono configurate per impedire che le comunicazioni del controller di dominio vengano intercettate o alterate da utenti malintenzionati. Per consentire agli utenti di comunicare correttamente con un controller di dominio che esegue Windows Server 2003, i computer client devono usare sia la firma SMB che la crittografia o la firma del traffico del canale sicuro. Per impostazione predefinita, per i client che eseguono Windows NT 4.0 con Service Pack 2 (SP2) o versioni precedenti installati e per i client che eseguono Windows 95 non è abilitata la firma dei pacchetti SMB. Pertanto, questi client potrebbero non essere in grado di eseguire l'autenticazione in un controller di dominio basato su Windows Server 2003.

      • Impostazioni dei criteri di Windows 2000 e Windows Server 2003: a seconda delle specifiche esigenze di installazione e configurazione, è consigliabile impostare le seguenti impostazioni dei criteri nell'entità più bassa dell'ambito necessario nella gerarchia dello snap-in Microsoft Management Console Criteri di gruppo Editor:

        • Configurazione computer\Impostazioni Sicurezza di Windows\Opzioni di sicurezza

        • Inviare una password non crittografata per connettersi a server SMB di terze parti (questa impostazione è per Windows 2000)

        • Client di rete Microsoft: inviare password non crittografate a server SMB di terze parti (questa impostazione è per Windows Server 2003)

        
        Nota In alcuni server CIFS di terze parti, ad esempio le versioni samba precedenti, non è possibile usare password crittografate.

      • I client seguenti non sono compatibili con il server di rete Microsoft: firma digitale delle comunicazioni (sempre):

        • Client Apple Computer, Inc., Mac OS X

        • Client di rete Microsoft MS-DOS (ad esempio, Microsoft LAN Manager)

        • Client Microsoft Windows per Workgroup

        • Client Microsoft Windows 95 senza il client DS installato

        • Computer basati su Microsoft Windows NT 4.0 senza SP3 o versioni successive installate

        • Client CIFS Novell Netware 6

        • Client SAMBA SMB che non dispongono del supporto per la firma SMB

   8. Requisiti di
      
      riavvio Riavviare il computer o riavviare il servizio Server. A questo scopo, digitare i comandi seguenti al prompt dei comandi. Premere INVIO dopo aver digitato ogni comando.

      net stop server
      net start server

7. Accesso alla rete: consentire la traduzione sid/nome anonima

   1. Priorità bassa
      
      L'impostazione di sicurezza Accesso di rete: consenti la traduzione sid/nome anonimo determina se un utente anonimo può richiedere attributi SID (Security Identification Number) per un altro utente.

   2. Configurazione
      
      rischiosa Abilitazione dell'accesso di rete: l'impostazione Consenti traduzione sid/nome anonimo è un'impostazione di configurazione dannosa.

   3. Motivi per abilitare questa impostazione
      
      Se l'impostazione Accesso alla rete: Consenti traduzione nome/SID anonimo è disabilitata, le applicazioni o i sistemi operativi precedenti potrebbero non essere in grado di comunicare con i domini di Windows Server 2003. Ad esempio, i sistemi operativi, i servizi o le applicazioni seguenti potrebbero non funzionare:

      • Server del Servizio accesso remoto basati su Windows NT 4.0

      • Microsoft SQL Server in esecuzione in computer basati su Windows NT 3.x o computer basati su Windows NT 4.0

      • Servizio accesso remoto in esecuzione in computer basati su Windows 2000 che si trovano nei domini Windows NT 3.x o Windows NT 4.0

      • SQL Server in esecuzione in computer basati su Windows 2000 che si trovano nei domini Windows NT 3.x o Windows NT 4.0

      • Utenti nel dominio di risorse di Windows NT 4.0 che vogliono concedere le autorizzazioni per accedere a file, cartelle condivise e oggetti del Registro di sistema agli account utente da domini di account che contengono controller di dominio di Windows Server 2003

   4. Motivi per disabilitare questa impostazione
      
      Se questa impostazione è abilitata, un utente malintenzionato potrebbe usare il noto SID Administrators per ottenere il nome reale dell'account administrator predefinito, anche se l'account è stato rinominato. La persona potrebbe quindi usare il nome dell'account per avviare un attacco con password.

   5. Nome simbolico: N/D

   6. Percorso del Registro di sistema: Nessuno. Il percorso è specificato nel codice dell'interfaccia utente.

   7. Esempi di problemi
      
      di compatibilità Windows NT 4.0: i computer nei domini delle risorse di Windows NT 4.0 visualizzano il messaggio di errore "Account sconosciuto" nell'editor ACL se le risorse, incluse le cartelle condivise, i file condivisi e gli oggetti del Registro di sistema, sono protette con entità di sicurezza che risiedono in domini di account che contengono controller di dominio di Windows Server 2003.

8. Accesso alla rete: non consentire l'enumerazione anonima degli account SAM

   1. Sfondo

      • L'impostazione Accesso di rete: non consentire l'enumerazione anonima degli account SAM determina quali autorizzazioni aggiuntive verranno concesse per le connessioni anonime al computer. Windows consente agli utenti anonimi di eseguire determinate attività, ad esempio enumerare i nomi degli account di gestione degli account di sicurezza (SAM) della workstation e del server e delle condivisioni di rete. Ad esempio, un amministratore può usarlo per concedere l'accesso agli utenti in un dominio attendibile che non mantiene un trust reciproco. Una volta eseguita una sessione, un utente anonimo può avere lo stesso accesso concesso al gruppo Tutti in base all'impostazione nell'accesso di rete: consenti a Tutti di applicare le autorizzazioni agli utenti anonimi o all'elenco di controllo di accesso discrezionale dell'oggetto.
        
        In genere, le connessioni anonime vengono richieste dalle versioni precedenti dei client (client di livello inferiore) durante la configurazione della sessione SMB. In questi casi, una traccia di rete mostra che l'ID processo SMB (PID) è il redirector client, ad esempio 0xFEFF in Windows 2000 o 0xCAFE in Windows NT. RPC può anche tentare di effettuare connessioni anonime.

      • Importante Questa impostazione non ha alcun impatto sui controller di dominio. Nei controller di dominio questo comportamento è controllato dalla presenza di "NT AUTHORITY\ANONYMOUS LOGON" in "Accesso compatibile con Windows 2000 precedente".

      • In Windows 2000, un'impostazione simile denominata Ulteriori restrizioni per connessioni anonime gestisce il valore del Registro di sistema RestrictAnonymous . La posizione di questo valore è la seguente:

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA  

   2. Configurazioni rischiose
      
      Abilitazione dell'accesso alla rete: non consentire l'impostazione dell'enumerazione anonima degli account SAM è un'impostazione di configurazione dannosa dal punto di vista della compatibilità. La disabilitazione è un'impostazione di configurazione dannosa dal punto di vista della sicurezza.

   3. Motivi per abilitare questa impostazione
      
      Un utente non autorizzato potrebbe elencare in modo anonimo i nomi degli account e quindi usare le informazioni per provare a indovinare le password o eseguire attacchi di ingegneria sociale. L'ingegneria sociale è un gergo che significa indurre le persone a rivelare le loro password o una qualche forma di informazioni di sicurezza.

   4. Motivi per disabilitare questa impostazione
      
      Se questa impostazione è abilitata, è impossibile stabilire trust con i domini di Windows NT 4.0. Questa impostazione causa anche problemi con i client di livello inferiore (ad esempio i client Windows NT 3.51 e i client windows 95) che tentano di usare le risorse sul server.

   5. Nome simbolico:
      
      
      RestrictAnonymousSAM

   6. Percorso del Registro di sistema:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM (Reg_DWORD)

   7. Esempi di problemi di compatibilità

   • L'individuazione della rete SMS non sarà in grado di ottenere informazioni sul sistema operativo e scriverà "Sconosciuto" nella proprietà OperatingSystemNameandVersion.

   • Windows 95, Windows 98: i client di Windows 95 e Windows 98 non saranno in grado di cambiare le loro password.

   • Windows NT 4.0: i computer membri basati su Windows NT 4.0 non potranno essere autenticati.

   • Windows 95, Windows 98: i computer basati su Windows 95 e Windows 98 non potranno essere autenticati dai controller di dominio Microsoft.

   • Windows 95, Windows 98: gli utenti di computer basati su Windows 95 e Windows 98 non potranno cambiare le password per i loro account utente.

9. Accesso alla rete: non consentire l'enumerazione anonima degli account e delle condivisioni SAM

   1. Sfondo

      • L'impostazione Accesso alla rete: non consentire l'enumerazione anonima degli account SAM e delle condivisioni (nota anche come RestrictAnonymous) determina se è consentita l'enumerazione anonima degli account e delle condivisioni sam (Security Accounts Manager). Windows consente agli utenti anonimi di eseguire determinate attività, ad esempio enumerare i nomi degli account di dominio (utenti, computer e gruppi) e delle condivisioni di rete. Questo è utile, ad esempio, quando un amministratore vuole concedere l'accesso agli utenti in un dominio attendibile che non mantiene un trust reciproco. Se non si desidera consentire l'enumerazione anonima degli account SAM e delle condivisioni, abilitare questa impostazione.

      • In Windows 2000, un'impostazione simile denominata Ulteriori restrizioni per connessioni anonime gestisce il valore del Registro di sistema RestrictAnonymous . La posizione di questo valore è la seguente:

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

   2. Configurazione
      
      rischiosa Abilitazione dell'accesso di rete: l'impostazione Non consentire l'enumerazione anonima degli account SAM e delle condivisioni è un'impostazione di configurazione dannosa.

   3. Motivi per abilitare questa impostazione

      • Abilitazione dell'accesso alla rete: non consentire l'impostazione dell'enumerazione anonima degli account SAM e delle condivisioni impedisce l'enumerazione degli account SAM e delle condivisioni da parte di utenti e computer che utilizzano account anonimi.

   4. Motivi per disabilitare questa impostazione

      • Se questa impostazione è abilitata, un utente non autorizzato potrebbe elencare in modo anonimo i nomi degli account e quindi usare le informazioni per provare a indovinare le password o eseguire attacchi di ingegneria sociale. L'ingegneria sociale è un gergo che significa indurre le persone a rivelare la propria password o una qualche forma di informazioni di sicurezza.

      • Se questa impostazione è abilitata, sarà impossibile stabilire trust con i domini di Windows NT 4.0. Questa impostazione causerà anche problemi con i client di livello inferiore, ad esempio i client Windows NT 3.51 e Windows 95 che provano a usare le risorse sul server.

      • Sarà impossibile concedere l'accesso agli utenti dei domini delle risorse perché gli amministratori del dominio attendibile non saranno in grado di enumerare gli elenchi di account nell'altro dominio. Gli utenti che accedono ai server di file e stampa in modalità anonima non potranno elencare le risorse di rete condivise in tali server. Gli utenti devono eseguire l'autenticazione prima di poter visualizzare gli elenchi di cartelle e stampanti condivise.

   5. Nome simbolico:
      
      Restrictanonymous

   6. Percorso del Registro di sistema:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous

   7. Esempi di problemi di compatibilità

      • Windows NT 4.0: gli utenti non saranno in grado di cambiare le password delle workstation Windows NT 4.0 quando RestrictAnonymous è abilitato nei controller di dominio nel dominio degli utenti.

      • Windows NT 4.0: l'aggiunta di utenti o gruppi globali dai domini attendibili di Windows 2000 ai gruppi locali di Windows NT 4.0 in User Manager avrà esito negativo e verrà visualizzato il messaggio di errore seguente:

        Attualmente non sono disponibili server di accesso per la richiesta di accesso.

      • Windows NT 4.0: i computer basati su Windows NT 4.0 non potranno partecipare ai domini durante l'installazione o usando l'interfaccia utente di aggiunta al dominio.

      • Windows NT 4.0: la creazione di un trust di livello inferiore con i domini delle risorse di Windows NT 4.0 avrà esito negativo. Quando RestrictAnonymous è abilitato nel dominio attendibile, viene visualizzato il messaggio di errore seguente:

        Impossibile trovare il controller di dominio per questo dominio.

      • Windows NT 4.0: gli utenti che accedono a computer Terminal Server basati su Windows NT 4.0 verranno mappati alla home directory predefinita anziché alla directory principale definita in User Manager per i domini.

      • Windows NT 4.0: i controller di dominio di backup di Windows NT 4.0 non saranno in grado di avviare il servizio Accesso Net, ottenere un elenco di browser di backup o sincronizzare il database SAM da Windows 2000 o dai controller di dominio di Windows Server 2003 nello stesso dominio.

      • Windows 2000: i computer membri basati su Windows 2000 nei domini Windows NT 4.0 non potranno visualizzare le stampanti in domini esterni se l'impostazione Nessun accesso senza autorizzazioni anonime esplicitamente è abilitata nei criteri di sicurezza locali del computer client.

      • Windows 2000: gli utenti del dominio di Windows 2000 non potranno aggiungere stampanti di rete da Active Directory; tuttavia, potranno aggiungere stampanti dopo averle selezionate nella visualizzazione albero.

      • Windows 2000: nei computer basati su Windows 2000, Editor ACL non sarà in grado di aggiungere utenti o gruppi globali da domini attendibili di Windows NT 4.0.

      • ADMT versione 2: la migrazione delle password per gli account utente migrati tra foreste con Active Directory Migration Tool (ADMT) versione 2 avrà esito negativo.
        
        Per altre informazioni, fare clic sul numero dell'articolo seguente per visualizzare l'articolo della Microsoft Knowledge Base:

        322981 Come risolvere i problemi relativi alla migrazione delle password tra foreste con ADMTv2

      • Client Outlook: l'elenco indirizzi globale apparirà vuoto per i client di Microsoft Exchange Outlook.

      • SMS: Microsoft Systems Management Server (SMS) Network Discovery non sarà in grado di ottenere le informazioni sul sistema operativo. Pertanto, scriverà "Unknown" nella proprietà OperatingSystemNameandVersion della proprietà SMS DDR del record di dati di individuazione (DDR).

      • SMS: quando si utilizza la Procedura guidata utente per l'amministratore di SMS per cercare utenti e gruppi, non verranno elencati utenti o gruppi. Inoltre, i client avanzati non possono comunicare con il punto di gestione. È necessario l'accesso anonimo nel punto di gestione.

      • SMS: quando si usa la funzionalità individuazione rete in SMS 2.0 e nell'installazione remota del client con l'opzione di individuazione della rete di topologia, client e sistemi operativi client attivata, i computer potrebbero essere individuati ma potrebbero non essere installati.

10. Sicurezza di rete: livello di autenticazione di Lan Manager

    1. Priorità bassa
       
       L'autenticazione LAN Manager (LM) è il protocollo usato per autenticare i client Windows per le operazioni di rete, inclusi i join a un dominio, l'accesso alle risorse di rete e l'autenticazione di utenti o computer. Il livello di autenticazione LM determina quale protocollo di autenticazione di verifica/risposta viene negoziato tra il client e i computer server. In particolare, il livello di autenticazione LM determina quali protocolli di autenticazione il client tenterà di negoziare o che il server accetterà. Il valore impostato per LmCompatibilityLevel determina quale protocollo di autenticazione challenge/response viene usato per gli accessi di rete. Questo valore influisce sul livello di protocollo di autenticazione usato dai client, sul livello di sicurezza della sessione negoziata e sul livello di autenticazione accettato dai server.
       
       Le impostazioni possibili includono quanto segue.

       Valore	Impostazione	Descrizione
       0	Inviare risposte NTLM & LM	I client utilizzano l'autenticazione LM e NTLM e non usano mai la sicurezza della sessione NTLMv2. I controller di dominio accettano l'autenticazione LM, NTLM e NTLMv2.
       1	Send LM & NTLM - use NTLMv2 session security if negotiated	I client utilizzano l'autenticazione LM e NTLM e la sicurezza della sessione NTLMv2, se supportato dal server. I controller di dominio accettano l'autenticazione LM, NTLM e NTLMv2.
       2	Invia solo risposta NTLM	I client utilizzano solo l'autenticazione NTLM e la sicurezza della sessione NTLMv2, se supportato dal server. I controller di dominio accettano l'autenticazione LM, NTLM e NTLMv2.
       3	Invia solo risposta NTLMv2	I client utilizzano solo l'autenticazione NTLMv2 e usano la sicurezza della sessione NTLMv2 se supportati dal server. I controller di dominio accettano l'autenticazione LM, NTLM e NTLMv2.
       4	Invia solo risposta NTLMv2/rifiuta LM	I client utilizzano solo l'autenticazione NTLMv2 e usano la sicurezza della sessione NTLMv2 se supportati dal server. I controller di dominio rifiutano LM e accettano solo l'autenticazione NTLM e NTLMv2.
       5	Invia solo risposta NTLMv2/rifiuta LM & NTLM	I client utilizzano solo l'autenticazione NTLMv2 e usano la sicurezza della sessione NTLMv2 se supportati dal server. I controller di dominio rifiutano LM e NTLM e accettano solo l'autenticazione NTLMv2.

       Nota In Windows 95, Windows 98 e Windows 98 Second Edition, il client servizi directory utilizza la firma SMB quando esegue l'autenticazione con i server Windows Server 2003 tramite l'autenticazione NTLM. Tuttavia, questi client non utilizzano la firma SMB quando eseguono l'autenticazione con questi server utilizzando l'autenticazione NTLMv2. Inoltre, i server Windows 2000 non rispondono alle richieste di firma SMB da questi client.
       
       Controllare il livello di autenticazione LM: è necessario modificare il criterio sul server per consentire NTLM, o è necessario configurare il computer client per supportare NTLMv2.
       
       Se il criterio è impostato su (5) Invia solo risposta NTLMv2\refuse LM & NTLM nel computer di destinazione a cui ci si vuole connettere, è necessario abbassare l'impostazione del computer o impostare la sicurezza sulla stessa impostazione del computer di origine da cui ci si connette.
       
       Trovare la posizione corretta in cui è possibile modificare il livello di autenticazione di GESTIONE LAN per impostare il client e il server allo stesso livello. Dopo aver trovato il criterio che sta impostando il livello di autenticazione del gestore LAN, se si desidera connettersi a e da computer che eseguono versioni precedenti di Windows, abbassare il valore almeno (1) Invia LM & NTLM - utilizzare la sicurezza della sessione NTLM versione 2 se negoziata. Un effetto delle impostazioni incompatibili è che se il server richiede NTLMv2 (valore 5), ma il client è configurato per l'uso solo di LM e NTLMv1 (valore 0), l'utente che prova l'autenticazione riscontra un errore di accesso con una password errata e che incrementa il numero di password non valide. Se è configurato il blocco dell'account, l'utente potrebbe essere bloccato.
       
       Ad esempio, potrebbe essere necessario esaminare il controller di dominio oppure esaminare i criteri del controller di dominio.
       
       Controllare il controller di
       
       dominio Nota Potrebbe essere necessario ripetere la procedura seguente in tutti i controller di dominio.

       1. Fare clic sul pulsante Start, scegliere Programmi e quindi strumenti di amministrazione.

       2. In Impostazioni di sicurezza locali espandi Criteri locali.

       3. Fare clic su Opzioni di sicurezza.

       4. Fare doppio clic su Sicurezza di rete: livello di autenticazione gestore LAN e quindi fare clic su un valore nell'elenco.

       
       Se l'impostazione effettiva e l'impostazione locale sono uguali, il criterio è stato modificato a questo livello. Se le impostazioni sono diverse, è necessario controllare i criteri del controller di dominio per determinare se è definita l'impostazione del livello di autenticazione Sicurezza di rete: GESTORE LAN. In caso contrario, esaminare i criteri del controller di dominio.
       
       Esaminare i criteri del controller di dominio

       1. Fare clic sul pulsante Start, scegliere Programmi e quindi strumenti di amministrazione.

       2. In Criteri di sicurezza del controller di dominio espandere Impostazioni di sicurezza e quindi Criteri locali.

       3. Fare clic su Opzioni di sicurezza.

       4. Fare doppio clic su Sicurezza di rete: livello di autenticazione gestore LAN e quindi fare clic su un valore nell'elenco.

       
       Nota

       • Può anche essere necessario controllare i criteri collegati a livello di sito, di dominio o di unità organizzativa per determinare dove configurare il livello di autenticazione di LAN manager.

       • Se si implementa un'impostazione di Criteri di gruppo come criterio di dominio predefinito, il criterio viene applicato a tutti i computer del dominio.

       • Se si implementa un'impostazione di Criteri di gruppo come criterio del controller di dominio predefinito, il criterio si applica solo ai server nell'unità organizzativa del controller di dominio.

       • È consigliabile impostare il livello di autenticazione del gestore LAN nell'entità più bassa dell'ambito necessario nella gerarchia delle applicazioni dei criteri.

       In Windows Server 2003 è disponibile una nuova impostazione predefinita per l'utilizzo solo di NTLMv2. Per impostazione predefinita, i controller di dominio basati su Windows Server 2003 e Windows 2000 Server SP3 hanno abilitato il criterio "Microsoft network server: digitally sign communications (always)". Questa impostazione richiede al server SMB di eseguire la firma dei pacchetti SMB. Sono state apportate modifiche a Windows Server 2003 perché controller di dominio, file server, server dell'infrastruttura di rete e server Web in qualsiasi organizzazione richiedono impostazioni diverse per massimizzare la sicurezza.
       
       Se si vuole implementare l'autenticazione NTLMv2 nella rete, è necessario verificare che tutti i computer nel dominio siano impostati per l'utilizzo di questo livello di autenticazione. Se si applicano le estensioni client di Active Directory per Windows 95 o Windows 98 e Windows NT 4.0, le estensioni client utilizzano le funzionalità di autenticazione migliorate disponibili in NTLMv2. Poiché i computer client che eseguono uno dei seguenti sistemi operativi non sono interessati da Windows 2000 Criteri di gruppo Objects, potrebbe essere necessario configurare manualmente questi client:

       • Microsoft Windows NT 4.0

       • Microsoft Windows Millennium Edition

       • Microsoft Windows 98

       • Microsoft Windows 95

       Nota Se si abilita la sicurezza della rete: non archiviare il valore hash del gestore LAN nei criteri di modifica della password successivi o impostare la chiave del Registro di sistema NoLMHash , i client basati su Windows 95 e Windows 98 che non hanno installato il client servizi directory non possono accedere al dominio dopo una modifica della password.
       
       Molti server CIFS di terze parti, come Novell Netware 6, non sono a conoscenza di NTLMv2 e utilizzano solo NTLM. Pertanto, i livelli superiori a 2 non consentono la connettività. Esistono anche client SMB di terze parti che non usano la sicurezza estesa delle sessioni. In questi casi, l'LmCompatiblityLevel del server delle risorse non viene preso in considerazione. Il server quindi crea il pacchetto di questa richiesta legacy e lo invia al controller di dominio utente. Le impostazioni del controller di dominio decidono quindi quali hash vengono usati per verificare la richiesta e se soddisfano i requisiti di sicurezza del controller di dominio.
       
        

       299656 Come impedire a Windows di archiviare un hash di gestione LAN della password in Active Directory e database SAM locali
        

       2701704Audit event shows authentication package as NTLMv1 instead of NTLMv2 For more information about LM authentication levels, click the following article number to view the article in the Microsoft Knowledge Base:

       239869 Come abilitare l'autenticazione NTLM 2
        

    2. Configurazioni rischiose
       
       Di seguito sono riportate le impostazioni di configurazione dannose:

       • Impostazioni non restrittive che inviano password in testo non crittografato e che negano la negoziazione NTLMv2

       • Impostazioni restrittive che impediscono ai client o ai controller di dominio incompatibili di negoziare un protocollo di autenticazione comune

       • Richiesta dell'autenticazione NTLMv2 nei computer membri e nei controller di dominio che eseguono versioni di Windows NT 4.0 precedenti al Service Pack 4 (SP4)

       • Richiesta dell'autenticazione NTLMv2 nei client Windows 95 o nei client Windows 98 in cui non è installato il client Servizi directory Windows.

       • Se si fa clic per selezionare la casella di controllo Richiedi sicurezza sessione NTLMv2 nello snap-in Microsoft Management Console Criteri di gruppo Editor in un computer basato su Windows Server 2003 o Windows 2000 Service Pack 3 e si riduce il livello di autenticazione di LAN Manager a 0, le due impostazioni sono in conflitto e potrebbe essere visualizzato il messaggio di errore seguente nel file Secpol.msc o nel file GPEdit.msc:

         Windows non può aprire il database dei criteri locali. Si è verificato un errore sconosciuto durante il tentativo di aprire il database.

         Per altre informazioni sullo Strumento di analisi e configurazione della sicurezza, vedere i file della Guida di Windows 2000 o Windows Server 2003.

    3. Motivi per modificare questa impostazione

       • Si vuole aumentare il protocollo di autenticazione comune più basso supportato dai client e dai controller di dominio dell'organizzazione.

       • Se l'autenticazione sicura è un requisito aziendale, si desidera impedire la negoziazione dei protocolli LM e NTLM.

    4. Motivi per disabilitare questa impostazione
       
       I requisiti di autenticazione client o server, o entrambi, sono stati aumentati fino a quando non è possibile eseguire l'autenticazione su un protocollo comune.

    5. Nome simbolico:
       
       Lmcompatibilitylevel

    6. Percorso del Registro di sistema:

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

    7. Esempi di problemi di compatibilità

       • Windows Server 2003: per impostazione predefinita, è abilitata l'impostazione Invia risposte NTLM di Windows Server 2003 NTLMv2. Pertanto, Windows Server 2003 riceve il messaggio di errore "Accesso negato" dopo l'installazione iniziale quando si tenta di connettersi a un cluster basato su Windows NT 4.0 o a server basati su LanManager V2.1, ad esempio OS/2 Lanserver. Questo problema si verifica anche se si tenta di connettersi da un client di versioni precedenti a un server basato su Windows Server 2003.

       • Installare il pacchetto di aggiornamento cumulativo della sicurezza 1 (SRP1) di Windows 2000. SRP1 forza NTLM versione 2 (NTLMv2). Questo pacchetto cumulativo è stato rilasciato dopo il rilascio di Windows 2000 Service Pack 2 (SP2).
          

       • Windows 7 e Windows Server 2008 R2: molti server CIFS di terze parti, come i server Novell Netware 6 o Samba basati su Linux, non sono a conoscenza di NTLMv2 e usano solo NTLM. Pertanto, i livelli superiori a "2" non consentono la connettività. Ora, in questa versione del sistema operativo, il valore predefinito per LmCompatibilityLevel è stato modificato in "3". Pertanto, quando aggiorni Windows, questi filer di terze parti potrebbero smettere di funzionare.

       • È possibile che ai client Microsoft Outlook vengano richieste le credenziali anche se sono già connessi al dominio. Quando gli utenti forniscono le proprie credenziali, ricevono il seguente messaggio di errore: Windows 7 e Windows Server 2008 R2

         Le credenziali di accesso fornite non erano corrette. Verificare che il nome utente e il dominio siano corretti, quindi digitare di nuovo la password.

         Quando si avvia Outlook, è possibile che vengano richieste le credenziali anche se l'impostazione Sicurezza rete di accesso è impostata su Passthrough o autenticazione password. Dopo aver digitato le credenziali corrette, potrebbe essere visualizzato il messaggio di errore seguente:

         Le credenziali di accesso fornite non erano corrette.

         Una traccia di Network Monitor può indicare che il catalogo globale ha emesso un errore RPC (Remote Procedure Call) con stato di 0x5. Lo stato di 0x5 indica "Accesso negato".

       • Windows 2000: l'acquisizione di un monitor di rete può mostrare i seguenti errori nella sessione di blocco messaggi del server NetBIOS su TCP/IP (NetBT):

         Errore SMB R Search Directory Dos, (5) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (91) Identificatore utente non valido

       • Windows 2000: se un dominio windows 2000 con NTLMv2 livello 2 o versione successiva è attendibile da un dominio Windows NT 4.0, i computer membri basati su Windows 2000 nel dominio della risorsa potrebbero riscontrare errori di autenticazione.

       • Windows 2000 e Windows XP: per impostazione predefinita, Windows 2000 e Windows XP impostano l'opzione Criteri di sicurezza locali a livello di autenticazione di LAN Manager su 0. L'impostazione 0 indica "Invia risposte LM e NTLM".
         
         Nota: i cluster basati su Windows NT 4.0 devono usare LM per l'amministrazione.

       • Windows 2000: il clustering di Windows 2000 non autentica un nodo di join se entrambi i nodi fanno parte di un dominio Windows NT 4.0 Service Pack 6a (SP6a).

       • Lo strumento di blocco IIS (HiSecWeb) imposta il valore LMCompatibilityLevel su 5 e il valore RestrictAnonymous su 2.

       • Servizi per Macintosh
         
         User Authentication Module (UAM): Microsoft UAM (User Authentication Module) fornisce un metodo per crittografare le password utilizzate per accedere ai server Windows PROXY (AppleTalk Filing Protocol). L'Apple User Authentication Module (UAM) fornisce solo crittografia minima o nessuna. Pertanto, la password potrebbe essere facilmente intercettata sulla LAN o su Internet. Anche se UAM non è obbligatorio, fornisce l'autenticazione crittografata ai server Windows 2000 che eseguono Services For Macintosh. Questa versione include il supporto per l'autenticazione crittografata A 128 bit NTLMv2 e una versione compatibile con MacOS X 10.1.
         
         Per impostazione predefinita, i Servizi di Windows Server 2003 per Macintosh consentono solo l'autenticazione Microsoft.
          

       • Windows Server 2008, Windows Server 2003, Windows XP e Windows 2000: se si configura il valore LMCompatibilityLevel su 0 o 1 e quindi si configura il valore NoLMHash su 1, l'accesso alle applicazioni e ai componenti tramite NTLM potrebbe essere negato. Questo problema si verifica perché il computer è configurato per abilitare LM ma non per usare password archiviate da LM.
         
         Se si configura il valore NoLMHash su 1, è necessario configurare il valore LMCompatibilityLevel su 2 o superiore.

11. Sicurezza di rete: requisiti di firma client LDAP

    1. Priorità bassa
       
       L'impostazione Sicurezza di rete: requisiti di firma client LDAP determina il livello di firma dei dati richiesto per conto dei client che emettono richieste BINDING LDAP (Lightweight Directory Access Protocol), come indicato di seguito:

       • Nessuno: la richiesta BINDING LDAP viene emessa con le opzioni specificate dal chiamante.

       • Negoziare la firma: se ssl/TLS (Secure Sockets Layer/Transport Layer Security) non è stato avviato, la richiesta BINDING LDAP viene avviata con l'opzione di firma dati LDAP impostata in aggiunta alle opzioni specificate dal chiamante. Se è stato avviato SSL/TLS, la richiesta BINDING LDAP viene avviata con le opzioni specificate dal chiamante.

       • Richiedi firma: equivale a Negoziare la firma. Tuttavia, se la risposta saslBindIn Progress intermedia del server LDAP non indica che è necessaria la firma del traffico LDAP, al chiamante viene indicato che la richiesta di comando BINDING LDAP non è riuscita.

    2. Configurazione
       
       rischiosa L'abilitazione dell'impostazione Sicurezza di rete: requisiti di firma client LDAP è un'impostazione di configurazione dannosa. Se si imposta il server in modo che richieda firme LDAP, è necessario configurare anche la firma LDAP nel client. La mancata configurazione del client per l'utilizzo delle firme LDAP impedirà la comunicazione con il server. In questo modo l'autenticazione dell'utente, le impostazioni di Criteri di gruppo, gli script di accesso e altre caratteristiche non riescono.

    3. Motivi per modificare questa impostazione
       
       Il traffico di rete non firmato è suscettibile agli attacchi man-in-the-middle in cui un intruso acquisisce pacchetti tra il client e i server, li modifica e quindi li inoltra al server. Quando ciò si verifica su un server LDAP, un utente malintenzionato potrebbe causare la risposta di un server in base a false query dal client LDAP. È possibile ridurre questo rischio in una rete aziendale implementando misure di sicurezza fisiche complesse per proteggere l'infrastruttura di rete. Inoltre, è possibile prevenire tutti i tipi di attacchi man-in-the-middle richiedendo firme digitali su tutti i pacchetti di rete tramite intestazioni di autenticazione IPSec.

    4. Nome simbolico:
       
       LDAPClientIntegrity

    5. Percorso del Registro di sistema:

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity

12. Registro eventi: dimensione massima del log di sicurezza

    1. Priorità bassa
       
       L'impostazione Relativa alle dimensioni massime del registro eventi del registro eventi di sicurezza specifica le dimensioni massime del registro eventi di sicurezza. Questo log ha una dimensione massima di 4 GB. Per individuare questa impostazione, espandere
       Impostazioni di Windows e quindi Impostazioni di sicurezza.

    2. Configurazioni rischiose
       
       Di seguito sono riportate le impostazioni di configurazione dannose:

       • Limitazione delle dimensioni del log di sicurezza e del metodo di conservazione del log di sicurezza quando l'impostazione Controlla: arresta immediatamente il sistema se non è possibile registrare i controlli di sicurezza è abilitata. Per altre informazioni, vedere la sezione "Controllare: arrestare immediatamente il sistema se non è possibile registrare i controlli di sicurezza".

       • Limitazione delle dimensioni del log di sicurezza in modo che gli eventi di sicurezza di interesse vengano sovrascritti.

    3. Motivi per aumentare questa impostazione
       
       I requisiti aziendali e di sicurezza possono determinare l'aumento delle dimensioni del log di sicurezza per gestire ulteriori dettagli del log di sicurezza o per conservare i log di sicurezza per un periodo di tempo più lungo.

    4. Motivi per ridurre questa impostazione
       
       Visualizzatore eventi log sono file di memoria mappati. La dimensione massima di un registro eventi è vincolata dalla quantità di memoria fisica nel computer locale e dalla memoria virtuale disponibile per il processo del registro eventi. L'aumento delle dimensioni del log oltre la quantità di memoria virtuale disponibile per Visualizzatore eventi non aumenta il numero di voci del log che vengono mantenute.

    5. Esempi di problemi
       
       di compatibilità Windows 2000: i computer che eseguono versioni di Windows 2000 precedenti al Service Pack 4 (SP4) potrebbero interrompere la registrazione di eventi nel registro eventi prima di raggiungere le dimensioni specificate nell'impostazione Dimensioni massime log in Visualizzatore eventi se è attivata l'opzione Non sovrascrivere eventi (cancella manualmente il log).
       
       
        

13. Registro eventi: Mantieni registro di sicurezza

    1. Priorità bassa
       
       Il registro eventi: l'impostazione di sicurezza Mantieni log di sicurezza determina il metodo di "wrapping" per il log di sicurezza. Per individuare questa impostazione, espandere Impostazioni di Windows e quindi Impostazioni di sicurezza.

    2. Configurazioni rischiose
       
       Di seguito sono riportate le impostazioni di configurazione dannose:

       • Mancato mantenimento di tutti gli eventi di sicurezza registrati prima che vengano sovrascritti

       • Configurazione dell'impostazione Dimensioni massime del log di sicurezza troppo piccole in modo che gli eventi di sicurezza vengano sovrascritti

       • Limitazione delle dimensioni e del metodo di conservazione del log di sicurezza durante il controllo: arrestare immediatamente il sistema se l'impostazione di sicurezza Non è possibile registrare i controlli di sicurezza è abilitata

    3. Motivi per abilitare questa impostazione
       
       Abilitare questa impostazione solo se si seleziona il metodo di conservazione Sovrascrivi eventi per giorni . Se si usa un sistema di correlazione di eventi che esegue sondaggi per gli eventi, verificare che il numero di giorni sia almeno tre volte la frequenza del sondaggio. Eseguire questa operazione per consentire cicli di sondaggio non riusciti.

14. Accesso alla rete: consentire a Tutti di applicare le autorizzazioni agli utenti anonimi

    1. Priorità bassa
       
       Per impostazione predefinita, l'impostazione Accesso alla rete: Consenti a tutti di applicare le autorizzazioni agli utenti anonimi è impostata su Non definito in Windows Server 2003. Per impostazione predefinita, Windows Server 2003 non include il token di accesso anonimo nel gruppo Everyone.

    2. Esempio di problemi
       
       di compatibilità Il valore seguente di

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous [REG_DWORD]=0x0 interrompe la creazione di trust tra Windows Server 2003 e Windows NT 4.0, quando il dominio windows server 2003 è il dominio dell'account e il dominio Windows NT 4.0 è il dominio delle risorse. Questo significa che il dominio dell'account è attendibile in Windows NT 4.0 e che il dominio delle risorse è attendibile sul lato Windows Server 2003. Questo comportamento si verifica perché il processo per avviare l'attendibilità dopo che la connessione anonima iniziale è ACL con il token Everyone che include il SID anonimo in Windows NT 4.0.

    3. Motivi per modificare questa impostazione
       
       Il valore deve essere impostato su 0x1 o impostato usando un oggetto Criteri di gruppo nell'unità organizzativa del controller di dominio: accesso alla rete: consenti a Tutti di applicare le autorizzazioni agli utenti anonimi - Abilitato per rendere possibili le creazioni di trust.
       
       Nota: la maggior parte delle altre impostazioni di sicurezza viene visualizzata per aumentare il valore invece che per 0x0 nello stato più protetto. Una procedura più sicura consiste nel modificare il Registro di sistema nell'emulatore del controller di dominio primario anziché in tutti i controller di dominio. Se il ruolo di emulatore del controller di dominio primario viene spostato per qualsiasi motivo, il Registro di sistema deve essere aggiornato nel nuovo server.
       
       Dopo aver impostato questo valore, è necessario riavviare il sistema.

    4. Percorso del Registro di sistema

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous

15. Autenticazione NTLMv2

    1. Sicurezza della sessione
       
       La sicurezza della sessione determina gli standard minimi di sicurezza per le sessioni client e server. È consigliabile verificare le seguenti impostazioni dei criteri di sicurezza nello snap-in Microsoft Management Console Criteri di gruppo Editor:

       • Impostazioni computer\Impostazioni di Windows\Impostazioni di sicurezza\Criteri locali\Opzioni di sicurezza

       • Sicurezza di rete: sicurezza minima della sessione per i server basati su SSP NTLM (inclusi i server RPC sicuri)

       • Sicurezza di rete: sicurezza minima della sessione per i client basati su SSP NTLM (inclusi i client RPC sicuri)

       Le opzioni per queste impostazioni sono le seguenti:

       • Richiedere l'integrità dei messaggi

       • Richiedere la riservatezza dei messaggi

       • Richiedere la sicurezza della sessione NTLM versione 2

       • Richiedere la crittografia a 128 bit

       L'impostazione predefinita precedente a Windows 7 è Nessun requisiti. A partire da Windows 7, per impostazione predefinita è stata impostata su Richiedi crittografia a 128 bit per una maggiore sicurezza. Con questa impostazione predefinita, i dispositivi legacy che non supportano la crittografia a 128 bit non saranno in grado di connettersi.
       
       Questi criteri determinano gli standard minimi di sicurezza per una sessione di comunicazione applicazione-applicazione su un server per un client.
       
       Si noti che, sebbene descritti come impostazioni valide, i contrassegni per richiedere l'integrità e la riservatezza dei messaggi non vengono utilizzati quando viene determinata la sicurezza della sessione NTLM.
       
       In passato, Windows NT ha supportato le due varianti seguenti di autenticazione challenge/response per gli accessi di rete:

       • Sfida/risposta LM

       • Test/risposta NTLM versione 1

       LM consente l'interoperabilità con la base installata di client e server. NTLM offre una maggiore sicurezza per le connessioni tra client e server.
       
       Le chiavi del Registro di sistema corrispondenti sono le seguenti:

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinServerSec"
       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinClientSec"

    2. Configurazioni rischiose
       
       Questa impostazione controlla come verranno gestite le sessioni di rete protette con NTLM. Ciò influisce, ad esempio, sulle sessioni basate su RPC autenticate con NTLM. I rischi sono i seguenti:

       • L'uso di metodi di autenticazione meno recenti rispetto a NTLMv2 rende la comunicazione più facile da attaccare a causa dei metodi di hash più semplici usati.

       • L'uso di chiavi di crittografia inferiori a 128 bit consente agli aggressori di interrompere la comunicazione usando attacchi di forza bruta.

Sincronizzazione dell'ora

Sincronizzazione dell'ora non riuscita. Il tempo è disattivato di più di 30 minuti in un computer interessato. Verificare che l'orologio del computer client sia sincronizzato con l'orologio del controller di dominio.

Soluzione alternativa per la firma SMB

È consigliabile installare Service Pack 6a (SP6a) nei client Windows NT 4.0 che interagiscono in un dominio basato su Windows Server 2003. I client basati su Windows 98 Second Edition, i client basati su Windows 98 e i client basati su Windows 95 devono eseguire il client dei servizi directory per eseguire NTLMv2. Se nei client basati su Windows NT 4.0 non è installato Windows NT 4.0 SP6 o se i client basati su Windows 95, i client basati su Windows 98 e i client basati su Windows 98SE non hanno installato il client Servizi directory, disabilitare l'accesso SMB nell'impostazione dei criteri del controller di dominio predefinito nell'unità organizzativa del controller di dominio e quindi collegare questo criterio a tutti gli utenti che ospitano controller di dominio.

Il client servizi directory per Windows 98 Second Edition, Windows 98 e Windows 95 eseguirà la firma SMB con i server Windows 2003 in base all'autenticazione NTLM, ma non in base all'autenticazione NTLMv2. Inoltre, i server Windows 2000 non risponderanno alle richieste di firma SMB da questi client.

Anche se non è consigliabile, è possibile impedire che venga richiesta la firma SMB in tutti i controller di dominio che eseguono Windows Server 2003 in un dominio. Per configurare questa impostazione di sicurezza, procedere come segue:

1. Aprire il criterio del controller di dominio predefinito.

2. Aprire la cartella Configurazione computer\Impostazioni di Windows\Impostazioni di sicurezza\Criteri locali\Opzioni di sicurezza.

3. Individuare e quindi fare clic sull'impostazione del criterio Server di rete Microsoft: Firmare digitalmente le comunicazioni (sempre) e quindi fare clic su Disabilitato.

Importante Questa sezione, metodo o attività contiene i passaggi che indicano come modificare il Registro di sistema. Tuttavia, se si modifica il Registro di sistema in modo non corretto, potrebbero verificarsi problemi gravi. Pertanto, assicurarsi di seguire attentamente questi passaggi. Per una maggiore protezione, eseguire il backup del Registro di sistema prima di modificarlo. In questo caso, è possibile ripristinare il Registro di sistema in caso di problemi. Per altre informazioni su come eseguire il backup e il ripristino del Registro di sistema, fare clic sul numero dell'articolo seguente per visualizzare l'articolo della Microsoft Knowledge Base:

322756 Come eseguire il backup e il ripristino del Registro di sistema in Windows In alternativa, disattivare la firma SMB sul server modificando il Registro di sistema. A tale scopo, esegui la procedura seguente:

1. Fare clic sul pulsante Start, scegliere Esegui, digitare regedit e quindi fare clic su OK.

2. Individuare e quindi fare clic sulla sottochiave seguente:
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters

3. Fare clic sulla voce enablesecuritysignature .

4. Scegliere Modifica dal menu Modifica.

5. Nella casella Dati valore digitare 0 e quindi fare clic su OK.

6. Uscire dall'editor del Registro di sistema.

7. Riavviare il computer o arrestare e quindi riavviare il servizio Server. A tale scopo, digitare i comandi seguenti al prompt dei comandi e quindi premere INVIO dopo aver digitato ogni comando:
   net stop server
   net start server

Nota: La chiave corrispondente nel computer client si trova nella seguente sottochiave del Registro di sistema:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters Di seguito sono elencati i numeri dei codici errore tradotti nei codici di stato e nei messaggi di errore testuali citati in precedenza:

Per altre informazioni, fare clic sui numeri dell'articolo seguente per visualizzare gli articoli della Microsoft Knowledge Base:

324802 Come configurare Criteri di gruppo per impostare la sicurezza per i servizi di sistema in Windows Server 2003

816585 Come applicare modelli di sicurezza predefiniti in Windows Server 2003