Direitos AD para hostname DNS validado: analisar a ACE

O significado dos direitos AD para hostname DNS validado

Os direitos AD para hostname DNS validado regem uma atualização restrita de dNSHostName num objeto do diretório. Uma ACE que contenha a GUID associada justifica a análise de uma delegação. Antes de a alterar, determine quem recebe a permissão, se a máscara concede realmente a escrita validada, se se aplica ao computador e que operação de aprovisionamento precisa dela.

A Microsoft identifica Validated-DNS-Host-Name pela GUID 72e39547-7b18-11d1-adef-00c04fd8d5cd. A permissão permite um hostname DNS compatível com as restrições de nomenclatura do computador e do domínio. Não estabelece permissão para editar uma zona DNS nem demonstra que alguém tenha redirecionado tráfego.

O resultado útil desta análise é uma decisão registada: uma delegação aprovada, uma concessão comprovadamente desnecessária a remover ou uma questão por resolver sobre recolha ou autorização. Uma lista de GUIDs correspondentes, por si só, não permite tomar essa decisão. Mantenha a identidade do objeto de computador, a ACE e o fluxo de trabalho legítimo associados ao longo de toda a investigação.

Como funciona: escrita validada versus WriteProperty

A semântica de escrita validada do MS-ADTS distingue o acesso normal RIGHT_DS_WRITE_PROPERTY das escritas validadas. O acesso normal de escrita de propriedades permite valores aceites pelo esquema do atributo, sem as verificações adicionais de valores da escrita validada. Uma ACE de escrita validada combina o bit da máscara de acesso RIGHT_DS_WRITE_PROPERTY_EXTENDED com uma GUID identificadora em ObjectType; uma ACE sem GUID ObjectType pode abranger todas as escritas validadas no objeto.

A GUID é também o identificador de esquema do atributo dNSHostName. Por isso, a GUID, por si só, não distingue uma ACE limitada à escrita dessa propriedade de outra limitada à sua operação de escrita validada. Interprete a máscara e o âmbito em conjunto.

Para o percurso validado, o MS-ADTS especifica as restrições de dNSHostName: o objeto deve ser um computador ou servidor, ou uma subclasse; em AD DS, o hostname combina o sAMAccountName atual, sem o cifrão final, com o nome DNS do contexto de nomenclatura do domínio ou um valor permitido de msDS-AllowedDNSSuffixes. O requerente deve possuir o direito de escrita validada. Analise estas entradas de nomenclatura ao avaliar a operação pretendida.

Para a investigação mais abrangente do proprietário e da DACL, consulte a análise da DACL e da propriedade de objetos de computador. Esta análise concentra-se na autorização específica de escrita validada. As transferências de zona DNS e a configuração de atualizações dinâmicas dizem respeito a outra superfície; alterar uma ACE de um objeto de computador não verifica essas definições da zona.

Deteção: recolher o objeto e analisar a ACE completa

Passo 1: Estabelecer os limites da recolha

Comece pelo DN afetado e pela população de computadores pretendida. Registe o controlador de domínio, o momento da recolha, as credenciais utilizadas para a leitura, a base de pesquisa e quaisquer OUs excluídas. Compare a população com o âmbito pretendido pelo administrador. A leitura bem-sucedida de um objeto nada demonstra sobre computadores omitidos do inventário.

Utilize uma estação de administração Windows com o módulo PowerShell ActiveDirectory para ler os objetos. O exemplo seguinte, baseado na documentação, utiliza os parâmetros suportados Identity, Server e Properties de Get-ADObject, com valores ilustrativos a substituir pelos da sua infraestrutura:

Get-ADObject -Identity "CN=APP01,OU=Servers,DC=example,DC=com" -Server "dc01.example.com" -Properties objectClass,sAMAccountName,dNSHostName,nTSecurityDescriptor

Confirme o DN e a classe devolvidos antes de interpretar as permissões. Guarde o descritor para inspeção detalhada, juntamente com os valores da conta e do hostname. Não classifique um descritor indisponível como uma DACL vazia. Registe separadamente as leituras falhadas e repita-as com uma identidade autorizada para a recolha antes de tirar conclusões sobre a cobertura.

Passo 2: Inventariar a ACL

A referência Dsacls da Microsoft documenta a apresentação das ACEs de um objeto fornecendo o seu DN entre aspas, sem opções de alteração. Execute numa linha de comandos Windows elevada, com permissões de leitura do diretório:

dsacls "\\dc01.example.com\CN=APP01,OU=Servers,DC=example,DC=com"

Este é um exemplo de sintaxe adaptado a um DN de computador ilustrativo, não uma verificação executada numa infraestrutura. Inspecione as entradas de permissão completas, utilizando o separador Segurança do objeto para uma análise detalhada do âmbito quando necessário. Registe o SID e a identidade resolvida de cada titular, o tipo de ACE, a máscara de acesso, ObjectType, a origem da herança e a aplicabilidade. Guarde o descritor original em vez de conservar apenas uma apresentação filtrada da GUID.

Passo 3: Resolver a máscara, o titular e a herança

As orientações da Microsoft sobre permissões de associação ao domínio ilustram a ACE de escrita DNS validada com a máscara 0x00000008, denominada ACTRL_DS_SELF, e a GUID do hostname DNS. O nome desta máscara é distinto do titular chamado SELF: uma conta de associação também pode receber o bit de escrita validada. Verifique se o bit relevante está presente na máscara recolhida; uma máscara diferente ou combinada exige a sua própria interpretação.

MS-ADTS Checking Access explica Principal Self, SID S-1-5-10: num objeto de principal de segurança, representa o principal desse objeto e é substituído pelo SID do objeto durante a verificação de acesso. O DC avalia o contexto de segurança do requerente, o acesso pedido e o descritor adequado. Resolver um nome de apresentação ou encontrar uma ACE de permissão não equivale a essa avaliação completa.

Analise os titulares baseados em grupos face à identidade real de associação ou aprovisionamento. Pergunte ao responsável pelo fluxo de trabalho que identidade executa cada passo e que máquinas pode gerir. Não considere um grupo com um nome relacionado com a implementação como prova de que todos os membros precisam de acesso a todos os computadores.

As regras de herança da Microsoft distinguem ACEs herdadas de ACEs apenas para herança. Uma entrada apenas para herança não se aplica ao objeto que a contém. Identifique o contentor de origem e o âmbito de classes de objetos; avalie a entrada tal como aparece no computador de destino, em vez de assumir que uma entrada do objeto pai tem a mesma aplicabilidade em todo o lado.

Passo 4: Separar os elementos esperados, observados e desconhecidos

Utilize esta ficha para cada computador afetado. É um modelo de análise, não um relatório de resultados medidos:

Correção: analisar o fluxo de trabalho e depois alterar a delegação (Remediation)

Passo 1: Preservar o estado inicial e estabelecer a necessidade

Guarde o descritor original e a ficha de análise. Acorde a operação necessária com os responsáveis pelas máquinas e pelo aprovisionamento antes de editar. Separe a criação de uma nova conta de computador da reutilização de uma existente. As orientações da Microsoft sobre associação ao domínio incluem a permissão de escrita DNS validada entre os direitos necessários à identidade de associação quando reutiliza uma conta; a presença desse direito pode, portanto, ser intencional.

Para uma exceção mantida, registe o SID do titular, o direito exato, a população de objetos, a origem da herança, a finalidade, o responsável e a data de revisão. Inclua as evidências que sustentam essa decisão e as questões pendentes. Uma exceção deve explicar por que razão a delegação é necessária nestes computadores, em vez de se limitar a dizer que o scanner já a tinha identificado.

Passo 2: Remover ou restringir a entrada comprovadamente desnecessária

Utilize o separador Segurança do objeto para editar a permissão desnecessária específica. Se for herdada, analise e corrija a delegação de origem com o responsável pela OU, verificando os outros destinatários antes de aplicar a alteração. Preserve as permissões necessárias ao fluxo de trabalho restante e verifique o âmbito da ACE resultante.

A documentação de dsacls /R indica que remove todas as ACEs do titular especificado. Não é adequado para remover apenas o acesso de escrita DNS validada de um titular que precisa de manter outras permissões. Não substitua uma edição de ACE analisada pela remoção integral dos direitos de um titular, nem reponha todo o descritor de segurança do objeto para fazer desaparecer um resultado.

Passo 3: Verificar as permissões e a operação pretendida

Leia novamente o computador e a sua ACL no DC escolhido. Compare o descritor resultante com o estado inicial e documente exatamente que entrada mudou. Confirme que o titular analisado já não possui a autorização efetiva indesejada através de outra entrada aplicável. Para alterações herdadas, obtenha uma amostra da população de destinatários relevante e verifique o limite de classes de objetos pretendido.

Teste o fluxo de associação ou aprovisionamento aprovado num computador de teste representativo, com a identidade efetivamente delegada. Registe que operação foi executada, se teve sucesso e quaisquer erros do diretório. Num membro do domínio, o teste do canal seguro da Microsoft fornece uma verificação funcional adicional, executada localmente numa sessão elevada do Windows PowerShell:

Test-ComputerSecureChannel -Verbose

Este teste verifica a relação do membro com o domínio; não estabelece que o aprovisionamento do hostname funciona nem que a análise da ACL está concluída. A Microsoft alerta que o cmdlet devolve erros falsos positivos em controladores de domínio. Estes comandos foram citados da documentação, não executados numa infraestrutura de cliente.

Como o EtcSec deteta este problema

A verificação do etc-collector ACL_COMPUTER_WRITE_VALIDATED_DNS, analisada no commit 15fc6399c215eabc415c370b762303cfcd7a353a, constrói um conjunto de DNs de computadores recolhidos sem distinguir maiúsculas de minúsculas. Conserva os registos ACLEntry cujo ObjectType é igual a 72e39547-7b18-11d1-adef-00c04fd8d5cd e cujo ObjectDN pertence a esse conjunto. Count representa os computadores afetados distintos; quando é diferente, TotalInstances regista o número de entradas correspondentes.

Detect() não filtra SELF nem outros titulares, não testa a máscara de escrita validada, não avalia a aplicabilidade de entradas apenas para herança nem calcula direitos efetivos. A sua saída é um inventário que serve de ponto de partida para a análise acima. A descrição do detetor menciona DNS spoofing e MITM, mas o predicado implementado não prova nenhum desses resultados.

A recolha também limita a interpretação. O fornecedor LDAP pede OWNER, GROUP e DACL com os sinalizadores de descritor de segurança 0x07, sem a SACL. Ignora erros por objeto e descritores em falta; os erros de rede, pelo contrário, interrompem a chamada principal e podem desencadear uma nova ligação e tentativa. O parser conserva ACEs padrão e de objeto que concedem acesso, preservando a máscara, o estado herdado e InheritOnly, mas exclui ACEs que negam acesso. O detetor não utiliza essas distinções para concluir uma verificação de autorização.

GetComputers e o seu parser fornecem os DNs utilizados para a associação. Um inventário de computadores incompleto deixa o âmbito do detetor incompleto. Um resultado zero significa que não existem entradas correspondentes nos dados fornecidos, não que todos os computadores foram lidos ou que nenhum principal pode modificar o atributo. Entradas amplas de escrita validada sem esta GUID específica também ficam fora do predicado de correspondência. Reconcilie as falhas de recolha e o âmbito antes de aceitar um zero e registe a decisão de autorização separadamente da contagem do scanner.