O que é triagem adminCount computador AD?
A triagem adminCount computador AD é o processo de explicar por que um objeto de diretório relacionado com uma máquina tem adminCount=1, antes de decidir se algo precisa de mudar. Um controlador de domínio, uma conta de serviço e um servidor membro comum podem aparecer na mesma lista de candidatos, embora exijam decisões muito diferentes. O resultado útil é uma classificação sustentada por evidências de identidade, pertença a grupos e permissões.
A referência do esquema Admin-Count da Microsoft descreve um atributo associado à proteção da ACL após a pertença direta ou transitiva a grupos administrativos. O marcador, por si só, não demonstra privilégios atuais, um caminho de ataque ou uma ACL obsoleta. Trate-o como um motivo para investigar o objeto, em vez de uma instrução para limpar um valor.
Este fluxo de trabalho produz um registo para cada SID: protegido, exceção justificada, resíduo plausível ou indeterminado. Complementa o nosso fluxo de trabalho para limpar adminCount obsoleto em contas de utilizador, que pede explicitamente aos leitores que classifiquem computadores e grupos separadamente. Os seus comandos de limpeza de utilizadores não devem tornar-se uma receita de manutenção em massa para máquinas.
Como a proteção afeta DCs, RODCs e outros objetos
O Apêndice C: Contas e grupos protegidos da Microsoft inclui tanto Domain Controllers como Read-only Domain Controllers na lista de grupos protegidos. O AdminSDHolder fornece permissões de modelo e o SDProp compara as permissões dos objetos protegidos com esse modelo. Os objetos protegidos têm a herança desativada; mover um deles para outra OU não remove a sua proteção.
Um DC ou RODC verificado pode, portanto, ter uma explicação legítima para a proteção. Determine a sua função e pertença reais, em vez de tratar todos os marcadores de máquinas como acesso administrativo acidental. Para uma estação de trabalho membro ou um servidor de aplicações, investigue os caminhos atuais de grupos e a sua finalidade empresarial. Nem o nome do host nem a sua localização na OU constituem evidência suficiente da sua função.
A pesquisa de computadores do coletor também é relevante: utiliza (objectClass=computer). Na revisão analisada, o parser reconhece explicitamente msDS-GroupManagedServiceAccount nessa população. Uma gMSA pode, por isso, aparecer como um resultado Computer sem ser um host comum. Confirme a classe estrutural devolvida e o responsável pelo serviço; não conceda uma exceção genérica apenas por se tratar de uma conta de serviço.
A explicação histórica do AdminSDHolder e do SDProp da Microsoft documenta marcadores residuais e herança desativada depois de um utilizador deixar de pertencer a grupos protegidos. Isso explica por que um resíduo é uma hipótese que merece ser testada. Não demonstra que um computador específico seja órfão, e a sua lista mais antiga de grupos protegidos não deve substituir o Apêndice C atual. O mesmo artigo descreve a proteção através de grupos de segurança ou distribuição aninhados, pelo que uma investigação de pertença deve preservar esses caminhos.
Deteção: recolher identidade e evidências independentes do diretório
Comece por Get-ADComputer, cujos parâmetros documentados incluem -LDAPFilter, -SearchBase, -Server e -Properties. Esta adaptação solicita os atributos necessários para investigar os computadores candidatos:
Get-ADComputer -LDAPFilter "(adminCount=1)" -SearchBase "DC=corp,DC=example" -Server "dc01.corp.example" -Properties adminCount,memberOf,primaryGroupID,PrimaryGroup,nTSecurityDescriptor,Enabled,SID,ObjectClass,userAccountControl
Esta consulta independente mantém deliberadamente os resultados ativados e desativados para classificação. A verificação EtcSec abordada abaixo seleciona apenas entradas Computer ativadas. Registe explicitamente o estado de ativação ao reconciliar as duas populações; uma diferença de âmbito não é necessariamente uma discrepância no marcador.
Utilize SID e DN para associar o resultado ao objeto do diretório. Preserve o seu GUID como outro identificador, a sua classe, o domínio e o servidor consultados, a hora de captura e quaisquer leituras falhadas. Guarde as evidências dos atributos em bruto, em vez de apenas uma listagem formatada no ecrã. Um resultado vazio numa base de pesquisa mais restrita não resolve um resultado recolhido noutro âmbito.
Para um candidato que se suspeita ser uma gMSA, utilize uma leitura independente da classe com o DN exato. Get-ADObject documenta a identificação por DN e propriedades adicionais:
Get-ADObject -Identity "CN=svcInventory,CN=Managed Service Accounts,DC=corp,DC=example" -Server "dc01.corp.example" -Properties objectClass,objectSid,adminCount,memberOf,primaryGroupID,nTSecurityDescriptor,userAccountControl
Compare essa identidade com o resultado antes de escolher o percurso de análise de host ou de conta de serviço. Uma pesquisa específica de computadores que falhe não deve descartar silenciosamente um objeto devolvido pelo filtro de classe mais abrangente do coletor.
| Observação | O que sustenta | O que falta determinar |
|---|---|---|
adminCount=1 | Marcador de candidato presente neste objeto | Proteção atual e significado da ACL |
| DC ou RODC verificado | Uma função com uma explicação plausível de proteção legítima | Pertença protegida relevante e permissões esperadas |
| Classe gMSA | É necessária uma análise da conta de serviço | Responsável, finalidade do serviço e caminhos de proteção |
| Host membro comum | Investigação da pertença específica do host | Se a proteção é justificada, residual ou não esclarecida |
| Falta de evidências da ACL ou do grupo primário | Uma lacuna de recolha | Resolução independente antes de uma decisão |
Correção: classificar cada objeto antes de aprovar alterações (Remediation)
Passo 1 — Estabelecer a referência de grupos protegidos
Resolva os grupos aplicáveis do Apêndice C nos domínios relevantes e na raiz da floresta, registando os seus SIDs e DNs. Os nomes podem ter sido alterados ou localizados. A referência de SID da Microsoft explica os identificadores de domínio e os identificadores relativos; utilize identidades de grupo verificadas em vez de uma comparação apenas pelo nome.
Get-ADGroup aceita um SID para -Identity e suporta propriedades adicionais. Esta adaptação documentada lê o grupo incorporado Administrators num contexto de domínio explícito:
Get-ADGroup -Identity "S-1-5-32-544" -Server "dc01.corp.example" -Properties memberOf,groupType
Repita a operação para os grupos protegidos aplicáveis utilizando os seus SIDs verificados. Este exemplo é uma única consulta, não um inventário completo de grupos protegidos. Separe as contas diretamente protegidas dos grupos de pertença e registe as exceções relevantes de configuração do domínio. Um grupo de referência não resolvido deixa a investigação incompleta.
Passo 2 — Resolver a pertença para além da primeira vista
Get-ADPrincipalGroupMembership suporta computadores, grupos e contas de serviço. O SID do exemplo é um valor de substituição para o SID verificado do candidato:
Get-ADPrincipalGroupMembership -Identity "S-1-5-21-111111111-222222222-333333333-1101" -Server "dc01.corp.example"
A Microsoft documenta que a pesquisa de grupos exige um catálogo global e que os grupos locais noutro domínio exigem o contexto de recursos apropriado. Registe os erros não terminantes como falhas na resolução da pertença, em vez de aceitar uma saída parcial como um resultado sem problemas. Consulte os domínios de recursos relevantes quando o objeto tiver pertenças nesses domínios.
Utilize os grupos devolvidos e as evidências de memberOf do objeto como pontos de partida. Para cada grupo, leia os seus grupos superiores com Get-ADGroup -Properties memberOf,groupType e continue até os caminhos terminarem ou atingirem o conjunto protegido verificado. Preserve as identidades intermédias, trate os ciclos e cubra os domínios envolvidos. Uma única invocação de cmdlet não é apresentada aqui como uma travessia transitiva completa e validada.
Passo 3 — Resolver o grupo primário separadamente
A referência de protocolo primaryGroupID da Microsoft explica que a pertença primária é omitida de memberOf do objeto e da lista member habitual do grupo. A documentação de Get-ADComputer também mostra PrimaryGroup e primaryGroupID na sua saída de computadores.
Leia novamente um computador verificado e resolva de forma independente o DN do seu grupo primário:
$machine = Get-ADComputer -Identity "CN=APP01,OU=Servers,DC=corp,DC=example" -Server "dc01.corp.example" -Properties PrimaryGroup,primaryGroupID,memberOf,adminCount,nTSecurityDescriptor
Get-ADGroup -Identity $machine.PrimaryGroup -Server "dc01.corp.example" -Properties memberOf,groupType
Execute a segunda leitura apenas quando PrimaryGroup tiver sido resolvido com sucesso. Se apenas o RID estiver disponível, construa o SID do grupo primário a partir do SID verificado do domínio da conta e desse RID; depois resolva o SID completo. Não substitua pelo SID completo do computador nem pressuponha um grupo primário esperado com base na função da máquina. Analise também os caminhos dos grupos superiores do próprio grupo primário. Evidências em falta ou contraditórias mantêm o caso indeterminado.
Passo 4 — Examinar as permissões do objeto e do objeto superior
Preserve o descritor de segurança e analise a herança, a propriedade e as ACEs explícitas. Compare o objeto com a sua função prevista e com o estado de referência do objeto superior. A proteção de permissões pode ser legítima; inversamente, um marcador familiar não explica uma concessão explícita suspeita.
A referência de Dsacls da Microsoft documenta a apresentação da ACL e a utilização de /A para acrescentar informações de propriedade e auditoria. Estas são operações de leitura separadas:
dsacls "\\dc01.corp.example\CN=APP01,OU=Servers,DC=corp,DC=example" /A
dsacls "\\dc01.corp.example\OU=Servers,DC=corp,DC=example" /A
Uma falha de acesso significa que a evidência solicitada não está disponível. Uma captura de texto é um artefacto de investigação, não uma garantia de uma cópia de segurança restaurável. Estabeleça o método de restauro aprovado antes de qualquer manutenção posterior da ACL.
A nossa análise de direitos, delegação e grupos perigosos em objetos de computador explica a superfície de ataque mais ampla das máquinas. Essas exposições exigem as suas próprias evidências: adminCount=1 por si só não demonstra nenhuma delas. Mantenha a ACL do objeto, as suas pertenças e quaisquer direitos que detenha noutros locais separados no registo da análise.
Passo 5 — Registar a decisão e validar o resultado pretendido
| Classificação | Evidências necessárias | Próxima ação |
|---|---|---|
| Protegido | Caminho de proteção atual verificado, incluindo uma função legítima de DC/RODC quando aplicável | Preservar a proteção; analisar pertenças inesperadas ou diferenças na ACL |
| Exceção justificada | Responsável identificado, finalidade aprovada, grupos e permissões compreendidos | Documentar a exceção e as condições da sua revisão |
| Resíduo plausível | Nenhum caminho de proteção encontrado na cobertura documentada, com histórico e evidências de ACL que sustentam uma função anterior | Investigar e aprovar separadamente a manutenção específica do objeto |
| Indeterminado | Classe, grupo primário, aninhamento, cobertura de domínios ou ACL por resolver | Concluir as leituras em falta e adiar alterações |
Uma exceção justificada é uma decisão empresarial; não torna um objeto protegido num objeto desprotegido. Resíduo plausível é uma classificação de investigação, não uma autorização para efetuar limpeza. Encaminhe qualquer proposta de alteração de pertença ou de ACL através do responsável pela máquina ou pelo serviço, com o estado de referência capturado e as permissões finais esperadas.
Após a manutenção aprovada, repita as leituras de identidade, pertença e ACL nos servidores registados. Tenha em conta a replicação do diretório e, onde a proteção se aplicar, observe o resultado subsequente do SDProp segundo o agendamento configurado. Registe o sucesso ou a falha e teste o comportamento de administração ou de serviço pretendido. Não limpe repetidamente um marcador para suprimir um resultado sem explicação.
Como a EtcSec deteta esta situação
Na revisão do coletor 9f698083354a1cb7f625df5cb490a515823c3257, a verificação analisada COMPUTER_ADMIN_COUNT percorre as entradas Computer recolhidas, ignora as entradas desativadas e seleciona aquelas cujo booleano AdminCount é verdadeiro. Emite um resultado Info com a contagem selecionada; os detalhes das entidades afetadas só são incluídos quando foram solicitados detalhes e existem candidatos.
O parser LDAP define esse booleano apenas quando o valor devolvido de adminCount é igual a 1. Um valor ausente ou diferente de 1 torna-se falso nessa representação. A verificação não exclui DCs, RODCs ou gMSAs, não resolve a pertença direta, transitiva ou ao grupo primário, nem examina ACLs. Fornece, portanto, candidatos para classificação, em vez de um veredicto de proteção obsoleta ou privilégios perigosos.
O fornecedor de computadores não solicita primaryGroupID nem nTSecurityDescriptor na sua lista predefinida de atributos. A sua ausência nesta recolha não deve ser interpretada como ausência de grupos ou direitos. BaseDN e MaxComputers limitam a população recolhida; um erro de GetComputers interrompe a recolha. O detetor continua a devolver um resultado Info com contagem zero quando não tem candidatos selecionados, pelo que a presença do tipo de resultado, por si só, não é evidência de uma ocorrência.
Reconcilie o âmbito da auditoria e as identidades dos candidatos com as leituras independentes acima. Utilize o registo de classificação para explicar a proteção legítima, escalar os hosts não esclarecidos e preservar a incerteza. Repetir a auditoria permite comparar a lista de candidatos dentro do âmbito com esse registo, mas não substitui a resolução da pertença nem a validação das permissões.
Explore as paginas de identidade que sustentam este tema
