Group Managed Service Accounts (gMSA): Guia Completo para Ambientes Corporativos
- Rodrigo Motta
- 26 de dez. de 2025
- 3 min de leitura
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:
O AD cria e armazena a conta gMSA
A senha é mantida e rotacionada automaticamente
Apenas servidores autorizados podem recuperar a senha
A autenticação ocorre via Kerberos
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.
Comentários