Group Managed Service Accounts (gMSA): Guia Completo para Ambientes Corporativos

Introdução

Contas de serviço sempre foram um ponto crítico em ambientes corporativos. Senhas estáticas, configuradas como “não expira”, compartilhadas entre equipes e raramente auditadas representam um risco real de segurança e disponibilidade.

Para resolver esse problema, a Microsoft introduziu no Active Directory as Group Managed Service Accounts (gMSA) — uma forma moderna, segura e automatizada de executar serviços e tarefas sem gerenciamento manual de senha.

Neste artigo você verá:

• O que é gMSA e como funciona

• Quando utilizar essa tecnologia

• Exemplos práticos reais

• Passo a passo de implementação

• Como migrar contas de serviço tradicionais para gMSA

  
  

O que é gMSA?

A gMSA (Group Managed Service Account) é um tipo especial de conta do Active Directory projetada para executar serviços, aplicações e tarefas agendadas sem senha manual.

Principais características:

• Senha gerenciada automaticamente pelo AD

• Senha extremamente complexa (240 caracteres)

• Rotação automática (padrão de 30 dias)

• Autenticação via Kerberos

• Pode ser usada por vários servidores simultaneamente

  
  

Diferente de contas de usuário, ninguém conhece ou precisa armazenar a senha de uma gMSA.

Como o gMSA funciona

O fluxo é totalmente integrado ao Active Directory:

1. O AD cria e armazena a conta gMSA

2. A senha é mantida e rotacionada automaticamente

3. Apenas servidores autorizados podem recuperar a senha

4. A autenticação ocorre via Kerberos

5. Serviços utilizam a conta sem interação humana

   
   

Para o administrador, o serviço simplesmente continua funcionando — mesmo após a troca automática da senha.

Quando utilizar gMSA

Utilize gMSA sempre que um serviço ou aplicação:

• Executa automaticamente (sem login interativo)

• Precisa de identidade de domínio

• Não deve depender de senha manual

• Pode rodar em mais de um servidor

• Exige segurança e compliance

  
  

Cenários ideais

• IIS Application Pools

• Serviços Windows

• SQL Server (Engine e Agent)

• ADFS

• Serviços em cluster ou HA

• Tarefas agendadas corporativas

• Aplicações com autenticação Kerberos

  
  

Se hoje você usa conta de usuário com “senha não expira”, gMSA é o caminho natural de evolução.

Exemplos práticos de uso

Exemplo 1 – IIS Application Pool

Aplicação web rodando em dois IIS atrás de load balancer.Com gMSA:

• Um único identity para os dois servidores

• Senha rotacionada automaticamente

• Zero downtime

  
  

Exemplo 2 – SQL Server

Separação de identidades:

• Uma gMSA para o SQL Engine

• Outra para o SQL AgentMais segurança e melhor auditoria.

  
  

Exemplo 3 – Serviço Windows customizado

Serviço interno acessando file server e banco SQL com:

• Permissões mínimas

• Identidade rastreável

• Nenhuma senha armazenada

  
  

Exemplo 4 – Scheduled Tasks

Scripts PowerShell rodando sem senha salva no Task Scheduler.

Pré-requisitos

• Domínio em Windows Server 2012 ou superior

• DNS e Kerberos saudáveis

• Módulo ActiveDirectory PowerShell

• Servidores membros do domínio

  
  

Passo a passo: criando e usando uma gMSA

1) Criar KDS Root Key (uma vez por domínio)

Add-KdsRootKey -EffectiveImmediately

Validar:

Get-KdsRootKey

2) Criar grupo de servidores autorizados

New-ADGroup -Name "GRP_GMSA_APP01_HOSTS" `
-GroupCategory Security `
-GroupScope Global `
-Path "OU=Grupos,DC=aramis,DC=local"

Adicionar servidores:

Add-ADGroupMember -Identity "GRP_GMSA_APP01_HOSTS" -Members "IIS01$","IIS02$"

3) Criar a gMSA

New-ADServiceAccount -Name "gmsa-app01" `
-DNSHostName "gmsa-app01.aramis.local" `
-PrincipalsAllowedToRetrieveManagedPassword "GRP_GMSA_APP01_HOSTS"

4) Instalar a gMSA no servidor

Install-ADServiceAccount gmsa-app01
Test-ADServiceAccount gmsa-app01

Se retornar True, está pronta para uso.

Como migrar uma conta de serviço tradicional para gMSA

Importante: não existe conversão direta. O processo correto é substituição controlada.

Cenário comum

• Conta antiga: svc_app01

• Senha manual, não expira

• Usada por serviços e tarefas

  
  

Passos de migração

1) Mapear todos os usos da conta antiga

Serviços, IIS, tarefas, permissões em pasta e SQL.

2) Criar a gMSA

Conforme passo a passo acima.

3) Replicar permissões

Pastas e shares:Adicionar DOMINIO\gmsa-app01$ com os mesmos acessos.

SQL Server:

CREATE LOGIN [DOMINIO\gmsa-app01$] FROM WINDOWS;
USE AppDB;
CREATE USER [DOMINIO\gmsa-app01$] FOR LOGIN [DOMINIO\gmsa-app01$];
ALTER ROLE db_datareader ADD MEMBER [DOMINIO\gmsa-app01$];
ALTER ROLE db_datawriter ADD MEMBER [DOMINIO\gmsa-app01$];

4) Trocar a conta do serviço

• Serviço Windows / IIS / Task Scheduler

DOMINIO\gmsa-app01$

Senha em branco.

5) Validar funcionamento

• Reinício do serviço

• Logs da aplicação

• Event Viewer (Kerberos)

• 
  

6) Desativar a conta antiga

Somente após dias de validação.

Boas práticas

• Uma gMSA por aplicação ou serviço

• Nunca reutilizar gMSA entre sistemas distintos

• Usar grupos para controle de servidores

• Documentar uso e permissões

• Monitorar eventos Kerberos

  
  

Quando não usar gMSA

• Login interativo

• Sistemas fora do domínio

• Aplicações legadas incompatíveis

Conclusão

As Group Managed Service Accounts eliminam um dos maiores riscos históricos do Active Directory: credenciais de serviço mal gerenciadas.

Com pouco esforço, é possível:

• Aumentar drasticamente a segurança

• Reduzir falhas operacionais

• Melhorar compliance e auditoria

Se sua infraestrutura ainda depende de contas com “senha não expira”, migrar para gMSA é uma das melhorias de maior impacto e menor custo.