AD workstation em OU de servidor: validar políticas antes da mudança

O que é a revisão de uma AD workstation em OU de servidor?

Uma revisão de uma AD workstation em OU de servidor verifica se a localização de um computador no diretório corresponde à sua finalidade real e às políticas que deve receber. Um computador ativado que parece ser uma workstation dentro de uma OU cujo nome sugere servidores merece uma revisão. A localização, por si só, não demonstra uma falha de política, um incidente de segurança ou uma violação de conformidade.

A pergunta útil é específica: mover este computador alteraria o resultado pretendido das políticas, e o responsável consegue demonstrar que a alteração é adequada? Comece pela função real do dispositivo e pela convenção de OUs da organização. Depois, preserve o resultado atual das políticas do computador, reveja o destino proposto e teste um piloto aprovado antes de alargar a alteração.

Este guia aborda um sinal de classificação de WORKSTATION_IN_SERVER_OU. Não introduz uma estrutura universal de OUs. Uma hierarquia partilhada, um nome herdado ou um endpoint de finalidade específica documentado podem explicar um resultado. A revisão deve produzir uma decisão de localização com responsabilidade definida e provas das políticas que a sustentem, incluindo a decisão de manter a localização atual quando houver justificação.

Como a localização se relaciona com o âmbito das políticas

A referência da Microsoft sobre o processamento de Políticas de Grupo descreve o processamento local, de site, de domínio e de OU, incluindo OUs superiores. A ordem das ligações, a imposição, o bloqueio de herança, as secções desativadas, a filtragem de segurança e a filtragem WMI afetam o resultado. A grafia do nome de uma OU não é uma definição de política.

Prepare uma comparação entre a origem e o destino na GPMC. Registe as ligações relevantes e a herança de cada localização. Depois, identifique as definições que o responsável pelo dispositivo espera manter, receber ou perder. Use as identidades das políticas, além dos nomes de apresentação, para não confundir GPOs com nomes semelhantes no registo da alteração. Resolva as diferenças sem explicação antes de agendar o piloto.

Para a camada de permissões, leia o nosso guia sobre Read para computadores, Apply direcionado e filtragem de segurança de GPOs. Read e Apply Group Policy são distintos; a obtenção pelo computador e o conjunto de destinatários pretendido para aplicação exigem verificações separadas. Esse guia apoia a revisão do âmbito aqui apresentada. Não demonstra que o nome de uma OU tenha causado uma falha.

Quando a experiência do utilizador depende do computador, reveja também o loopback. A referência de processamento da Microsoft distingue Merge, que acrescenta a lista de políticas de utilizador baseada no computador, de Replace, que utiliza essa lista em substituição da outra. Registe o modo configurado e inclua testes com utilizadores representativos quando for relevante. Um resultado apenas do computador não responde a todas as perguntas sobre sessões de utilizador.

Existe ainda um problema separado relativo ao contentor predefinido. O nosso guia sobre CN=Computers, redirecionamento e resultados de políticas no cliente explica que o contentor predefinido não pode ter uma ligação direta a uma GPO como uma OU. Redirecionar a criação futura, deslocar objetos existentes e validar os resultados dos clientes são tarefas distintas. Um objeto que já esteja numa OU chamada Servers não exige automaticamente esse procedimento de redirecionamento.

Deteção: identificar o dispositivo e preservar o seu resultado

1. Confirmar os dados de entrada do resultado

Para cada candidato, conserve o distinguished name, sAMAccountName, o atributo de diretório operatingSystem, o estado de ativação, a hora de recolha e o âmbito da recolha. Identifique a parte do DN que correspondeu ao padrão de nomes de servidores. Uma correspondência num antepassado tem uma explicação administrativa diferente de uma correspondência no elemento superior imediato, embora o detetor aceite ambas.

Peça ao responsável pelo dispositivo que verifique a função atual e o sistema operativo através do inventário de endpoints de confiança da organização ou de uma verificação autorizada do dispositivo. Reconcilie as divergências com os atributos do diretório. Um prefixo no nome é uma pista de investigação; não constitui prova independente de que o host seja atualmente um desktop ou de que deva ser movido.

Use esta matriz de revisão para manter as provas separadas:

2. Recolher o RSoP do computador antes de alterar a localização

A Microsoft documenta Get-GPResultantSetOfPolicy como um cmdlet que escreve informações de RSoP num ficheiro. A sintaxe aceita Computer, ReportType e Path. O exemplo seguinte, destinado ao leitor, adapta esses parâmetros documentados a uma workstation fictícia e a um nome de ficheiro para a referência inicial:

Get-GPResultantSetOfPolicy -Computer 'pc01.contoso.com' -ReportType Xml -Path 'C:\Reports\pc01-before.xml'

Use o nome verificado do dispositivo, um diretório de relatórios disponível e uma conta autorizada no seu ambiente. A orientação da Microsoft sobre Group Policy Results documenta o acesso remoto através da permissão delegada Remotely access Group Policy Results data no domínio ou na OU que contém o objeto, ou através da pertença ao grupo local Administrators do computador de destino. Verifique também a conectividade de rede com o destino. Conserve o relatório com a identidade do objeto, o DN original, a hora de recolha e o registo da revisão. Inspecione o contexto de registo devolvido e a secção do computador no relatório para confirmar que as provas dizem respeito ao dispositivo pretendido. Uma consulta falhada deixa o resultado desconhecido; não representa uma referência inicial vazia obtida com sucesso.

O cmdlet devolve resultados de registo. A Microsoft encaminha os administradores para a GPMC para a modelação de RSoP. Por isso, este relatório regista o processamento observado em vez de prever o resultado no destino. Compare-o com a referência aprovada e enumere as diferenças por resolver antes de considerar uma mudança. Quando uma definição controla um serviço ou uma proteção, planeie também uma verificação operacional correspondente.

Correção: validar um piloto antes de mover mais hosts (Remediation)

1. Escolher uma decisão documentada

Classifique o candidato revisto como uma exceção aprovada, uma divergência de classificação ou uma alteração de localização que exige validação. Registe o responsável, a explicação e as provas. Manter um objeto pode ser o resultado correto se a sua função e a política pretendida já estiverem satisfeitas. Mudar o nome de um dispositivo ou de uma OU apenas para eliminar a correspondência com a heurística não fornece provas de que o resultado das políticas tenha melhorado.

Para uma mudança proposta, documente o DN de origem, o destino aprovado, a diferença de política esperada, o dispositivo piloto, os critérios de aceitação e o responsável pela reversão. Confirme que a alteração diz respeito ao mesmo domínio e ao computador selecionado. Uma migração entre domínios exige um procedimento próprio revisto; está fora do exemplo de localização de um único computador aqui apresentado.

2. Rever a operação individual no diretório

A referência da Microsoft sobre Move-ADObject documenta Identity, TargetPath, WhatIf e Confirm. O exemplo seguinte substitui esses elementos da sintaxe por um DN de computador fictício e uma OU aprovada fictícia:

Move-ADObject -Identity 'CN=PC01,OU=Servers,DC=contoso,DC=com' -TargetPath 'OU=Workstations,DC=contoso,DC=com' -WhatIf

-WhatIf apresenta uma pré-visualização da operação. Não move o objeto nem simula o processamento de GPOs. Reveja a origem e o destino resolvidos antes de continuar. Nunca encaminhe todos os resultados através de uma pipeline para uma operação de mudança: o predicado não conhece a decisão do responsável, a adequação do destino nem o plano de manutenção aprovado.

Após validação e autorização, a operação individual do piloto pode utilizar os mesmos parâmetros documentados com confirmação:

Move-ADObject -Identity 'CN=PC01,OU=Servers,DC=contoso,DC=com' -TargetPath 'OU=Workstations,DC=contoso,DC=com' -Confirm

Substitua todos os identificadores do exemplo pelos valores revistos. A confirmação é um pedido de confirmação da execução; não substitui a aprovação organizacional nem valida o desenho das políticas. Estes são exemplos documentados para o leitor, não comandos executados num domínio AD para este artigo.

3. Comparar o resultado após o piloto

Verifique a nova localização no diretório e conclua o processamento de políticas exigido pelo plano de teste aprovado. A referência de processamento da Microsoft distingue arranque, início de sessão e atualização em segundo plano; a atualização em segundo plano não processa todas as extensões. Registe o contexto de processamento antes de interpretar um relatório recolhido após a mudança.

Recolha um resultado separado para o mesmo computador usando os parâmetros RSoP documentados:

Get-GPResultantSetOfPolicy -Computer 'pc01.contoso.com' -ReportType Xml -Path 'C:\Reports\pc01-after.xml'

Compare os dois relatórios conservados com as alterações esperadas e, depois, verifique as definições relevantes e os critérios de aceitação operacional. Quando o loopback for relevante, inclua as comparações aprovadas das sessões de utilizador. Investigue adições, omissões ou falhas inesperadas antes de alargar o piloto. Use o procedimento de reversão registado se os critérios de aceitação não forem cumpridos e verifique o resultado, em vez de assumir que restaurar o DN restaura todas as definições.

Encerre a revisão com a decisão, as provas e as exceções pendentes. Um resultado eliminado pode confirmar que o diretório deixou de corresponder a esta heurística. Os relatórios de políticas e as verificações operacionais estabelecem se o resultado pretendido foi alcançado. Não reúna estes critérios de conclusão num único estado verde.

Como a EtcSec deteta este caso

Esta secção descreve apenas WORKSTATION_IN_SERVER_OU, revisto no commit 20268a321609c193b79c5da6764f3f56950449cb do etc-collector, em public/internal/audit/detectors/ad/computers/organization/workstation-in-server-ou.go:37.

O detetor ignora computadores marcados como Disabled. Para os restantes computadores fornecidos, pesquisa todo o DN com os padrões não ancorados ou=server e ou=datacenter, sem distinguir maiúsculas de minúsculas. Estes padrões podem corresponder a um antepassado e a prefixos como OU=Serverless; não analisam um nome exato da OU imediatamente superior.

Um objeto selecionado é classificado como workstation se o seu sAMAccountName começar, sem distinguir maiúsculas de minúsculas, por ws, pc, laptop, desktop ou nb, ou se a cadeia do SO contiver Windows 10, Windows 11, Windows 7 ou Windows 8. Qualquer uma das vias é suficiente. Por exemplo, um prefixo correspondente pode selecionar um objeto sem uma cadeia de SO de workstation correspondente. São testes de cadeias de caracteres, não uma verificação em direto da função do dispositivo.

O fornecedor LDAP em public/internal/providers/ldap/client.go:515 fornece objetos de computador, e parser.go:220–278 lê o DN, o nome da conta, o sistema operativo e o controlo de conta de utilizador para o modelo de computador. O estado Disabled é derivado do controlo de conta de utilizador. Os valores configurados BaseDN e MaxComputers limitam o inventário; uma contagem de zero deve ser interpretada no âmbito real da recolha.

O resultado é informativo. O comentário do código identifica explicitamente uma heurística do produto sem uma norma de nomenclatura de um fornecedor ou regulador e não regista uma ativação confirmada em laboratório nem uma validação por introdução e reversão do estado. A descrição do resultado afirma um efeito incorreto de GPO, mas o predicado revisto não lê a função atual nem um relatório de políticas resultantes e não consegue sustentar essa afirmação causal.

Use o resultado para selecionar uma revisão documentada. Confirme a função e a convenção local, avalie o percurso das políticas e conserve provas de antes e depois para qualquer mudança aprovada. Não se afirma aqui um piloto AD bem-sucedido, uma correção de política ou um resultado de laboratório.