Processi di credenziali in Autenticazione di Windows
Si applica a: Windows Server 2022, Windows Server 2019, Windows Server 2016
Questo argomento di riferimento per professionisti IT descrive come Autenticazione di Windows elabora le credenziali.
La gestione delle credenziali di Windows è il processo con cui il sistema operativo riceve le credenziali dal servizio o dall'utente e protegge tali informazioni per la presentazione futura alla destinazione di autenticazione. Nel caso di un computer aggiunto a un dominio, la destinazione di autenticazione è il controller di dominio. Le credenziali usate nell'autenticazione sono documenti digitali che associano l'identità dell'utente a una forma di autenticità, ad esempio un certificato, una password o un PIN.
Per impostazione predefinita, le credenziali di Windows vengono convalidate rispetto al database SAM (Security Accounts Manager) nel computer locale o in Active Directory in un computer aggiunto a un dominio tramite il servizio Winlogon. Le credenziali vengono raccolte tramite l'input dell'utente nell'interfaccia utente di accesso o a livello di codice tramite l'API (Application Programming Interface) da presentare alla destinazione di autenticazione.
Le informazioni di sicurezza locali vengono archiviate nel registro in HKEY_LOCAL_MACHINE\SECURITY. Le informazioni archiviate includono impostazioni dei criteri, valori di sicurezza predefiniti e informazioni sull'account, ad esempio, le credenziali di accesso memorizzate nella cache. Una copia del database SAM viene archiviata anche qui, anche se è protetta da scrittura.
Il diagramma seguente illustra i componenti necessari e i percorsi che le credenziali riguardano il sistema per autenticare l'utente o il processo per un accesso riuscito.
La tabella seguente descrive ogni componente che gestisce le credenziali nel processo di autenticazione al punto di accesso.
Componenti di autenticazione per tutti i sistemi
| Componente | Descrizione |
|---|---|
| Accesso utente | Winlogon.exe è il file eseguibile responsabile della gestione delle interazioni utente sicure. Il servizio Winlogon avvia il processo di accesso per i sistemi operativi Windows passando le credenziali raccolte dall'utente sul desktop protetto (interfaccia utente di accesso) all'autorità di sicurezza locale (LSA) tramite Secur32.dll. |
| Accesso applicazione | Accessi all'applicazione o al servizio che non richiedono l'accesso interattivo. La maggior parte dei processi avviati dall'utente viene eseguita in modalità utente usando Secur32.dll mentre i processi avviati all'avvio, ad esempio i servizi, vengono eseguiti in modalità kernel usando Ksecdd.sys. Per maggiori informazioni sulla modalità utente e sulla modalità kernel, vedere Applicazioni e modalità utente o Servizi e modalità kernel in questo argomento. |
| Secur32.dll | Più provider di autenticazione che costituiscono la base del processo di autenticazione. |
| Lsasrv.dll | Il servizio LSA Server, che applica entrambi i criteri di sicurezza e funge da gestione pacchetti di sicurezza per LSA. LSA contiene la funzione Negotiate, che seleziona il protocollo NTLM o Kerberos dopo aver determinato quale protocollo deve essere completato correttamente. |
| Security Support Provider | Serie di provider che possono richiamare singolarmente uno o più protocolli di autenticazione. Il set predefinito di provider può cambiare con ogni versione del sistema operativo Windows e i provider personalizzati possono essere scritti. |
| Netlogon.dll | Di seguito sono riportati i servizi eseguiti dal servizio Accesso rete: - Gestisce il canale sicuro del computer (da non confondere con Schannel) a un controller di dominio. |
| Samsrv.dll | Security Accounts Manager (SAM), che archivia gli account di sicurezza locali, applica i criteri archiviati in locale e supporta le API. |
| Registro | Il registro contiene una copia del database SAM, delle impostazioni dei criteri di sicurezza locali, dei valori di sicurezza predefiniti e delle informazioni sull'account accessibili solo al sistema. |
Questo argomento include le sezioni seguenti:
Input delle credenziali per l'accesso utente
In Windows Server 2008 e Windows Vista, l'architettura di identificazione grafica e autenticazione (GINA) è stata sostituita con un modello di provider di credenziali, che ha reso possibile enumerare diversi tipi di accesso tramite l'uso di riquadri di accesso. Di seguito vengono descritti entrambi i modelli.
Architettura di identificazione grafica e autenticazione
L'architettura GINA (Graphical Identification and Authentication) si applica ai sistemi operativi Windows Server 2003, Microsoft Windows 2000 Server, Windows XP e Windows 2000 Professional. In questi sistemi, ogni sessione di accesso interattiva crea un'istanza separata del servizio Winlogon. L'architettura GINA viene caricata nello spazio di processo usato da Winlogon, riceve ed elabora le credenziali ed esegue le chiamate alle interfacce di autenticazione tramite LSALogonUser.
Le istanze di Winlogon per un accesso interattivo vengono eseguite nella sessione 0. La sessione 0 ospita i servizi di sistema e altri processi critici, incluso il processo LSA (Local Security Authority).
Il diagramma seguente illustra il processo delle credenziali per Windows Server 2003, Microsoft Windows 2000 Server, Windows XP e Microsoft Windows 2000 Professional.
Architettura del provider di credenziali
L'architettura del provider di credenziali si applica alle versioni designate nell'elenco Si applica a all'inizio di questo argomento. In questi sistemi, l'architettura di input delle credenziali è stata modificata in una progettazione estendibile usando provider di credenziali. Questi provider sono rappresentati dai diversi riquadri di accesso sul desktop sicuro che consentono un numero qualsiasi di scenari di accesso: account diversi per lo stesso utente e metodi di autenticazione diversi, ad esempio password, smart card e biometrici.
Con l'architettura del provider di credenziali, Winlogon avvia sempre l'interfaccia utente di accesso dopo aver ricevuto un evento di sequenza di attenzione sicuro. L'interfaccia utente di accesso esegue query su ogni provider di credenziali per il numero di tipi di credenziali diversi configurati per l'enumerazione. I provider di credenziali hanno la possibilità di specificare uno di questi riquadri come predefinito. Dopo che tutti i provider hanno enumerato i riquadri, l'interfaccia utente di accesso li visualizza all'utente. L'utente interagisce con un riquadro per fornire le proprie credenziali. L'interfaccia utente di accesso invia queste credenziali per l'autenticazione.
I provider di credenziali non sono meccanismi di imposizione. Vengono usati per raccogliere e serializzare le credenziali. I pacchetti di autenticazione e autorità di sicurezza locali rafforzano la sicurezza.
I provider di credenziali vengono registrati nel computer e sono responsabili dei seguenti elementi:
Descrizione delle informazioni sulle credenziali necessarie per l'autenticazione.
Gestione della comunicazione e della logica con le autorità di autenticazione esterne.
Creazione di pacchetti di credenziali per l'accesso interattivo e di rete.
La creazione di pacchetti delle credenziali per l'accesso interattivo e di rete include il processo di serializzazione. Serializzando le credenziali, è possibile visualizzare più riquadri di accesso nell'interfaccia utente di accesso. Pertanto, l'organizzazione può controllare la visualizzazione dell'accesso, ad esempio gli utenti, i sistemi di destinazione per l'accesso, l'accesso pre-accesso alla rete e ai criteri di blocco/sblocco della workstation, tramite l'uso di provider di credenziali personalizzati. Più provider di credenziali possono coesistere nello stesso computer.
I provider Single Sign-On (SSO) possono essere sviluppati come provider di credenziali standard o come provider di accesso preliminare.
Ogni versione di Windows contiene un provider di credenziali predefinito e un provider di credenziali predefinito pre-accesso (PLAP), noto anche come provider SSO. Il provider SSO consente agli utenti di stabilire una connessione a una rete prima di accedere al computer locale. Quando questo provider viene implementato, il provider non enumera i riquadri nell'interfaccia utente di accesso.
Un provider SSO deve essere usato negli scenari seguenti:
L'autenticazione di rete e l'accesso al computer vengono gestiti da provider di credenziali diversi. Le varianti di questo scenario includono:
Un utente ha la possibilità di connettersi a una rete, ad esempio connettersi a una rete privata virtuale (VPN), prima di accedere al computer, ma non è necessario per stabilire questa connessione.
L'autenticazione di rete è necessaria per recuperare le informazioni usate durante l'autenticazione interattiva nel computer locale.
Più autenticazioni di rete sono seguite da uno degli altri scenari. Ad esempio, un utente esegue l'autenticazione a un provider di servizi Internet (ISP), esegue l'autenticazione a una VPN e quindi usa le credenziali dell'account utente per accedere localmente.
Le credenziali memorizzate nella cache sono disabilitate e una connessione di Servizi di accesso remoto tramite VPN è necessaria prima dell'accesso locale per autenticare l'utente.
Un utente di dominio non dispone di un account locale configurato in un computer aggiunto a un dominio e deve stabilire una connessione a Servizi di accesso remoto tramite connessione VPN prima di completare l'accesso interattivo.
L'autenticazione di rete e l'accesso al computer vengono gestiti dallo stesso provider di credenziali. In questo scenario, l'utente deve connettersi alla rete prima di accedere al computer.
Enumerazione riquadro di accesso
Il provider di credenziali enumera i riquadri di accesso nelle istanze seguenti:
Per i sistemi operativi indicati nell'elenco Si applica a all'inizio di questo argomento.
Il provider di credenziali enumera i riquadri per l'accesso alla workstation. Il provider di credenziali serializza in genere le credenziali per l'autenticazione all'autorità di sicurezza locale. Questo processo visualizza riquadri specifici per ogni utente e specifici per i sistemi di destinazione di ogni utente.
L'architettura di accesso e autenticazione consente a un utente di usare riquadri enumerati dal provider di credenziali per sbloccare una workstation. In genere, l'utente attualmente connesso è il riquadro predefinito, ma, se più utenti sono connessi, vengono visualizzati numerosi riquadri.
Il provider di credenziali enumera i riquadri in risposta a una richiesta dell'utente per modificare la password o altre informazioni private, ad esempio, un PIN. In genere, l'utente attualmente connesso è il riquadro predefinito, tuttavia, se più utenti sono connessi, vengono visualizzati numerosi riquadri.
Il provider di credenziali enumera i riquadri in base alle credenziali serializzate da usare per l'autenticazione nei computer remoti. L'interfaccia utente delle credenziali non usa la stessa istanza del provider dell'interfaccia utente di accesso, sblocco della workstation o modifica password. Pertanto, le informazioni sullo stato non possono essere mantenute nel provider tra istanze dell'interfaccia utente delle credenziali. Questa struttura comporta un riquadro per ogni accesso al computer remoto, presupponendo che le credenziali siano state serializzate correttamente. Questo scenario viene usato anche in Controllo account utente, che consente di impedire modifiche non autorizzate a un computer richiedendo all'utente l'autorizzazione o una password di amministratore prima di consentire azioni che potrebbero influire potenzialmente sull'operazione del computer o che potrebbero modificare le impostazioni che interessano altri utenti del computer.
Il diagramma seguente illustra il processo delle credenziali per i sistemi operativi designati nell'elenco Si applica a all'inizio di questo argomento.
Input delle credenziali per l'accesso all'applicazione e al servizio
Autenticazione di Windows è progettato per gestire le credenziali per applicazioni o servizi che non richiedono l'interazione dell'utente. Le applicazioni in modalità utente sono limitate in termini di risorse di sistema a cui hanno accesso, mentre i servizi possono avere accesso illimitato alla memoria di sistema e ai dispositivi esterni.
I servizi di sistema e le applicazioni a livello di trasporto accedono a un provider di supporto di sicurezza (SSP) tramite Security Support Provider Interface (SSPI) in Windows, che fornisce funzioni per enumerare i pacchetti di sicurezza disponibili in un sistema, selezionando un pacchetto e usando tale pacchetto per ottenere una connessione autenticata.
Quando viene autenticata una connessione client/server:
L'applicazione sul lato client della connessione invia le credenziali al server usando la funzione SSPI
InitializeSecurityContext (General).L'applicazione sul lato server della connessione risponde con la funzione SSPI
AcceptSecurityContext (General).Le funzioni SSPI
InitializeSecurityContext (General)eAcceptSecurityContext (General)vengono ripetute fino a quando non vengono scambiati tutti i messaggi di autenticazione necessari per avere esito positivo o negativo.Dopo l'autenticazione della connessione, LSA nel server usa le informazioni del client per compilare il contesto di sicurezza, che contiene un token di accesso.
Il server può quindi chiamare la funzione SSPI
ImpersonateSecurityContextper collegare il token di accesso a un thread di rappresentazione per il servizio.
Applicazioni e modalità utente
La modalità utente in Windows è costituita da due sistemi in grado di passare le richieste di I/O ai driver in modalità kernel appropriati: il sistema di ambiente, che esegue applicazioni scritte per molti tipi diversi di sistemi operativi e il sistema integrale, che opera funzioni specifiche del sistema per conto del sistema ambientale.
Il sistema integrale gestisce le funzioni specifiche del sistema operativo per conto del sistema ambientale ed è costituito da un processo di sistema di sicurezza (LSA), un servizio workstation e un servizio server. Il processo del sistema di sicurezza gestisce i token di sicurezza, concede o nega le autorizzazioni per accedere agli account utente in base alle autorizzazioni delle risorse, gestisce le richieste di accesso e avvia l'autenticazione di accesso e determina le risorse di sistema necessarie per il controllo del sistema operativo.
Le applicazioni possono essere eseguite in modalità utente, in cui l'applicazione può essere eseguita come qualsiasi entità, incluso nel contesto di sicurezza di Sistema locale (SYSTEM). Le applicazioni possono essere eseguite anche in modalità kernel in cui l'applicazione può essere eseguita nel contesto di sicurezza del Sistema locale (SYSTEM).
SSPI è disponibile tramite il modulo Secur32.dll, che è un'API usata per ottenere servizi di sicurezza integrati per l'autenticazione, l'integrità dei messaggi e la privacy dei messaggi. Fornisce un livello di astrazione tra protocolli a livello di applicazione e protocolli di sicurezza. Poiché diverse applicazioni richiedono modi diversi per identificare o autenticare gli utenti e diversi modi di crittografare i dati durante il viaggio in una rete, SSPI offre un modo per accedere alle librerie a collegamento dinamico (DLL) che contengono funzioni di autenticazione e crittografia diverse. Queste DLL sono denominate provider di supporto per la sicurezza (SSP).
Gli account del servizio gestito e gli account virtuali sono stati introdotti in Windows Server 2008 R2 e Windows 7 per fornire alle applicazioni cruciali, ad esempio Microsoft SQL Server e Internet Information Services (IIS), l'isolamento dei propri account di dominio, eliminando al contempo la necessità per un amministratore di amministrare manualmente il nome dell'entità servizio (SPN) e le credenziali per questi account. Per maggiori informazioni su queste funzionalità e il relativo ruolo nell'autenticazione, consultare la sezione Documentazione degli account del servizio gestito per Windows 7 e Windows Server 2008 R2 e Panoramica degli account del servizio gestito di gruppo.
Servizi e modalità kernel
Anche se la maggior parte delle applicazioni Windows viene eseguita nel contesto di sicurezza dell'utente che li avvia, questo non vale per i servizi. Molti servizi Windows, ad esempio servizi di rete e stampa, vengono avviati dal controller del servizio quando l'utente avvia il computer. Questi servizi potrebbero essere eseguiti come servizio locale o sistema locale e potrebbero continuare a essere eseguiti dopo l'ultimo disconnettersi dell'utente umano.
Nota
I servizi vengono in genere eseguiti in contesti di sicurezza noti come Sistema locale (SYSTEM), Servizio di rete o Servizio locale. Windows Server 2008 R2 ha introdotto i servizi eseguiti con un account del servizio gestito, ovvero entità di dominio.
Prima di avviare un servizio, il controller del servizio accede usando l'account designato per il servizio e quindi presenta le credenziali del servizio per l'autenticazione da parte dell'LSA. Il servizio Windows implementa un'interfaccia programmatica che il gestore del controller di servizio può usare per controllare il servizio. Un servizio Windows può essere avviato automaticamente quando il sistema viene avviato o manualmente con un programma di controllo del servizio. Ad esempio, quando un computer client Windows aggiunge un dominio, il servizio messenger nel computer si connette a un controller di dominio e apre un canale sicuro. Per ottenere una connessione autenticata, il servizio deve disporre di credenziali che l'autorità di sicurezza locale del computer remoto considera attendibile. Quando si comunica con altri computer nella rete, LSA usa le credenziali per l'account di dominio del computer locale, come tutti gli altri servizi in esecuzione nel contesto di sicurezza del sistema locale e del servizio di rete. I servizi nel computer locale vengono eseguiti come SYSTEM in modo che le credenziali non debbano essere presentate all'LSA.
Il file Ksecdd.sys gestisce e crittografa queste credenziali e usa una chiamata di procedura locale all'LSA. Il tipo di file è DRV (driver) ed è noto come provider di supporto per la sicurezza (SSP) in modalità kernel e, nelle versioni designate nell'elenco Si applica a all'inizio di questo argomento, è conforme a FIPS 140-2 Livello 1.
La modalità kernel ha accesso completo alle risorse hardware e di sistema del computer. La modalità kernel impedisce ai servizi e alle applicazioni in modalità utente di accedere ad aree critiche del sistema operativo a cui non devono avere accesso.
Autorità di protezione locale
L'Autorità di sicurezza locale (LSA) è un processo di sistema protetto che autentica e registra gli utenti nel computer locale. Inoltre, LSA mantiene informazioni su tutti gli aspetti della sicurezza locale in un computer (questi aspetti sono collettivamente noti come criteri di sicurezza locali) e fornisce vari servizi per la conversione tra nomi e identificatori di sicurezza (SID). Il processo del sistema di sicurezza, il servizio del server dell'autorità di sicurezza locale (LSASS), tiene traccia dei criteri di sicurezza e degli account in vigore in un sistema informatico.
L'LSA convalida l'identità di un utente in base alla quale delle due entità seguenti ha emesso l'account dell'utente:
Autorità di protezione locale. LSA può convalidare le informazioni utente controllando il database di Gestione account di sicurezza (SAM) che si trova nello stesso computer. Qualsiasi workstation o server membro può archiviare account utente locali e informazioni sui gruppi locali. Tuttavia, questi account possono essere usati per accedere solo a tale workstation o computer.
Autorità di sicurezza per il dominio locale o per un dominio attendibile. L'LSA contatta l'entità che ha emesso l'account e richiede la verifica che l'account sia valido e che la richiesta abbia avuto origine dal titolare dell'account.
Il servizio LSASS (Local Security Authority Subsystem Service) permette di archiviare credenziali in memoria per conto di utenti con sessioni attive di Windows. Le credenziali salvate permettono agli utenti di accedere facilmente alle risorse di rete, ad esempio condivisioni file, cassette postali di Exchange Server e siti di SharePoint, senza immettere di nuovo le proprie credenziali per ogni servizio remoto.
Il servizio LSASS permette di archiviare credenziali in più formati, inclusi i seguenti:
Testo normale crittografato in modo reversibile
Ticket Kerberos (ticket-granting ticket (TGT), ticket di servizio
Hash NT
Hash di LAN Manager (LM)
Se l'utente accede a Windows usando una smart card, il servizio LSASS non archivia una password in testo non crittografato, ma archivierà il valore dell'hash NT corrispondente per l'account e il PIN in testo non crittografato per la smart card. Se l'attributo dell'account è abilitato per una smart card necessaria per l'accesso interattivo, un valore di hash NT casuale viene generato automaticamente per l'account invece dell'hash della password originale. L'hash di password generato automaticamente quando si imposta l'attributo non viene modificato.
Se un utente accede a un computer Windows con una password compatibile con gli hash LAN Manager (LM), questo autenticatore sarà presente in memoria.
L'archiviazione di credenziali in testo non crittografato in memoria non può essere disabilitata, anche se i provider di credenziali che le richiedono sono disabilitati.
Le credenziali archiviate sono associate direttamente alle sessioni di accesso Local Security Authority Subsystem Service (LSASS) avviate dopo l'ultimo riavvio e non chiuse. Ad esempio, sessioni LSA con credenziali LSA archiviate vengono create quando un utente esegue una delle operazioni seguenti:
Accesso a una sessione locale o una sessione RDP (Remote Desktop Protocol) nel computer
Esecuzione di un task con l'opzione RunAs
Esecuzione di un servizio di Windows attivo nel computer
Esecuzione di un'attività o un processo batch pianificato
Esecuzione di un'attività nel computer locale tramite uno strumento di amministrazione remota
In alcune circostanze, i segreti LSA, che sono parti segrete di dati accessibili solo ai processi dell'account SYSTEM, vengono archiviati nell'unità disco rigido. Alcuni di questi segreti sono credenziali che devono essere mantenute dopo un riavvio e sono archiviate in formato crittografato nell'unità disco rigido. Le credenziali archiviate come segreti LSA possono includere:
Password dell'account per l'account Dominio di Active Directory Services (AD DS) del computer
Password di account per servizi di Windows configurati nel computer
Password di account per le attività pianificate configurate
Password di account per pool di applicazioni IIS e siti Web
Password per gli account Microsoft
Introdotto in Windows 8.1, il sistema operativo client offre una protezione aggiuntiva per LSA per impedire la lettura della memora e le operazioni di code injection da processi non protetti. In questo modo, le credenziali archiviate e gestite in LSA sono più sicure.
Per maggiori informazioni su queste protezioni aggiuntive, consultare la sezione Configurazione della protezione LSA aggiuntiva.
Credenziali e convalida memorizzate nella cache
I meccanismi di convalida si basano sulla presentazione delle credenziali al momento dell'accesso. Tuttavia, quando il computer viene disconnesso da un controller di dominio e l'utente presenta le credenziali di dominio, Windows usa il processo di credenziali memorizzate nella cache nel meccanismo di convalida.
Ogni volta che un utente accede a un dominio, Windows memorizza nella cache le credenziali fornite e le archivia nell'hive di sicurezza nel registro operativo.
Con le credenziali memorizzate nella cache, l'utente può accedere a un membro di dominio senza essere connesso a un controller di dominio all'interno di tale dominio.
Archiviazione e convalida delle credenziali
Non è sempre consigliabile usare un set di credenziali per l'accesso a risorse diverse. Ad esempio, un amministratore potrebbe voler usare credenziali amministrative anziché utente durante l'accesso a un server remoto. Analogamente, se un utente accede a risorse esterne, ad esempio, un conto bancario, può usare solo credenziali diverse dalle credenziali di dominio. Le sezioni seguenti descrivono le differenze nella gestione delle credenziali tra le versioni correnti dei sistemi operativi Windows e i sistemi operativi Windows Vista e Windows XP.
Processi di credenziali di accesso remoto
Remote Desktop Protocol (RDP) gestisce le credenziali dell'utente che si connette a un computer remoto usando il client desktop remoto, introdotto in Windows 8. Le credenziali in formato non crittografato vengono inviate all'host di destinazione in cui l'host tenta di eseguire il processo di autenticazione e, se ha esito positivo, connette l'utente alle risorse consentite. RDP non archivia le credenziali nel client, ma le credenziali di dominio dell'utente vengono archiviate in LSASS.
Introdotta in Windows Server 2012 R2 e Windows 8.1, la modalità di amministrazione con restrizioni offre sicurezza aggiuntiva agli scenari di accesso remoto. Questa modalità di Desktop remoto fa sì che l'applicazione client esegua una richiesta di richiesta di accesso alla rete con la funzione NT unidirezionale (NTOWF) o usi un ticket di servizio Kerberos durante l'autenticazione nell'host remoto. Dopo l'autenticazione dell'amministratore, l'amministratore non dispone delle rispettive credenziali dell'account in LSASS perché non sono state fornite all'host remoto. L'amministratore dispone invece delle credenziali dell'account computer per la sessione. Le credenziali dell'amministratore non vengono fornite all'host remoto, quindi le azioni vengono eseguite come account computer. Le risorse sono limitate anche all'account computer e l'amministratore non può accedere alle risorse con il proprio account.
Processo di credenziali di accesso automatico per il riavvio
Quando un utente accede a un dispositivo Windows 8.1, LSA salva le credenziali utente in memoria crittografata accessibili solo da LSASS.exe. Quando Windows Update avvia un riavvio automatico senza presenza dell'utente, queste credenziali vengono usate per configurare l'accesso automatico per l'utente.
Al riavvio, l'utente accede automaticamente tramite il meccanismo di accesso automatico e quindi il computer viene bloccato per proteggere la sessione dell'utente. Il blocco viene avviato tramite Winlogon, mentre la gestione delle credenziali viene eseguita da LSA. Accedendo e bloccando automaticamente la sessione dell'utente nella console, le applicazioni della schermata di blocco dell'utente vengono riavviate e disponibili.
Per maggiori informazioni su ARSO, consultare la sezione Riavvio automatico winlogon (ARSO) .
Nomi utente archiviato e password in Windows Vista e Windows XP
In Windows Server 2008 , Windows Server 2003, Windows Vista e Windows XP, Nomi utente archiviato e le password in Pannello di controllo semplifica la gestione e l'uso di più set di credenziali di accesso, inclusi i certificati X.509 usati con smart card e credenziali di Windows Live (ora denominato account Microsoft). Le credenziali, parte del profilo dell'utente, vengono archiviate fino a quando non sono necessarie. Questa azione può aumentare la sicurezza per ogni risorsa assicurandosi che, se una password è compromessa, non compromette tutta la sicurezza.
Dopo che un utente accede e tenta di accedere a risorse aggiuntive protette da password, ad esempio una condivisione in un server e se le credenziali di accesso predefinite dell'utente non sono sufficienti per ottenere l'accesso, viene eseguita una query su Nomi utente archiviato e password. Se le credenziali alternative con le informazioni di accesso corrette sono state salvate in Nomi utente archiviato e password, queste credenziali vengono usate per ottenere l'accesso. In caso contrario, all'utente viene richiesto di specificare nuove credenziali, che possono essere salvate per il riutilizzo, in un secondo momento nella sessione di accesso o durante una sessione successiva.
Si applicano le seguenti restrizioni:
Se i Nomi utente archiviato e password contiene credenziali non valide o errate per una risorsa specifica, l'accesso alla risorsa viene negato e la finestra di dialogo Nomi utente archiviato e password non viene visualizzata.
Nomi utente archiviato e password archivia le credenziali solo per l'autenticazione NTLM, protocollo Kerberos, account Microsoft (in precedenza Windows Live ID) e Secure Sockets Layer (SSL). Alcune versioni di Internet Explorer mantengono la propria cache per l'autenticazione di base.
Queste credenziali diventano una parte crittografata del profilo locale di un utente nella directory \Documents and Settings\Username\Application Data\Microsoft\Credentials. Di conseguenza, queste credenziali possono eseguire il roaming con l'utente se i criteri di rete dell'utente supportano profili utente mobili. Tuttavia, se l'utente dispone di copie di Nomi utente archiviato e password in due computer diversi e modifica le credenziali associate alla risorsa in uno di questi computer, la modifica non viene propagata a Nomi utente archiviato e password nel secondo computer.
Insieme di credenziali di Windows e Gestione credenziali
Credential Manager è stato introdotto in Windows Server 2008 R2 e Windows 7 come funzionalità di Pannello di controllo per archiviare e gestire nomi utente e password. Credential Manager consente agli utenti di archiviare le credenziali rilevanti per altri sistemi e siti Web nell'insieme di credenziali di Windows sicuro. Alcune versioni di Internet Explorer usano questa funzionalità per l'autenticazione nei siti Web.
La gestione delle credenziali mediante Gestione credenziali è controllata dall'utente nel computer locale. Gli utenti possono salvare e archiviare le credenziali dai browser supportati e dalle applicazioni Windows in modo da rendere più pratico l'accesso a queste risorse. Le credenziali vengono salvate in speciali cartelle crittografate nel profilo utente del computer. Le applicazioni che supportano questa funzionalità (tramite l'uso delle API di Gestione credenziali), ad esempio Web browser e app, possono presentare le credenziali corrette ad altri computer e siti Web durante il processo di accesso.
Quando un sito Web, un'applicazione o un altro computer richiede l'autenticazione tramite NTLM o il protocollo Kerberos, viene visualizzata una finestra di dialogo in cui si seleziona la casella di controllo Aggiorna credenziali predefinite o Salva password. Questa finestra di dialogo che consente a un utente di salvare le credenziali in locale viene generata da un'applicazione che supporta le API di Gestione credenziali. Se l'utente seleziona la casella di controllo Salva password, Gestione credenziali tiene traccia del nome utente, della password e delle informazioni correlate per il servizio di autenticazione in uso.
Al successivo utilizzo del servizio, Gestione credenziali fornisce automaticamente le credenziali archiviate nell'insieme di credenziali di Windows. Se queste non vengono accettate, le informazioni di accesso corrette vengono richieste all'utente. Se l'accesso viene concesso con le nuove credenziali, Gestione credenziali sovrascrive le credenziali precedenti con quella nuova e quindi archivia le nuove credenziali nell'insieme di credenziali di Windows.
Database di gestione degli account di sicurezza (SAM)
Security Accounts Manager (SAM) è un database che archivia gli account utente e i gruppi locali. È presente in ogni sistema operativo Windows; tuttavia, quando un computer viene aggiunto a un dominio, Active Directory gestisce gli account di dominio nei domini di Active Directory.
Ad esempio, i computer client che eseguono un sistema operativo Windows partecipano a un dominio di rete comunicando con un controller di dominio anche quando nessun utente umano è connesso. Per avviare le comunicazioni, il computer deve avere un account attivo nel dominio. Prima di accettare comunicazioni dal computer, l'LSA nel controller di dominio autentica l'identità del computer e quindi crea il contesto di sicurezza del computer come farebbe per l'entità di sicurezza umana. Questo contesto di sicurezza definisce l'identità e le capacità di un utente o di un servizio in un computer specifico oppure di un utente, un servizio o un computer in una rete. Ad esempio, il token di accesso contenuto nel contesto di sicurezza definisce le risorse, come una condivisione file o una stampante, a cui è possibile accedere e le azioni, come lettura, scrittura o modifica, che possono essere eseguite da un utente, un computer, un servizio principale sulla risorsa.
Il contesto di sicurezza di un utente o di un computer può variare da un computer all'altro, ad esempio quando un utente esegue l'accesso a un server o in una workstation diversa dalla sua workstation principale. Può anche variare da una sessione all'altra, ad esempio quando un amministratore modifica i diritti e le autorizzazioni dell'utente. Inoltre, il contesto di sicurezza è generalmente diverso quando un utente o un computer opera su base autonoma, in una rete o come parte di un dominio di Active Directory.
Domini locali e domini attendibili
Quando esiste un trust tra due domini, i meccanismi di autenticazione per ogni dominio si basano sulla validità delle autenticazioni provenienti dall'altro dominio. I trust consentono l'accesso controllato alle risorse condivise in un dominio di risorse (il dominio trusting) verificando che le richieste di autenticazione in ingresso provengano da un'autorità attendibile (il dominio attendibile). In questo modo, i trust fungono da ponti che consentono solo alle richieste di autenticazione convalidate di spostarsi tra i domini.
Il modo in cui un determinato trust supera le richieste di autenticazione dipende dalla relativa configurazione. Le relazioni di trust possono essere unidirezionale, fornendo l'accesso dal dominio attendibile alle risorse nel dominio attendibile o bidirezionale, fornendo l'accesso da ogni dominio alle risorse nell'altro dominio. I trust sono anche non transitivi, nel qual caso, esiste una relazione di trust solo tra i due domini partner di trust o transitiva, nel qual caso un trust si estende automaticamente a qualsiasi altro dominio che uno dei partner considera attendibili.
Per informazioni sulle relazioni di trust tra domini e foreste relative all'autenticazione, consultare la sezione Autenticazione delegata e relazioni di trust.
Certificati in autenticazione di Windows
Un'infrastruttura a chiave pubblica (PKI) è la combinazione di software, tecnologie di crittografia, processi e servizi che consentono a un'organizzazione di proteggere i dati, le comunicazioni e le transazioni commerciali. La capacità di un'infrastruttura a chiave pubblica di proteggere le comunicazioni e le transazioni aziendali si basa sullo scambio di certificati digitali tra utenti autenticati e risorse attendibili.
Un certificato digitale è un documento elettronico che contiene informazioni sull'entità a cui appartiene, l'entità a cui è stata rilasciata, un numero di serie univoco o altre date di identificazione, rilascio e scadenza univoche e un'impronta digitale.
L'autenticazione è il processo di determinazione se un host remoto può essere considerato attendibile. Per stabilire la sua attendibilità, l'host remoto deve fornire un certificato di autenticazione accettabile.
Gli host remoti stabiliscono la loro attendibilità ottenendo un certificato da un'autorità di certificazione (CA). La CA può, a sua volta, avere la certificazione di un'autorità superiore, che crea una catena di attendibilità. Per determinare se un certificato è attendibile, un'applicazione deve determinare l'identità della CA radice e quindi determinare se è attendibile.
Analogamente, l'host remoto o il computer locale deve determinare se il certificato presentato dall'utente o dall'applicazione è autenticato. Il certificato presentato dall'utente tramite LSA e SSPI viene valutato per l'autenticità nel computer locale per l'accesso locale, in rete o nel dominio tramite gli archivi certificati in Active Directory.
Per produrre un certificato, i dati di autenticazione passano attraverso algoritmi hash, ad esempio Secure Hash Algorithm 1 (SHA1), per produrre un digest del messaggio. Il digest del messaggio viene quindi firmato digitalmente usando la chiave privata del mittente per dimostrare che il digest del messaggio è stato prodotto dal mittente.
Nota
SHA1 è l'impostazione predefinita in Windows 7 e Windows Vista, ma è stata modificata in SHA2 in Windows 8.
Autenticazione con smart card
La tecnologia smart card è un esempio di autenticazione basata su certificati. L'accesso a una rete con una smart card offre una forma avanzata di autenticazione perché usa l'identificazione basata sulla crittografia e la prova di possesso durante l'autenticazione di un utente in un dominio. Servizi certificati Active Directory fornisce l'identificazione basata su crittografia tramite il rilascio di un certificato di accesso per ogni smart card.
Per informazioni sull'autenticazione tramite smart card, consultare la Documentazione tecnica sulla smart card di Windows.
La tecnologia smart card virtuale è stata introdotta in Windows 8. Archivia il certificato della smart card nel PC e lo protegge usando il chip di sicurezza TPM (Trusted Platform Module) a prova di manomissione del dispositivo. In questo modo, il PC diventa effettivamente la smart card che deve ricevere il PIN dell'utente per poter essere autenticato.
Autenticazione remota e wireless
L'autenticazione di rete remota e wireless è un'altra tecnologia che usa i certificati per l'autenticazione. Il servizio di autenticazione Internet (IAS) e i server di rete privata virtuale usano Extensible Authentication Protocol-Transport Level Security (EAP-TLS), Protected Extensible Authentication Protocol (PEAP) o Internet Protocol Security (IPsec) per eseguire l'autenticazione basata su certificati per molti tipi di accesso alla rete, tra cui la rete privata virtuale (VPN) e le connessioni wireless.
Per informazioni sull'autenticazione basata su certificati nella rete, consultare la sezione Autenticazione e certificati di accesso alla rete.