Filtragem GPO MS16-072: repor Read e preservar o âmbito

O que é a filtragem GPO MS16-072?

A resolução de problemas da filtragem GPO MS16-072 começa com duas perguntas distintas: o computador consegue obter a política de utilizador e o utilizador com sessão iniciada tem permissão para a aplicar? Uma política destinada a um pequeno grupo de utilizadores pode deixar de funcionar quando o computador perde a permissão Read. Repor uma permissão Apply abrangente pode fazer a política funcionar, mas também alterar o seu público previsto.

O artigo de suporte sobre MS16-072 da Microsoft documenta a alteração introduzida em 14 de junho de 2016: o Windows obtém as GPO de utilizador no contexto de segurança do computador, em vez do contexto do utilizador. A solução indicada é a permissão Read para Authenticated Users ou para Domain Computers quando se utiliza filtragem de segurança. O boletim MS16-072 associa a atualização ao artigo 3163622 da Microsoft Knowledge Base; os pacotes de atualização instaláveis dependem da versão do Windows. Trata-se de uma alteração de processamento já estabelecida, não de um problema recentemente descoberto.

O objetivo prático é restabelecer a obtenção da política preservando os destinatários previstos. A mesma revisão deve distinguir as políticas que devem estar em produção dos pares AD/SYSVOL incompletos, das políticas desativadas com ligações ativas, dos objetos não utilizados e das delegações questionáveis. Estes estados exigem decisões diferentes; fazer com que todas as políticas sejam aplicadas não é um objetivo de correção útil.

Como funciona: Read, Apply e o âmbito das ligações

As orientações atuais de resolução de problemas da Microsoft explicam por que remover Authenticated Users de Security Filtering pode impedir o funcionamento das políticas de utilizador: essa ação remove tanto Read como Apply Group Policy. Um grupo de utilizadores específico pode manter as suas permissões enquanto a conta de computador deixa de conseguir obter a GPO.

Read adicionado através do separador Delegation da GPMC é diferente da entrada designada Read (from Security Filtering). Esta última inclui Apply; Read simples restabelece a obtenção sem conceder esse direito de aplicação. Mantenha o grupo de utilizadores previsto em Security Filtering e conceda Read à população de computadores adequada através de Delegation.

A filtragem de segurança atua nos locais abrangidos pelas ligações da GPO. A referência sobre filtragem de segurança da Microsoft explica que pertencer a um grupo, por si só, não inclui um utilizador fora do âmbito num site, domínio ou OU com uma ligação. Adicionar Apply abrangente pode alargar os destinatários dentro do âmbito aplicável das ligações; não aplica automaticamente a GPO a todo o domínio. Esta página histórica explica o mecanismo da filtragem e deve ser lida em conjunto com as orientações atuais sobre Read para os computadores.

A documentação sobre processamento de Group Policy da Microsoft descreve condições adicionais: secções desativadas, filtros WMI e processamento loopback. Merge acrescenta a lista de políticas de utilizador baseada no computador depois da lista do utilizador; Replace utiliza a lista baseada no computador em substituição. Registe o modo real antes de interpretar um resultado. Para loopback Merge, o artigo de suporte MS16-072 instrui especificamente os administradores a adicionar os utilizadores e computadores previstos em Scope > Security Filtering. Valide separadamente essa configuração dirigida; a correção geral de Read para os computadores descrita acima não constitui um procedimento completo de loopback.

A sequência da falha e as políticas que exigem revisão

Uma sequência comum de falha é simples: um administrador restringe uma GPO de utilizador a um grupo de negócio, remove Authenticated Users e depois verifica que as definições de utilizador estão ausentes nos computadores relevantes. O grupo alvo continua a parecer correto. A dependência em falta é Read para os computadores. Voltar a adicionar Authenticated Users a Security Filtering pode ocultar essa dependência ao repor tanto Read como Apply.

A Microsoft documenta a falha na aplicação de políticas de utilizador como um sintoma; o seu exemplo de resolução de problemas inclui um erro no relatório de resultados. Não assuma que esta falha é sempre silenciosa, nem trate cada definição ausente como prova de um problema de permissões MS16-072.

Outros estados de GPO merecem uma decisão separada antes de alguém criar ligações ou reativá-las:

• Inconsistência AD/SYSVOL: verifique o objeto do diretório e os ficheiros correspondentes, a replicação e as cópias de segurança recuperáveis. Um resultado de objeto órfão não justifica, por si só, voltar a utilizar a política ou eliminá-la.
• Ambas as secções desativadas, mas uma ligação ativa: determine se se trata de manutenção deliberada ou de uma ligação obsoleta. O resultado não significa que as definições desativadas estejam atualmente a ser aplicadas.
• Nenhuma ligação inventariada: identifique um rascunho, uma política de reserva ou uma implementação esquecida. A ausência de ligação é um sinal de inventário, não uma prova de comprometimento.
• Delegação questionável em torno de políticas e ligações: examine os titulares de permissões e os objetos relevantes. Um resultado de permissões não prova que alguém tenha inserido uma ligação maliciosa.

Para a questão distinta de quem pode reescrever definições, configurações incorretas de GPO como vetor de ataque explica a exposição através de direitos de edição de políticas e de configurações fracas. Para uma OU privilegiada, ACL fracas de GPO no Tier 0 explica por que bloquear a herança não protege as permissões de edição da própria GPO ligada. O acesso de leitura, o acesso de edição de políticas e o acesso de escrita de ligações exigem, cada um, as suas próprias provas.

Deteção: medir permissões e resultados reais

Comece por uma GPO afetada, identificada sem ambiguidade. O exemplo 3 da referência Get-GPPermission da Microsoft apresenta este comando:

Get-GPPermission -Name "TestGPO" -All

Substitua o nome do exemplo pela política real. O cmdlet apresenta os principais que têm permissões nessa GPO; não é uma simulação completa do processamento de políticas. Se os nomes forem ambíguos, utilize o GUID da GPO. As seguintes consultas individuais adaptam parâmetros documentados:

Get-GPPermission -Name "TestGPO" -TargetName "Domain Computers" -TargetType Group

Get-GPPermission -Name "TestGPO" -TargetName "Authenticated Users" -TargetType Group

Get-GPPermission -Name "TestGPO" -TargetName "GPO-Users-Cible" -TargetType Group

Utilize nomes resolvidos do seu domínio. Compare Read para os computadores, a permissão Apply do grupo previsto e qualquer Apply abrangente inesperado. Um resultado ausente ou um erro não constitui uma verificação de permissões bem-sucedida. Examine permissões personalizadas e entradas Deny explícitas, em vez de inferir o acesso efetivo a partir de um nível resumido.

Para o resultado do processamento, o exemplo de resolução de problemas da Microsoft utiliza:

gpresult /h gpresult.html

Execute um teste positivo e um teste negativo de utilizador e examine os relatórios gerados. Preserve o computador, o utilizador, a identidade da GPO, as ligações relevantes e qualquer erro com cada resultado. A matriz de diagnóstico abaixo ajuda a manter visíveis as explicações concorrentes:

Estes são comandos documentados e um procedimento de validação proposto. Não são aqui alegados resultados de testes AD nem capturas de registos de eventos.

Correção: repor Read sem alargar Apply (Remediation)

1. Registar o público previsto e o estado atual

Antes de alterar permissões, preserve o estado da política e determine o seu responsável, os utilizadores alvo, os computadores de início de sessão, o âmbito das ligações e o modo de processamento. Determine que população de computadores necessita de Read. Authenticated Users, Domain Computers ou um grupo de computadores adequado são opções a avaliar face a essa população; verifique Deny explícito separadamente.

2. Conceder Read aos computadores através de Delegation

Na GPMC, abra o separador Delegation da GPO afetada, selecione Add, escolha o grupo ou objeto de computador, selecione Read e confirme. Mantenha Apply no grupo de utilizadores previsto. A página de resolução de problemas da Microsoft documenta este procedimento e a distinção resultante entre Read simples e Read proveniente de Security Filtering.

Para uma pré-visualização em PowerShell, este exemplo utiliza parâmetros da documentação Set-GPPermission da Microsoft:

Set-GPPermission -Name "TestGPO" -TargetName "Domain Computers" -TargetType Group -PermissionLevel GpoRead -WhatIf

-WhatIf permite pré-visualizar a operação; não aplica a alteração. Utilize a GPO e o titular de permissões reais, reveja a pré-visualização e execute a alteração aprovada numa única política através do procedimento escolhido.

3. Corrigir uma concessão acidental de Apply abrangente

Se Authenticated Users deve apenas ler esta GPO dirigida, pré-visualize a substituição do seu nível atual de permissões:

Set-GPPermission -Name "TestGPO" -TargetName "Authenticated Users" -TargetType Group -PermissionLevel GpoRead -Replace -WhatIf

A documentação indica que um nível de permissões existente mais elevado permanece inalterado, a menos que se utilize -Replace. Por isso, pedir apenas GpoRead pode deixar uma concessão Apply existente em vigor. A substituição só é adequada após confirmar que o principal deve perder a sua permissão mais elevada nessa GPO. Preserve a permissão Apply do grupo alvo e o estado registado para reverter a alteração.

4. Validar a aplicação e resolver os resultados de inventário

Repita as medições de permissões e ambos os testes de utilizador. Verifique a aplicação esperada, a exclusão de utilizadores fora do grupo alvo e as condições de processamento relevantes. Para objetos órfãos, valide ambos os componentes de armazenamento antes de restaurar ou retirar de utilização. Para políticas desativadas mas com ligação, confirme a intenção e remova ligações obsoletas quando apropriado; não reative automaticamente as definições. Reveja concessões questionáveis com o seu responsável, incluindo os direitos de escrita de ligações independentemente das permissões no contentor de políticas.

Como a EtcSec deteta este problema

As descrições seguintes refletem sete implementações Detect() revistas no commit c38a5bb9d0d847a56980c8ba02c7b0169abbc69f do etc-collector. Descrevem sinais de configuração, não sete ataques comprovados nem um teste executado neste ambiente.

Verificações de filtragem

GPO_AUTHENTICATED_USERS_APPLY seleciona GPO com uma ligação ativa e uma entrada ACL de Authenticated Users com o bit Apply. O adaptador LDAP associa esse bit ao direito alargado relevante; a Microsoft documenta Apply Group Policy como o direito utilizado para determinar a aplicação. O próprio Detect() não rejeita entradas Deny, não calcula o acesso efetivo, não avalia WMI e não verifica secções desativadas. Uma política de base intencionalmente abrangente pode legitimamente produzir um sinal para revisão.

GPO_NO_SECURITY_FILTERING procura GPO ativas com ligação e Apply para Everyone ou Authenticated Users, sem outro titular específico de Apply, excluindo Domain Computers desse teste de titular específico. Um grupo específico não anula uma concessão Apply abrangente, pelo que o detetor pode não identificar um alargamento quando ambos coexistem. Também não calcula o acesso efetivo nem o estado das secções. Estas duas verificações sobrepõem-se e devem ser revistas como uma única questão de filtragem, em vez de serem contadas como provas independentes de exposição.

Nenhum dos predicados estabelece que falta Read para os computadores. Utilize as medições de permissões e os testes de processamento acima para o diagnóstico MS16-072.

Verificações de inventário

GPO_ORPHANED utiliza os resultados SYSVOL fornecidos dos tipos orphaned_ldap ou orphaned_sysvol. Se não for devolvido um resultado órfão correspondente, o seu mecanismo alternativo LDAP sinaliza um caminho de ficheiros vazio ou um objeto com DisplayName e CN ambos vazios. Esse mecanismo alternativo pode ser executado mesmo quando foram fornecidos outros resultados SYSVOL. Um objeto LDAP completo cuja pasta SYSVOL desapareceu pode escapar a esse mecanismo. Registe se foram fornecidas provas SYSVOL; este não é um detetor de um gPLink que referencia uma GPO em falta.

GPO_DISABLED_BUT_LINKED exige Flags = 3, o que significa que ambas as secções estão desativadas, e uma ligação ativa. Identifica um estado de inventário a explicar, não definições desativadas atualmente aplicadas.

GPO_UNLINKED encontra GPO sem qualquer ligação inventariada, incluindo as ligações desativadas no conjunto de GPO com ligação, e exclui os GUID das duas GPO predefinidas. Não significa o mesmo que uma ligação desativada, secções desativadas ou um par AD/SYSVOL órfão. Reveja o ciclo de vida e a intenção antes de ligar ou retirar o objeto de utilização.

Verificações de delegação

GPO_MODIFY_RIGHTS verifica a pertença direta ou resolvida através do grupo primário a Group Policy Creator Owners, identificado pelo RID 520. Não percorre pertenças aninhadas. A referência sobre identificadores de segurança da Microsoft descreve a capacidade do grupo para criar GPO e a propriedade do criador sobre os novos objetos. A pertença, por si só, não prova direitos de edição sobre todas as GPO existentes nem permissão para as ligar. Reveja a pertença e as políticas e delegações detidas por esses membros.

GPO_LINK_POISONING seleciona ACE de concessão cujo DN de objeto contém CN=Policies,CN=System e cuja máscara inclui GenericAll, GenericWrite ou WriteDACL. O próprio Detect() não exclui administradores, não examina a ACL de cada GPO, não estabelece acesso de escrita ao gPLink de uma OU e não identifica uma ligação maliciosa existente. O seu Count representa objetos distintos; TotalInstances pode incluir várias ACE. Valide o titular de permissões e a delegação, depois examine separadamente as permissões de ligação relevantes do site, domínio ou OU. A documentação sobre âmbito da Microsoft situa gPLink nesses objetos, e o seu procedimento de delegação gere aí as permissões Link GPOs.