Orientação sobre como configurar contas protegidas
Por meio de ataques Pass-the-hash (PtH), um invasor pode se autenticar em um servidor ou serviço remoto usando o hash NTLM subjacente da senha de um usuário (ou outros derivados de credenciais). A Microsoft já publicou orientações para mitigar ataques pass-the-hash. O Windows Server 2012 R2 inclui novos recursos para ajudar a mitigar ainda mais esses ataques. Para obter mais informações sobre outros recursos de segurança que ajudam a proteger contra roubo de credenciais, consulte de Proteção e Gerenciamento de Credenciais . Este tópico explica como configurar os seguintes novos recursos:
Há atenuações adicionais incorporadas ao Windows 8.1 e ao Windows Server 2012 R2 para ajudar a proteger contra roubo de credenciais, que são abordadas nos seguintes tópicos:
Modo de Administrador Restrito para Área de Trabalho Remota
Utilizadores Protegidos
Usuários Protegidos é um novo grupo de segurança global ao qual você pode adicionar usuários novos ou existentes. Os dispositivos Windows 8.1 e os hosts do Windows Server 2012 R2 têm um comportamento especial com os membros desse grupo para fornecer melhor proteção contra roubo de credenciais. Para um membro do grupo, um dispositivo Windows 8.1 ou um host do Windows Server 2012 R2 não armazena em cache credenciais que não são suportadas para Usuários Protegidos. Os membros desse grupo não terão proteção adicional se estiverem conectados a 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 Windows Server 2012 R2 não podem mais usar:
Delegação de credenciais padrão (CredSSP) - as credenciais de texto sem formatação não são armazenadas em cache, mesmo quando a política Permitir delegação de credenciais padrão está habilitada.
Resumo do Windows - credenciais de texto sem formatação não são armazenadas em cache, mesmo quando estão habilitadas
NTLM - NTOWF não é armazenado em cache
Chaves de longo prazo Kerberos - O tíquete de concessão de tíquete (TGT) Kerberos é adquirido no logon e não pode ser readquirido automaticamente
Iniciar sessão offline - o verificador de início de sessão em cache não foi 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 a autenticação NTLM
Usar pacotes de codificação DES (Data Encryption Standard) ou RC4 na pré-autenticação Kerberos
Ser delegado usando delegação irrestrita ou restrita
Renovar tíquetes de usuário (TGTs) além da vida útil inicial de 4 horas
Para adicionar usuários ao grupo, você pode usar
Advertência
As restrições de autenticação não têm solução alternativa, o que significa que os membros de grupos altamente privilegiados, como o grupo Administradores de Empresa ou o grupo Administradores de 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. Nunca deve adicionar todas as contas altamente privilegiadas ao grupo Utilizadores Protegidos até ter testado exaustivamente o potencial impacto.
Os membros do grupo Usuários Protegidos devem ser capazes de se autenticar usando Kerberos com AES (Advanced Encryption Standards). Este método requer chaves AES para a conta no Ative 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, está bloqueada. Portanto, siga estas práticas recomendadas:
Não teste em domínios, a menos que todos os controladores de domínio estejam a executar o Windows Server 2008 ou posterior.
Alterar a senha para todas as contas de domínio que foram criadas antes de o domínio ter sido criado. Caso contrário, essas contas não poderão ser autenticadas.
Alterar de senha para 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
As contas protegidas têm os seguintes requisitos de implantação:
Para fornecer restrições do lado do cliente para Usuários Protegidos, os hosts devem executar o Windows 8.1 ou o Windows Server 2012 R2 . Um utilizador só tem de iniciar sessão com uma conta que seja membro de um grupo de Utilizadores Protegidos. Nesse caso, o grupo Usuários Protegidos pode ser criado transferindo a função de emulador de controlador de domínio primário (PDC) para um controlador de domínio que executa o Windows Server 2012 R2. Depois que esse objeto de grupo é replicado para outros controladores de domínio, a função de emulador de PDC pode ser hospedada em um controlador de domínio que executa uma versão anterior do Windows Server.
Para fornecer restrições do lado do controlador de domínio para Usuários Protegidos, ou seja, restringir o uso da autenticação NTLM e outras restrições, o nível funcional do domínio deve ser Windows Server 2012 R2 . Para obter mais informações sobre níveis funcionais, consulte Noções básicas sobre os níveis funcionais dos Serviços de Domínio Ative Directory (AD DS).
Observação
O Administrador de domínio interno (S-1-5-<domain>-500) está sempre isento de Políticas de Autenticação, mesmo quando elas são atribuídas a um Silo de Política de Autenticação.
Solucionar problemas de eventos relacionados a Usuários Protegidos
Esta seção cobre novos logs para ajudar a resolver eventos relacionados a Usuários Protegidos e como os Usuários Protegidos podem impactar as alterações ao solucionar problemas de expiração de tíquetes de concessão de tíquetes (TGT) ou problemas 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 do Usuário Protegido - Log do Controlador de Domínio. Esses novos logs estão localizados no Visualizador de Eventos e são desabilitados por padrão. Para ativar um log, clique em Logs de Aplicações e Serviços, clique em Microsoft, clique em Windows, clique em Autenticação, e depois clique no nome do log e clique em Ação (ou clique com o botão direito do rato no log) e clique em Ativar Log.
Para obter mais informações sobre eventos nestes logs, consulte Políticas de Autenticação e Silos de Políticas de Autenticação.
Solucionar problemas de expiração do TGT
Normalmente, o controlador de domínio define o tempo de vida e a renovação do TGT com base na diretiva de domínio, conforme mostrado na seguinte janela do Editor de Gerenciamento de Diretiva de Grupo.
Para Usuários Protegidos, as seguintes configurações são codificadas:
Tempo de vida máximo para o bilhete de utilizador: 240 minutos
Vida útil máxima para renovação de bilhete de utilizador: 240 minutos
Solucionar problemas de delegação
Anteriormente, se uma tecnologia que usa a delegação Kerberos estivesse falhando, a conta do cliente era verificada para ver se Conta é confidencial e não pode ser delegada foi definida. No entanto, se a conta for membro do Protected Users, talvez não tenha essa configuração configurada no Ative Directory Administrative Center (ADAC). Como resultado, verifique a configuração e a filiação ao grupo ao solucionar problemas de delegação.
Tentativas de autenticação de auditoria
Para auditar explicitamente as tentativas de autenticação para os membros do grupo Usuários Protegidos, pode continuar a recolher eventos de auditoria de log de segurança ou recolher os dados nos novos logs administrativos operacionais. Para obter mais informação sobre os eventos, consulte Políticas de Autenticação e Silos de Políticas de Autenticação
Fornecer proteções no lado da corrente contínua para serviços e computadores
As contas de serviços e computadores não podem ser membros de Utilizadores Protegidos. Esta seção explica quais proteções baseadas em controlador de domínio podem ser oferecidas para essas contas:
Rejeitar autenticação NTLM: apenas configurável através de políticas de bloco NTLM
Rejeitar DES (Data Encryption Standard) na pré-autenticação Kerberos: os controladores de domínio do Windows Server 2012 R2 não aceitam DES para contas de computador, a menos que estejam configurados para DES apenas porque todas as versões do Windows lançadas com Kerberos também suportam RC4.
Rejeitar RC4 na pré-autenticação Kerberos: não configurável.
Observação
Embora seja possível alterar a configuração dos tipos de criptografia suportados, não é recomendável alterar essas configurações para contas de computador sem testar no ambiente de destino.
Restrinja os tíquetes de usuário (TGTs) a um tempo de vida inicial de 4 horas: use políticas de autenticação.
Negar delegação com delegação irrestrita ou restrita: para restringir uma conta, abra o Centro Administrativo do Ative Directory (ADAC) e marque a caixa de seleção Conta é confidencial e não pode ser delegada caixa.
Políticas de autenticação
As Políticas de Autenticação sã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 a exposição ao roubo de credenciais, como restringir o tempo de vida do TGT para contas ou adicionar outras condições relacionadas a declarações.
No Windows Server 2012, o controlo de acesso dinâmico introduziu uma classe de objeto de escopo de floresta do Active Directory chamada Diretiva de Acesso Central para fornecer uma maneira fácil de configurar servidores de ficheiros em uma organização. No Windows Server 2012 R2, uma nova classe de objeto chamada Diretiva de Autenticação (objectClass msDS-AuthNPolicies) pode ser usada para aplicar a configuração de autenticação a classes de conta em domínios do Windows Server 2012 R2. As classes de conta do Ative Directory são:
Utilizador
Computador
Conta de Serviço Gerenciado e Conta de Serviço Gerenciado de Grupo (GMSA)
Atualização rápida do Kerberos
O protocolo de autenticação Kerberos consiste em três tipos de trocas, também conhecidas como subprotocolos:
O serviço de autenticação (AS) Exchange (KRB_AS_*)
Troca do Serviço de Ticket-Granting (TGS) (KRB_TGS_*)
O Exchange Cliente/Servidor (AP) (KRB_AP_*)
O processo de troca AS é quando o cliente usa a senha da conta ou a chave privada para criar um pré-autenticador para solicitar um bilhete de concessão de bilhete (TGT). Isso acontece no logon do usuário ou na primeira vez que um tíquete de serviço é necessário.
O intercâmbio TGS é o local onde o TGT da conta é usado para criar um autenticador para solicitar um bilhete de serviço. Isso acontece quando uma conexão autenticada é necessária.
A troca de pontos de acesso ocorre normalmente como dados dentro do protocolo de aplicativo e não é afetada por políticas de autenticação.
Para obter informações mais detalhadas, consulte Como funciona o protocolo de autenticação Kerberos versão 5.
Visão geral
As políticas de autenticação complementam os Usuários Protegidos, fornecendo uma maneira de aplicar restrições configuráveis a contas e fornecendo restrições para contas de serviços e computadores. As políticas de autenticação são aplicadas durante a troca AS ou a troca TGS.
Você pode restringir a autenticação inicial ou a troca AS configurando:
O tempo de vida útil de um TGT
Condições de controlo de acesso para restringir o início de sessão do utilizador, que devem ser cumpridas pelos dispositivos de onde está a ser originada a troca AS.
Você pode restringir as solicitações de tíquetes de serviço através de uma troca de concessão de tíquetes (TGS) ao configurar:
- Condições de controlo de acesso que devem ser cumpridas pelo cliente (utilizador, serviço, computador) ou dispositivo de onde provém a troca TGS
Requisitos para usar políticas de autenticação
| Política | Requerimentos |
|---|---|
| Forneça durações personalizadas para TGTs | Domínios de contas no nível funcional do domínio do Windows Server 2012 R2 |
| Restringir o acesso do utilizador | - Domínios de conta no nível funcional de domínio do Windows Server 2012 R2 com suporte para Controlo de Acesso Dinâmico - Dispositivos Windows 8, Windows 8.1, Windows Server 2012 ou Windows Server 2012 R2 com suporte ao 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 recursos ao nível funcional do domínio do Windows Server 2012 R2 |
| Restringir a emissão de tíquetes de serviço com base em declarações de usuário ou conta de dispositivo, grupos de segurança ou declarações | Domínios de recursos de nível funcional de domínio do Windows Server 2012 R2 com suporte ao Controle de Acesso Dinâmico |
Restringir uma conta de utilizador a dispositivos e anfitriões 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 o suporte ao controlador de domínio
O domínio da conta do usuário deve estar no nível funcional de domínio (DFL) do Windows Server 2012 R2. Verifique se todos os controladores de domínio são Windows Server 2012 R2 e, em seguida, use Domínios e Confianças do Active Directory para elevar o DFL para Windows Server 2012 R2.
Para configurar o suporte para o Controle de Acesso Dinâmico
Na Diretiva de Controladores de Domínio Padrão, clique em Habilitado para habilitar suporte ao cliente KDC (Centro de Distribuição de Chaves) para declarações, autenticação composta e proteção Kerberos em Configuração do Computador | Modelos Administrativos | Sistema | KDC.
Em Opções , na caixa de listagem suspensa, selecione Fornecer declarações sempre.
Observação
Os suportados também podem ser configurados, mas como o domínio está no Windows Server 2012 R2 DFL, fazer com que os DCs sempre forneçam declarações permitirá 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 conectar a serviços com reconhecimento de declarações.
Advertência
Configurar Falhar solicitações de autenticação sem proteção resultará em falhas de autenticação de qualquer sistema operacional que não ofereça suporte à proteção Kerberos, como o Windows 7 e sistemas operacionais anteriores, ou sistemas operacionais a partir do Windows 8, que não tenham sido explicitamente configurados para suportá-la.
Criar uma auditoria de conta de usuário para política de autenticação com o ADAC
Abra o Centro Administrativo do Ative Directory (ADAC).
Observação
O nó de Autenticação selecionado é visível para domínios que estão no Windows Server 2012 R2 DFL. Se o nó não aparecer, tente novamente usando uma conta de administrador de domínio de um domínio que esteja no Windows Server 2012 R2 DFL.
Clique em Políticas de Autenticaçãoe, em seguida, clique em Nova para criar uma nova política.
As Políticas de Autenticações devem ter um nome para exibição e são impostas por padrão.
Para criar uma política somente de 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 Ative Directory. Uma única política pode ser aplicada a todos os três tipos de conta, definindo configurações para cada tipo. Os tipos de conta são:
Utilizador
Computador
Conta de Serviço Gerenciado e Conta de Serviço Gerenciado de Grupo
Se tiver estendido o esquema com novos principais que podem ser usados pelo Centro de Distribuição de Chaves (KDC), o novo tipo de conta é classificado a partir do tipo de conta derivada mais próximo.
Para configurar um tempo de vida de TGT para contas de usuário, marque a caixa de seleção Especificar um tempo de vida de tíquete de Ticket-Granting para contas de usuário e insira o tempo em minutos.
Por exemplo, se você quiser uma vida útil máxima de 10 horas de TGT, insira 600 conforme mostrado. Se nenhum tempo de vida do 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. Caso contrário, o tempo de vida e a renovação do TGT serão baseados na política de domínio, conforme visto na seguinte janela do Editor de Gerenciamento de Diretiva de Grupo para um domínio com configurações padrão.
Para restringir a conta de usuário para selecionar dispositivos, clique em Editar para definir as condições necessárias para o dispositivo.
Na janela Editar Condições de Controle de Acesso, clique em Adicionar uma condição.
Adicionar conta de computador ou condições de grupo
Para configurar contas ou grupos de computadores, na lista suspensa, selecione Membro de cada e altere para Membro de qualquer.
Observação
Esse controle de acesso define as condições do dispositivo ou host a partir do qual o usuário faz logon. Na terminologia de controlo de acesso, a conta de computador para o dispositivo ou host é o utilizador, e é por isso que Utilizador é a única opção.
Clique Adicionar itens.
Para alterar os tipos de objeto, clique em Tipos de objeto.
Para selecionar objetos de computador no Ative Directory, clique em Computadorese, em seguida, clique em OK.
Digite os nomes dos computadores para limitar o acesso do utilizador e, em seguida, clique em Verificar Nomes.
Clique em OK e crie quaisquer outras condições para a conta de computador.
Quando terminar, clique em OK e as condições definidas aparecerão para a conta do computador.
Adicionar condições de reclamação para computador
Para configurar declarações de computador, utilize o menu suspenso do Grupo para selecionar a declaração.
As reivindicações só estão disponíveis se já estiverem provisionadas na floresta.
Digite o nome da UO, a conta de usuário deve ser restrita para fazer logon.
Quando terminar, clique em OK e a caixa mostrará as condições definidas.
Solucionar problemas de declarações de computador ausentes
Se a declaração tiver sido provisionada, mas não estiver disponível, ela poderá ser configurada apenas para classes Computer.
Suponhamos que pretendia restringir a autenticação com base na unidade organizacional (OU) do computador, que já estava configurada, mas apenas para as classes de Computador .
Para que a declaração esteja disponível para restringir o início de sessão do utilizador no dispositivo, selecione a caixa de verificação de utilizador .
Provisionar uma conta de usuário com uma política de autenticação com o ADAC
Na conta de utilizador , clique em Política.
Selecione a caixa de verificação Atribuir uma política de autenticação a esta conta.
pt-PT:
Em seguida, selecione a política de autenticação a ser aplicada ao usuário.
Configurar o suporte ao Controle de Acesso Dinâmico em dispositivos e hosts
Você pode configurar os tempos de vida do TGT sem configurar o DAC (Controle de Acesso Dinâmico). O DAC só é necessário para verificar AllowedToAuthenticateFrom e AllowedToAuthenticateTo.
Usando a Diretiva de Grupo ou o Editor de Diretiva de Grupo Local, ative suporte ao cliente Kerberos para declarações, autenticação composta e proteção Kerberos na Configuração do Computador | Modelos Administrativos | Sistema | Kerberos:
Solucionar problemas de políticas de autenticação
Determinar as contas às quais é atribuída diretamente uma Política de Autenticação
A seção contas na Política de Autenticação mostra as contas que aplicaram diretamente a política.
Usar o log administrativo de Falhas na Política de Autenticação do Controlador de Domínio
Um novo Falhas de Política de Autenticação - Controlador de Domínio log administrativo em Logs de Aplicativos e Serviços>Microsoft>Windows>Autenticação foi criado para facilitar a descoberta de falhas devido a Políticas de Autenticação. O log é desativado por padrão. Para ativá-lo, clique com o botão direito do mouse no nome do log e clique em Ativar Log. Os novos eventos são bastante semelhantes em termos de conteúdo aos eventos já existentes de auditoria de tíquetes de serviço e de TGT Kerberos. Para obter mais informações sobre estes eventos, consulte Políticas de Autenticação e Silos de Políticas de Autenticação.
Gerenciar 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 a partir 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
Este comando obtém todas as políticas de autenticação que correspondem ao filtro especificado pelo parâmetro
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 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
Silos de Política de Autenticação é um novo contentor (objectClass msDS-AuthNPolicySilos) no AD DS para contas de utilizador, computador e serviço. Eles ajudam a proteger contas de alto valor. Embora todas as organizações precisem proteger os membros dos grupos Administradores de Empresa, Administradores de Domínio e Administradores de Esquema, pois essas contas podem ser usadas por um invasor para acessar qualquer coisa na floresta, outras contas também podem precisar de proteção.
Algumas organizações isolam cargas de trabalho criando contas exclusivas para elas e aplicando configurações de Diretiva de Grupo para limitar o logon interativo local e remoto e os privilégios administrativos. Os silos de política de autenticação complementam esse trabalho, criando uma maneira de definir uma relação entre as contas de Usuário, Computador e Serviço gerenciado. As contas só podem pertencer a um silo. Você pode configurar a política de autenticação para cada tipo de conta para controlar:
Vida útil não renovável do TGT
Condições de controle de acesso para retornar TGT (Nota: não pode ser aplicado a sistemas porque a blindagem Kerberos é necessária)
Condições de controlo de acesso para devolução de bilhete de serviço
Além disso, as contas em um silo de política de autenticação têm uma declaração de silo, que pode ser usada por recursos com reconhecimento de 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 em:
Usuário, grupos de segurança do usuário e/ou declarações do usuário
Dispositivo, grupo de segurança do dispositivo e/ou declarações do dispositivo
Transmitir esta informação para os DCs do recurso requer o Controle de Acesso Dinâmico:
Declarações do usuário:
Clientes Windows 8 e posteriores com suporte ao Controle de Acesso Dinâmico
O domínio da conta suporta o Controle de Acesso Dinâmico e declarações
Dispositivo e/ou grupo de segurança do dispositivo.
Clientes Windows 8 e posteriores com suporte ao Controle de Acesso Dinâmico
Recurso configurado para autenticação composta
Reclamações do dispositivo:
Clientes Windows 8 e posteriores com suporte ao Controle de Acesso Dinâmico
O domínio do dispositivo suporta o 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ção separadas podem ser aplicadas a diferentes tipos de contas dentro de um silo. Por exemplo, uma política de autenticação pode ser aplicada a contas de usuário altamente privilegiadas e uma política diferente pode ser aplicada a contas de serviços. Pelo menos uma política de autenticação deve ser criada antes que um silo de política de autenticação possa ser criado.
Observação
Uma política de autenticação pode ser aplicada a membros de um silo de política de autenticação ou pode ser aplicada independentemente de silos para restringir o escopo específico da conta. Por exemplo, para proteger uma única conta ou um pequeno conjunto de contas, uma política pode ser definida nessas contas sem adicionar as contas a um silo.
Você pode criar um silo de política de autenticação usando o Centro Administrativo do Ative Directory ou o Windows PowerShell. Por padrão, um silo de política de autenticação audita apenas políticas de silo, o que equivale a especificar o parâmetro WhatIf nos cmdlets do Windows PowerShell. Nesse caso, as restrições de silos de políticas não se aplicam, mas são geradas auditorias para indicar se ocorrem falhas caso as restrições sejam aplicadas.
Para criar um silo de política de autenticação usando a Central Administrativa do Ative Directory
Abra Centro Administrativo do Active Directory, clique em Autenticação, clique com o botão direito em Silos da Política de Autenticação, clique em Novoe, em seguida, clique 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, escreva os nomes das contas e, em seguida, clique em OK. Você pode especificar usuários, computadores ou contas de serviço. Em seguida, especifique se deseja usar uma única política para todas as entidades ou uma política separada para cada tipo de entidade e o nome da política ou políticas.
Gerenciar silos de política de autenticação usando o Windows PowerShell
Este comando cria um objeto de silo de política de autenticação e aplica-o.
PS C:\>New-ADAuthenticationPolicySilo -Name newSilo -Enforce
Este 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 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
PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Enforce -eq $False' | Remove-ADAuthenticationPolicySilo
Este comando concede acesso ao silo de política de autenticação chamado Silo à conta de usuário denominada User01.
PS C:\>Grant-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01
Este comando revoga o acesso ao silo de política de autenticação denominado Silo para a conta de usuário denominada 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 exemplo usa primeiro o cmdlet Get-ADComputer para obter todas as contas de computador que correspondem ao filtro que o parâmetro Filter especifica. 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