Administradores locais com Restricted Groups: verificar Members antes da implantação

O que as políticas de administradores locais com Restricted Groups realmente controlam

A revisão das políticas de administradores locais com Restricted Groups começa com uma pergunta prática: quais identidades precisam manter acesso administrativo em cada estação de trabalho ou servidor membro? Uma entrada de GPO é apenas uma parte das evidências. Antes de implantar uma configuração de referência para a associação ao grupo, compare a população prevista com o grupo real, examine as duas propriedades de associação da política e comprove quais computadores a recebem.

Este guia descreve um procedimento de verificação e implantação, conferido com a documentação da Microsoft e a implementação do etc-collector em 4 de outubro de 2026. Os comandos são exemplos de consulta para um administrador Windows autorizado; nenhum foi executado em um domínio para este artigo. Não se afirma que houve qualquer alteração de associação ou resultado de implantação.

A Microsoft documenta duas operações diferentes em Restricted Groups:

A Microsoft oferece suporte a esse mecanismo para grupos locais, não para gerenciar a associação de grupos de domínio. Adicionar um grupo de segurança do domínio ao grupo Administrators local de um computador é uma operação diferente de editar os membros desse próprio grupo de domínio. Este procedimento se aplica a estações de trabalho e servidores membros; os controladores de domínio exigem um projeto de administração separado.

O grupo local também difere da atribuição de direitos de usuário. Revise privilégios de GPO como SeDebug e SeTcb separadamente da associação ao grupo Administrators local. Uma revisão da associação ao grupo não pode certificar essas atribuições de privilégios.

Como funciona: leia a política antes de interpretar o achado

Nos arquivos SYSVOL da GPO, examine Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf, incluindo toda a seção [Group Membership]. Registre o GUID da GPO, o nome de exibição, o controlador de domínio de origem, o horário da coleta e se a leitura do arquivo foi bem-sucedida. Preserve as linhas originais junto com a visualização no editor de políticas.

O exemplo a seguir é um modelo ilustrativo, que reflete o formato de chave lido pelo coletor. Os valores entre sinais de menor e maior são marcadores de posição, não SIDs válidos nem uma configuração de referência pronta para implantação:

[Group Membership]
*S-1-5-32-544__Members = *<approved-domain-group-SID>,*<approved-local-account-SID>

Identifique a entidade de segurança antes de __ e verifique se o arquivo real contém __Members, __Memberof, ambos ou nenhum deles para essa entidade. Registre um valor __Members explicitamente vazio separadamente de uma chave ausente. Essas diferenças não podem ser recuperadas apenas a partir de um array de membros vazio produzido pelo parser.

O procedimento de modelos de segurança da Microsoft mostra as duas áreas de edição: Members of this group e This group is a member of. Esse artigo descreve o fluxo histórico do snap-in do Windows Server 2003; use-o para compreender as propriedades, em vez de tratar sua interface antiga ou sua lista de plataformas como orientações atuais de implantação.

Prefira uma revisão baseada em SID quando os nomes de exibição diferirem entre idiomas. A documentação de identificadores de segurança da Microsoft identifica S-1-5-32-544 como o grupo Administrators integrado. Mantenha tanto o SID quanto o nome resolvido nas evidências. Um nome localizado ser válido no Windows não significa que a comparação de strings de um coletor o reconheça.

Não edite manualmente um arquivo SYSVOL de produção para fazer um achado de auditoria desaparecer. Revise e crie a GPO pretendida por meio do processo de gerenciamento aprovado e, depois, examine o arquivo resultante e o comportamento dos dispositivos.

Detecção: comprovar associação, escopo e alterações

Etapa 1 — Capturar o estado inicial do dispositivo

Em cada estação de trabalho ou servidor membro selecionado, obtenha a associação direta atual antes de alterar a política. A Microsoft fornece este exemplo exato de Get-LocalGroupMember para um nome de grupo em inglês:

Get-LocalGroupMember -Group "Administrators"

Para selecionar o grupo independentemente do idioma, a mesma documentação define o parâmetro -SID. Este exemplo de consulta usa esse parâmetro documentado com o SID do grupo integrado:

Get-LocalGroupMember -SID 'S-1-5-32-544'

Use um contexto compatível do Windows PowerShell; a Microsoft informa que o módulo LocalAccounts não está disponível no PowerShell de 32 bits em um sistema de 64 bits. Salve o resultado com a identidade do computador e o horário. Se o comando falhar, preserve o erro e marque o dispositivo como pendente, em vez de registrar um grupo vazio.

Para cada entidade de segurança retornada, registre seu SID, a conta ou o grupo resolvido, o responsável operacional e o motivo do acesso. Quando um grupo de domínio estiver listado, revise separadamente as pessoas e os grupos aninhados que recebem direitos por meio dele. A lista de membros locais diretos, por si só, não informa quem acaba recebendo acesso por esse grupo.

Etapa 2 — Comprovar que o computador recebe a política pretendida

Revise os vínculos da GPO, o estado da configuração do computador, a filtragem de segurança, a filtragem WMI e a herança. Inclua dispositivos representativos do escopo previsto e dispositivos que devem permanecer fora dele. Não deduza a aplicação da política a partir de um nome descritivo de GPO ou da presença de seu arquivo no SYSVOL.

A Microsoft documenta gpresult para informações do conjunto de políticas resultante. Estes exemplos somente de leitura combinam suas opções documentadas de escopo do computador e de saída:

gpresult /scope computer /r
gpresult /scope computer /h computer-policy.html

O primeiro exibe um resumo; o segundo salva um relatório HTML. Execute-os em um contexto autorizado que possa obter dados de política do computador. Preserve as evidências de GPOs aplicadas e negadas, o horário e quaisquer erros na geração do relatório. Em ARM64, a página da Microsoft especifica o executável gpresult do SysWow64 para a opção HTML.

Use RSoP para investigar a aplicação e a precedência e, depois, confirme a associação real no dispositivo. Nem um relatório nem um modelo legível substituem essa observação final.

Etapa 3 — Identificar outras fontes que alteram a associação

Inventarie os itens Local Users and Groups das Preferências de Política de Grupo, suas ações e seu direcionamento. A referência de Preferências de Política de Grupo da Microsoft lista essa extensão como um mecanismo para alterar usuários e grupos locais. Pergunte também ao responsável pelo gerenciamento de dispositivos sobre scripts e perfis MDM que afetem o mesmo grupo.

Para dispositivos gerenciados por MDM, examine o LocalUsersAndGroups Policy CSP. Sua ação Update pode adicionar ou remover membros especificados enquanto preserva os membros não especificados; Restrict substitui a associação. Para a ação Restrict desse CSP no grupo Administrators integrado, inclua a conta Administrator integrada na lista de membros a adicionar; a Microsoft documenta um erro se uma substituição tentar removê-la. A documentação alerta que aplicar as políticas CSP LocalUsersAndGroups e RestrictedGroups ao mesmo dispositivo não é compatível. Esse alerta se refere às duas políticas CSP nomeadas; não é uma regra universal de precedência para toda combinação de GPO e MDM.

Documente qual sistema controla a associação para cada população de dispositivos. Resolva instruções sobrepostas antes do piloto; não suponha qual fonte deixará o estado final pretendido.

Etapa 4 — Monitorar adições e remoções

As páginas de eventos da Microsoft confirmam estes registros no log de Segurança sob Audit Security Group Management:

Colete nos dispositivos relevantes, não apenas nos controladores de domínio. Para este fluxo, selecione eventos cujo TargetSid seja S-1-5-32-544 e preserve o computador, o horário, MemberSid, a identidade do autor da ação e SubjectLogonId. Verifique se a coleta e o encaminhamento da auditoria funcionam antes de confiar na ausência de eventos.

Compare as alterações com o registro de implantação e os testes de aplicações. Uma adição inesperada após uma atualização de política pode justificar a investigação de outra fonte de gerenciamento ou de uma alteração manual; ela não identifica, por si só, a GPO responsável nem comprova um ataque. Esses eventos descrevem alterações de associação, não a lista completa de membros atuais.

Correção: implantar uma configuração de associação aprovada (Remediation)

Etapa 1 — Aprovar a população com acesso

Crie configurações de referência separadas quando as funções de estações de trabalho e servidores tiverem necessidades diferentes. Para cada entidade de segurança mantida, exija um responsável, uma finalidade e um escopo. Para cada remoção proposta, peça ao responsável pela aplicação ou pelo suporte afetado que valide o impacto. Registre exceções com sua população de dispositivos, justificativa e data de revisão.

Use o modelo de administração por tiers para definir responsáveis, populações administrativas e limites de logon. Uma configuração de referência para a associação local faz parte dessa arquitetura; ela não substitui a decisão sobre onde essas identidades podem iniciar sessão.

Etapa 2 — Estabelecer uma rota de recuperação utilizável

Antes da substituição, teste o processo de recuperação aprovado nos dispositivos piloto. Confirme a conta administrativa local designada, sua associação necessária e a capacidade da equipe autorizada de recuperar o acesso caso a administração normal do domínio falhe. Mantenha credenciais fora das exportações de revisão de políticas e dos arquivos compartilhados de evidências.

O Windows LAPS gerencia e faz backup das senhas de contas de administrador local em dispositivos ingressados compatíveis. Para uma conta de recuperação gerenciada pelo LAPS, verifique o gerenciamento de senha e a recuperação autorizada dessa senha separadamente da associação da conta e de uma rota de logon utilizável. A simples existência de uma política LAPS não conclui o teste de recuperação.

Etapa 3 — Preparar a política e os critérios de aprovação do piloto

Faça backup da GPO existente e preserve as observações anteriores dos membros. Prepare a lista aprovada no editor de políticas, revise o modelo resultante e defina os vínculos e filtros exatos do piloto. Combine as responsabilidades de reversão e um procedimento de restauração da associação, não apenas da configuração da GPO.

Não suponha que remover um vínculo de GPO recriará todos os membros removidos durante a aplicação. Exija um procedimento de recuperação testado que restaure o acesso necessário e trate a fonte que controla a associação. Pause se a coleta, a responsabilidade, a resolução de nomes ou o escopo permanecerem incertos.

Etapa 4 — Validar após a aplicação

Implante na população piloto por meio do processo de alteração aprovado. Depois do processamento da política, repita os comandos de consulta de associação e gpresult apresentados acima. Compare os SIDs anteriores e posteriores com a lista aprovada e o comportamento documentado da conta integrada. Revise as adições e remoções durante a janela de alteração.

Peça aos responsáveis por aplicações e suporte que testem suas tarefas administrativas reais, rotinas de manutenção e acesso de recuperação. Repita as observações após processamentos posteriores da política ou atividades de gerenciamento de dispositivos para revelar fontes conflitantes. Um dispositivo inacessível ou um teste de aplicação que falhou continua sendo um critério de implantação pendente.

Etapa 5 — Expandir somente com evidências registradas

Avance por função de dispositivo ou população administrativa depois que o responsável pelo piloto aceitar os resultados. Preserve as exceções explicitamente, em vez de ocultá-las em um grupo mais amplo. Agende revisões posteriores da associação e alertas para desvios do estado aprovado. Mantenha os dispositivos excluídos e não observados visíveis no relatório.

Como o EtcSec detecta isso

A verificação M29_LOCAL_ADMIN_NOT_RESTRICTED do EtcSec é um sinal de revisão de configuração. O código-fonte do etc-collector foi lido no commit 15fc6399c215eabc415c370b762303cfcd7a353a, incluindo m29_local_admin.go:38, gptmpl_parser.go:367 e SMB client.go:154 e :214.

Os ramos reais de Detect() são:

Count 1 é o sinal desse detector, não uma contagem de computadores afetados. A comparação não aceita outros nomes localizados. Ela não avalia MembersSIDs, MemberOfSIDs, a população com acesso aprovada, os vínculos ou a aplicabilidade da GPO, nem a associação real no dispositivo.

O parser agrega Members e Memberof em uma especificação por entidade de segurança e cria essa especificação antes de verificar o sufixo. Um valor Members vazio e uma propriedade Members ausente são indistinguíveis no array de membros resultante. Assim, uma especificação correspondente que contenha apenas Memberof pode suprimir o achado sem estabelecer uma configuração de substituição de Members.

O provedor SMB preenche os valores da política quando a leitura de GptTmpl.inf é bem-sucedida. Ele ainda insere um objeto de política quando essa leitura falha. Para esta verificação, uma falha de leitura pode parecer uma configuração ausente; o achado não expõe uma distinção específica para o sucesso da coleta. Uma entrada correspondente em uma GPO fora do escopo efetivo de um computador também pode suprimir o sinal.

A decisão de implantação deve identificar a política exata, as populações aprovadas, as observações do piloto, o teste de recuperação e os dispositivos pendentes. Um detector silencioso, por si só, não é evidência suficiente para encerrar essa decisão.