Conta AD sem direito de alterar senha: auditar ACEs Deny

Conta AD sem direito de alterar senha: o que significa a definição?

Ao investigar o problema conta AD sem direito de alterar senha, inspecione a lista de controle de acesso discricionário (DACL) do usuário antes de alterar a política de senhas do domínio. A conta pode ter o direito estendido Change Password negado. Trata-se de uma restrição de acesso à alteração da senha pelo próprio usuário, uma questão diferente de saber se um administrador pode redefinir a senha.

Comece pela conta exata e pela operação que falhou. Registre se a pessoa tentou alterar a própria senha ou pediu a um operador do suporte que definisse uma nova. Uma redefinição administrativa bem-sucedida não demonstra que a alteração pelo próprio usuário é permitida. Da mesma forma, uma falha nessa alteração não identifica, por si só, uma ACE Deny como causa: ainda é necessário ler a DACL.

Este guia examina uma condição específica de permissão, em vez de prescrever uma nova idade ou um novo comprimento de senha. Mantenha separada a análise da política mais ampla: Segurança de senhas no Active Directory aborda políticas de domínio, expiração, definições de contas e armazenamento de credenciais. Alterar esses controles não substitui a identificação das ACEs aplicáveis à conta investigada.

Como funciona: alteração da própria senha e redefinição administrativa

A Microsoft identifica o direito estendido User-Change-Password pelo nome de exibição Change Password e pelo GUID ab721a53-1e2f-11d0-9819-00aa0040529b. As evidências relevantes estão no descritor de segurança do objeto de usuário. Não deduza o estado a partir de um teste comum de bit de userAccountControl: a condição do collector analisada aqui não usa esse atributo.

O procedimento de modificação LDAP da Microsoft descreve uma configuração padrão com ACEs específicas de objeto para dois titulares de segurança: Everyone e SELF. A negação da permissão usa ADS_ACETYPE_ACCESS_DENIED_OBJECT; sua concessão usa o tipo Allow específico de objeto correspondente.

Elemento a registrar	Valor nesta análise	Por que é relevante
Tipo de objeto	`ab721a53-1e2f-11d0-9819-00aa0040529b`	Identifica Change Password, em vez de outra permissão de objeto
Titular Everyone	`S-1-1-0`	Um dos titulares aceitos pelo predicado do collector
Titular SELF	`S-1-5-10`	O outro titular aceito por esse predicado
Direção da ACE	Deny	Uma entrada Allow não satisfaz o detector
Alvo	Nome distinto exato do usuário	Permite associar a evidência à conta correta

Preserve a distinção entre a configuração documentada e a condição do detector. O exemplo de leitura da Microsoft reconhece o estado negado padrão quando as ACEs de ambos os titulares são Deny. O collector usa uma condição OR: uma Deny correspondente para qualquer um dos titulares é suficiente para seu predicado. Registre uma única ACE correspondente como uma condição de um único titular que exige análise; não a descreva como a configuração completa de duas ACEs do exemplo da Microsoft.

A redefinição administrativa de senha é uma questão de permissão separada. O artigo sobre ResetNightmare aborda uma exploração de uma operação de senha Kerberos e sua distinção dos direitos delegados Reset Password. Ele fornece contexto para separar as operações, não evidência de que esta restrição à alteração da própria senha cause essa exploração. Avalie essa exposição separada usando os pré-requisitos e as orientações de correção do artigo vinculado.

Detecção: ler a DACL de forma independente

Etapa 1: escolher uma conta e preservar o contexto

Use o nome distinto da conta, em vez de um nome de exibição presumido. Anote o responsável pela conta, seu estado habilitado ou desabilitado, finalidade de negócio, controlador de domínio consultado e horário da inspeção. Inclua contas desabilitadas no inventário se estiver comparando-o com este predicado do collector: Detect() não tem filtro Disabled. O estado da conta pode afetar a prioridade da correção, mas não deve remover silenciosamente uma entrada da análise de permissões.

Para uma identidade de serviço, identifique quem é responsável pelas alterações de senha antes de classificar a restrição como indesejada. A questão é saber se a restrição é intencional e sustentada por um processo com responsável definido. O rótulo de conta de serviço, por si só, não constitui evidência suficiente para uma exceção.

Etapa 2: obter e filtrar as regras de acesso

O procedimento de leitura LDAP da Microsoft lê ntSecurityDescriptor, obtém sua DACL e examina ObjectType, titular e AceType. Também alerta que os nomes dos titulares são localizados. Compare os SIDs conhecidos, em vez de fixar nomes de contas em inglês no código.

A adaptação PowerShell somente de leitura a seguir usa ADSI por meio de .NET em uma estação Windows de administração. Substitua o controlador de domínio e o DN de exemplo por valores verificados. Ela lê diretamente o descritor de segurança do diretório, fora do parser de ACL do collector. Estes comandos não foram executados em um domínio para este artigo.

Add-Type -AssemblyName System.DirectoryServices
$dc = 'dc01.example.test'
$dn = 'CN=Example User,OU=Users,DC=example,DC=test'
$entry = New-Object -TypeName System.DirectoryServices.DirectoryEntry -ArgumentList "LDAP://$dc/$dn"
$entry.psbase.Options.SecurityMasks = [System.DirectoryServices.SecurityMasks]::Dacl
$descriptor = $entry.psbase.ObjectSecurity
$rules = @($descriptor.GetAccessRules(
    $true, $true, [System.Security.Principal.SecurityIdentifier]
))
$changePassword = [guid]'ab721a53-1e2f-11d0-9819-00aa0040529b'
$matchingDenies = @($rules | Where-Object {
    $_.ObjectType -eq $changePassword -and
    $_.AccessControlType -eq [System.Security.AccessControl.AccessControlType]::Deny -and
    $_.IdentityReference.Value -in @('S-1-1-0', 'S-1-5-10')
})
$matchingDenies | Select-Object IdentityReference, ObjectType,
    AccessControlType, ActiveDirectoryRights, IsInherited,
    InheritanceType, InheritanceFlags, PropagationFlags | Format-List
$entry.psbase.Dispose()

As referências de API documentam ObjectSecurity, SecurityMasks e GetAccessRules. São solicitadas regras explícitas e herdadas, e as identidades dos titulares são devolvidas como SIDs. Mantenha as regras não filtradas disponíveis para uma análise mais ampla da DACL; o filtro seleciona deliberadamente apenas a condição tratada neste artigo.

Se a vinculação ou a obtenção do descritor de segurança falhar, preserve o erro e marque a conta como não inspecionada. Uma DACL ilegível não é uma DACL vazia. Não substitua uma falha de inspeção por um resultado aparentemente bem-sucedido e sem problemas.

Etapa 3: interpretar a estrutura sem exagerar o resultado

Resultado observado	O que registrar	Próxima ação
Everyone e SELF têm entradas Deny específicas de objeto correspondentes	Possível configuração negada com dois titulares	Confirmar o direito control-access e a aplicabilidade das regras, depois analisar a intenção antes de uma alteração direcionada
Apenas um titular tem uma Deny correspondente	Condição de um único titular aceita pelo predicado do detector	Inspecionar a DACL completa; não descartar a condição porque a outra entrada está ausente
Nenhuma Deny correspondente é devolvida após uma leitura bem-sucedida	Esta condição restrita não foi encontrada	Continuar a investigação; não é um veredito completo sobre acesso efetivo ou política de senhas
Não foi possível obter a DACL	Evidência ausente	Resolver a falha de leitura antes de tirar uma conclusão

A saída inclui informações de direitos e herança para que o responsável pela análise possa inspecionar a aplicabilidade. O filtro não testa a máscara de acesso nem a aplicabilidade da herança. Antes de classificar um par como a configuração padrão da Microsoft, compare-o com a máscara ADS_RIGHT_DS_CONTROL_ACCESS e os sinalizadores de ACE do procedimento de modificação. Este é um inventário direcionado de ACEs, não uma implementação completa da verificação de acesso do Windows. Permissões amplas, outros titulares e configurações de ACL não padronizadas exigem avaliação adicional. Não conte duas ACEs correspondentes em uma conta como duas contas afetadas, nem trate leituras diferentes do mesmo DN como identidades diferentes.

Correção: restaurar a alteração da própria senha apenas para contas aprovadas (Remediation)

Etapa 1: documentar a intenção e o estado anterior

Atribua um responsável a cada conta analisada e preserve a evidência da DACL antes de editá-la. Registre se a alteração da própria senha deve estar disponível, quem aprovou a decisão e qual dependência operacional precisa ser verificada. Se uma restrição for mantida, documente seu motivo de negócio, equipe responsável, procedimento de gestão de senhas e momento de revisão. Evite conceder ou remover permissões em uma OU inteira apenas porque um único usuário relatou uma falha.

Analise regras explícitas e herdadas antes de escolher a modificação. Se a restrição vier de uma regra herdada, identifique sua origem e a população afetada. Encaminhe essa decisão de escopo ao responsável pelo diretório, em vez de tratar uma alteração em um nível superior como uma correção de conta individual.

Etapa 2: fazer uma alteração direcionada

A Microsoft documenta CannotChangePassword em Set-ADAccountControl. Seu exemplo descreve a definição do descritor de segurança do usuário. A adaptação a seguir remove a restrição de uma conta aprovada; primeiro visualize a operação com -WhatIf.

Set-ADAccountControl -Identity 'CN=Example User,OU=Users,DC=example,DC=test' -Server 'dc01.example.test' -CannotChangePassword $false -WhatIf

Depois de aprovar o alvo e a alteração, execute a operação de conta individual com confirmação:

Set-ADAccountControl -Identity 'CN=Example User,OU=Users,DC=example,DC=test' -Server 'dc01.example.test' -CannotChangePassword $false -Confirm

Estas são adaptações de comandos documentadas, não comandos executados durante esta análise. Uma prévia não comprova que a gravação posterior foi bem-sucedida. Capture o resultado da operação real e verifique se há erros antes de avançar para a validação.

Para uma implementação LDAP personalizada, siga o procedimento de modificação da Microsoft: localize as entradas Change Password dos dois titulares, altere seu AceType específico de objeto para Allow, adicione entradas ausentes com a máscara control-access e o sinalizador de tipo de objeto documentados, e então grave e confirme o descritor de segurança. Siga a etapa de ordenação da ACL ao criar entradas. Não substitua a DACL inteira por um par mínimo de regras, nem remova permissões não relacionadas para fazer a conta parecer conforme.

Etapa 3: reler e verificar a operação pretendida

Após a gravação, obtenha novamente o descritor de segurança e repita o procedimento de leitura da Microsoft. Compare os dois titulares, o GUID e o AceType com o estado anterior. Mantenha visíveis quaisquer restrições herdadas restantes. Uma resposta de comando bem-sucedida é um artefato intermediário; a DACL após a alteração é a evidência de permissão.

Em seguida, organize uma verificação controlada da alteração da própria senha pelo responsável pela conta, usando o fluxo normal de alteração de senha. Mantenha esse resultado separado do resultado da DACL. Se a operação continuar falhando, investigue o erro real e outros controles aplicáveis, em vez de alterar repetidamente a ACL ou enfraquecer a política de domínio. Uma redefinição pelo suporte não é a etapa de verificação da restauração da alteração da própria senha.

Como o EtcSec detecta esta condição

O identificador de catálogo desta condição é USER_CANNOT_CHANGE_PASSWORD. Na implementação analisada de cannot-change.go, Detect() examina as entradas de ACL fornecidas e seleciona aquelas com:

ObjectType igual ao GUID de Change Password, comparado sem distinguir maiúsculas de minúsculas;
AceType contendo DENIED, após conversão para maiúsculas;
um titular igual a Everyone S-1-1-0 ou SELF S-1-5-10.

Ele converte os DNs dos objetos selecionados para minúsculas em um mapa e depois os compara com os DNs dos usuários. Isso elimina duplicatas das ACEs correspondentes por DN de conta antes de construir a lista de usuários afetados. O Count do achado vem dessa lista, e não há filtro Disabled. Uma ACE Allow não atende ao predicado, e a implementação não lê um sinalizador de userAccountControl para estabelecer essa condição. Ela também não testa a máscara de acesso nem a aplicabilidade da herança; portanto, uma correspondência do predicado, por si só, não é um veredito completo de acesso efetivo.

A fronteira da coleta é a limitação atual. Em public/internal/providers/ldap/acl_parser.go, parseACE() aceita apenas os tipos de ACE ACCESS_ALLOWED e ACCESS_ALLOWED_OBJECT. Outros tipos devolvem nil, incluindo as ACEs Deny necessárias aqui. Um predicado correto sobre entradas fornecidas não estabelece uma detecção funcional pelo caminho de coleta LDAP. Este artigo não reivindica um teste completo do collector nem uma validação em domínio real.

O que guardar no registro da análise

Para cada conta, preserve o DN exato, controlador consultado, horário, SIDs dos titulares correspondentes, ObjectType, direção Deny ou Allow, direitos e contexto de herança. Preserve erros de inspeção em vez de descartar leituras que falharam. Associe os registros anteriores e posteriores à mesma identidade, juntamente com a aprovação da alteração ou o responsável pela exceção.

A decisão de encerramento deve indicar o que foi estabelecido: uma restrição foi mantida com motivo documentado, uma permissão foi alterada e relida de forma independente, ou uma investigação adicional permanece aberta. Registre um resultado funcional de alteração da própria senha apenas quando essa verificação tiver sido realmente realizada. Não transforme esta análise de fontes, um exemplo de comando, uma operação de redefinição ou uma contagem vazia do collector em evidência de rotação de senha bem-sucedida pelo próprio usuário.