Não é possível excluir o objeto do Active Directory

Question

Estou tentando resolver esse mistério há alguns dias, mas acho que cheguei a um beco sem saída.

Nós delegamos a criação e administração de usuários a um grupo. Essas permissões são aplicadas a uma unidade organizacional Grandparent e herdadas de uma OU Pai e de uma OU Child, elas incluem tudo, exceto para Controle total e Excluir ( Excluir subárvore é marcado embora).

OsusuáriosdogrupopodemcriaremodificarusuáriosemtodasasOUs.Noentanto,elespodemexcluirsomenteusuáriosdaUOdefilhos(oúltimonível).Seelestentaremexcluirumusuáriodasoutrasunidadesorganizacionais,obterãoumerrodeacessonegado.

Coisasqueeujáverifiquei:

• "Proteger objeto de exclusão acidental" não está marcado.
• Compararam as permissões efetivas usando objetos das diferentes UOs, são idênticas e não incluem a permissão Excluir, mas incluem a permissão Excluir subárvore.
• Exportou as ACLs de usuários das diferentes OUs usando dsacls.exe . Os arquivos são idênticos.

Coisas estranhas que vi até agora:

• Na UO raiz há uma Deny delete explícita (aplicar a objetos de usuários descendentes) . Isso também não deve impedir a exclusão de usuários da UO Criança?

Suponho que isso tenha algo a ver com a permissão Excluir subárvore , mas não encontrei muitas informações sobre isso. Apenas mais um bit, o nível funcional do domínio é 2008 R2, se isso ajudar.

    

Answer 1

Seu problema é a permissão Deny delete explicitamente definida na UO "raiz" (apropriadamente chamada de "avós"), e removê-la deve resolver seus problemas. É difícil seguir as estruturas exatas da UO e quais permissões são explícitas e quais são herdadas da sua descrição (uma imagem vale mais que mil palavras), mas parece-me:

Há um Deny delete explícito na OU raiz / avós. Está funcionando apenas em objetos na raiz e um nível abaixo.

Isso seria porque:

1. O Deny delete aplica-se apenas ao primeiro nível de objetos descendentes (por isso, é herdado pela OU pai, mas não pela OU filha) ou
2. O segundo nível de objetos descendentes (na UO filho) tem uma permissão Allow delete que é de maior precedência.

Para resolver o problema e permitir que seu grupo exclua os objetos que você deseja excluir, remova a permissão Deny delete na UO raiz ou defina-a para aplicar somente ao objeto da UO (não a seus objetos descendentes ).

Aqui está um prático link para informações sobre precedência de permissões no NTFS (que também se aplica às permissões do AD) ):

Aqui estão algumas regras para resolver conflitos de permissões:

1. As permissões "Negar" geralmente têm precedência sobre as permissões "permitir".
2. As permissões aplicadas diretamente a um objeto (permissões explícitas) têm precedência sobre as permissões herdadas de um pai (por exemplo, de um grupo).
3. As permissões herdadas de parentes próximos têm precedência sobre as permissões herdadas de predecessores distantes. Portanto, as permissões herdadas da pasta pai do objeto têm precedência sobre as permissões herdadas da pasta "grandparent" do objeto, e assim por diante.
4. As permissões de grupos de usuários diferentes que estão no mesmo nível (em termos de serem diretamente definidas ou herdadas e em termos de "negar" ou "permitir") são cumulativas. Portanto, se um usuário for um membro de dois grupos, um dos quais tem uma permissão "allow" de "Read" e o outro tem uma "allow" de "Write", o usuário terá permissão de leitura e gravação - dependendo as outras regras acima, é claro.

Embora as permissões Negar geralmente tenham precedência sobre as permissões permitidas, isso nem sempre é o caso. Uma permissão "allow" explícita pode ter precedência sobre uma permissão "negar" herdada.

A hierarquia de precedência para as permissões pode ser resumida da seguinte forma, com as permissões de precedência mais altas listadas no topo da lista:

• Negar explícito
• Permitir explícito
• Inherited Deny
• Herdado Permitir

Também é verdade:

As permissões de arquivo substituem as permissões de pasta, a menos que a permissão Controle Total tenha sido concedida à pasta.