Bloccare l'uso remoto di account locali in Windows

Questo articolo descrive come bloccare l'uso remoto di account locali in Windows.

Versione originale del prodotto: SQL Server 2016 Developer, SQL Server 2016 Enterprise, SQL Server 2016 Enterprise Core
Numero KB originale: 4488256

Riepilogo

Quando si usano account locali per l'accesso remoto in ambienti Active Directory, è possibile che si verifichino diversi problemi. Il problema più significativo si verifica se un account locale amministrativo ha lo stesso nome utente e la stessa password in più dispositivi. Un utente malintenzionato che dispone di diritti amministrativi su un dispositivo in tale gruppo può usare l'hash delle password degli account dal database SAM (Security Accounts Manager) locale per ottenere diritti amministrativi su altri dispositivi nel gruppo che usano tecniche di "pass the hash".

Ulteriori informazioni

Le linee guida sulla sicurezza più recenti rispondono a questi problemi sfruttando le nuove funzionalità di Windows per bloccare gli accessi remoti da parte degli account locali. Windows 8.1 e Windows Server 2012 R2 hanno introdotto gli identificatori di sicurezza seguenti (SID):

• S-1-5-113: NT AUTHORITY\Account locale

• S-1-5-114: NT AUTHORITY\Local account and member of Administrators group

Questi SID sono definiti anche in Windows 7, Windows 8, Windows Server 2008 R2 e Windows Server 2012 dopo aver installato l'aggiornamento avviso di sicurezza Microsoft: Aggiornamento per migliorare la protezione e la gestione delle credenziali: 13 maggio 2014.

Il primo SID viene aggiunto al token di accesso degli utenti al momento dell'accesso se l'account utente che viene autenticato è un account locale. Il secondo SID viene aggiunto anche al token se l'account locale è membro del gruppo Administrators predefinito.

Questi SID possono concedere l'accesso o negare l'accesso a tutti gli account locali o a tutti gli account locali amministrativi. Ad esempio, è possibile usare questi SID in Assegnazioni diritti utente in Criteri di gruppo per "Negare l'accesso a questo computer dalla rete" e "Nega accesso tramite Servizi Desktop remoto". Questa è la procedura consigliata nelle linee guida sulla sicurezza più recenti. Per ottenere lo stesso effetto prima che questi nuovi SID siano stati definiti, è necessario denominare in modo esplicito ogni account locale che si desidera limitare.

Nella versione iniziale delle linee guida per Windows 8.1 e Windows Server 2012 R2 è stato negato l'accesso alla rete e al desktop remoto all'account locale (S-1-5-113) per tutte le configurazioni di client e server Windows. In questo modo viene bloccato tutto l'accesso remoto per tutti gli account locali.

È stato rilevato di nuovo che il clustering di failover si basa su un account locale non amministrativo (CLIUSR) per la gestione dei nodi del cluster e che bloccando l'accesso all'accesso alla rete, i servizi cluster hanno esito negativo. Poiché l'account CLIUSR non è membro del gruppo Administrators, sostituendo S-1-5-113 con S-1-5-114 nell'impostazione "Nega l'accesso a questo computer dalla rete" consente il corretto funzionamento dei servizi cluster. In questo modo viene comunque offerta una protezione contro i tipi di attacchi "pass the hash" negando l'accesso di rete agli account locali amministrativi.

Anche se è possibile mantenere invariate le linee guida e aggiungere una nota a piè di pagina "caso speciale" per gli scenari del cluster di failover, è stato scelto di semplificare le distribuzioni e modificare la baseline del server membro di Windows Server 2012 R2, come indicato nella tabella seguente.

Percorso criteri	Computer Configuration\Windows Settings\Local Policies\User Rights Assignment
Nome criteri	Negare l'accesso al computer dalla rete
Valore originale	Guest, account locale*
Nuovo valore	Guest, account locale e membri del gruppo Administrators*

• Queste indicazioni consigliano anche di aggiungere amministratori di dominio (DA) ed Enterprise Administrators (EA) a queste restrizioni. L'eccezione riguarda i controller di dominio e le workstation di amministrazione dedicate. DA e EA sono specifici del dominio e non possono essere specificati nelle baseline generiche dell'oggetto Criteri di gruppo.

Note

• Questa modifica si applica solo alla linea di base del server membro. La restrizione sull'accesso desktop remoto non viene modificata. Le organizzazioni possono comunque decidere di negare l'accesso alla rete all'account locale per i server non cluster.

• Le restrizioni relative agli account locali sono destinate ai sistemi aggiunti a un dominio di Active Directory. I dispositivi Windows del gruppo di lavoro non aggiunti non possono autenticare gli account di dominio. Pertanto, se si applicano restrizioni all'uso remoto di account locali in questi dispositivi, sarà possibile accedere solo nella console.

Altre informazioni sull'account CLIUSR

L'account CLIUSR è un account utente locale creato dalla funzionalità Clustering di failover se la funzionalità è installata in Windows Server 2012 o versioni successive.

In Windows Server 2003 e versioni precedenti del servizio cluster è stato usato un account utente di dominio per avviare il servizio. Questo account del servizio cluster è stato usato per formare il cluster, aggiungere un nodo, eseguire la replica del Registro di sistema e così via. Fondamentalmente, qualsiasi tipo di autenticazione eseguita tra i nodi usa questo account utente come identità comune.

Sono stati rilevati diversi problemi di supporto perché gli amministratori di dominio impostavano criteri di gruppo che rimuovevano le autorizzazioni dagli account utente di dominio. Gli amministratori non consideravano che alcuni di questi account utente venivano usati per eseguire i servizi.

Ad esempio, questo problema è stato rilevato nell'uso del diritto di accesso come servizio. Se l'account del servizio cluster non dispone di questa autorizzazione, non sarà possibile avviare il servizio cluster. Se si usava lo stesso account per più cluster, è possibile riscontrare tempi di inattività di produzione in diversi sistemi importanti. È stato anche necessario gestire le modifiche delle password in Active Directory. Se è stata modificata la password degli account utente in Active Directory, è anche necessario modificare le password in tutti i cluster e i nodi che usano l'account.

In Windows Server 2008 è stato riprogettato tutto il modo in cui si avvia il servizio per rendere il servizio più resiliente, meno soggetto a errori e più facile da gestire. È stato avviato l'uso del servizio di rete predefinito per avviare il servizio cluster. Tenere presente che questo non è l'account completo, ma solo un set con privilegi ridotto. Riducendo l'ambito di questo account, è stata trovata una soluzione per i problemi di Criteri di gruppo.

Per l'autenticazione, l'account è stato passato per usare l'oggetto computer associato al nome del cluster noto come oggetto nome cluster (CNO) per un'identità comune. Poiché questo CNO è un account computer nel dominio, ruota automaticamente la password, come definito dai criteri di dominio. Per impostazione predefinita, questo è ogni 30 giorni.

A partire da Windows Server 2008 R2, gli amministratori hanno iniziato a virtualizzare tutto nel data center. Sono inclusi i controller di dominio. È stata introdotta anche la funzionalità Volumi condivisi cluster (CSV) ed è diventata lo standard per l'archiviazione cloud privato. Alcuni amministratori hanno adottato la virtualizzazione e virtualizzato ogni server nel data center. Sono inclusi l'aggiunta di controller di dominio come macchina virtuale a un cluster e l'uso dell'unità CSV per contenere il VHD/VHDX della macchina virtuale.

Questo ha creato uno scenario "Catch 22" per molte aziende. Per montare l'unità CSV per accedere alle macchine virtuali, è necessario contattare un controller di dominio per recuperare l'oggetto CNO. Tuttavia, non è stato possibile avviare il controller di dominio perché era in esecuzione nel file CSV.

La presenza di una connessione lenta o inaffidabile ai controller di dominio influisce anche sull'I/O sulle unità CSV. CSV esegue la comunicazione all'interno del cluster tramite SMB, in modo analogo alla connessione alle condivisioni file. Per connettersi a SMB, la connessione deve eseguire l'autenticazione. In Windows Server 2008 R2, che ha comportato l'autenticazione dell'oggetto CNO tramite un controller di dominio remoto.

Per Windows Server 2012, abbiamo dovuto pensare a come potevamo prendere il meglio di entrambi i mondi ed evitare alcuni problemi che stavamo vedendo. Si sta ancora usando il diritto dell'utente del servizio di rete ridotto per avviare il servizio cluster. Tuttavia, per rimuovere tutte le dipendenze esterne, viene ora usato un account utente locale (non di dominio) per l'autenticazione tra i nodi.

Questo account "utente" locale non è un account amministrativo o un account di dominio. Questo account viene creato automaticamente in ogni nodo quando si crea un cluster o in un nuovo nodo che viene aggiunto al cluster esistente. Questo account è autogestito dal servizio cluster. Ruota automaticamente la password per l'account e sincronizza automaticamente tutti i nodi. La password CLIUSR viene ruotata alla stessa frequenza dell'oggetto CNO, come definito dai criteri di dominio. Per impostazione predefinita, questo è ogni 30 giorni. Poiché l'account è locale, può eseguire l'autenticazione e montare csv in modo che i controller di dominio virtualizzati possano essere avviati correttamente. È ora possibile virtualizzare tutti i controller di dominio senza paura. Di conseguenza, stiamo aumentando la resilienza e la disponibilità del cluster riducendo le dipendenze esterne.

Questo account è l'account CLIUSR. È identificato dalla relativa descrizione nello snap-in Gestione computer.

Una domanda frequente è se l'account CLIUSR può essere eliminato. Dal punto di vista della sicurezza, gli account locali aggiuntivi (non predefiniti) possono essere contrassegnati durante i controlli. Se l'amministratore di rete non è sicuro di cosa si tratti, ovvero non legge la descrizione di "Identità locale del cluster di failover", può eliminarlo senza comprendere le ramificazioni. Affinché il clustering di failover funzioni correttamente, questo account è necessario per l'autenticazione.

1. Il nodo di join avvia il servizio cluster e passa le credenziali CLIUSR.

2. Per ottenere lo stesso effetto, tutte le credenziali vengono passate in modo che il nodo possa essere aggiunto.

Abbiamo fornito una maggiore tutela per garantire un successo continuo. Se si elimina accidentalmente l'account CLIUSR, verrà ricreato automaticamente quando un nodo tenta di aggiungere il cluster.

Per riepilogare: l'account CLIUSR è un componente interno del servizio cluster. Si tratta di una gestione automatica in modo che non sia necessario configurarla o gestirla.

In Windows Server 2016 è stato eseguito un ulteriore passo avanti sfruttando i certificati per consentire il funzionamento dei cluster senza alcun tipo di dipendenza esterna. In questo modo è possibile creare cluster usando server che si trovano in domini diversi o all'esterno di tutti i domini.