Linee guida su come configurare gli account protetti
Si applica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Gli attacchi Pass-the-hash (PtH) consentono agli autori di attacchi di eseguire l'autenticazione a un server o un servizio remoto usando l'hash NTLM sottostante della password di un utente (o altri derivati delle credenziali). Microsoft ha in precedenza pubblicato indicazioni per ridurre gli attacchi pass-the-hash. Windows Server 2012 R2 include nuove funzionalità per limitare ulteriormente tali attacchi. Per ulteriori informazioni sulle altre funzionalità di sicurezza per la protezione contro il furto di credenziali, vedere Gestione e protezione delle credenziali. In questo argomento viene illustrato come configurare le nuove funzionalità seguenti:
In Windows 8.1 e Windows Server 2012 R2 sono inoltre incorporate le funzionalità per la prevenzione dei furti di credenziali descritte negli argomenti seguenti:
Utenti protetti
Utenti protetti è un nuovo gruppo di sicurezza globale a cui è possibile aggiungere utenti nuovi o esistenti. I dispositivi Windows 8.1 e Windows Server 2012 R2 host hanno un comportamento speciale con i membri di questo gruppo per fornire una migliore protezione contro il furto di credenziali. Per un membro del gruppo, un host Windows Server 2012 R2 o un dispositivo Windows 8.1 non memorizzare nella cache le credenziali che non sono supportate per utenti protetti. I membri di questo gruppo non dispongono di alcuna protezione aggiuntiva se sono connessi a un dispositivo che esegue una versione di Windows precedenti a Windows 8.1.
Gruppo di utenti protetti che sono firmati-on per i dispositivi Windows 8.1 e gli host Windows Server 2012 R2 possono non è più utilizzare:
Delega delle credenziali (CredSSP) - predefinita non vengono memorizzate le credenziali in testo normale anche quando il Consenti delega credenziali predefinite criterio è abilitato
Digest di Windows: le credenziali in testo normale non vengono memorizzate nella cache, anche se sono abilitate
Autenticazione NTLM: la funzione NTOWF non viene memorizzata nella cache
Chiavi a lungo termine Kerberos: il ticket di concessione ticket (TGT) Kerberos viene acquisito all'accesso e non può essere riacquisito automaticamente
Accesso offline: il verificatore dell'accesso memorizzato nella cache non viene creato
Se il livello funzionale del dominio è Windows Server 2012 R2, i membri del gruppo è più possono:
Usare l'autenticazione NTLM.
Usare pacchetti di crittografia DES (Data Encryption Standard) o RC4 nella preautenticazione Kerberos.
Essere delegati tramite delega vincolata o non vincolata.
Rinnovare i ticket utente (TGT) di Kerberos oltre la durata iniziale di quattro ore.
Per aggiungere utenti al gruppo, è possibile utilizzare strumenti dell'interfaccia Utente ad esempio Active Directory amministrativi CENTRO utenti di Active Directory e i computer o uno strumento da riga di comando, ad esempio Dsmod group, o Windows PowerShellAdd-ADGroupMember cmdlet. Account per servizi e computer non dovrebbero essere membri del gruppo utenti protetti. L'appartenenza per questi account non fornisce protezioni locali perché la password o il certificato è sempre disponibile nell'host.
Avviso
Non sono disponibili soluzioni alternative per le restrizioni dell'autenticazione, di conseguenza i membri di gruppi con privilegi elevati, ad esempio il gruppo Admins o il gruppo Domain Admins sono soggetti alle stesse restrizioni degli altri membri del gruppo Utenti protetti. Se tutti i membri di tali gruppi vengono aggiunti al gruppo Utenti protetti, è possibile che questi account vengano bloccati. È consigliabile non aggiungere mai tutti gli account con privilegi elevati al gruppo Utenti protetti fintanto che non se ne è verificato l'impatto potenziale.
I membri del gruppo Utenti protetti devono essere in grado di eseguire l'autenticazione tramite Kerberos con crittografia AES (Advanced Encryption Standards). Questo metodo richiede le chiavi AES per l'account in Active Directory. L'amministratore predefinito non dispone di una chiave AES a meno che la password è stata modificata in un controller di dominio che esegue Windows Server 2008 o versione successiva. Inoltre, qualsiasi account la cui password è stata modificata in un controller di dominio che esegue una versione precedente di Windows Server, rimane bloccato. Attenersi quindi alle procedure consigliate riportate di seguito:
Non eseguire test in domini a meno che non tutti i controller di dominio eseguono Windows Server 2008 o versione successiva.
Modifica della password per tutti gli account di dominio che sono stati creati prima il dominio è stato creato. In caso contrario, non sarà possibile autenticare questi account.
Modifica della password per ogni utente prima di aggiungere l'account per utenti protetti di gruppo o verificare che la password sia stata modificata di recente in un controller di dominio che esegue Windows Server 2008 o versione successiva.
Requisiti per l'uso degli account protetti
Per gli account protetti sono previsti i requisiti di distribuzione seguenti:
Per specificare restrizioni sul lato client per utenti protetti, gli host devono eseguire Windows 8.1 o Windows Server 2012 R2. Un utente deve semplicemente eseguire l'accesso con un account membro di un gruppo Utenti protetti. In questo caso, il gruppo utenti protetti può essere creato da trasferire il ruolo di emulatore dominio primario (PDC) controller a un controller di dominio che esegue Windows Server 2012 R2. Dopo avere replicato l'oggetto gruppo in altri controller di dominio, il ruolo dell'emulatore PDC può essere ospitato in un controller di dominio che esegue una versione precedente di Windows Server.
Per specificare restrizioni sul lato controller di dominio per utenti protetti, che consiste nel limitare l'utilizzo dell'autenticazione NTLM, e altre restrizioni, il livello funzionale del dominio deve essere Windows Server 2012 R2. Per ulteriori informazioni sui livelli di funzionalità, vedere livelli di funzionalità di servizi di dominio Active Directory informazioni (AD DS).
Nota
L'amministratore del dominio predefinito (S-1-5-<domain>-500) è sempre esonerato dai criteri di autenticazione, anche quando vengono assegnati a un silo dei criteri di autenticazione.
Risolvere i problemi relativi agli eventi correlati a Utenti protetti
In questa sezione vengono illustrati i nuovi registri che consentono di risolvere i problemi relativi agli eventi correlati a Utenti protetti e viene descritto il modo in cui il gruppo Utenti protetti può influire sulle modifiche per la risoluzione dei problemi relativi alla delega o alla scadenza dei ticket di concessione ticket (TGT).
Nuovi registri per Utenti protetti
Due nuovi registri amministrativi sono disponibili per la risoluzione di eventi relativi a utenti protetti: utenti protetti - Client Log e Protected User Failures - Domain Controller Log. Questi due nuovi registri sono disponibili nel Visualizzatore eventi e sono disabilitati per impostazione predefinita. Per abilitare un registro, fare clic su registri applicazioni e servizi, fare clic su Microsoft, fare clic su Windows, fare clic su autenticazione, quindi fare clic sul nome del log e fare clic su azione (o destro di log) e fare clic su Attiva registro.
Per ulteriori informazioni sugli eventi in questi registri, vedere criteri di autenticazione e silo di criteri di autenticazione.
Risolvere i problemi relativi alla scadenza del ticket di concessione ticket (TGT)
In genere, il controller di dominio imposta la durata e il rinnovo del ticket di concessione ticket (TGT) in base ai criteri di dominio come illustrato nella finestra dell'Editor Gestione Criteri di gruppo seguente.
Per utenti protetti, le impostazioni seguenti sono hardcoded:
Durata massima ticket utente: 240 minuti
Durata massima rinnovo ticket utente: 240 minuti
Risolvere i problemi relativi alla delega
In precedenza, se si verifica un errore una tecnologia che utilizza la delega Kerberos, l'account del client è stato controllato per verificare se Account è sensibile e non può essere delegato è stata impostata. Tuttavia, se l'account è un membro di utenti protetti, potrebbe non contenere questa impostazione configurata in Active Directory amministrativi CENTRO. Di conseguenza, per la risoluzione dei problemi relativi alla delega, verificare l'impostazione e l'appartenenza al gruppo.
Controllare i tentativi di autenticazione
Per controllare in modo esplicito i tentativi di autenticazione per i membri del utenti protetti gruppo, è possibile continuare a raccogliere eventi di controllo del Registro di protezione o raccogliere i dati nei nuovi registri amministrativi. Per ulteriori informazioni su questi eventi, vedere criteri di autenticazione e silo di criteri di autenticazione
Fornire protezioni sul lato controller di dominio per servizi e computer
Account per servizi e i computer non possono essere membri di utenti protetti. In questa sezione vengono illustrate le protezioni sul lato controller di dominio disponibili per questi account:
Rifiutare l'autenticazione NTLM: configurabile solo tramite criteri di blocco NTLM
Rifiutare Data Encryption Standard (DES) nella preautenticazione Kerberos: il controller di dominio di Windows Server 2012 R2 non accettano la crittografia DES per gli account computer a meno che non sono configurati per DES solo perché ogni versione di Windows rilasciata con Kerberos supporta anche RC4.
Rifiutare la crittografia RC4 nella preautenticazione Kerberos: non configurabile.
Nota
Sebbene sia possibile modificare la configurazione dei tipi di crittografia supportati, non è consigliabile modificare tali impostazioni per gli account computer senza eseguire il test nell'ambiente di destinazione.
Limitare i ticket utente (TGT) per una durata iniziale di 4 ore: usare i criteri di autenticazione.
Negare la delega vincolata o non vincolata: per limitare un account, aprire Active Directory amministrativi CENTRO e selezionare il Account è sensibile e non può essere delegato casella di controllo.
Criteri di autenticazione
Criteri di autenticazione è un nuovo contenitore in Servizi di dominio Active Directory che contiene gli oggetti Criteri di autenticazione. I criteri di autenticazione consentono di specificare impostazioni che permettono di attenuare l'esposizione al furto di credenziali, ad esempio la limitazione della durata del ticket di concessione ticket (TGT) per gli account o l'aggiunta di altre condizioni basate su attestazioni.
In Windows Server 2012, controllo dinamico degli accessi ha introdotto una classe di oggetto di ambito della foresta di Active Directory denominata criteri di accesso centrale per fornire un modo semplice per configurare file server all'interno dell'organizzazione. In Windows Server 2012 R2, una nuova classe di oggetti denominata criteri di autenticazione (objectClass msDS-AuthNPolicies) può essere utilizzata per applicare la configurazione dell'autenticazione alle classi di account in domini di Windows Server 2012 R2. Di seguito sono riportate le classi di account Active Directory:
Utente
Computer
Account del servizio gestito e Account del servizio gestito di gruppo
Aggiornamento rapido Kerberos
Il protocollo di autenticazione Kerberos è costituito da tre tipi di scambi, noti anche come protocolli secondari:
Scambio del Servizio di autenticazione (AS) (KRB_AS_*)
Scambio del Servizio di concessione ticket (TGS) (KRB_TGS_*)
Scambio client/server (AP) (KRB_AP_*)
Lo scambio AS è in cui il client utilizza la password dell'account o la chiave privata per creare un preautenticatore e richiedere un ticket di concessione ticket (TGT). Questo avviene all'accesso dell'utente o la prima volta che è necessario un ticket di servizio.
Lo scambio TGS è dove TGT dell'account viene utilizzato per creare un autenticatore e richiedere un ticket di servizio. Questo avviene quando è necessaria una connessione autenticata.
Lo scambio client/server avviene normalmente nei dati all'interno del protocollo dell'applicazione e non è interessato dai criteri di autenticazione.
Per ulteriori informazioni, vedere Kerberos versione 5 autenticazione protocollo funzionamento del.
Panoramica
I criteri di autenticazione integrano il gruppo Utenti protetti, offrendo un modo per applicare restrizioni configurabili agli account, oltre a offrire restrizioni per gli account per servizi e computer. I criteri di autenticazione sono applicati durante lo scambio Kerberos AS o TGS.
È possibile limitare l'autenticazione iniziale o lo scambio AS configurando gli elementi seguenti:
Durata TGT
Condizioni del controllo di accesso per limitare l'accesso utente, che devono essere soddisfatte dai dispositivi dai quali proviene lo scambio AS
È possibile limitare le richieste di ticket di servizio tramite uno scambio del servizio di concessione ticket (TGS) configurando gli elementi seguenti:
- Condizioni del controllo di accesso che devono essere soddisfatte dal client (utente, servizio, computer) o dispositivo da cui proviene lo scambio del servizio di concessione ticket (TGS)
Requisiti per l'uso dei criteri di autenticazione
| Criteri | Requisiti |
|---|---|
| Specifica durate TGT personalizzate | Domini di account con livello funzionale di dominio Windows Server 2012 R2 |
| Limita l'accesso utente | -Domini di account con livello funzionale di dominio Windows Server 2012 R2 con il supporto di controllo dinamico degli accessi -Supportano Windows 8, Windows 8.1, Windows Server 2012 o Windows Server 2012 R2 dispositivi con controllo dinamico degli accessi |
| Limita il rilascio di ticket di servizio basati su account utente e gruppi di sicurezza | Domini di risorse a livello funzionale di dominio Windows Server 2012 R2 |
| Limita il rilascio di ticket di servizio basati su attestazioni utente o account del dispositivo, gruppi di sicurezza o attestazioni | Domini di risorse a livello funzionale di dominio di Windows Server 2012 R2 con il supporto di controllo dinamico degli accessi |
Limitare un account utente a dispositivi e host specifici
Un valore elevato di account con privilegi amministrativi deve essere un membro del utenti protetti gruppo. Per impostazione predefinita, nessun account è membro del utenti protetti gruppo. Prima di aggiungere account al gruppo, configurare il supporto per il controller di dominio e creare un criterio di controllo per verificare che non vi siano problemi di blocco.
Configurare il supporto per il controller di dominio
Il dominio dell'account utente deve essere a livello funzionale di dominio Windows Server 2012 R2 (Livello). Verificare che tutti i controller di dominio siano Windows Server 2012 R2 e quindi utilizzano Active Directory Domains and Trusts per aumentare il livello di funzionalità DEL a Windows Server 2012 R2.
Per configurare il supporto per il controllo dinamico degli accessi
Nel criterio controller di dominio predefinito, fare clic su Enabled per abilitare supporto client Centro distribuzione chiavi (KDC) di attestazioni, autenticazione composta e blindatura Kerberos in configurazione Computer | Modelli amministrativi | Sistema | KDC.
In Opzioni, nella casella di riepilogo a discesa, selezionare Fornisci sempre attestazioni.
Nota
Supportato può anche essere configurato, ma poiché il dominio è Windows Server 2012 R2 DFL, con i controller di dominio sempre fornire attestazioni consentirà l'accesso basato sulle attestazioni utente si verificano quando si utilizzano dispositivi grado di riconoscere attestazioni non controlla e dagli host per connettersi ai servizi in grado di riconoscere attestazioni.
Avviso
Configurazione Rifiuta richieste di autenticazione non blindate genererà errori di autenticazione da qualsiasi sistema operativo che non supporta la blindatura Kerberos, ad esempio Windows 7 e sistemi operativi precedenti, o sistemi operativi a partire da Windows 8, che non sono stati configurati in modo esplicito per supportarla.
Creare un controllo dell'account utente per il criterio di autenticazione tramite il Centro di amministrazione di Active Directory
Aprire il Centro di amministrazione di Active Directory.
Nota
Selezionato autenticazione nodo è visibile per i domini sono funzionalità del Dominio di Windows Server 2012 R2. Se non viene visualizzato il nodo, quindi riprovare utilizzando un account di amministratore di dominio da un dominio al Dominio di Windows Server 2012 R2.
Fare clic su criteri di autenticazione, quindi fare clic su New per creare un nuovo criterio.
I criteri di autenticazione devono avere un nome visualizzato e vengono imposti per impostazione predefinita.
Per creare un criterio di solo controllo, fare clic su solo restrizioni dei criteri di controllo.
I criteri di autenticazione vengono applicati in base al tipo di account di Active Directory. Per applicare un singolo criterio a tutti e tre i tipi di account, configurare le impostazioni per ogni tipo. I tipi di account sono:
Utente
Computer
Account del servizio gestito e Account del servizio gestito di gruppo
Se lo schema è stato esteso con nuove entità che possono essere usate dal Centro distribuzione chiavi (KDC), il nuovo tipo di account sarà classificato come il tipo di account derivato più vicino.
Per configurare una durata TGT per gli account utente, selezionare il specificare una durata Ticket di concessione Ticket per gli account utente casella di controllo e immettere il tempo in minuti.
Ad esempio, se si desidera una durata TGT massima di 10 ore, immettere 600 come illustrato. Se non è configurata alcuna durata TGT, quindi se l'account è un membro del utenti protetti gruppo, la durata TGT e rinnovo è 4 ore. In caso contrario, la durata e il rinnovo del ticket di concessione ticket (TGT) sono impostati in base ai criteri di dominio, come illustrato nella finestra dell'Editor Gestione Criteri di gruppo seguente per un dominio con impostazioni predefinite.
Per limitare l'account utente per selezionare i dispositivi, fare clic su modificare per definire le condizioni necessarie per il dispositivo.
Nel modificare condizioni di controllo di accesso finestra, fare clic su aggiungere una condizione.
Aggiungere condizioni per account computer o gruppi
Per configurare gli account computer o gruppi, nell'elenco a discesa, selezionare la casella di riepilogo membro di ogni e modificare membro di qualsiasi.
Nota
Questo controllo di accesso definisce le condizioni del dispositivo o dell'host dal quale l'utente esegue l'accesso. Nella terminologia di controllo di accesso, l'account computer per il dispositivo o un host è l'utente, il motivo per cui utente è l'unica opzione.
Fare clic su aggiungere elementi.
Per modificare i tipi di oggetto, fare clic su tipi di oggetto.
Per selezionare gli oggetti computer in Active Directory, fare clic su computer, quindi fare clic su OK.
Digitare il nome del computer per limitare l'utente e quindi fare clic su Controlla nomi.
Fare clic su OK ed eventualmente creare altre condizioni per l'account computer.
Al termine, quindi fare clic su OK e verranno visualizzate le condizioni definite per l'account computer.
Aggiungere condizioni per le attestazioni computer
Per configurare le attestazioni computer, fare clic sull'elenco a discesa Gruppo per selezionare l'attestazione.
Le attestazioni sono disponibili solo se ne è già stato effettuato il provisioning nella foresta.
Digitare il nome di unità organizzativa. L'account utente dovrebbe avere l'accesso limitato.
Al termine, fare clic su OK per visualizzare le condizioni definite nella casella.
Risolvere i problemi relativi ad attestazioni computer mancanti
Se l'attestazione è stato eseguito il provisioning, ma non è disponibile, e può essere configurata solo per Computer classi.
Si supponga che si desidera limitare l'autenticazione basata sull'unità organizzativa (OU) del computer, che era già configurato, ma solo per Computer classi.
Per l'attestazione sia disponibile per limitare l'accesso utente al dispositivo, selezionare il utente casella di controllo.
Eseguire il provisioning di un account utente con un criterio di autenticazione tramite il Centro di amministrazione di Active Directory
Dal utente account, fare clic su criteri.
Selezionare il assegnare un criterio di autenticazione a questo account casella di controllo.
Selezionare quindi il criterio di autenticazione da applicare all'utente.
Configurare il supporto per il controllo dinamico degli accessi su dispositivi e host
È possibile configurare durate del ticket di concessione ticket (TGT) senza configurare il controllo dinamico degli accessi. Il controllo dinamico degli accessi è necessario solo per il controllo di llowedToAuthenticateFrom e AllowedToAuthenticateTo.
Utilizzando criteri di gruppo o Editor criteri di gruppo, abilitare supporto client Kerberos per attestazioni, autenticazione composta e blindatura Kerberos in configurazione Computer | Modelli amministrativi | Sistema | Kerberos:
Risolvere i problemi relativi ai criteri di autenticazione
Individuare gli account a cui è assegnato direttamente un criterio di autenticazione
Nella sezione Account in Criterio di autenticazione sono visualizzati gli account è cui è stato direttamente assegnato il criterio.
Utilizzare gli errori dei criteri di autenticazione - registro amministrativo di Controller di dominio
Un nuovo Authentication Policy Failures - Controller di dominio registro amministrativo in registri applicazioni e servizi>Microsoft>Windows>autenticazione è stata creata per semplificare l'individuazione degli errori a causa dei criteri di autenticazione. Questo registro è disabilitato per impostazione predefinita. Per abilitarlo, fare doppio clic il nome del log e fare clic su Attiva registro. I nuovi eventi presentano un contenuto molto simile a quello degli eventi di controllo del ticket di servizio e del ticket di concessione ticket (TGT) di Kerberos esistenti. Per ulteriori informazioni su questi eventi, vedere criteri di autenticazione e silo di criteri di autenticazione.
Gestire i criteri di autenticazione con Windows PowerShell
Questo comando crea un criterio di autenticazione denominato TestAuthenticationPolicy. Il UserAllowedToAuthenticateFrom parametro specifica i dispositivi da cui gli utenti possono autenticarsi tramite una stringa SDDL nel file denominato Somefile.
PS C:\> New-ADAuthenticationPolicy testAuthenticationPolicy -UserAllowedToAuthenticateFrom (Get-Acl .\someFile.txt).sddl
Questo comando Ottiene tutti i criteri di autenticazione che corrispondono al filtro che il filtro parametro specifica.
PS C:\> Get-ADAuthenticationPolicy -Filter "Name -like 'testADAuthenticationPolicy*'" -Server Server02.Contoso.com
Questo comando modifica la descrizione e il UserTGTLifetimeMins le proprietà dei criteri di autenticazione specificato.
PS C:\> Set-ADAuthenticationPolicy -Identity ADAuthenticationPolicy1 -Description "Description" -UserTGTLifetimeMins 45
Questo comando rimuove i criteri di autenticazione che il identità parametro specifica.
PS C:\> Remove-ADAuthenticationPolicy -Identity ADAuthenticationPolicy1
Questo comando Usa il Get-ADAuthenticationPolicy cmdlet con il filtro per ottenere tutti i criteri di autenticazione che non vengono applicati. Il set di risultati viene reindirizzato al Remove-ADAuthenticationPolicy cmdlet.
PS C:\> Get-ADAuthenticationPolicy -Filter 'Enforce -eq $false' | Remove-ADAuthenticationPolicy
Silo di criteri di autenticazione
Silo di criteri di autenticazione è un nuovo contenitore (objectClass msDS-AuthNPolicySilos) in Servizi di dominio Active Directory per gli account utente, computer e del servizio. I silo consentono di proteggere gli account a valore elevato. Tutte le organizzazioni proteggono i membri dei gruppi Enterprise Admins, Domain Admins e Schema Admins in quanto questi account potrebbero essere usati dagli autori di attacchi per accedere a tutti gli elementi nella foresta, ma anche altri account potrebbero richiedere una protezione.
Alcune organizzazioni isolano i carichi di lavoro creando account univoci dedicati e applicando le impostazioni di Criteri di gruppo per liminare l'accesso interattivo locale e remoto e i privilegi amministrativi. In questo scenario, i silo di criteri di autenticazione consentono di definire una relazione tra gli account utente, computer e del servizio gestito. Gli account possono appartenere a un solo silo. È possibile configurare criteri di autenticazione per ogni tipo di account per controllare:
Durata TGT non rinnovabile
Condizioni di controllo di accesso per la restituzione del ticket di concessione ticket (TGT). Nota: non si applica ai sistemi perché è richiesta la blindatura Kerberos.
Condizioni di controllo di accesso per la restituzione del ticket di servizio
Inoltre, gli account in un silo di criteri di autenticazione hanno un'attestazione silo che può essere usata da risorse in grado di riconoscere le attestazioni, quali i file server, per controllare gli accessi.
È possibile configurare un nuovo descrittore di sicurezza per controllare il ticket di servizio emittente in base a:
Utente, gruppi di sicurezza dell'utente e/o le attestazioni utente
Dispositivo, il gruppo di sicurezza del dispositivo e/o attestazioni del dispositivo
Queste informazioni ai controller di dominio della risorsa richiede controllo dinamico degli accessi:
Attestazioni utente:
Client Windows 8 e versioni successive con il supporto di Controllo dinamico degli accessi
Il dominio dell'account supporta Controllo dinamico degli accessi e attestazioni
Dispositivo e/o gruppo di sicurezza del dispositivo
Client Windows 8 e versioni successive con il supporto di Controllo dinamico degli accessi
Risorsa configurata per l'autenticazione composta
Attestazioni dispositivo:
Client Windows 8 e versioni successive con il supporto di Controllo dinamico degli accessi
Il dominio del dispositivo supporta Controllo dinamico degli accessi e attestazioni
Risorsa configurata per l'autenticazione composta
È possibile applicare i criteri di autenticazione a tutti i membri di un silo di criteri di autenticazione anziché ad account singoli o applicare criteri di autenticazione separati a diversi tipi di account all'interno di un silo. Ad esempio, è possibile applicare un criterio di autenticazione ad account utente con privilegi elevati e un altro agli account del servizio. È necessario creare almeno un criterio di autenticazione prima di poter creare un silo di criteri di autenticazione.
Nota
È possibile applicare un criterio di autenticazione ai membri di un silo di criteri di autenticazione oppure applicarlo indipendentemente dai silo per limitare l'ambito dell'account specifico. Ad esempio, per proteggere un singolo account o un piccolo set di account, è possibile impostare un criterio senza dover aggiungere gli account a un silo.
È possibile creare un silo di criteri di autenticazione utilizzando il centro di amministrazione di Active Directory o Windows PowerShell. Per impostazione predefinita, un silo di criteri di autenticazione controlla solo i criteri del sito, che equivale a specificare il WhatIf parametro nel cmdlet di Windows PowerShell. In questo caso, le restrizioni al silo di criteri non si applicano ma vengono generati i controlli per indicare se si verificano errori in caso di applicazione delle restrizioni.
Per creare un silo di criteri di autenticazione con il Centro di amministrazione di Active Directory
Aprire Centro di amministrazione di Active Directory, fare clic su autenticazione, fare doppio clic su silo di criteri di autenticazione, fare clic su nuovo, quindi fare clic su Silo di criteri di autenticazione.
In nome, digitare un nome per il silo. In account consentiti, fare clic su Aggiungi, digitare i nomi degli account e quindi fare clic su OK. È possibile specificare account utente, computer o del servizio. Specificare quindi se usare un singolo criterio per tutte le entità o un criterio separato per ogni tipo di entità e il nome del criterio o dei criteri.
Gestire i silo di criteri di autenticazione con Windows PowerShell
Questo comando crea un oggetto silo di criterio di autenticazione e lo impone.
PS C:\>New-ADAuthenticationPolicySilo -Name newSilo -Enforce
Questo comando Ottiene tutte le autenticazioni di silo di criteri che corrispondono al filtro specificato dal filtro parametro. L'output viene quindi passato per il Format-Table cmdlet per visualizzare il nome dei criteri di e il valore per Imponi in ogni criterio.
PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Name -like "*silo*"' | Format-Table Name, Enforce -AutoSize
Name Enforce
---- -------
silo True
silos False
Questo comando Usa il Get-ADAuthenticationPolicySilo cmdlet con il filtro per ottenere il risultato del filtro di silo di criteri di autenticazione che non vengono applicati le pipe di Remove-ADAuthenticationPolicySilo cmdlet.
PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Enforce -eq $False' | Remove-ADAuthenticationPolicySilo
Questo comando concede l'accesso al silo di criteri di autenticazione denominato Silo per l'account utente denominato User01.
PS C:\>Grant-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01
Questo comando revoca l'accesso al silo di criteri di autenticazione denominato Silo per l'account utente denominato User01. Poiché il conferma parametro è impostato su $False, viene visualizzato alcun messaggio di conferma.
PS C:\>Revoke-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01 -Confirm:$False
In questo esempio utilizza in primo luogo il Get-ADComputer per ottenere tutti gli account di computer che corrispondono al filtro che il filtro parametro specifica. L'output di questo comando viene passato a Set-ADAccountAuthenticatinPolicySilo per assegnare il silo di criteri di autenticazione denominato Silo e i criteri di autenticazione denominato AuthenticationPolicy02 ad essi.
PS C:\>Get-ADComputer -Filter 'Name -like "newComputer*"' | Set-ADAccountAuthenticationPolicySilo -AuthenticationPolicySilo Silo -AuthenticationPolicy AuthenticationPolicy02
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per