Linee guida su come configurare gli account protetti

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:

• Utenti protetti

• Criteri di autenticazione

• Silo di criteri di autenticazione

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:

• Modalità di amministrazione limitata per Desktop remoto

• Protezione LSA

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.

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).

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

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

1. 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.

   

2. 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

1. 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.

2. 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.

3. 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.

4. 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.

   

5. Per limitare l'account utente per selezionare i dispositivi, fare clic su modificare per definire le condizioni necessarie per il dispositivo.

   

6. Nel modificare condizioni di controllo di accesso finestra, fare clic su aggiungere una condizione.

   

Aggiungere condizioni per account computer o gruppi

1. 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.

2. Fare clic su aggiungere elementi.

   

3. Per modificare i tipi di oggetto, fare clic su tipi di oggetto.

   

4. Per selezionare gli oggetti computer in Active Directory, fare clic su computer, quindi fare clic su OK.

   

5. Digitare il nome del computer per limitare l'utente e quindi fare clic su Controlla nomi.

   

6. Fare clic su OK ed eventualmente creare altre condizioni per l'account computer.

   

7. Al termine, quindi fare clic su OK e verranno visualizzate le condizioni definite per l'account computer.

   

Aggiungere condizioni per le attestazioni computer

1. 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.

2. Digitare il nome di unità organizzativa. L'account utente dovrebbe avere l'accesso limitato.

   

3. 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

1. Dal utente account, fare clic su criteri.

   

2. Selezionare il assegnare un criterio di autenticazione a questo account casella di controllo.

   

3. 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:

1. Durata TGT non rinnovabile

2. 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.

3. 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.

È 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

1. 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.

   

2. 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-ADAccountAuthenticationPolicySilo per assegnare il silo dei criteri di autenticazione denominato Silo e i criteri di autenticazione denominati AuthenticationPolicy02 ad essi.

PS C:\>Get-ADComputer -Filter 'Name -like "newComputer*"' | Set-ADAccountAuthenticationPolicySilo -AuthenticationPolicySilo Silo -AuthenticationPolicy AuthenticationPolicy02