Diretrizes sobre como configurar contas protegidas

Com ataques PtH (passagem de hash), um invasor pode autenticar em um servidor ou serviço remoto usando um hash de NTLM subjacente da senha de um usuário (ou outros derivados de credenciais). A Microsoft publicou anteriormente diretrizes para mitigar ataques de passagem de hash. O Windows Server 2012 R2 inclui novos recursos para ajudar a reduzir ainda mais ataques como esse. Para obter mais informações sobre outros recursos de segurança que ajudam a proteger contra roubo de credenciais, consulte Proteção e gerenciamento de credenciais. Este artigo explica como configurar os seguintes recursos novos:

• Usuários protegidos

• Políticas de autenticação

• Silos de política de autenticação

Existem medidas para ajudar a evitar o roubo de credenciais adicionais integradas ao Windows 8.1 e Windows Server 2012 R2, abordadas nos seguintes artigos:

• Modo Administração Restrita para Área de Trabalho Remota

• Proteção LSA

Usuários protegidos

Usuários protegidos é um novo grupo de segurança global ao qual é possível adicionar usuários novos ou existentes. Dispositivos do Windows 8.1 e hosts do Windows Server 2012 R2 têm um comportamento especial com membros deste grupo a fim de oferecer melhor proteção contra roubo de credenciais. Para um membro deste grupo, um dispositivo do Windows 8.1 ou host do Windows Server 2012 R2 não armazena em cache as credenciais sem suporte para usuários protegidos. Os membros deste grupo não terão proteção adicional se estiverem conectados em um dispositivo que executa uma versão do Windows anterior ao Windows 8.1.

Os membros do grupo Usuários Protegidos que estão conectados a dispositivos Windows 8.1 e hosts do Windows Server 2012 R2 não podem mais usar:

• Delegação de credencial padrão (CredSSP) - credenciais em texto simples não são armazenadas em cache mesmo se a política Permitir credenciais de delegação padrão for habilitada

• Windows Digest - credenciais em texto simples não serão armazenadas em cache mesmo se habilitadas

• NTLM - NTOWF não é armazenado em cache

• Chaves de Kerberos a longo prazo - o TGT de Kerberos é adquirido no logon e não pode ser readquirido automaticamente

• Entrar offline - o verificador de logon armazenado em cache não é criado

Se o nível funcional do domínio for Windows Server 2012 R2, os membros do grupo não poderão mais:

• Autenticar usando autenticação NTLM

• Usar suites de criptografia DES (padrão de criptografia de dados) ou RC4 na pré-autenticação do Kerberos

• Ser delegado com delegação restrita ou irrestrita

• Renovar tíquetes de usuário (TGTs) além do tempo de vida inicial de quatro horas

Para adicionar usuários ao grupo, você pode usar ferramentas de interface do usuário, como o ADAC (Active Directory Administrative Center) ou usuários e computadores do Active Directory, ou uma ferramenta de linha de comando, como o grupo Dsmod ou o cmdletAdd-ADGroupMember do Windows PowerShell. Contas de serviços e computadores não devem ser membros do grupo Usuários Protegidos. A associação a essas contas não oferece proteções locais, pois a senha ou certificado sempre está disponível no host.

Os membros do grupo Usuários Protegidos devem poder se autenticar usando Kerberos com AES. Este método pede chaves AES para a conta do Active Directory. O Administrador interno não tem uma chave AES a menos que a senha tenha sido alterada em um controlador de domínio que executa o Windows Server 2008 ou posterior. Além disso, qualquer conta que tenha uma senha que foi alterada em um controlador de domínio que executa uma versão anterior do Windows Server será bloqueada. Portanto, siga estas melhores práticas:

• Não teste em domínios a menos que todos os controladores de domínio executem o Windows Server 2008 ou posterior.

• Altere a senha para todas as contas de domínio que foram criadas antes da criação do domínio. Senão, essas contas não poderão ser autenticadas.

• Altere a senha de cada usuário antes de adicionar a conta ao grupo Usuários Protegidos ou verifique se a senha foi alterada recentemente em um controlador de domínio que executa o Windows Server 2008 ou posterior.

Requisitos para usar contas protegidas

Contas protegidas possuem os seguintes requisitos para implantação:

• Para fornecer restrições a Usuários protegidos no lado do cliente, os hosts devem executar o Windows 8.1 ou o Windows Server 2012 R2. Um usuário precisa apenas entrar com uma conta membro do grupo Usuários protegidos. Nesse caso, o grupo Usuários Protegidos pode ser criado pela transferência da função de emulador do PDC (controlador de domínio primário) para um controlador de domínio que executa o Windows Server 2012 R2. Depois de o objeto do grupo ser replicado para outros controladores de domínio, a função do emulador de PDC pode se hospedada em um controlador de domínio que executa uma versão anterior do Windows Server.

• Para fornecer restrições aos Usuários Protegidos no lado do controlador de domínio, ou seja, restringir o uso de autenticação NTLM e demais restrições, o nível funcional do domínio deve ser Windows Server 2012 R2. Para mais informações sobre níveis funcionais, confira Reconhecer os níveis funcionais do AD DS (Active Directory Domain Services).

Solução de problemas de eventos relacionados a Usuários protegidos

Esta seção aborda os novos logs para ajudar solucionar problemas de eventos relacionados aos Usuários protegidos e demonstra como os Usuários protegidos podem representar mudanças nas soluções de problemas de expiração de TGT e de delegação.

Novos logs para Usuários protegidos

Dois novos logs administrativos operacionais estão disponíveis para ajudar a solucionar problemas de eventos relacionados a Usuários Protegidos: Usuário Protegido – Log do cliente e falhas de usuário protegido – Log do controlador de domínio. Esses novos logs encontram-se no Visualizador de Eventos e estão desabilitados por padrão. Para habilitar um log, clique em Logs de aplicativos e serviços, depois em Microsoft, Windows, Autenticação, clique no nome do log e em Ação (ou então, clique com o botão direito no log) e clique em Habilitar log.

Para saber mais sobre eventos nesses logs, consulte Políticas de autenticação e Silos de políticas de autenticação.

Solução de problemas de expiração de TGT

Normalmente, o controlador de domínio define o tempo de vida de TGT e sua renovação com base na política de domínio, conforme mostrado na janela Editor de Gerenciamento de Política de Grupo a seguir.

Para usuários protegidos, as seguintes configurações são codificadas em código:

• Tempo de vida máximo por tíquete de usuário: 240 minutos

• Renovação do tempo de vida máximo por tíquete de usuário: 240 minutos

Solução de problemas de delegação

Anteriormente, se uma tecnologia que usa delegação de Kerberos falhasse, a conta cliente era verificada para ver se Conta sensível à segurança, não pode ser delegada estava definido. No entanto, se a conta for um membro de Usuários Protegidos, talvez ela não tenha essa configuração configurada no ADAC (Centro Administrativo do Active Directory). Por isso, verifique as definições de associações de grupo ao solucionar problemas de delegação.

Auditar tentativas de autenticação

Para auditar as tentativas de autenticação explicitamente para os membros do grupo Usuários Protegidos , você pode continuar coletando eventos de auditoria de log de segurança ou coletando os dados nos novos logs administrativos operacionais. Para saber mais sobre esses eventos, consulte Políticas de autenticação e Silos de políticas de autenticação

Fornecer proteções do lado do controlador de domínio a serviços e computadores

Contas de serviços e computadores não podem ser membros de Usuários Protegidos. Esta seção explica quais proteções baseadas no controlador de domínio podem ser oferecidas a tais contas:

• Rejeitar autenticação NTLM: configurável somente por meio de políticas de bloco de NTLM

• Rejeitar DES (padrão de criptografia de dados) na pré-autenticação do Kerberos: os controladores de domínio do Windows Server 2012 R2 não aceitam DES para contas de computador exceto se forem configuradas somente para DES, pois todas as versões do Windows lançadas com o Kerberos também dão suporte a RC4.

• Rejeitar RC4 na pré-autenticação do Kerberos: não configurável.

  Note

  Embora seja possível alterar a configuração dos tipos de criptografia com suporte, não é recomendável alterar essas configurações em contas de computador sem antes testar no ambiente de destino.

• Restringir tíquetes de usuário (TGTs) a um tempo de vida inicial de quatro horas: use as políticas de autenticação.

• Negar delegação com delegação restrita ou irrestrita: para restringir uma conta, abra o ADAC (Centro Administrativo do Active Directory) e marque a caixa de seleção Conta é confidencial e não pode ser delegada.

  

Políticas de autenticação

Políticas de autenticação é um novo contêiner no AD DS que contém objetos de política de autenticação. As políticas de autenticação podem especificar configurações que ajudam a reduzir o risco de roubo de credenciais, tais como restringir o tempo de vida de TGT das contas ou adicionar outras condições relacionadas a declarações.

No Windows Server 2012, o Controle de Acesso Dinâmico introduziu a classe de objeto de escopo de floresta do Active Directory chamado Política de Acesso Central para configurar servidores de arquivo em toda a organização. No Windows Server 2012 R2, uma nova classe de objeto chamada Política de Autenticação (objectClass msDS-AuthNPolicies) pode ser usada para aplicar a configuração de autenticação a classes de conta nos domínios do Windows Server 2012 R2. As classes da conta do Active Directory são:

• User

• Computer

• Conta de serviço gerenciado e Conta de serviço gerenciado de grupo (GMSA)

Atualizador rápido do Kerberos

O protocolo de autenticação Kerberos consiste em três tipos de trocas, também conhecidas como subprotocolos:

• A troca de serviço de autenticação (AS) (KRB_AS_*)

• A troca de Serviço de concessão de tíquete (TGS) (KRB_TGS_*)

• A troca entre Cliente/servidor (AP) (KRB_AP_*)

A troca de AS é quando o cliente usa a senha ou a chave privada da conta para criar um pré-autenticador para solicitar um TGT (tíquete de concessão de tíquete). Isso ocorre no momento da entrada do usuário ou na primeira vez que um tíquete de serviço é necessário.

A troca de TGS é quando o TGT da conta é usado para criar um autenticador para solicitar um tíquete de serviço. Isso ocorre quando uma conexão autenticada é necessária.

A troca AP ocorre geralmente como dados dentro do protocolo do aplicativo e não é afetada pelas políticas de autenticação.

Para obter informações mais detalhadas, confira Como funciona o protocolo de autenticação Kerberos versão 5.

Overview

As políticas de autenticação complementam o grupo Usuários Protegidos ao oferecer uma maneira de aplicar restrições configuráveis a contas, além de fornecer restrições a contas para serviços e computadores. As políticas de autenticação são impostas durante as trocas AS ou TGS.

Você pode restringir a autenticação inicial ou a troca AS configurando:

• Um tempo de vida de TGT

• As condições de controle de acesso para restringir a entrada do usuário, devendo ser cumpridas pelos dispositivos que enviam a troca AS

Você pode restringir as solicitações de tíquete de serviço por meio da troca TGS configurando:

• As condições de controle de acesso que devem ser cumpridas pelo cliente (usuário, serviço ou computador) ou dispositivo que enviam a troca TGS

Requisitos para usar políticas de autenticação

Restringir uma conta de usuário a dispositivos e hosts específicos

Uma conta de alto valor com privilégio administrativo deve ser membro do grupo Usuários Protegidos . Por padrão, nenhuma conta é membro do grupo Usuários Protegidos . Antes de adicionar contas ao grupo, configure o suporte ao controlador de domínio e crie uma política de auditoria para garantir que não haja problemas de bloqueio.

Configurar suporte ao controlador de domínio

O domínio de contas do usuário deve estar no DFL (nível funcional do domínio) do Windows Server 2012 R2. Verifique se todos os controladores de domínio são do Windows Server 2012 R2 e, em seguida, use Domínios e Relações de confiança do Active Directory para elevar o DFL para o Windows Server 2012 R2.

Para configurar o suporte ao Controle de Acesso Dinâmico

1. Na Política de Controladores de Domínio Padrão, clique em Habilitado para habilitar o suporte ao cliente do Centro de Distribuição de Chaves (KDC) para declarações, autenticação composta e blindagem Kerberos na Configuração do Computador | Modelos Administrativos | Sistema | KDC.

   

2. Em Opções, na caixa de listagem suspensa, selecione Sempre fornecer declarações.

   Note

   O suporte também pode ser configurado, mas como o domínio está no Windows Server 2012 R2 DFL, fazer com que os DCs sempre forneçam declarações permite que verificações de acesso baseadas em declarações do usuário ocorram ao usar dispositivos e hosts sem reconhecimento de declarações para se conectarem a serviços com reconhecimento de declarações.

   

   Warning

   A configuração de solicitações de autenticação não demoradas resulta em falhas de autenticação de qualquer sistema operacional que não dê suporte ao blindamento Kerberos, como o Windows 7 e sistemas operacionais anteriores, ou sistemas operacionais que começam com o Windows 8, que não foram explicitamente configurados para dar suporte a ele.

Criar uma auditoria de conta de usuário para política de autenticação com o ADAC

1. Abra o ADAC (Centro Administrativo do Active Directory).

   

   Note

   O nó de Autenticação selecionado é visível para domínios que estão na DFL do Windows Server 2012 R2. Se o nó não for exibido, tente novamente usando uma conta de administrador do domínio de um domínio que esteja no DFL do Windows Server 2012 R2.

2. Clique em Políticas de Autenticação e clique em Novo para criar uma nova política.

   

   As políticas de autenticação devem possuir um nome de exibição e são impostas por padrão.

3. Para criar uma política somente para auditoria, clique em Somente restrições de política de auditoria.

   

   As políticas de autenticação são aplicadas com base no tipo de conta do Active Directory. Uma única política pode ser aplicada a todos os três tipos de conta ao configurar as definições de cada tipo. Os tipos de conta são:

   • User

   • Computer

   • Conta de serviço gerenciado e conta de serviço gerenciado de grupo

   Se você estender o esquema com as novas entidades que podem ser usadas pelo KDC, o novo tipo de conta será classificado de acordo com o tipo de conta derivada mais próximo.

4. Para configurar um tempo de vida do TGT nas contas de usuário, selecione a caixa de seleção Especificar um tempo de vida do Tíquete de Concessão de Tíquete das contas de usuário e insira a hora em minutos.

   

   Por exemplo, se você quiser um tempo de vida máximo de TGT de 10 horas, insira 600 , conforme mostrado. Se nenhum tempo de vida TGT estiver configurado, se a conta for membro do grupo Usuários Protegidos , o tempo de vida e a renovação do TGT serão de 4 horas. Senão, o tempo de vida de TGT e sua renovação baseiam-se na política do domínio como indicado na janela Editor de Gerenciamento de Política de Grupo para o domínio com configurações padrão.

   

5. Para restringir a conta de usuário a dispositivos selecionados, clique em Editar para definir as condições necessárias para o dispositivo.

   

6. Na janela Editar Condições de Controle de Acesso e clique em Adicionar uma condição.

   

Adicionar conta de computador ou condições de grupo

1. Para configurar contas de computador ou grupos na lista suspensa, selecione a caixa de listagem suspensa Membro de cada uma e mude para Membro de qualquer uma.

   

   Note

   Este controle de acesso define as condições do dispositivo ou host do qual o usuário entra. Na terminologia do controle de acesso, a conta do computador para o dispositivo ou host é o usuário, razão pela qual o Usuário é a única opção.

2. Clique em Adicionar itens.

   

3. Para alterar os tipos de objeto, clique em Tipos de Objeto.

   

4. Para selecionar objetos de computador no Active Directory, clique em Computadores e clique em OK.

   

5. Digite o nome dos computadores para restringir o usuário e clique em Verificar Nomes.

   

6. Clique em OK e crie quaisquer outras condições desejadas para a conta de computador.

   

7. Quando terminar, clique em OK e as condições definidas aparecem para a conta do computador.

   

Adicionar condições de declaração de computador

1. Para configurar declarações de computador, vá para a lista suspensa Grupo para escolher a declaração.

   

   As declarações somente estarão disponíveis se já tiverem sido provisionadas na floresta.

2. Digite o nome do OU e a conta de usuário deverá ser restrita ao tentar entrar.

   

3. Ao concluir, clique em OK e a caixa mostra as condições definidas.

   

Solução de problemas de declarações de computador faltantes

Se a declaração tiver sido provisionada, mas não estiver disponível, ela poderá ser configurada apenas para classes de computador .

Digamos que você queria restringir a autenticação com base na UO (unidade organizacional) do computador, que já estava configurada, mas apenas para classes de computador .

Para que a declaração esteja disponível para restringir o logon do usuário ao dispositivo, marque a caixa de seleção Usuário .

Provisione uma conta de usuário com uma política de autenticação com o ADAC

1. Na conta de usuário , clique em Política.

   

2. Selecione a caixa de seleção Atribuir uma política de autenticação a esta conta.

   

3. Em seguida, escolha a política de autenticação a ser aplicada ao usuário.

   

Configurar suporte a Controle de Acesso Dinâmico em dispositivos e hosts

Você pode configurar os tempos d vida de TGT sem configurar o DAC (Controle de Acesso Dinâmico). O DAC somente é necessário para verificar AllowedToAuthenticateFrom e AllowedToAuthenticateTo.

Usando o Editor de Política de Grupo ou de Política de Grupo Local, habilite o Suporte a cliente Kerberos para declarações, autenticação composta e proteção do Kerberos em Configuração do Computador | Modelos Administrativos | Sistema | Kerberos:

Solução de problemas de políticas de autenticação

Determinar as contas às quais uma Política de autenticação é diretamente atribuída

A seção de contas na Política de autenticação mostra que as contas que possuem políticas diretamente aplicadas.

Usar o log administrativo Falhas da Política de Autenticação – Controlador de Domínio

O novo log administrativo Falhas da Política de Autenticação – Controlador de Domínio em Logs de Aplicativos e Serviços>Microsoft>Windows>Authentication foi criado para facilitar a descoberta de falhas causadas pelas políticas de autenticação. Este log fica desabilitado por padrão. Para habilitá-lo, clique com o botão direito do mouse no nome do log e clique em Habilitar Log. Os novos eventos são semelhantes com relação ao conteúdo aos eventos de TGT de Kerberos e auditoria de tíquete de serviço. Para saber mais sobre esses eventos, consulte Políticas de autenticação e Silos de políticas de autenticação.

Gerenciar as políticas de autenticação usando o Windows PowerShell

Esse comando cria uma política de autenticação chamada TestAuthenticationPolicy. O parâmetro UserAllowedToAuthenticateFrom especifica os dispositivos dos quais os usuários podem se autenticar por uma cadeia de caracteres SDDL no arquivo chamado someFile.txt.

PS C:\> New-ADAuthenticationPolicy testAuthenticationPolicy -UserAllowedToAuthenticateFrom (Get-Acl .\someFile.txt).sddl

Esse comando obtém todas as políticas de autenticação que correspondem ao filtro especificado pelo parâmetro Filter .

PS C:\> Get-ADAuthenticationPolicy -Filter "Name -like 'testADAuthenticationPolicy*'" -Server Server02.Contoso.com

Esse comando modifica a descrição e as propriedades UserTGTLifetimeMins da política de autenticação especificada.

PS C:\> Set-ADAuthenticationPolicy -Identity ADAuthenticationPolicy1 -Description "Description" -UserTGTLifetimeMins 45

Esse comando remove a política de autenticação especificada pelo parâmetro Identity .

PS C:\> Remove-ADAuthenticationPolicy -Identity ADAuthenticationPolicy1

Esse comando usa o cmdlet Get-ADAuthenticationPolicy com o parâmetro Filter para obter todas as políticas de autenticação que não são impostas. O conjunto de resultados é canalizado para o cmdlet Remove-ADAuthenticationPolicy .

PS C:\> Get-ADAuthenticationPolicy -Filter 'Enforce -eq $false' | Remove-ADAuthenticationPolicy

Silos de política de autenticação

Os Silos de política de autenticação são um novo contêiner (objectClass msDS-AuthNPolicySilos) no AD DS para contas de usuário, computador e serviço. Eles ajudam a proteger contas de alto valor. Embora todas as organizações precisem proteger membros dos grupos Administradores de Empresa, Admins. do Domínio e Administradores de Esquema devido ao fato de que essas contas podem ser usadas por um invasor para acessar qualquer coisa presente na floresta, outras contas também podem precisar de proteção.

Algumas organizações isolam as cargas de trabalho criando contas específicas para elas e aplicando configurações de Política de grupo para limitar a entrada interativa local e remota e os privilégios administrativos. Os silos de política de autenticação complementam este trabalho ao criar uma maneira para definir uma relação entre as contas de Usuário, Computador e Serviço gerenciada. As contas podem pertencer somente a um silo. Você pode configurar uma política de autenticação para cada tipo de conta a fim de controlar:

1. O tempo de vida de TGT não renovável

2. As condições de controle de acesso para retornar o TGT (observação: não pode ser aplicado a sistemas, pois a proteção do Kerberos é necessária)

3. As condições de controle de acesso para retornar o tíquete de serviço

Além disso, as contas pertencentes a um silo de política de autenticação possuem uma declaração de silo, que pode ser usada por recursos equipados para declarações como servidores de arquivos para controlar o acesso.

Um novo descritor de segurança pode ser configurado para controlar a emissão de tíquete de serviço com base no:

• Usuário, grupos de segurança do usuário e/ou declarações do usuário

• Dispositivo, grupos de segurança do dispositivo e/ou declarações do dispositivo

Obter essas informações para os DCs do recurso requer o Controle de Acesso Dinâmico:

• Declarações do usuário:

  • Clientes do Windows 8 ou posterior com suporte ao Controle de Acesso Dinâmico

  • Domínio de conta com suporte ao Controle de Acesso Dinâmico e declarações

• Dispositivo e/ou seu grupo de segurança:

  • Clientes do Windows 8 ou posterior com suporte ao Controle de Acesso Dinâmico

  • Recurso configurado para autenticação composta

• Declarações de dispositivo:

  • Clientes do Windows 8 ou posterior com suporte ao Controle de Acesso Dinâmico

  • Domínio de dispositivo com suporte ao Controle de Acesso Dinâmico e declarações

  • Recurso configurado para autenticação composta

As políticas de autenticação podem ser aplicadas a todos os membros de um silo de política de autenticação em vez de contas individuais, ou políticas de autenticações separadas podem ser aplicadas a diferentes tipos de contas em um mesmo silo. Por exemplo, uma política de autenticação pode ser aplicada a contas de usuário com altos privilégios e outra política pode ser aplicada a contas de serviço. Pelo menos uma política de autenticação deverá ser criada antes da criação do silo de política de autenticação.

Você pode criar um silo de política de autenticação usando o Centro Administrativo do Active Directory ou o Windows PowerShell. Por padrão, um silo de política de autenticação audita apenas as políticas de silo, o que equivale a especificar o parâmetro WhatIf nos cmdlets do Windows PowerShell. Neste caso, as restrições do silo de políticas não são aplicadas, mas as auditorias são geradas, a fim de indicar se ocorreriam falhas durante a aplicação das restrições.

Para criar um silo de política de autenticação usando o Centro Administrativo do Active Directory

1. Abra o Centro Administrativo do Active Directory, clique em Autenticação, clique com o botão direito em Silos de Política de Autenticação, clique em Novo e em Silo de Política de Autenticação.

   

2. Em Nome de exibição, digite um nome para o silo. Em Contas Permitidas, clique em Adicionar, digite os nomes das contas e clique em OK. Você pode especificar contas de usuários, computadores ou serviço. Em seguida, especifique se deseja usar uma única política para todas as entidades ou um política separada para cada tipo de entidade, bem como o nome das políticas em questão.

   

Gerenciar os silos de política de autenticação usando o Windows PowerShell

Este comando cria um objeto do silo de política de autenticação e o impõe.

PS C:\>New-ADAuthenticationPolicySilo -Name newSilo -Enforce

Esse comando obtém todos os silos de política de autenticação que correspondem ao filtro especificado pelo parâmetro Filter . Em seguida, a saída é passada para o cmdlet Format-Table para exibir o nome da política e o valor para Impor em cada política.

PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Name -like "*silo*"' | Format-Table Name, Enforce -AutoSize

Name  Enforce
----  -------
silo     True
silos   False

Esse comando usa o cmdlet Get-ADAuthenticationPolicySilo com o parâmetro Filter para obter todos os silos de política de autenticação que não são impostos e redirecionar o resultado do filtro para o cmdlet Remove-ADAuthenticationPolicySilo .

PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Enforce -eq $False' | Remove-ADAuthenticationPolicySilo

Esse comando concede acesso ao silo da política de autenticação chamado Silo para a conta de usuário chamada User01.

PS C:\>Grant-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01

Esse comando revoga o acesso ao silo de política de autenticação chamado Silo para a conta de usuário chamada User01. Como o parâmetro Confirm está definido como $False, nenhuma mensagem de confirmação será exibida.

PS C:\>Revoke-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01 -Confirm:$False

Este exemplo usa primeiro o cmdlet Get-ADComputer para obter todas as contas de computador que correspondem ao filtro especificado pelo parâmetro Filter . A saída desse comando é passada para Set-ADAccountAuthenticationPolicySilo para atribuir o silo de política de autenticação chamado Silo e a política de autenticação chamada AuthenticationPolicy02 a eles.

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