Account Active Directory
Si applica a: Windows Server 2022, Windows Server 2019, Windows Server 2016
I sistemi operativi Windows Server vengono installati con account locali predefiniti. È anche possibile creare account utente per soddisfare gli specifici requisiti dell'organizzazione.
Questo articolo di riferimento descrive gli account locali predefiniti di Windows Server che vengono archiviati localmente nel controller di dominio e usati in Active Directory. Non descrive gli account utente locali predefiniti per un membro, un server autonomo o un client Windows. Per altre informazioni, vedere Account locali.
Account locali predefiniti in Active Directory
Gli account locali predefiniti sono account incorporati che vengono creati automaticamente quando viene installato un controller di dominio di Windows Server e viene creato il dominio. Questi account locali predefiniti hanno controparti in Active Directory. Hanno anche accesso a livello di dominio e sono completamente separati dagli account utente locali predefiniti di un membro o un server autonomo.
È possibile assegnare diritti e autorizzazioni agli account locali predefiniti in un determinato controller di dominio ed esclusivamente in tale controller di dominio. Questi account sono locali del dominio. Dopo l'installazione, gli account locali predefiniti vengono archiviati nel contenitore Utenti in Utenti e computer di Active Directory. È consigliabile mantenere gli account locali predefiniti nel contenitore Utente e non provare a spostarli, ad esempio in un'unità organizzativa diversa.
Gli account locali predefiniti nel contenitore Utenti includono: Administrator, Guest e KRBTGT. L'account HelpAssistant viene installato quando viene stabilita una sessione di Assistenza remota. Le sezioni seguenti descrivono gli account locali predefiniti e il relativo utilizzo in Active Directory.
Gli account locali predefiniti consento di eseguire le azioni seguenti:
Permettere al dominio di rappresentare, identificare e autenticare l'identità dell'utente assegnato all'account usando credenziali univoche (nome utente e password). È consigliabile assegnare ogni utente a un singolo account per garantire la massima sicurezza. Non è possibile condividere un account tra più utenti. Un account utente permette a un utente di accedere a computer, reti e domini con un identificatore univoco che può essere autenticato dal computer, dalla rete o dal dominio.
Autorizzare (concedere o negare) l'accesso alle risorse. Dopo l'autenticazione delle credenziali, all'utente viene autorizzato ad accedere alle risorse della rete e del dominio in base ai diritti espliciti assegnati a tale utente per la risorsa.
Controlla le azioni eseguite sugli account utente.
In Active Directory gli amministratori usano gli account locali predefiniti per gestire i server di dominio e membri direttamente e tramite workstation amministrative dedicate. Gli account Active Directory forniscono l'accesso alle risorse di rete. Gli account utente e gli account computer di Active Directory possono rappresentare un'entità fisica, ad esempio un PC o una persona, o fungere da account del servizio dedicati per alcune applicazioni.
Ogni account locale predefinito viene assegnato automaticamente a un gruppo di sicurezza preconfigurato con i diritti e le autorizzazioni appropriati per eseguire attività specifiche. I gruppi di sicurezza di Active Directory raccolgono account utente, account computer e altri gruppi in unità gestibili. Per altre informazioni, vedere Gruppi di sicurezza di Active Directory.
In un controller di dominio di Active Directory, ogni account locale predefinito viene definito entità di sicurezza. Un'entità di sicurezza è un oggetto directory utilizzato per proteggere e gestire i servizi di Active Directory che forniscono accesso alle risorse del controller di dominio. Un'entità di sicurezza include oggetti quali account utente, account computer, gruppi di sicurezza oppure i thread o i processi eseguiti nel contesto di sicurezza di un account utente o computer. Per altre informazioni, vedere Entità di sicurezza.
Un'entità di sicurezza è rappresentata da un ID di sicurezza univoco (SID). I SID correlati a ognuno degli account locali predefiniti in Active Directory sono descritti nelle sezioni successive.
Alcuni degli account locali predefiniti sono protetti da un processo in background che controlla periodicamente e applica uno specifico descrittore di sicurezza. Un descrittore di sicurezza è una struttura di dati che contiene le informazioni sulla sicurezza associate a un oggetto protetto. Questo processo assicura che qualunque tentativo non autorizzato di modificare il descrittore di sicurezza in uno degli account o gruppi locali predefiniti venga sovrascritto con le impostazioni protette.
Questo descrittore di sicurezza si trova nell'oggetto AdminSDHolder. Se si vogliono modificare le autorizzazioni per uno dei gruppi di amministratori dei servizi o per uno degli account membri, è necessario modificare il descrittore di sicurezza nell'oggetto AdminSDHolder per assicurarsi che le autorizzazioni vengano applicate in modo coerente. Prestare attenzione quando si apportano queste modifiche, perché vengono modificate di conseguenza anche le impostazioni predefinite applicate a tutti gli account protetti.
Account amministratore
Un account Administrator è un account predefinito usato in tutte le versioni del sistema operativo Windows in ogni computer e dispositivo. L'account Administrator viene usato dall'amministratore di sistema per le attività che richiedono credenziali amministrative. Questo account non può essere eliminato o bloccato, ma può essere rinominato o disabilitato.
L'account Administrator concede all'utente l'accesso completo (autorizzazioni Controllo completo) ai file, alle directory, ai servizi e alle altre risorse presenti nel server locale. Può essere usato per creare utenti locali e per assegnare diritti utente e autorizzazioni di controllo dell'accesso. L'account può anche essere usato per assumere il controllo delle risorse locali in qualsiasi momento, semplicemente modificando i diritti utente e le autorizzazioni. Anche se i file e le directory possono essere protetti temporaneamente dall'account Administrator, l'account può assumere il controllo di queste risorse in qualsiasi momento modificando le autorizzazioni di accesso.
Appartenenza a gruppi di account
L'account Administrator appartiene ai gruppi di sicurezza predefiniti, come descritto nella tabella Attributi dell'account Administrator più avanti in questo articolo.
I gruppi di sicurezza assicurano che sia possibile controllare i diritti di amministratore senza dover modificare ogni account Administrator. Nella maggior parte dei casi non è necessario modificare le impostazioni di base per questo account. Tuttavia, può essere necessario modificare le impostazioni avanzate, ad esempio l'appartenenza a particolari gruppi.
Considerazioni sulla sicurezza
Dopo l'installazione del sistema operativo server, la prima attività da eseguire è configurare le proprietà dell'account Administrator in modo sicuro. Questo include la configurazione di una password particolarmente lunga e complessa e la protezione delle impostazioni del profilo di Servizi Desktop remoto e controllo remoto.
L'account Administrator può anche essere disabilitato se non è necessario. Rinominare o disabilitare questo account rende più difficili i tentativi di accesso degli utenti non autorizzati. Anche quando è disabilitato, tuttavia, è comunque possibile utilizzare l'account Administrator per accedere a un controller di dominio in modalità provvisoria.
In un controller di dominio, l'account Administrator diventa l'account amministratore di dominio. L'account amministratore di dominio viene usato per accedere al controller di dominio e richiede una password complessa. L'account amministratore di dominio consente di accedere alle risorse di dominio.
Nota
Al momento dell'installazione iniziale del controller di dominio, è possibile accedere e usare Server Manager per configurare un account Administrator locale, con i diritti e le autorizzazioni che si vogliono assegnare. Ad esempio, è possibile usare un account Administrator locale per gestire il sistema operativo alla prima installazione. Usando questo approccio è possibile configurare il sistema operativo senza restare bloccati. In genere non è necessario usare l'account dopo l'installazione. È possibile creare account utente locali nel controller di dominio solo prima dell'installazione di Active Directory Domain Services e non successivamente.
Quando Active Directory viene installato nel primo controller di dominio nel dominio, viene creato l'account Administrator per Active Directory. L'account Administrator è l'account più potente nel dominio. Dispone di accesso a livello di dominio e di diritti amministrativi sul computer e sul dominio e ha i diritti e le autorizzazioni più estesi sul dominio. La persona che installa Active Directory Domain Services nel computer crea la password per questo account durante l'installazione.
Attributi dell'account Administrator
| Attributo | Valore |
|---|---|
| SID/RID noto | S-1-5-<domain>-500 |
| Digita | User |
| Contenitore predefinito | CN=Utenti, DC=<domain>, DC= |
| Membri predefiniti | N/D |
| Membro predefinito di | Administrators, Domain Admins, Enterprise Admins, Domain Users (l'ID gruppo primario di tutti gli account utente è Domain Users) Proprietari autori criteri di gruppo e Schema Admins nel gruppo Domain Users di Active Directory |
| Protetto da ADMINSDHOLDER? | Sì |
| È sicuro spostarlo fuori dal contenitore predefinito? | Sì |
| È sicuro delegare la gestione di questo gruppo ad amministratori non di servizio? | No |
Account Guest
L'account Guest è un account locale predefinito con accesso limitato al computer ed è disabilitato per impostazione predefinita. Per impostazione predefinita, la password dell'account Guest viene lasciata vuota. La password vuota consente di accedere all'account Guest senza che l'utente debba immettere una password.
L'account Guest consente a utenti occasionali che non hanno un account personale nel computer di accedere al server locale o al dominio con diritti e autorizzazioni limitati. L'account Guest può essere abilitato e la password può essere configurata se necessario, ma solo da un membro del gruppo Administrators del dominio.
Appartenenza a gruppi dell'account Guest
L'account Guest appartiene ai gruppi di sicurezza predefiniti descritti nella tabella Attributi dell'account Guest che segue. Per impostazione predefinita l'account Guest è l'unico membro del gruppo predefinito Guests, che consente a un utente di accedere a un server, e del gruppo globale Domain Guests, che consente a un utente di accedere a un dominio.
Un membro del gruppo Administrators o Domain Admins può configurare un utente con un account Guest in uno o più computer.
Considerazioni sulla sicurezza dell'account Guest
Poiché l'account Guest può fornire l'accesso anonimo, pone un rischio per la sicurezza. Ha anche un SID noto. Per questo motivo, è consigliabile lasciare disabilitato l'account Guest a meno che non sia necessario usarlo, e in tal caso concedere solo diritti e autorizzazioni limitati per un periodo di tempo molto limitato.
Quando è necessario l'account Guest, per abilitarlo occorre l'intervento di un amministratore nel controller di dominio. L'account Guest può essere abilitato senza richiedere una password oppure può essere abilitato con una password complessa. L'amministratore concede inoltre diritti e autorizzazioni limitati per l'account. Per impedire l'accesso non autorizzato:
Non concedere all'account Guest il diritto utente Arresto del sistema. Quando un computer si arresta o si avvia, è possibile che un utente Guest o chiunque disponga di accesso locale, ad esempio un utente malintenzionato, ottenga l'accesso non autorizzato al computer.
Non concedere all'account Guest la possibilità di visualizzare i registri eventi. Dopo aver abilitato l'account Guest, è consigliabile monitorarlo spesso per assicurarsi che altri utenti non possano usare servizi e altre risorse, ad esempio risorse che non sono state involontariamente lasciate disponibili da un utente precedente.
Non usare l'account Guest quando il server ha accesso alla rete esterna o ad altri computer.
Se si decide di abilitare l'account Guest, assicurarsi di limitarne l'uso e di modificare regolarmente la password. Come per l'account Administrator, è possibile rinominare l'account come precauzione di sicurezza aggiuntiva.
Inoltre, un amministratore è responsabile della gestione dell'account Guest. L'amministratore monitora l'account, lo disabilita quando non è più in uso e modifica o rimuove la password in base alle esigenze.
Per informazioni dettagliate sugli attributi dell'account Guest, vedere la tabella seguente:
Attributi dell'account guest
| Attributo | Valore |
|---|---|
| SID/RID noto | S-1-5-<domain>-501 |
| Digita | User |
| Contenitore predefinito | CN=Utenti, DC=<domain>, DC= |
| Membri predefiniti | Nessuno |
| Membro predefinito di | Guests, Domain Guests |
| Protetto da ADMINSDHOLDER? | No |
| È sicuro spostarlo fuori dal contenitore predefinito? | Può essere spostato, ma non è consigliabile. |
| È sicuro delegare la gestione di questo gruppo ad amministratori non di servizio? | No |
Account HelpAssistant (installato con una sessione di Assistenza remota)
L'account HelpAssistant è un account locale predefinito che viene abilitato quando viene eseguita una sessione di Assistenza remota. Viene disabilitato automaticamente se non sono presenti richieste di Assistenza remota in sospeso.
HelpAssistant è l'account principale usato per stabilire una sessione di Assistenza remota. La sessione di Assistenza remota viene usata per connettersi a un altro computer che esegue il sistema operativo Windows e viene avviata tramite invito. Per richiedere assistenza remota, un utente invia un invito dal computer, tramite posta elettronica o come file, a una persona che può fornire assistenza. Dopo l'accettazione dell'invito a una sessione di assistenza remota, l'account HelpAssistant predefinito viene creato automaticamente per concedere all'utente che fornisce assistenza un accesso limitato al computer. L'account HelpAssistant viene gestito dal servizio Gestione sessione di assistenza mediante desktop remoto
Considerazioni sulla sicurezza dell'account HelpAssistant
I SID relativi all'account HelpAssistant predefinito includono:
SID: S-1-5-
<domain>-13, nome visualizzato Utente di Terminal Server. Questo gruppo include tutti gli utenti che accedono a un server in cui è abilitato Servizi Desktop remoto. In Windows Server 2008, Servizi Desktop remoto si chiama Servizi terminal.SID: S-1-5-
<domain>-14, nome visualizzato Remote Interactive Logon. Questo gruppo include tutti gli utenti che si connettono al computer tramite una connessione Desktop remoto. È un subset del gruppo Interactive. I token di accesso che contengono il SID Remote Interactive Logon contengono anche il SID Interactive.
Per il sistema operativo Windows Server, Assistenza remota è un componente facoltativo non configurato per impostazione predefinita. È necessario installare Assistenza remota prima di poterlo usare.
Per informazioni dettagliate sugli attributi dell'account HelpAssistant, vedere la tabella seguente:
Attributi dell'account HelpAssistant
| Attributo | Valore |
|---|---|
| SID/RID noto | S-1-5-<domain>-13 (Utente di Terminal Server), S-1-5-<domain>-14 (Remote Interactive Logon) |
| Digita | User |
| Contenitore predefinito | CN=Utenti, DC=<domain>, DC= |
| Membri predefiniti | Nessuno |
| Membro predefinito di | Domain Guests Utenti guest |
| Protetto da ADMINSDHOLDER? | No |
| È sicuro spostarlo fuori dal contenitore predefinito? | Può essere spostato, ma non è consigliabile. |
| È sicuro delegare la gestione di questo gruppo ad amministratori non di servizio? | No |
Account KRBTGT
L'account KRBTGT è un account predefinito locale che funge da account del servizio Centro distribuzione chiavi (KDC). Non può essere eliminato e il nome dell'account non può essere modificato. L'account KRBTGT non può essere abilitato in Active Directory.
KRBTGT è anche il nome dell'entità di sicurezza usato dal servizio KDC per un dominio di Windows Server, come definito da RFC 4120. L'account KRBTGT è l'entità per l'entità di sicurezza KRBTGT e viene creato automaticamente quando si crea un nuovo dominio.
L'autenticazione Kerberos di Windows Server viene eseguita mediante l'utilizzo di uno speciale ticket di concessione ticket (Ticket Granting Ticket, TGT) di Kerberos, crittografato con una chiave simmetrica. Questa chiave deriva dalla password del server o del servizio a cui viene richiesto l'accesso. La password TGT dell'account KRBTGT è nota solo al servizio Kerberos. Per richiedere un ticket di sessione, il TGT deve essere presentato al Centro distribuzione chiavi. Il TGT viene rilasciato al client Kerberos dal Centro distribuzione chiavi.
Considerazioni sulla manutenzione dell'account KRBTGT
Agli account KRBTGT e agli account trust viene assegnata automaticamente una password complessa. Come per qualunque account del servizio con privilegi, le organizzazioni devono modificare queste password con regolarità. La password dell'account KDC viene usata per derivare una chiave privata per crittografare e decrittografare le richieste TGT emesse. La password per un account trust del dominio viene usata per derivare una chiave per aree di autenticazione interoperative per crittografare i ticket di riferimento.
Per reimpostare la password è necessario essere membri del gruppo Domain Admins oppure avere ricevuto in delega l'autorità appropriata. È inoltre necessario essere un membro del gruppo Administrators locale oppure avere ricevuto in delega l'autorità appropriata.
Dopo aver reimpostato la password KRBTGT, assicurarsi che l'ID evento 9 nell'origine evento Key-Distribution-Center (Kerberos) sia scritto nel registro eventi di sistema.
Considerazioni sulla sicurezza dell'account KRBTGT
È consigliabile reimpostare la password dell'account KRBTGT per assicurarsi che un controller di dominio appena ripristinato non venga replicato con un controller di dominio compromesso. In questo caso, nel ripristino di una foresta di grandi dimensioni che si estende su più località, non è possibile garantire che tutti i controller di dominio vengano arrestati e, se vengono arrestati, che non possano essere riavviati prima dell'esecuzione di tutti i passaggi di ripristino appropriati. Dopo aver reimpostato l'account KRBTGT, un altro controller di dominio non può replicare la password di questo account usando una password precedente.
Un'organizzazione che sospetti la compromissione dell'account KRBTGT deve prendere in considerazione l'uso di servizi professionali di risposta agli incidenti. Il ripristino della proprietà dell'account incide a livello dell'intero dominio, è impegnativo e deve essere intrapreso come parte di una più ampia operazione di ripristino.
La password KRBTGT è la chiave da cui derivano tutte le relazioni di trust in Kerberos. Reimpostare la password KRBTGT è paragonabile a rinnovare il certificato CA radice con una nuova chiave considerando immediatamente non attendibile la chiave precedente. Di conseguenza, quasi tutte le operazioni Kerberos successive ne risentiranno.
Per tutti i tipi di account (utenti, computer e servizi)
Tutti i TGT già rilasciati e distribuiti non saranno validi perché i controller di dominio li rifiuteranno. Questi ticket vengono crittografati con la password KRBTGT in modo che qualsiasi controller di dominio possa convalidarli. Quando la password viene modificata, i ticket non sono più validi.
Tutte le sessioni attualmente autenticate stabilite dagli utenti connessi (in base ai ticket di servizio) a una risorsa, ad esempio una condivisione file, un sito di SharePoint o un server Exchange, restano valide finché non è necessario ripetere l'autenticazione del ticket di servizio.
Le connessioni autenticate NTLM non sono interessate.
Poiché è impossibile prevedere gli errori specifici che si verificheranno per qualsiasi utente in un ambiente operativo di produzione, è necessario presupporre che saranno interessati tutti i computer e tutti gli utenti.
Importante
Riavviare un computer è l'unico modo affidabile per ripristinare le funzionalità, perché in questo modo sia l'account computer che gli account utente dovranno accedere di nuovo. Per ripetere l'accesso occorreranno nuovi TGT validi con la nuova password KRBTGT, correggendo così eventuali problemi operativi correlati a KRBTGT nel computer.
Controller di dominio di sola lettura e account KRBTGT
In Windows Server 2008 è stato introdotto il controller di dominio di sola lettura (RODC). Il controller di dominio di sola lettura viene presentato come Centro distribuzione chiavi (KDC) per la succursale. Il controller di dominio di sola lettura usa un account KRBTGT e una password diversi rispetto al KDC in un controller di dominio scrivibile quando firma o crittografa le richieste dei ticket di concessione ticket (TGT). Dopo l'autenticazione di un account, il controller di dominio di sola lettura determina se le credenziali di un utente o le credenziali di un computer possono essere replicate dal controller di dominio scrivibile al controller di dominio di sola lettura usando i Criteri di replica password.
Dopo che le credenziali vengono memorizzate nella cache nel controller di dominio di sola lettura, questo può accettare le richieste di accesso dell'utente fino alla modifica delle credenziali. Quando un TGT è firmato con l'account KRBTGT del controller di dominio di sola lettura, il controller di dominio di sola lettura riconosce di avere una copia delle credenziali memorizzata nella cache. Se un altro controller di dominio firma il TGT, il controller di dominio di sola lettura inoltra le richieste a un controller di dominio scrivibile.
Attributi dell'account KRBTGT
Per informazioni dettagliate sugli attributi dell'account KRBTGT, vedere la tabella seguente:
| Attributo | Valore |
|---|---|
| SID/RID noto | S-1-5-<domain>-502 |
| Digita | User |
| Contenitore predefinito | CN=Utenti, DC=<domain>, DC= |
| Membri predefiniti | Nessuno |
| Membro predefinito di | Gruppo Domain Users (l'ID gruppo primario di tutti gli account utente è Domain Users) |
| Protetto da ADMINSDHOLDER? | Sì |
| È sicuro spostarlo fuori dal contenitore predefinito? | Può essere spostato, ma non è consigliabile. |
| È sicuro delegare la gestione di questo gruppo ad amministratori non di servizio? | No |
Impostazioni per gli account locali predefiniti in Active Directory
Ogni account locale predefinito in Active Directory include diverse impostazioni dell'account che è possibile usare per configurare le impostazioni della password e le informazioni specifiche della sicurezza, come descritto nella tabella seguente:
| Impostazioni account | Descrizione |
|---|---|
| Cambiamento obbligatorio password all'accesso successivo | Impone il cambiamento della password in occasione del successivo accesso dell'utente alla rete. Usare questa opzione per assicurarsi che l'utente sia l'unica persona a conoscenza della password. |
| Cambiamento password non consentito | Impedisce all'utente di modificare la password. Usare questa opzione se si vuole mantenere il controllo su un account utente, come nel caso di un account Guest o temporaneo. |
| Password never expires | Non imposta alcuna scadenza per una password utente. È consigliabile abilitare questa opzione per gli account del servizio e usare password complesse. |
| Archivia password mediante crittografia reversibile | Fornisce supporto per le applicazioni che usano protocolli che devono conoscere la password in chiaro dell'utente ai fini dell'autenticazione. Questa opzione è necessaria quando si usa il protocollo CHAP (Challenge Handshake Authentication Protocol) in Internet Authentication Services (IAS) e quando si usa l'autenticazione del digest in Internet Information Services (IIS). |
| Account disabilitato | Impedisce all'utente di eseguire l'accesso con l'account selezionato. Gli amministratori possono usare gli account disabilitati come modelli per gli account utente comuni. |
| Per l'accesso interattivo occorre una smart card | Richiede l'utilizzo di una smart card per l'accesso interattivo alla rete. L'utente dovrà inoltre disporre di un lettore di smart card collegato al computer e di un PIN valido per la smart card. Quando questo attributo viene applicato all'account, l'effetto è il seguente: |
| L'account è trusted per delega | Consente a un servizio eseguito con questo account di eseguire operazioni per conto di altri account utente nella rete. Un servizio in esecuzione con un account utente (noto anche come account del servizio) trusted per delega può rappresentare un client per ottenere l'accesso a risorse, sia nel computer in cui è in esecuzione il servizio che in altri computer. Ad esempio, in una foresta impostata sul livello di funzionalità di Windows Server 2003, questa impostazione si trova nella scheda Delega. È disponibile solo per gli account a cui sono stati assegnati nomi dell'entità servizio (SPN), impostati con il comando setspn degli strumenti di supporto di Windows. Questa impostazione è sensibile per la sicurezza e deve essere assegnata con cautela. |
| L'account è sensibile e non può essere delegato | Consente di mantenere il controllo su un account utente, ad esempio un account Guest o un account temporaneo. Questa opzione può essere usata se l'account non può essere assegnato per la delega da un altro account. |
| Utilizza crittografia DES per questo account | Attiva il supporto della crittografia DES (Data Encryption Standard). DES supporta vari livelli di crittografia, tra cui Microsoft Point-to-Point Encryption (MPPE) standard a 40 bit, MPPE standard a 56 bit, MPPE avanzata a 128 bit, DES a 40 bit per IPSec, DES a 56 bit per IPSec e Triple DES (3DES) per IPSec. |
| Non richiedere l'autenticazione preliminare Kerberos | Fornisce il supporto per implementazioni alternative del protocollo Kerberos. Poiché la preautenticazione offre maggiore sicurezza, prestare attenzione quando si abilita questa opzione. I controller di dominio che eseguono Windows 2000 o Windows Server 2003 possono usare altri meccanismi per sincronizzare l'ora. |
Nota
DES non è abilitato per impostazione predefinita nei sistemi operativi Windows Server (a partire da Windows Server 2008 R2) o nei sistemi operativi client Windows (a partire da Windows 7). Per questi sistemi operativi, per impostazione predefinita i computer non useranno i pacchetti di crittografia DES-CBC-MD5 o DES-CBC-CRC. Se l'ambiente richiede l'utilizzo di DES, questa impostazione può influire sulla compatibilità con computer client o con servizi e applicazioni presenti nell'ambiente.
Per altre informazioni, vedere Cercare DES per distribuire in modo sicuro Kerberos.
Gestire gli account locali predefiniti in Active Directory
Dopo l'installazione, gli account locali predefiniti risiedono nel contenitore Utenti in Utenti e computer di Active Directory. È possibile creare, disabilitare, reimpostare ed eliminare account locali predefiniti usando lo snap-in Utenti e computer di Active Directory di Microsoft Management Console (MMC) e usando gli strumenti da riga di comando.
Si può usare Utenti e computer di Active Directory per assegnare diritti e autorizzazioni a un controller di dominio locale specificato e solo a tale controller di dominio, per limitare la capacità di utenti e gruppi locali di eseguire determinate azioni. Un diritto autorizza un utente a eseguire determinate operazioni in un computer, quali il backup di file e cartelle o l'arresto di un computer. Un'autorizzazione di accesso è invece una regola associata a un oggetto, in genere un file, una cartella o una stampante, che determina quali utenti possono accedervi e in che modo.
Per altre informazioni sulla creazione e gestione di account utente locali in Active Directory, vedere Gestire utenti locali.
È anche possibile usare Utenti e computer di Active Directory in un controller di dominio per puntare a computer remoti che non sono controller di dominio nella rete.
È possibile ottenere consigli da Microsoft per le configurazioni del controller di dominio che è possibile distribuire usando lo strumento Security Compliance Manager (SCM). Per altre informazioni, vedere Microsoft Security Compliance Manager.
Alcuni degli account utente locali predefiniti sono protetti da un processo in background che controlla periodicamente e applica uno specifico descrittore di sicurezza, ovvero una struttura di dati che contiene le informazioni sulla sicurezza associate a un oggetto protetto. Questo descrittore di sicurezza si trova nell'oggetto AdminSDHolder.
Questo significa che, quando si vogliono modificare le autorizzazioni per un gruppo di amministratori dei servizi o per uno degli account membri, è necessario modificare anche il descrittore di sicurezza nell'oggetto AdminSDHolder. Questo approccio assicura che le autorizzazioni vengano applicate in modo coerente. Prestare attenzione quando si apportano queste modifiche, perché l'azione può modificare di conseguenza anche le impostazioni predefinite applicate a tutti gli account amministrativi protetti.
Limitare e proteggere gli account di dominio sensibili
Per limitare e proteggere gli account di dominio nell'ambiente di dominio è necessario adottare e implementare l'approccio consigliato seguente:
Limitare rigorosamente l'appa ai gruppi Administrators, Enterprise Admins e Domain Admins.
Controllare rigorosamente dove e come vengono usati gli account di dominio.
Gli account membri nei gruppi Administrators, Domain Admins ed Enterprise Admins in un dominio o foresta sono bersagli di grande valore per gli utenti malintenzionati. Per limitare qualsiasi esposizione, è consigliabile limitare rigorosamente l'appartenenza a questi gruppi di amministratori al minor numero di account. Limitare l'appartenenza a questi gruppi riduce la possibilità che un amministratore possa involontariamente usare in modo improprio le credenziali e creare una vulnerabilità che gli utenti malintenzionati possono sfruttare.
Inoltre, è consigliabile controllare rigorosamente dove e come vengono usati gli account di dominio sensibili. Limitare l'uso degli account Domain Admins e di altri account amministratore per impedire che vengano usati per accedere ai sistemi di gestione e alle workstation protette allo stesso livello dei sistemi gestiti. Quando gli account amministratore non vengono limitati in questo modo, ogni workstation da cui un amministratore di dominio esegue l'accesso rappresenta un altro punto che gli utenti malintenzionati possono provare a sfruttare.
L'implementazione di queste procedure consigliate è suddivisa nelle attività seguenti:
- Separare gli account amministratore dagli account utente
- Limitare l'accesso dell'amministratore ai server e alle workstation
- Disabilitare il diritto di delega dell'account per gli account amministratore sensibili
Per affrontare le situazioni in cui si prevedono problemi di integrazione con l'ambiente di dominio, ogni attività è descritta in termini di requisiti da soddisfare per un'implementazione minima, migliore o ideale. Come per tutte le modifiche significative in un ambiente di produzione, eseguire test approfonditi prima di implementarle e distribuirle. Procedere quindi a una distribuzione in fasi che consenta il rollback della modifica in caso di problemi tecnici.
Separare gli account amministratore dagli account utente
Limitare gli account Domain Admins e altri account sensibili per evitare che vengano usati per accedere a server e workstation con un livello di attendibilità inferiore. Limitare e proteggere gli account amministratore separando gli account amministratore dagli account utente standard, separando i compiti amministrativi dalle altre attività e limitando l'uso di questi account. Creare account dedicati per il personale amministrativo che richiede credenziali di amministratore per eseguire specifiche attività amministrative e quindi creare account separati per altre attività utente standard, in base alle linee guida seguenti:
Account con privilegi: assegnare account amministratore solo per l'esecuzione dei compiti amministrativi seguenti:
Minimo: creare account separati per amministratori di dominio, amministratori dell'organizzazione o equivalenti, con i diritti di amministratore appropriati nel dominio o nella foresta. Usare gli account a cui sono stati concessi diritti di amministratore sensibili solo per amministrare i dati del dominio e i controller di dominio.
Migliore: creare account separati per gli amministratori con diritti amministrativi ridotti, ad esempio gli account per gli amministratori delle workstation e gli account con diritti utente su unità organizzative di Active Directory designate.
Ideale: creare più account separati per un amministratore che ha responsabilità professionali diverse che richiedono livelli di attendibilità diversi. Configurare ogni account amministratore con diritti utente diversi, ad esempio per l'amministrazione della workstation, l'amministrazione del server e l'amministrazione del dominio, per consentire all'amministratore di accedere a workstation, server e controller di dominio specificati esclusivamente in base alle proprie responsabilità professionali.
Account utente standard: concedere diritti utente standard per le attività utente standard, ad esempio la posta elettronica, l'esplorazione del Web e l'uso di applicazioni line-of-business. A questi account non devono essere concessi diritti amministrativi.
Importante
Assicurarsi che gli account amministratore sensibili non possano accedere alla posta elettronica o esplorare Internet come descritto nella sezione seguente.
Per altre informazioni sull'accesso con privilegi, vedere Dispositivi con accesso con privilegi.
Limitare l'accesso dell'amministratore ai server e alle workstation
Come procedura consigliata, impedire agli amministratori di usare account amministratore sensibili per accedere a server e workstation con un livello di attendibilità inferiore. Questa restrizione impedisce agli amministratori di aumentare involontariamente il rischio di furto di credenziali accedendo a un computer con attendibilità inferiore.
Importante
Assicurarsi di disporre di accesso locale al controller di dominio oppure di aver creato almeno una workstation amministrativa dedicata.
Limitare l'accesso ai server e alle workstation con attendibilità inferiore usando le linee guida seguenti:
Minimo: limitare l'accesso degli amministratori di dominio ai server e alle workstation. Prima di iniziare questa procedura, identificare tutte le unità organizzative del dominio che contengono workstation e server. I computer nelle unità organizzative che non vengono identificati non impediranno l'accesso agli amministratori con account sensibili.
Migliore: limitare l'accesso degli amministratori di dominio alle workstation e ai server non controller di dominio.
Ideale: impedire agli amministratori del server di accedere alle workstation, oltre che agli amministratori di dominio.
Nota
Per questa procedura, non collegare gli account all'unità organizzativa che contiene workstation per gli amministratori che eseguono solo compiti di amministrazione e non fornire l'accesso a Internet o alla posta elettronica.
Per limitare l'accesso degli amministratori di dominio alle workstation (minimo)
Come amministratore di dominio, aprire Console Gestione Criteri di gruppo.
Aprire Gestione Criteri di gruppo, espandere <foresta>\Domini\
<domain>.Fare clic con il pulsante destro del mouse su Oggetti Criteri di gruppo e quindi scegliere Nuovo.
Nella finestra Nuovo oggetto Criteri di gruppo assegnare un nome all'oggetto Criteri di gruppo che impedisce agli amministratori di accedere alle workstation e quindi scegliere OK.
Fare clic con il pulsante destro del mouse sul nuovooggetto Criteri di gruppo e scegliere Modifica.
Configurare i diritti utente per negare l'accesso in locale per gli amministratori di dominio.
Selezionare Configurazione computer>Criteri>Impostazioni di Windows>Criteri locali, selezionare Assegnazione diritti utente e procedere come segue:
a. Fare doppio clic su Nega accesso localee quindi selezionare Definisci le impostazioni relative ai criteri. b. Selezionare Aggiungi utente o gruppo, selezionare Sfoglia, digitare Enterprise Admins e quindi scegliere OK. Selezionare Aggiungi utente o gruppo, selezionare Sfoglia, digitare Domain Admins e quindi scegliere OK.
Suggerimento
Facoltativamente, è possibile aggiungere qualunque gruppo contenente amministratori del server a cui si vuole limitare l'accesso alle workstation.
Nota
Il completamento di questo passaggio può causare problemi con le attività amministrative che vengono eseguite come attività o servizi pianificati con account nel gruppo Domain Admins. La prassi di usare account amministratore di dominio per eseguire servizi e attività nelle workstation crea un rischio significativo di attacchi con furto di credenziali e, di conseguenza, deve essere sostituita con mezzi alternativi per eseguire attività o servizi pianificati.
d. Selezionare OK per completare la configurazione.
Collegare l'oggetto Criteri di gruppo alla prima unità organizzativa Workstation. Passare al percorso <foresta>\Domini\
<domain>\UO e quindi eseguire le operazioni seguenti:a. Fare clic con il pulsante destro del mouse sull'unità organizzativa della workstation e scegliere Collega oggetto Criteri di gruppo esistente.
b. Selezionare l'oggetto Criteri di gruppo appena creato e quindi scegliere OK.
Testare la funzionalità delle applicazioni aziendali nelle workstation nella prima unità organizzativa e risolvere eventuali problemi causati dai nuovi criteri.
Collegare tutte le altre unità organizzative che contengono workstation.
Tuttavia, non creare un collegamento all'unità organizzativa Workstation amministrativa se viene creata per workstation amministrative dedicate solo ai compiti di amministrazione e prive di accesso a Internet o alla posta elettronica.
Importante
Se in seguito si estende questa soluzione, non negare i diritti di accesso per il gruppo Domain Users. Il gruppo Domain Users include tutti gli account utente nel dominio, inclusi Users, Domain Admins ed Enterprise Admins.
Disabilitare il diritto di delega dell'account per gli account amministratore sensibili
Anche se gli account utente non vengono contrassegnati per la delega per impostazione predefinita, gli account in un dominio di Active Directory possono essere considerati attendibili per la delega. Ciò significa che un servizio o un computer attendibile per la delega può rappresentare un account che esegue l'autenticazione al suo interno per accedere ad altre risorse nella rete.
Per gli account sensibili, ad esempio quelli appartenenti ai membri dei gruppi Administrators, Domain Admins o Enterprise Admins in Active Directory, la delega può porre un notevole rischio di escalation dei diritti. Ad esempio, se un account del gruppo Domain Admins viene usato per accedere a un server membro compromesso considerato attendibile per la delega, quel server può richiedere l'accesso alle risorse nel contesto dell'account Domain Admins e far degenerare la compromissione del server membro in una compromissione dell'intero dominio.
È consigliabile configurare gli oggetti utente per tutti gli account sensibili in Active Directory selezionando la casella di controllo L'account è sensibile e non può essere delegato in Opzioni account per impedire che gli account vengano delegati. Per altre informazioni, vedere Impostazioni per gli account locali predefiniti in Active Directory.
Come per qualsiasi modifica della configurazione, testare completamente questa impostazione abilitata per assicurarsi che funzioni correttamente prima di implementarla.
Proteggere e gestire i controller di dominio
È consigliabile applicare restrizioni rigorose ai controller di dominio dell'ambiente. Ciò garantisce che i controller di dominio:
- Eseguano solo il software necessario.
- Richiedano l'aggiornamento regolare del software.
- Siano configurati con le impostazioni di sicurezza appropriate.
Un aspetto della protezione e della gestione dei controller di dominio consiste nell'assicurarsi che gli account utente locali predefiniti siano completamente protetti. È fondamentale limitare e proteggere tutti gli account di dominio sensibili, come descritto nelle sezioni precedenti.
Poiché i controller di dominio archiviano gli hash delle password delle credenziali di tutti gli account nel dominio, sono bersagli di valore elevato per utenti malintenzionati. Quando i controller di dominio non sono ben gestiti e protetti usando restrizioni applicate in modo rigoroso, possono essere compromessi da utenti malintenzionati. Ad esempio, un utente malintenzionato potrebbe rubare credenziali di amministratore di dominio sensibili da un controller di dominio e quindi usarle per attaccare il dominio e la foresta.
Inoltre, le applicazioni installate e gli agenti di gestione nei controller di dominio possono fornire un percorso per l'escalation dei diritti, che gli utenti malintenzionati possono usare per compromettere il servizio di gestione o gli amministratori di tale servizio. Gli strumenti e i servizi di gestione usati dall'organizzazione per gestire i controller di dominio e i relativi amministratori sono altrettanto importanti per la sicurezza dei controller di dominio e degli account amministratore di dominio. Assicurarsi che questi servizi e amministratori siano completamente protetti con lo stesso impegno.