ACLs diferentes em duas OUs com a mesma configuração "proteger objeto da exclusão"

Question

Antecedentes

Depois que eu configurei nosso Active Directory para que a capacidade de mover computadores fosse delegada à equipe de helpdesk, comecei a ouvir relatos de que os computadores ficariam "presos" em UOs específicas. Eles podem mover um computador, mas recebem uma mensagem de "acesso negado" ao tentar remover um computador. O problema é 100% reproduzível e está presente apenas em um pequeno número de UOs em nosso domínio.

As duas OUs têm Protect object from accidental deletion ativado.

O que eu já sei

Inspecionar o ACL usando ldp.exe revela uma pequena, mas importante diferença. Por algum motivo, apenas uma das UOs tem o atributo ACTRL_DS_DELETE_CHILD negado a Everyone .

Ativar e desativar a sinalização Protect object na OU não resolve o problema. Ele modifica a ACL conforme o esperado, mas o sinalizador ACTRL_DS_DELETE_CHILD é completamente inalterado em ambos os casos.

Eu posso usar essa solução para "consertar" uma unidade organizacional específica:

1. Desativar Protect object flag
2. Exclua o Deny ACE associado a todos.
3. Ativar Protect object em
4. Agora a correspondência da ACL.

Pode ser que diferentes versões do Active Directory, ou Remote Server Admin Tools, possam ter um comportamento diferente com a forma como o sinal Protect object é realmente representado em uma OU?

A questão

O que poderia causar essa diferença e o que posso fazer para garantir que ela seja corrigida em todas as OUs no domínio do Active Directory?

Detalhes

O diff unificado é assim:

18c18
<       Ace Mask:  0x00010042
---
>       Ace Mask:  0x00010040
20d19
<           ACTRL_DS_DELETE_CHILD

Comoidentificarunidadesorganizacionaisafetadas

EDIT:EuescreviumscriptdoPowerShellparalocalizarUnidadesorganizacionaisquetêmessesinalizadordefinidonelas.

$Base="OU=MyOU,DC=your,DC=domain,DC=com"
Import-Module ActiveDirectory
Set-Location AD:
Get-ADOrganizationalUnit -SearchBase $Base -filter * |
    ForEach-Object {
        $matches = @(
            (Get-ACL $_.DistinguishedName).access |
            Where-Object {
                $_.IdentityReference -eq "Everyone"
            } |
            Where-Object {
                $_.ActiveDirectoryRights -like "*DeleteChild*"
            }
        )
        if ($matches.length -gt 0) {
            Write-Output $_
        }
    } |
    Format-Table DistinguishedName

    

Answer 1

Explicação

Quando você ativa o sinalizador Protect object from accidental deletion em uma unidade organizacional, isso afeta a ACL desse objeto e seu pai .

1. A unidade organizacional protegida recebe {Deny, Everyone, Delete + DeleteSubtree}
2. A OU pai recebe {Deny, Everyone, DeleteChildObjects}

A entrada de controle de acesso no pai é necessária para impor proteção, mas tem resultados inesperados como o observado aqui. E não importa quantas vezes você alterna o sinalizador protect , a entrada de controle de acesso Negar no pai nunca será removida automaticamente.

Assim, no Active Directory com o qual eu estava trabalhando, qualquer UO que já contivesse uma UO protegida (basicamente qualquer UO não-folha) tinha a ACE DeleteChild Deny , portanto, "trapping" objetos de computador nessa UO na perspectiva de usuários com permissões delegadas.

Via: Protege o objeto da exclusão acidental nos fóruns da Technet

Solução

Isso pode ser facilmente resolvido garantindo que a UO base usada para delegar permissões tenha essas duas entradas de controle de acesso na ACL.

1. {Permitir, GROUP, Criar / excluir objetos de computador, este objeto e todos os descendentes} *
2. {Permitir, Agrupar, Excluir + Excluir subtribo, Objetos de computador descendente}

Eu já havia configurado a primeira entrada de controle de acesso na UO relevante em meu diretório, mas agora sei que isso era insuficiente. A primeira regra é cancelada pela configuração automática da ACE negar sempre que uma OU protegida é criada. A segunda regra permite que um objeto seja excluído diretamente, ignorando, assim, a entrada negar configurada quando uma OU filha é protegida.

* ( É possível que a primeira regra seja redundante. Alguém pode confirmar?)