Diretrizes sobre como configurar contas protegidas
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 e Windows Server 2012
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 diretrizes anteriormente para mitigar ataques pass-the-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 tópico explica como configurar os seguintes recursos novos:
Existem medidas para ajudar a evitar o roubo de credenciais adicionais integradas ao Windows 8.1 e Windows Server 2012 R2, abordadas nos seguintes tópicos:
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 conectados em dispositivos do 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, use ferramentas de interface do usuário como ADAC (Centro Administrativo do Active Directory) ou Usuários e Computadores do Active Directory, uma ferramenta de linha de comando como Dsmod group ou o cmdlet Add-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.
Aviso
As restrições de autenticação não possuem solução alternativa, o que significa que membros de grupos altamente privilegiados como os grupos Administradores de Empresa e Admins. do Domínio estão sujeitos às mesmas restrições que outros membros do grupo Usuários protegidos. Se todos os membros desses grupos forem adicionados ao grupo Usuários Protegidos, é possível que todas essas contas sejam bloqueadas. Você nunca deve adicionar todas as contas altamente privilegiadas ao grupo Usuários Protegidos até testar completamente o potencial impacto.
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 de todas as contas 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 de 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).
Observação
O Administrador de domínio interno (S-1-5-<domain>-500) sempre é isento das Políticas de Autenticação, mesmo quando elas são atribuídas a um Silo de Política de Autenticação.
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 os Usuários protegidos, as configurações a seguir são embutidas no 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. Contudo, se a conta for um membro de Usuários protegidos, ela pode não ter esta definiçã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 tentativas explicitamente para os membros do grupo Usuários protegidos, você pode continuar a coletar eventos de auditoria de log de segurança ou os dados dos 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 do 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.
Observação
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:
Usuário
Computador
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.
Visão geral
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
| Política | Requisitos |
|---|---|
| Fornecer tempos de vida de TGT personalizados | Domínios de contas no nível funcional de domínio do Windows Server 2012 R2 |
| Entrada de usuário restrita | – Domínios de contas no nível funcional de domínio do Windows Server 2012 R2 com suporte para Controle de Acesso Dinâmico – Dispositivos do Windows 8, Windows 8.1, Windows Server 2012 ou Windows Server 2012 R2 com suporte para Controle de Acesso Dinâmico |
| Restringir a emissão de tíquetes de serviço com base na conta de usuário e grupos de segurança | Domínios de recurso no nível funcional de domínio do Windows Server 2012 R2 |
| Restringir a emissão de tíquetes de serviço com base nas declarações de usuário ou conta de dispositivo, grupos de segurança ou declarações | Domínios de recurso no nível funcional de domínio do Windows Server 2012 R2 com suporte para Controle de Acesso Dinâmico |
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
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.
Em Opções, na caixa de listagem suspensa, escolha Sempre fornecer declarações.
Observação
Com suporte também pode ser configurado, mas devido ao domínio estar no DFL do Windows Server 2012 R2, ter os DCs sempre fornecem declarações possibilitará realizar verificações de acesso de usuário baseadas em declarações ao usar dispositivos sem reconhecimento de declaração e hosts para conectar a serviços com reconhecimento de declaração.
Aviso
Configurar Recusar solicitações de autenticação desprotegidas resultará em falhas de autenticação de qualquer sistema operacional sem suporte à proteção Kerberos, tal como o Windows 7 e sistemas operacionais mais antigos, ou sistemas operacionais a partir do Windows 8, mas que não tenham sido explicitamente configurados para dar suporte a isso.
Criar uma auditoria de conta de usuário para política de autenticação com o ADAC
Abra o ADAC (Centro Administrativo do Active Directory).
Observação
O nó escolhido Autenticação fica visível para os domínios que estão no 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.
Clique em Políticas de Autenticaçãoe em Nova 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.
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:
Usuário
Computador
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.
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ê quer obter um tempo de vida do TGT máximo de 10 horas, digite 600 como mostrado. Se o tempo de vida de TGT não for configurado, se a conta for membro do grupo Protected Users, o tempo de vida de TGT e sua renovação serão de quatro 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.
Para restringir a conta de usuário a certos dispositivos, clique em Editar para definir as condições pedidas pelo dispositivo.
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
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.
Observação
Este controle de acesso define as condições do dispositivo ou host do qual o usuário entra. Na terminologia de controle de acesso, a conta do computador para o dispositivo ou host é o usuário, e é por isso que Usuário é a única opção.
Clique em Adicionar itens.
Para alterar os tipos de objeto, clique em Tipos de Objeto.
Para escolher os objetos do computador no Active Directory, clique em Computadorese em OK.
Digite o nome dos computadores para restringir o usuário e clique em Verificar Nomes.
Clique em OK e crie quaisquer outras condições desejadas para a conta de computador.
Ao concluir, clique em OK e as condições definidas serão exibidas na conta do computador.
Adicionar condições de declaração de computador
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.
Digite o nome do OU e a conta de usuário deverá ser restrita ao tentar entrar.
Ao concluir, clique em OK e a caixa mostrará as condições definidas.
Solução de problemas de declarações de computador faltantes
Se a declaração foi provisionada, mas não está disponível, pode ter sido configurada somente para classes Computador.
Digamos que você queira restringir a autenticação com base na UO (unidade organizacional) do computador, o que já foi configurado, mas somente para classes Computador.
Para que a declaração esteja disponível para restringir a entrada do Usuário no dispositivo, selecione a caixa de seleção Usuário.
Provisione uma conta de usuário com uma política de autenticação com o ADAC
Na conta de Usuário e clique em Política.
Selecione a caixa de seleção Atribuir uma política de autenticação a esta conta.
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>Autenticação 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 no nome do log e clique em Habilitar log. Os novos eventos são muito 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
Este comando cria uma política de autenticação chamada TestAuthenticationPolicy. O parâmetro UserAllowedToAuthenticateFrom especifica os dispositivos aos quais o usuário pode autenticar-se com uma cadeia SDDL no arquivo chamado someFile.txt.
PS C:\> New-ADAuthenticationPolicy testAuthenticationPolicy -UserAllowedToAuthenticateFrom (Get-Acl .\someFile.txt).sddl
Este comando obtém todas as políticas de autenticação correspondentes ao filtro especificado no parâmetro Filter.
PS C:\> Get-ADAuthenticationPolicy -Filter "Name -like 'testADAuthenticationPolicy*'" -Server Server02.Contoso.com
Este 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
Este comando remove a política de autenticação especificada pelo parâmetro Identity.
PS C:\> Remove-ADAuthenticationPolicy -Identity ADAuthenticationPolicy1
Este comando usa o cmdlet Get-ADAuthenticationPolicy com o parâmetro Filter para obter todas as políticas de autenticação que não estão sendo 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:
O tempo de vida de TGT não renovável
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)
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 de 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 do 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.
Observação
Uma política de autenticação pode ser aplicada aos membros de um silo de política de autenticação, ou então, aplicada independentemente dos silos para restringir um escopo específico de contas. Por exemplo, para proteger uma única conta ou um pequeno conjunto de contas, uma política pode ser definida nessas contas sem adicionar a conta a um silo.
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 somente políticas do silo, o que é equivalente a especificar o parâmetro WhatIf em 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
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.
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
Este comando obtém todos os silos de política de autenticação correspondentes ao filtro especificado pelo parâmetroFilter. A saída é então repassada ao cmdlet Format-Table para exibir o nome da política e o valor de Enforce em cada política.
PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Name -like "*silo*"' | Format-Table Name, Enforce -AutoSize
Name Enforce
---- -------
silo True
silos False
Este comando usa o cmdlet Get-ADAuthenticationPolicySilo com o parâmetro Filter para obter todos os silos de política de autenticação não impostos e canalizar o resultado do filtro para o cmdlet Remove-ADAuthenticationPolicySilo.
PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Enforce -eq $False' | Remove-ADAuthenticationPolicySilo
Este comando concede acesso ao silo de política de autenticação chamado Silo para a conta de usuário chamada User01.
PS C:\>Grant-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01
Este 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 é exibida.
PS C:\>Revoke-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01 -Confirm:$False
Este primeiro exemplo usa o cmdlet Get-ADComputer para obter todas as contas de computador correspondentes ao filtro especificado pelo parâmetro Filter. A saída deste comando é repassada para o Set-ADAccountAuthenticatinPolicySilo para atribuir o silo de política de autenticação chamado Silo e a política de autenticação chamada AuthenticationPolicy02 a ele.
PS C:\>Get-ADComputer -Filter 'Name -like "newComputer*"' | Set-ADAccountAuthenticationPolicySilo -AuthenticationPolicySilo Silo -AuthenticationPolicy AuthenticationPolicy02