Olá pessoal, tudo bem?
Hoje o assunto é segurança, vamos falar de conta de serviço gerenciado de grupo (gMSA). A maioria dos profissionais de TI se quer saber de existência dela, inclusive eu, não sabia, até surgir uma demanda em um dos clientes para criação de um conta gMSA (Group Managed Service Accounts) para execução de um script de Powershell, usando o Agendador de Tarefas do Windows.
Este conteúdo faz parte do exame AZ-800 Como administrar a infraestrutura de núcleo híbrido do Windows Server (Administering Windows Server Hybrid Core Infrastructure).
Um pouco da história
Desde sua introdução no Windows Server 2003, as contas de serviço têm desempenhado um papel importante no isolamento de serviços e sua autenticação. Contas de serviço são contas de usuário utilizadas para fornecer autenticação e autorização para serviços ou aplicativos em execução no servidor Windows. Originalmente, as contas de serviço estavam disponíveis somente como contas locais que exigiam manutenção contínua e esforço administrativo significativos. No entanto, elas se desenvolveram e agora incluem Managed Service Accounts (MSAs) de grupo e contas virtuais que fornecem gerenciamento simplificado de nomes da entidade de serviço (SPN, service principal names) e gerenciamento de senhas automático.
As contas de serviço gerenciadas foram introduzidas no Windows Server 2008 R2 (tipo de objeto). Sua principal limitação é que tal conta só pode ser usada em um servidor (eles não podem ser usados em serviços de cluster e NLB). Portanto, o Windows Server 2012 introduziu contas de serviço gerenciadas em grupo/gMSA (tipo). As contas gMSA podem ser usadas simultaneamente em vários hosts.
Requisitos para o uso de contas de serviços MSA/gMSA:
| Conta de serviço gerenciada (MAS) | Conta de serviço gerenciada em grupo (gMSA) | |
| Domínio de AD e nível funcional florestal | Windows Server 2008 R2 ou mais novo | Windows Server 2012 ou mais novo |
| KDC | Controlador de domínio com o Serviço de Distribuição de Chaves da Microsoft (KdsSvc) ativado | |
| PowerShell | Para criar e gerenciar contas de AD de serviço, você precisa instalar o módulo Active Directory para Windows PowerShell | |
| .Net Framework | .NET Framework 3.5 ou mais novo deve ser instalado no servidor | |
| Versões do Windows suportadas | Windows 7/Windows Server 2008 R2 ou mais novo | Windows Server 2012/Windows 8 ou mais novo |
Descrição do recurso
Uma SMSA (Conta de Serviço Gerenciado) autônoma é uma conta de domínio gerenciado que fornece gerenciamento automático de senha, gerenciamento simplificado de SPN (nome da entidade de serviço) e a capacidade de delegar o gerenciamento a outros administradores. Esse tipo de MSA (conta de serviço gerenciado) foi introduzido no Windows Server 2008 R2 e no Windows 7.
A gMSA (Conta de Serviço Gerenciado) do grupo fornece a mesma funcionalidade dentro do domínio, mas também estende essa funcionalidade em vários servidores. Ao se conectar a um serviço hospedado em um farm de servidores, como a solução Balanceamento de Carga de Rede, os protocolos de autenticação que suportam a autenticação mútua exigem que todas as instâncias dos serviços usem a mesma entidade de segurança. Quando uma gMSA é usada como entidades de serviço, o sistema operacional Windows gerencia a senha da conta em vez de depender do administrador para gerenciar a senha.
O Serviço de Distribuição de Chaves da Microsoft (kdssvc.dll) fornece o mecanismo para obter de forma segura a chave mais recente ou uma chave específica com um identificador de chave para uma conta do Active Directory. O Serviço de Distribuição de Chaves compartilha um segredo que é usado para criar chaves para a conta. Essas chaves são alteradas periodicamente. Para uma gMSA, o controlador de domínio calcula a senha na chave fornecida pelos Serviços de Distribuição de Chaves, além de outros atributos da gMSA. Os hosts membros podem obter os valores de senha atuais e anteriores contatando um controlador de domínio.
Aplicações práticas
Os gMSAs fornecem uma única solução de identidade para serviços em execução em um farm de servidores ou em sistemas por trás do Network Load Balancer. Ao fornecer uma solução gMSA, os serviços podem ser configurados para a nova entidade de segurança gMSA e o gerenciamento de senhas é tratado pelo Windows.
Usando uma gMSA, os serviços ou administradores de serviços não precisam gerenciar a sincronização de senha entre instâncias de serviço. A gMSA dá suporte a hosts que são mantidos offline por um longo período e ao gerenciamento de hosts membros para todas as instâncias de um serviço. Isso significa que você pode implantar um farm de servidores que fornece suporte para uma única identidade na qual os computadores clientes atuais podem se autenticar sem saberem a qual instância do serviço eles estão se conectando.
Os clusters de failover não dão suporte a gMSAs. No entanto, os serviços que são executados sobre o Serviço de cluster poderão usar uma gMSA ou uma sMSA, se forem um serviço Windows, um pool de aplicativos, uma tarefa agendada ou oferecerem suporte nativo a gMSA ou sMSA.
Escolha o tipo certo de conta de serviço
| Critério | gMSA | sMSA | Conta de Computador | Conta de usuário |
|---|---|---|---|---|
| O aplicativo é executado em um único servidor | Sim | Sim. Use uma gMSA, se possível. | Sim. Use uma MSA, se possível. | Sim. Use uma MSA, se possível. |
| O aplicativo é executado em vários servidores | Sim | Não | Não. A conta está vinculada ao servidor. | Sim. Use uma MSA, se possível. |
| O aplicativo é executado atrás de um balanceador de carga | Sim | Não | Não | Sim. Use somente se você não puder usar uma gMSA. |
| O aplicativo é executado no Windows Server 2008 R2 | Não | Sim | Sim. Use uma MSA, se possível. | Sim. Use uma MSA, se possível. |
| O aplicativo é executado no Windows Server 2012 | Sim | Sim. Use uma gMSA, se possível. | Sim. Use uma MSA, se possível. | Sim. Use uma MSA, se possível. |
| Requisito para restringir a conta de serviço a um servidor único | Não | Sim | Sim. Use uma sMSA, se possível. | Não |
Requisitos de software
Uma arquitetura de 64 bits é necessária para executar os comandos do PowerShell que são usados para administrar gMSAs.
Uma conta de serviços gerenciados depende de tipos de criptografia Kerberos com suporte. Quando um computador cliente se autentica em um servidor usando Kerberos, o controlador de domínio cria um ticket de serviço Kerberos protegido com uma criptografia que é compatível tanto nesse controlador quanto no servidor. O DC usa o atributo msDS-SupportedEncryptionTypes da conta para determinar a qual criptografia ao servidor dá suporte e, se não houver nenhum atributo, ele pressuporá que o computador cliente não dá suporte a tipos de criptografia mais fortes. Se o host estiver configurado para não dar suporte ao RC4, a autenticação sempre falhará. Por esse motivo, o AES sempre deve ser configurado explicitamente para contas de serviços gerenciados.
Observações: A partir do Windows Server 2008 R2, o DES fica desabilitado por padrão. Para obter mais informações sobre os tipos de criptografia com suporte, consulte Alterações da autenticação do Kerberos.
gMSAs não são aplicáveis Windows sistemas operacionais anteriores Windows Server 2012.
GitHub
Faça o download aqui do script com todos os comandos de Powershell apresentados no vídeo.
Vídeo
No vídeo será demostrado de forma clara e objetiva, como criar uma gMSA (Conta de Serviço Gerenciado), criar uma tarefa no Agendador de tarefa do Windows para execução de um script Powershell. Todo o processo que será demostrado será em Powershell.
As seguintes as seguintes etapas demostradas no vídeo:
a. Crie um gMSA e vincule-o a dois servidores Windows.
b. Instale o gMSA nos servidores Windows e teste-o.
c. Crie um trabalho de Agenda de Tarefas e execute-o sob o gMSA.
d. Execute uma senha de atualização do gMSA e verifique se o trabalho de agenda de tarefas ainda será executado.
Referências
Inscreva-se no meu canal do YouTube!
Há 10 anos atuo na área de TI focado em suporte e administração de infraestrutura, especializado em plataformas Microsoft. Tenho grande experiência em troubleshooting, implantação, configuração e administração de funções e recursos de tecnologia Microsoft. Formado em Redes de Computadores pela faculdade Estácio de Sá de Belo Horizonte.
Comecei a compartilhar o meu conhecimento no ano de 2012, fazendo artigos e vídeos para o meu Blog. Em 2017 comecei a escrever artigos para o portal Cooperati.
Sou apaixonado em compartilhar o meu conhecimento. Meu lema é: um conhecimento só é válido quando compartilhado.
No responses yet