Active Directory Security Groups: Guia Prático de Gestão com PowerShell para PME
Active Directory · Security Groups · PowerShell · AD DS · Delegação · PME | ✎ Duarte Spínola | 2026-06-27
Active Directory · Security Groups · PowerShell · AD DS · Delegação · PME
Em qualquer PME portuguesa com um domínio Windows Server — seja 2016, 2019, 2022 ou o novo 2025 (Windows Server 2025: Novidades e Migração) — a gestão de permissões passa quase inteiramente pelos Security Groups do Active Directory. Atribuir acesso a pastas partilhadas, unidades de rede, impressoras, aplicações VPN, políticas de grupo (GPO) e licenças de Microsoft 365 depende de grupos bem estruturados. O erro mais comum não é técnico: é organizacional. Grupos criados à pressa, com nomes inconsistentes, sem documentação, sem proprietário definido e com membros que deviam ter sido removidos há anos. Este guia percorre os fundamentos dos Security Groups — tipos, âmbitos, nomenclatura, aninhamento, delegação — e fornece comandos PowerShell reais do módulo ActiveDirectory para criar, auditar e manter grupos correctamente. As referências oficiais da Microsoft estão inline, e para gestão de tickets associada consulte o Registar e Documentar Tickets Correctamente.
Neste artigo
- O Que São Security Groups
- Grupos de Segurança vs Grupos de Distribuição
- Âmbitos: Global, Domain Local e Universal
- Convenção de Nomenclatura para PME
- Criar Grupos com PowerShell
- Gerir Membros: Adicionar e Remover
- Aninhar Grupos: Regras e Boas Práticas
- Delegação de Gestão sem Domain Admins
- Auditoria e Relatórios de Grupos
- Grupos Predefinidos e Contas de Serviço
- Integração com Microsoft 365 e Entra ID
- Erros Comuns na Gestão de Grupos
- Checklist de Gestão de Security Groups
1. O Que São Security Groups
Um Security Group no Active Directory é um objecto de directório que agrupa contas de utilizador, contas de computador e outros grupos para fins de autorização. Quando um utilizador pertence a um Security Group, esse grupo pode ser usado em listas de controlo de acesso (ACL) — por exemplo, num NTFS folder, numa partilha SMB, numa política de grupo filtrada por segurança, ou num perfil de VPN. O grupo recebe um identificador de segurança (SID) único, descrito em Security Identifiers, que é incluído no token de acesso do utilizador no momento de logon. Isto significa que o Windows avalia as permissões do grupo em cada acesso a recursos — não é necessário consultar o AD em cada operação.
ℹ️ Nota: O token de acesso (access token) é gerado no logon e inclui os SIDs de todos os grupos de que o utilizador é membro directo ou aninhado. Por isso, se alterar a filiação de um grupo, o utilizador precisa de fazer logoff e logon novamente para que a alteração tenha efeito.
A documentação oficial completa dos Security Groups está em Understand Security Groups no Microsoft Learn. Para consulta de utilizadores, consultar a referência do cmdlet Get-ADUser; para modificar propriedades, Set-ADUser. Para inventariar grupos existentes, consultar também Get-ADGroup e Set-ADGroup. Para configuração de Samba AD como alternativa Linux, ver o Samba AD: Controlador de Domínio Open Source.
2. Grupos de Segurança vs Grupos de Distribuição
O Active Directory distingue dois tipos de grupos:
| Propriedade | Security Group | Distribution Group |
|---|---|---|
| Finalidade | Autorização (ACL, GPO, permissões) | Listas de distribuição de email |
| Pode ser usado em ACL? | Sim | Não |
| Recebe SID? | Sim | Não |
| Usado por Exchange/Entra? | Sim | Sim (apenas email) |
| Recomendado para PME | Sim — sempre | Raramente; usar grupos de segurança com email habilitado |
⚠️ Atenção: Num ambiente PME com Exchange ou Microsoft 365, recomenda-se usar Security Groups habilitados para email em vez de Distribution Groups. Assim, o mesmo grupo serve para permissões de pastas e para listas de distribuição, reduzindo objectos duplicados. Converter um Distribution Group num Security Group é possível mas pode afectar permissões existentes — testar antes em ambiente de validação.
O conceito de controlo de acesso baseado em grupos está documentado em Access Control. Para gestão de identidade híbrida com Entra Connect, consultar o BitLocker + Entra Hybrid Join.
3. Âmbitos: Global, Domain Local e Universal
Cada Security Group tem um âmbito que determina onde pode ser usado e de onde pode ter membros:
| Âmbito | Membros podem ser de | Pode ser atribuído em | Uso típico em PME |
|---|---|---|---|
| Global | Mesmo domínio | Qualquer domínio na floresta | Agrupar utilizadores da mesma empresa/filial |
| Domain Local | Qualquer domínio ou domínio fidedigno | Apenas no próprio domínio | Atribuir permissões em recursos locais |
| Universal | Qualquer domínio na floresta | Qualquer domínio na floresta | Grupos que cruzam domínios (raro em PME) |
ℹ️ Nota: A grande maioria das PME tem um único domínio. Nesse cenário, o âmbito Global é suficiente para quase tudo. O padrão recomendado pela Microsoft é o modelo AGDLP (Account → Global → DomainLocal → Permission): contas em grupos globais, grupos globais aninhados em grupos Domain Local, e permissões atribuídas ao grupo Domain Local. Num domínio único, simplifica-se para AGP (Account → Global → Permission).
⚠️ Atenção: Grupos Universal são replicados para o Global Catalog, o que aumenta o tráfão de replicação entre sites. Numa PME com vários sites ligados por WAN, evitar grupos Universal sempre que possível.
4. Convenção de Nomenclatura para PME
A falta de uma convenção de nomenclatura é o problema mais frequente em PME. Grupos chamados “grp_contas”, “ContabilidadeNovo”, “ACESSO_PASTA3” e “financeiro” convivem sem lógica, tornando a auditoria impossível. Uma convenção simples e consistente reduz o tempo de diagnóstico e evita duplicações.
| Prefixo | Tipo | Exemplo | Descrição |
|---|---|---|---|
| GG_ | Global Group | GG_Fin_Equipa | Grupo global de utilizadores da equipa de Finanças |
| DL_ | Domain Local | DL_FS_Contas_RW | Permissão de leitura/escrita na partilha Contas |
| U_ | Universal | U_VPN_Acesso | Grupo universal (multi-domínio) |
| SG_ | Security Group genérico | SG_Printers_HP3 | Acesso à impressora HP sala 3 |
| M365_ | Microsoft 365 | M365_Lic_Premium | Atribuição de licença no Entra ID |
💡 Dica
Definir a convenção num documento curto (uma página) e incluí-la na política de TI. Qualquer novo grupo deve seguir o padrão. Grupos antigos podem ser renomeados sem afectar o SID — as permissões permanecem intactas. Para automatizar a verificação de conformidade da nomenclatura, consultar o Ransomware: Backup 3-2-1 Imutável sobre Git para sysadmin.
5. Criar Grupos com PowerShell
O módulo ActiveDirectory fornece o cmdlet New-ADGroup para criar grupos. O exemplo seguinte cria um grupo Global de segurança para a equipa de Finanças:
Import-Module ActiveDirectory
# Criar grupo Global de segurança para Finanças
New-ADGroup -Name “GG_Fin_Equipa” `
-SamAccountName “GG_Fin_Equipa” `
-GroupCategory Security `
-GroupScope Global `
-Path “OU=Grupos,OU=PME,DC=empresa,DC=local” `
-Description “Equipa de Finanças — acesso a partilhas e aplicações” `
-DisplayName “GG Finanças Equipa”
Para criar um grupo Domain Local destinado a permissões numa partilha:
-SamAccountName “DL_FS_Contas_RW” `
-GroupCategory Security `
-GroupScope DomainLocal `
-Path “OU=Grupos,OU=PME,DC=empresa,DC=local” `
-Description “Leitura/Escrita na partilha \\\\SRV01\\Contas”
ℹ️ Nota: O parâmetro -Path especifica a OU onde o grupo é criado. Manter todos os grupos numa OU dedicada (e não no contentor “Users” predefinido) facilita a aplicação de GPOs de delegação e a auditoria.
6. Gerir Membros: Adicionar e Remover
Adicionar membros a um grupo usa-se o cmdlet Add-ADGroupMember:
Add-ADGroupMember -Identity “GG_Fin_Equipa” -Members “jsilva”
# Adicionar múltiplos utilizadores de uma lista
$utilizadores = @(“jsilva”, “mferreira”, “acosta”)
Add-ADGroupMember -Identity “GG_Fin_Equipa” -Members $utilizadores
# Adicionar a partir de uma OU inteira
Get-ADUser -Filter * -SearchBase “OU=Financas,OU=PME,DC=empresa,DC=local” |
Add-ADGroupMember -Identity “GG_Fin_Equipa”
Para listar os membros de um grupo, usa-se Get-ADGroupMember:
Get-ADGroupMember -Identity “GG_Fin_Equipa”
# Listar todos os membros, incluindo grupos aninhados (recursivo)
Get-ADGroupMember -Identity “DL_FS_Contas_RW” -Recursive |
Select-Object Name, ObjectClass, distinguishedName |
Format-Table -AutoSize
Para remover membros, usa-se Remove-ADGroupMember:
Remove-ADGroupMember -Identity “GG_Fin_Equipa” -Members “jsilva” -Confirm:$false
# Remover todos os utilizadores inactivos (desactivados) de um grupo
$inactivos = Get-ADGroupMember -Identity “GG_Fin_Equipa” |
Where-Object { $_.ObjectClass -eq ‘user’ } |
Get-ADUser -Properties Enabled |
Where-Object { -not $_.Enabled }
if ($inativos) {
Remove-ADGroupMember -Identity “GG_Fin_Equipa” -Members $inativos -Confirm:$false
Write-Host “Removidos $($inativos.Count) utilizadores inactivos.”
}
⚠️ Atenção: O parâmetro -Confirm:$false suprime a confirmação interactiva. Em scripts de automação é necessário, mas em execução manual deve-se confirmar para evitar remoções acidentais. Sempre auditar o resultado com Get-ADGroupMember após alterações.
7. Aninhar Grupos: Regras e Boas Práticas
O aninhamento de grupos (colocar um grupo dentro de outro) reduz o número de atribuições individuais e simplifica a gestão. As regras de aninhamento dependem do âmbito:
| Grupo pai (contém) | Grupo filho (membro) | Permitido? |
|---|---|---|
| Global | Global | Sim (mesmo domínio) |
| Global | Domain Local | Não |
| Global | Universal | Não |
| Domain Local | Global | Sim |
| Domain Local | Domain Local | Sim |
| Domain Local | Universal | Sim |
| Universal | Global | Sim |
| Universal | Universal | Sim |
O padrão recomendado para PME de domínio único é aninhar grupos Global dentro de grupos Domain Local:
Add-ADGroupMember -Identity “DL_FS_Contas_RW” -Members “GG_Fin_Equipa”
Desta forma, a permissão na partilha é atribuída apenas ao grupo DL_FS_Contas_RW, e a gestão de membros é feita no grupo GG_Fin_Equipa. Se a equipa crescer, basta adicionar o utilizador ao grupo global — a permissão já está herdada.
ℹ️ Nota: O parâmetro -Recursive do Get-ADGroupMember percorre todo o aninhamento. Sem ele, apenas os membros directos são listados. Para auditoria de acesso efectivo, usar sempre -Recursive.
8. Delegação de Gestão sem Domain Admins
Uma das maiores falhas de segurança em PME é dar privilégios de Domain Admin a técnicos de suporte de 1ª linha. O correcto é delegar a gestão de grupos específicos a contas de serviço ou a técnicos designados, sem lhes dar acesso administrativo ao domínio.
O método mais robusto é usar o cmdlet Set-ADAccountControl combinado com permissões de ACL na OU dos grupos. No entanto, a forma mais simples é usar o assistente de Delegation of Control no Active Directory Users and Computers (ADUC), ou via PowerShell com dsacls:
$grupo = “GG_Fin_Equipa”
$tecnico = “suporte1”
# Usar dsacls para dar permissão de escrita na propriedade member
dsacls “\\empresa.local\OU=Grupos,OU=PME,DC=empresa,DC=local” /G “${tecnico}:WP;member” /I:S
💡 Dica
Para PME com mais de 50 utilizadores, criar uma OU “Grupos_Delegados” e delegar a gestão dos grupos dessa OU a um grupo “GG_TI_Suporte1”. Os técnicos podem adicionar/remover membros sem ser Domain Admins. Documentar a delegação num ticket (Registar e Documentar Tickets Correctamente) para rastreabilidade.
⚠️ Atenção: A delegação via dsacls é granular mas complexa. Testar primeiro num ambiente de validação. Uma alternativa é usar o módulo ActiveDirectory com Set-ACL e Get-ACL, mas requer conhecimentos de SDDL (Security Descriptor Definition Language).
9. Auditoria e Relatórios de Grupos
A auditoria periódica de grupos é essencial para segurança e conformidade (incluindo NIS2, abordado no NIS2: Checklist em 90 Dias). Os relatórios mais úteis para PME:
Get-ADGroup -Filter * -SearchBase “OU=Grupos,OU=PME,DC=empresa,DC=local” |
Where-Object { -not (Get-ADGroupMember $_.SamAccountName) } |
Select-Object Name, GroupScope, Description |
Export-Csv -Path “$env:USERPROFILE\Desktop\grupos_orfaos.csv” -NoTypeInformation -Encoding UTF8
# Relatório: grupos com mais de 50 membros (potencial sobrecarga)
Get-ADGroup -Filter * |
ForEach-Object {
$count = (Get-ADGroupMember $_.SamAccountName).Count
if ($count -gt 50) {
[PSCustomObject]@{
Grupo = $_.Name
Membros = $count
Scope = $_.GroupScope
}
}
} | Sort-Object Membros -Descending |
Export-Csv -Path “$env:USERPROFILE\Desktop\grupos_grandes.csv” -NoTypeInformation -Encoding UTF8
ℹ️ Nota: Em domínios grandes, Get-ADGroup -Filter * pode ser lento. Usar -Properties Member e processar a propriedade member directamente é mais eficiente do que chamar Get-ADGroupMember para cada grupo. Para PME com menos de 500 grupos, a diferença é irrelevante.
10. Grupos Predefinidos e Contas de Serviço
O Active Directory inclui grupos predefinidos como Domain Admins, Enterprise Admins, Account Operators e Server Operators. Estes grupos têm privilégios elevados e não devem ser usados para acesso a recursos de negócio. Para contas de serviço, o grupo Protected Users aplica restrições de credenciais que mitigam ataques de pass-the-hash.
| Grupo predefinido | Privilégio | Recomendação PME |
|---|---|---|
| Domain Admins | Controlo total do domínio | Máximo 2 contas, usar apenas para emergências |
| Enterprise Admins | Controlo total da floresta | 1 conta, em PME raramente necessário |
| Account Operators | Gerir utilizadores e grupos | Evitar; usar delegação granular |
| Server Operators | Administrar servidores membros | Restringir a equipa de infraestrutura |
| Protected Users | Restrições de credencial | Aplicar a contas de serviço e admins sensíveis |
⚠️ Atenção: O grupo Protected Users aplica restrições que podem quebrar aplicações antigas (Kerberos DES, NTLM). Testar com contas de serviço individuais antes de alargar. Em PME com aplicações legadas, pode ser necessário manter contas de serviço fora deste grupo e usar gMSA (Group Managed Service Accounts) como alternativa.
11. Integração com Microsoft 365 e Entra ID
Num ambiente híbrido com Entra Connect (antigo Azure AD Connect), os Security Groups do AD on-premises são sincronizados para o Entra ID e podem ser usados para atribuir licenças de Microsoft 365, acesso ao SharePoint, Teams e aplicações SaaS. A sincronização respeita o âmbito: grupos Universal e Global são sincronizados por defeito; grupos Domain Local não são sincronizados (não são suportados no Entra ID).
💡 Dica
Para gestão de licenças do Microsoft 365, criar grupos dedicados com prefixo M365_ e atribuir licenças via group-based licensing no portal Entra. Nunca reutilizar grupos de permissões de pastas para licenças — a semântica é diferente e cria confusão. Para migração Google Workspace para Microsoft 365, consultar o BitLocker + Entra ID Join.
12. Erros Comuns na Gestão de Grupos
| Problema | Causa | Solução |
|---|---|---|
| Utilizador não consegue aceder a partilha após ser adicionado a grupo | Token de acesso não actualizado — alteração feita após logon | Pedir ao utilizador para fazer logoff e logon novamente |
| Grupo Domain Local não aparece no Entra ID | Grupos Domain Local não são sincronizados | Migrar para grupo Global ou Universal antes de sincronizar |
Add-ADGroupMember falha com “object not found” |
SamAccountName incorrecto ou conta desactivada | Verificar com Get-ADUser -Identity x antes de adicionar |
| Remoção de membro não tem efeito | Membro é membro de subgrupo aninhado, não directo | Usar Get-ADGroupMember -Recursive para identificar o caminho |
| Grupos com nomes duplicados em OUs diferentes | Sem convenção de nomenclatura | Implementar convenção (ver secção 4) e renomear com Rename-ADGroup |
| Permissão de pasta não funciona mesmo com grupo correcto | Grupo criado após o logon; ou permissão NTFS vs partilha em conflito | Verificar permissões NTFS efectivas com Effective Access no File Explorer |
| Conta de serviço perde acesso após reinício | Conta movida para Protected Users sem testar compatibilidade Kerberos | Remover do Protected Users e testar com gMSA |
13. Checklist de Gestão de Security Groups
- [ ] Convenção de nomenclatura documentada e comunicada à equipa
- [ ] Todos os grupos criados em OU dedicada (não no contentor Users)
- [ ] Padrão AGDLP aplicado: grupos Global aninhados em Domain Local
- [ ] Nenhum técnico de 1ª linha com privilégios de Domain Admin
- [ ] Delegação de gestão documentada por grupo/OU
- [ ] Relatório mensal de grupos sem membros (órfãos)
- [ ] Relatório trimestral de membros de grupos privilegiados (Domain Admins, Enterprise Admins)
- [ ] Grupos Domain Local não usados para sincronização Entra ID
- [ ] Contas de serviço sensíveis migradas para Protected Users ou gMSA
- [ ] Auditoria de access tokens: utilizadores testam após alterações de grupo
- [ ] Backup do estado dos grupos antes de alterações em massa (
Get-ADGroup -Properties * | Export-Clixml) - [ ] Integração com ticketing: cada alteração de grupo documentada num ticket (Registar e Documentar Tickets Correctamente)
