Grupo de acesso pré-Windows 2000 Active Directory

O que é o grupo de acesso pré-Windows 2000 no Active Directory?

O grupo de acesso pré-Windows 2000 no Active Directory, cujo nome é Pre-Windows 2000 Compatible Access, pode conceder acesso amplo de leitura ao diretório, mas os atributos que um chamador pode ler dependem das ACEs do objeto. “Leitura em todo o diretório” não significa que todos os segredos sejam legíveis, e a associação ao grupo não garante enumeração LDAP anónima. A Microsoft documenta tanto as verificações de acesso aos objetos como uma restrição LDAP separada. Requisitos de acesso para gestão de rede, restrições de LDAP anónimo.

Pre-Windows 2000 Compatible Access é o grupo de segurança incorporado identificado por S-1-5-32-554, situado em CN=Builtin no domínio. A Microsoft descreve-o como um mecanismo de compatibilidade para clientes Windows NT 4.0 e anteriores, com acesso de leitura a informações de utilizadores e grupos. Não é protegido por AdminSDHolder, e a tabela de grupos da Microsoft indica que não pode ser movido para fora do seu contentor predefinido. Reveja os seus membros em vez de eliminar ou deslocar o grupo. Grupos de segurança do Active Directory.

Uma investigação útil responde a quatro perguntas: que principais de segurança são membros, que permissões recebem, que interface aceita os seus pedidos e que aplicações ainda precisam dessas leituras? Mantenha essas respostas separadas no registo da alteração. A contagem de membros fornece a primeira pista; não resolve as outras três questões.

Defina os critérios de sucesso da revisão antes de alterar o acesso. Para um caminho anónimo desnecessário, o resultado pretendido é uma redução documentada desse caminho, mantendo em funcionamento as funções autenticadas necessárias. Para uma conta de serviço, pode ser a substituição de permissões amplas de compatibilidade por acesso verificado aos atributos que realmente pede. Para uma dependência por resolver, o resultado pode ser uma exceção com um responsável e um plano de testes. Estes são resultados operacionais propostos, não observações sobre o seu domínio nem uma afirmação de que qualquer associação ao grupo é explorável.

A associação inicial depende da criação do domínio

A especificação do protocolo relaciona os membros iniciais com o sistema operativo do primeiro controlador de domínio e o modo de permissões selecionado pelo administrador. Documenta estes casos. MS-ADTS 6.1.1.4.12.14.

“Everyone é sempre a predefinição” perde esta distinção. A orientação da Microsoft sobre acesso de aplicações também explica que adicionar um DC Windows Server 2003 a um domínio Windows 2000 existente não altera a seleção de compatibilidade anterior. Um domínio atualizado pode, portanto, manter uma escolha antiga. KB331951: aplicações e informações de autorização.

Use este histórico para interpretar uma referência inicial, não para aprovar todos os membros atuais. Uma predefinição histórica pode já não responder a uma necessidade de negócio, enquanto uma adição posterior pode suportar uma aplicação. A lista atual não revela quem adicionou uma entrada nem porquê. Registe “origem desconhecida” quando os registos de implementação e os históricos de alterações conservados não responderem a essa pergunta.

Como funciona: membros, ACEs e restrições de protocolo

Everyone, por si só, não é Anonymous

Os requisitos NetAPI da Microsoft exigem explicitamente a associação de Anonymous para acesso anónimo às informações de grupos: o token anónimo normal não inclui o SID de Everyone. O comportamento do Windows 2000 e a configuração EveryoneIncludesAnonymous=1 são exceções documentadas na mesma página. Num sistema moderno com o comportamento normal dos tokens, Everyone, por si só, não equivale a Anonymous Logon. A associação explícita de Anonymous fornece um caminho de autorização, sujeito às restantes restrições da interface. Requisitos de acesso para gestão de rede.

O acesso de leitura e a enumeração têm condições próprias. NetQueryDisplayInformation devolve informações que o chamador pode ler; exige List Contents no objeto Domain e Enumerate Entire SAM Domain no objeto SAM Server do contentor System. É um caminho concreto de permissões a investigar, não uma promessa de que qualquer cliente de rede possa listar todos os objetos. NetQueryDisplayInformation.

LDAP tem uma restrição separada

O Windows Server 2003 introduziu um bloqueio predefinido de operações LDAP anónimas para além dos binds e das pesquisas rootDSE. O sétimo caráter de dsHeuristics, definido como 2, desativa esse bloqueio; as operações continuam a precisar de permissão na ACL. Adicionar Anonymous a este grupo não altera esse atributo. Inversamente, verificar a restrição LDAP não demonstra a segurança de outra interface de enumeração. KB326690: operações LDAP anónimas.

Para esse mecanismo separado, leia acesso LDAP anónimo e a restrição dsHeuristics. O tema desse artigo é a configuração LDAP e a verificação de binds e pesquisas. Aqui, o tema é o caminho de autorização do grupo de compatibilidade. Use o artigo associado para investigar essa restrição, validando as decisões técnicas com a documentação da Microsoft.

De onde vêm as permissões de leitura herdadas

O descritor de segurança predefinido de Domain-DNS publicado contém permissões para RU. A referência de cadeias SID da Microsoft define RU como o alias de Pre-Windows 2000 Compatible Access. Este excerto pertence à secção Windows 2000 Server da página. Mostra permissões ao nível da raiz e permissões herdáveis; compare a versão adequada e a DACL real do seu domínio antes de se basear nele. Classe Domain-DNS, cadeias SID.

(A;CI;LC;;;RU)
(A;;RC;;;RU)
(OA;CIIO;RPLCLORC;;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RPLCLORC;;bf967a9c-0de6-11d0-a285-00aa003049e2;RU)

Em SDDL, A e OA são formas de ACE de permissão; CI indica herança de contentor e IO apenas herança. RP significa Read Property, LC List Children, LO List Object e RC Read Control. A máscara de direitos e os indicadores de herança são campos separados, pelo que uma entrada herdada específica de objeto não deve ser interpretada como uma permissão irrestrita na própria raiz. Cadeias ACE.

Os dois GUIDs de classes herdadas identificam User e Group. Computer é uma subclasse de User: inclua computadores na revisão, sem inventar neste excerto uma ACE separada dirigida a Computer. As referências das classes publicam descritores predefinidos por versão; a entrada User mais antiga não prova que todos os utilizadores atuais tenham uma DACL idêntica. Classe User, classe Group, classe Computer.

O descritor Domain-DNS completo também inclui ACEs de leitura de conjuntos de propriedades de User. A referência Sam-Server mostra separadamente uma entrada RU com RPLCLORC. Estas predefinições explicam caminhos a medir; não substituem a inspeção da herança, das entradas explícitas e dos objetos protegidos de um domínio real. Descritor Domain-DNS, classe Sam-Server.

Medir o grupo real e as permissões de leitura

Os exemplos abaixo adaptam parâmetros documentados de cmdlets e a sintaxe de dsacls. Não foram executados contra um domínio. Substitua o servidor fictício e os nomes distintos por valores resolvidos no seu ambiente. Execute-os a partir de uma estação administrativa adequada, com as ferramentas e permissões de leitura necessárias. Conserve separadamente os resultados e os erros de cada comando, para que uma consulta falhada não pareça um resultado sem problemas.

Passo 1: Registar os membros diretos

Comece pelo nome inglês habitual, quando existir. Este exemplo adapta os parâmetros documentados Identity e Server do cmdlet de associação a grupos. Get-ADGroupMember.

Get-ADGroupMember -Identity "Pre-Windows 2000 Compatible Access" -Server "dc01.contoso.com"

Identifique depois o grupo incorporado pelo seu SID estável e peça a propriedade member em bruto. O exemplo de Get-ADGroup da Microsoft usa este padrão com outro SID incorporado; esta adaptação substitui-o pelo SID 554. Get-ADGroup.

Get-ADGroup -Identity "S-1-5-32-554" -Properties member -Server "dc01.contoso.com"

Use essa identidade também para a vista dos membros diretos. O cmdlet aceita um SID em Identity. Opções de identidade de Get-ADGroupMember.

Get-ADGroupMember -Identity "S-1-5-32-554" -Server "dc01.contoso.com"

Compare os membros resolvidos com as referências em bruto, especialmente quando falhar a resolução de identidades especiais ou de principais de segurança externos. Registe o DN e o SID do grupo, o DC contactado e a identidade de cada membro. Um erro de resolução não significa que o grupo esteja vazio. Investigue o objeto referenciado antes de concluir ou preparar uma remoção.

Conserve esta vista direta para comparar com a contagem de membros do collector. -Recursive responde a outra pergunta: o cmdlet percorre a hierarquia do grupo para devolver membros sem objetos subordinados. Uma revisão recursiva registada separadamente pode ajudar a investigar principais aninhados, mas não deve substituir silenciosamente a referência direta. Comportamento recursivo de Get-ADGroupMember.

No registo de evidências proposto, identifique explicitamente consultas bem-sucedidas, consultas falhadas e referências não resolvidas. Preserve os valores originais em bruto junto das suas anotações. Isso permite rever uma comparação posterior: um nome apresentado que desaparece pode resultar de uma diferença de resolução, enquanto uma alteração no valor bruto de associação merece investigação. Evite que um relatório convenientemente formatado se torne a única evidência conservada, sobretudo quando outro revisor precisar de reproduzir a decisão.

Passo 2: Inspecionar a raiz e descendentes representativos

Com o DN de um objeto e sem opções de alteração, dsacls apresenta as ACEs do objeto. A ferramenta também pode alterar permissões, pelo que deve conservar a forma de leitura mostrada aqui. A referência da Microsoft exige uma linha de comandos elevada e permissão de leitura no objeto de destino. Estes quatro comandos são adaptações com objetos fictícios. Referência de Dsacls.

dsacls "DC=contoso,DC=com"

dsacls "CN=Alice,OU=Users,DC=contoso,DC=com"

dsacls "CN=AppReaders,OU=Groups,DC=contoso,DC=com"

dsacls "CN=PC01,OU=Computers,DC=contoso,DC=com"

Para cada amostra, registe o principal a que a ACE se aplica, o tipo de permissão ou negação, os direitos, a herança, o âmbito de classe e o âmbito de conjunto de propriedades. Identifique entradas do SID 554 mesmo quando o nome apresentado esteja localizado. Inclua objetos usados pelas aplicações em revisão e exemplos com diferentes configurações de herança. Um único objeto de utilizador comum é uma amostra, não um resultado de acesso efetivo para todo o domínio.

A distinção é relevante para a escrita diferida de palavras-passe: a Microsoft documenta permissões necessárias na raiz e permissões herdadas nos descendentes, pedindo depois aos administradores que inspecionem as permissões efetivas da conta do conector. Ler uma DACL e testar uma operação de um chamador respondem a perguntas diferentes. Use ambos ao validar uma dependência. Permissões de escrita diferida de palavras-passe.

Passo 3: Criar um registo de dependências

Para cada principal mantido, proponha um registo com o responsável, a aplicação e versão, a identidade chamadora, os atributos pedidos, o protocolo, os objetos de destino e o teste funcional. Inclua a falha que justificaria a reversão. Um nome de conta parecido com um produto é uma pista para investigação, não uma prova de uma ação do instalador.

Esta revisão também difere de Everyone e Authenticated Users em grupos AD privilegiados. Esse artigo analisa identidades abrangentes colocadas diretamente em grupos privilegiados e associações privilegiadas permanentes. Aqui, a função documentada do grupo é autorizar leitura para compatibilidade; não transforme a sua contagem de membros numa afirmação de associação administrativa direta.

Deteção: estabelecer o estado e monitorizar alterações de membros

Combine o inventário baseado em SID com um histórico de alterações. A documentação de eventos de Segurança da Microsoft coloca 4732 e 4733 em Audit Security Group Management, com um evento por membro adicionado ou removido. Podem ser gerados em controladores de domínio, servidores membros e estações de trabalho; selecione os registos dos DCs relevantes para o grupo do domínio. Evento 4732, evento 4733.

Uma regra de monitorização proposta deve comparar TargetSid com S-1-5-32-554, conservar MemberSid e os campos do sujeito, e comparar as alterações com trabalhos aprovados. Comparar SIDs evita depender de um nome de grupo traduzido. Teste o mapeamento dos campos na sua cadeia de recolha antes de considerar que a regra fornece cobertura. Os nomes dos campos vêm dos exemplos XML dos eventos; esta regra é uma proposta operacional, não uma deteção SIEM implementada. Campos do evento 4732.

Estes eventos registam alterações de membros. Não mostram que atributos foram lidos, não descobrem todas as dependências de aplicações nem confirmam enumeração anónima bem-sucedida. A ausência de eventos é inconclusiva sem uma política de auditoria, recolha e retenção funcionais. Combine os registos com o estado guardado e testes funcionais autorizados, em vez de tratar qualquer um deles como uma avaliação completa do acesso.

Remediação: remover acesso desnecessário por etapas (Remediation)

Este é um processo de alteração proposto com base nos mecanismos documentados, não uma instrução universal da Microsoft para esvaziar o grupo. Conserve o estado anterior, teste dependências e altere membros selecionados. A associação é uma alteração de um grupo do domínio: chamar-lhe “piloto numa OU” não limita a uma OU o efeito de remover um membro.

Passo 1: Separar predefinições históricas de desvios posteriores

Use o inventário de SIDs e os valores member em bruto acima. Compare-os com os registos disponíveis de criação e atualização e classifique as entradas como predefinições explicadas, adições de aplicações documentadas ou associações sem explicação. Aplique a mesma revisão de necessidade atual a cada categoria. A tabela de membros iniciais explica a origem; não dispensa a revisão. Especificação de membros MS-ADTS.

Passo 2: Resolver dependências documentadas antes de remover

As fontes seguintes apresentam dependências específicas e alternativas a investigar. Preserve os seus limites em vez de os alargar a todas as implementações de acesso remoto ou sincronização.

Fontes: resolução de problemas de VPN NT4, registar um NPS, acesso a TGGAU, permissões de escrita diferida de palavras-passe.

O registo do NPS não prova uma necessidade de Anonymous. Para TGGAU, a alternativa Windows Authorization Access requer a sua própria verificação de permissões: a orientação da Microsoft distingue domínios novos de domínios em modo misto e atualizados, nos quais o grupo não recebeu automaticamente o acesso necessário. Não substitua por um grupo privilegiado apenas para fazer desaparecer um erro de acesso negado. TGGAU e WAA.

A orientação do Entra Connect alerta explicitamente para problemas de escrita diferida quando Authenticated Users está ausente, sobretudo com versões mais antigas. A secção sobre o servidor SAM também distingue permissões diretas de Authenticated Users de acesso através deste grupo. Esta dependência documentada impede uma recomendação indiscriminada de remover todas as identidades abrangentes. Resolução de problemas de escrita diferida.

Exchange permanece aqui sem prova como origem automática de membros. O Apêndice B diz que instalar Exchange pode criar contas e grupos adicionais em Builtin e Users; não demonstra adições automáticas ao SID 554 nem versões afetadas. Trate entradas com nomes de Exchange e appliances como questões que exigem evidências específicas do produto e testes funcionais. Apêndice B.

Passo 3: Simular uma remoção selecionada

Dê prioridade à investigação de Anonymous, depois de Everyone com o comportamento real do token, e de contas sem necessidade confirmada. Preserve Authenticated Users até compreender as suas dependências. Escolha o membro exato já resolvido e ensaie num domínio de teste representativo antes de agendar a alteração do domínio de produção.

A adaptação seguinte usa identificadores SID documentados e -WhatIf. Simula a remoção de Anonymous; não é um comando executado para este artigo. Valide primeiro o principal resolvido. Remove-ADGroupMember.

Remove-ADGroupMember -Identity "S-1-5-32-554" -Members "S-1-5-7" -Server "dc01.contoso.com" -WhatIf

Após os testes e a decisão de alteração do administrador, execute apenas a remoção selecionada com confirmação normal. O cmdlet documenta o comportamento de confirmação; evite um ciclo que esvazie o grupo ou suprima a revisão de cada membro. Uma pré-visualização -WhatIf não executa a remoção nem prova que teria sucesso; não pode prever o comportamento das aplicações após uma alteração real. Parâmetros de remoção e confirmação.

Passo 4: Verificar funcionamento, permissões e histórico da alteração

Proponha uma janela de alteração do domínio, um membro de cada vez, com um responsável identificado pela reversão. Volte a ler os membros nos DCs usados pelos serviços afetados após a replicação e repita as operações autorizadas da aplicação no contexto de segurança relevante. A orientação da Microsoft para escrita diferida aborda especificamente os atrasos de replicação e o uso de um DC preferido durante a correção de permissões. Considerações sobre replicação.

Reveja os erros de acesso das aplicações e 4733 para a remoção pretendida; monitorize 4732 para adições, incluindo uma reversão controlada. Se o funcionamento regredir, restaure apenas a associação alterada através do processo de recuperação aprovado e investigue a dependência. Não prescreva uma duração arbitrária de monitorização nem um reinício universal dos DCs: a instrução de reinício do documento de VPN NT4 pertence ao seu cenário histórico específico. 4733, 4732, cenário NT4.

Como a EtcSec deteta esta situação

A verificação PRE_WINDOWS_2000_ACCESS do etc-collector está implementada em ad/groups/membership/pre-windows-2000-access.go:24. A função Detect() revista converte CN e SAMAccountName de cada grupo para minúsculas e seleciona depois o primeiro grupo cujo nome contém pre-windows 2000 compatible access. O seu Count é len(targetGroup.Members): todos os membros recolhidos contam, incluindo Authenticated Users e contas de aplicações. O catálogo revisto classifica-a como Medium, com peso 1.

A função devolve uma constatação mesmo quando não encontra um grupo correspondente ou a contagem é zero. Os detalhes e o grupo afetado só são incluídos quando IncludeDetails está ativo, foi encontrado um grupo e a contagem é positiva. Estas afirmações descrevem a implementação revista, não uma auditoria executada contra o seu domínio.

A verificação não confirma os SIDs do grupo ou dos membros, inspeciona ACEs, lê dsHeuristics, expande associações aninhadas nesta função nem testa o acesso de uma aplicação. A correspondência por uma subcadeia inglesa pode não detetar nomes localizados e pode selecionar um nome correspondente não pretendido; dados de entrada em falta também podem produzir zero. Use as medições baseadas em SID para qualificar o sinal. Uma contagem positiva não prova a associação de Anonymous, e zero não prova que todos os caminhos de leitura estejam restringidos.

COMPUTER_PRE_WINDOWS_2000 está explicitamente fora do âmbito e das etiquetas deste artigo. A sua função Detect(), revista separadamente em ad/computers/other/pre-windows-2000.go:43, compara valores OperatingSystem não vazios com Windows 95|Windows 98, sem distinguir maiúsculas de minúsculas. Não inspeciona os membros nem as permissões deste grupo.

Conclua a revisão com os factos estabelecidos: identidades resolvidas, caminhos ACL inspecionados, restrições de protocolo verificadas, dependências testadas e alterações selecionadas monitorizadas. O detetor de membros ajuda a dar prioridade a esse trabalho; as evidências determinam que acesso pode ser removido em segurança.