Cenário

Cenário

Cenário

O Active Directory tem um processo agendado em segundo plano chamadoSDPropque verifica e aplica periodicamente um descritor de segurança específico (permissões) de determinados grupos (e seus membros) que o AD consideraprotegido. As permissões definidas são derivadas daquelas definidas noAdminSDHolderobjeto no AD.

Para o propósito desta discussão, vamos nos concentrar emAdministradores de domínio.

Veja aqui: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory

E aqui: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#default-security-groups

Citar:

... Se as permissões em qualquer uma das contas e grupos protegidos não corresponderem às permissões no objeto AdminSDHolder, as permissões nas contas e grupos protegidos serão redefinidas para corresponder às do objeto AdminSDHolder do domínio

Avançar,Operadores de contater, por padrão, permissões para gerenciar todos os objetos de usuário/computador/grupo no domínio,exceto para qualquer um dos grupos/membros protegidos, devido a este processo SDProp.

Caso em questão, a tentativa de modificar uma conta de administrador de domínio com um operador de conta leva a umacesso negadoerro.

Problemas

Primeira questão:

Embora eles não possammodificaressas contas protegidas, conforme o processo acima,Operadores de contaPODE, no entanto, exclua-os! Isso não deveria ser possível, pelo meu entendimento deste mecanismo de proteção.

Ao visualizar as permissões da conta de administrador do domínio, os Operadores de Conta não são listados em nenhum lugar. Além disso, executar uma verificação de acesso eficaz para um AO mostra que ele só possuipermissões/propriedades de leitura. Todas as permissões de gravação e exclusão são negadas. Isto é esperado.

Parece que a capacidade de excluir a conta protegida decorre de uma ACL na UO que a contém, por meio da qual o grupo Operadores de conta tem oCriar e excluir objetos de usuáriocerto (somente este objeto), dentro dessa UO.

Caso em questão, se eu editar essa ACE e remover o direito Excluir, o problema mencionado acima desaparecerá e o AO não poderá mais excluir o administrador do domínio.

Segunda edição

Conforme observado acima, as permissões efetivas parecem ocultar o fato de que o AO pode excluir o objeto. Eu realmente não entendo isso.

Perguntas que precisam ser respondidas

  1. Por que a permissão na UO substitui as permissões definidas na conta protegida pelo adminSDHolder? Todo o objetivo deste processo é EVITAR que quaisquer permissões delegadas específicas de qualquer lugar se apliquem às contas protegidas, a fim deprotegereles.

  2. Por que a guia Acesso Efetivo não reflete corretamente que tenho a capacidade de excluir esta conta, de acordo com as permissões da UO?

Responder1

As permissões efetivas parecem esconder o fato de que o AO pode excluir o objeto. Eu realmente não entendo isso.

eu gostei dissoIdentidade Segurapostei tanto sobre esse tópico que resolvi fazer referência e citar as partes relevantes dele no que se refere especificamente à sua pergunta.

Acho que essa é uma boa pergunta que muitas pessoas gostariam de saber, uma vez cientes disso, se o uso de Operadores de Conta é uma prática padrão em seu ambiente de domínio AD - eu certamente nunca tentei excluir uma conta AD de membro Administrador de Domínio com um Operador de Conta, mas Apoiei ambientes no passado onde eles usavam Operadores de Conta onde eu era Administrador de Domínio.

Agora, se olharmos as opções que temos em relação à exclusão de objetos no Active Directory, você deve ter visto que existem três tipos diferentes de exclusão:

  • Excluir (Máscara de acesso DELETE)
  • Excluir filho (máscara de acesso ADS_RIGHT_DS_DELETE_CHILD)
  • Excluir subárvore (máscara de acesso ADS_RIGHT_DS_DELETE_TREE)

E aqui fica interessante. Ao executar uma ação de exclusão, o sistema verifica o descritor de segurança do objeto e de seu objeto pai antes de permitir ou negar a exclusão.

Uma ACE que nega explicitamente o acesso Delete a um usuário não terá efeito se o usuário tiver acesso Delete Child no pai. Da mesma forma, uma ACE que negue o acesso Delete Child no pai poderá ser substituída se o acesso DELETE for permitido no próprio objeto.

Fonte: Controle de acesso e exclusão de objetos

Exemplos de Excluir e Excluir filho:

Exemplo um:

Meu usuário administrador Tony não tem o acesso ACE: Permitir exclusão em um usuário administrador de domínio chamado Hank. Tony ainda poderá excluir a conta se tiver o ACE: Permitir exclusão de usuário filho na UO pai.

Exemplo dois:

Se um acesso ACE explícito: Negar exclusão estiver definido em Hank. Tony ainda poderá excluir a conta se tiver o ACE: Permitir exclusão de usuário filho na UO pai.

E se revertermos: Tony termina em uma ACE: Deny Delete Child User na UO pai, ele ainda poderá excluí-la se tiver Explicit Allow Delete em uma ACE no objeto de usuário.

Então, com isso podemos ver que AdminSDHolder Security Descriptorrealmente não protege os administradores ou grupos aninhados em todos os cenários. Se você olhar novamente para a imagem das permissões efetivas, Tony não tinha direitos sobre o usuário para excluí-la. Mas ele tem o ACE: Permitir Excluir Usuário Filho na UO pai e poderá excluir Hank, que é membro do grupo Administradores de Domínio.

Direitos padrão

Agora, quando falamos sobre os direitos de acesso de exclusão, pode ser uma boa ideia pensar em quem tem esses poderes padrão no Active Directory?Além dos óbvios, como Administradores, Administradores de Domínio, Administradores Corporativos, é claro que também temos os conhecidos Grupo Operadores de conta.

Os Operadores de Conta têm Controle Total padrão explícito nos objetos Usuário, Computador, Grupo e InetOrgPerson. Eles não têm esse acesso explícito concedido no descritor de segurança AdminSDHolder, mas têm uma criação/exclusão explícita de usuário filho, grupo, computador e InetOrgPerson em unidades organizacionais.Se a UO pai dos Administradores de Domínio não tiver o AO Negar Exclusão de Usuários Filhos explícito, será possível excluir usuários Administradores de Domínio.

(Isso pode ser removido do atributo defaultSecurityDescriptor da classe de objeto definida no Schema se você estiver à altura da tarefa)

Outro ângulo é direcionar o aninhamento de grupo, se os usuários forem membros do DA por meio do aninhamento de grupo, basta excluir esse grupo e eles não serão mais DA.

Esses são alguns motivos pelos quais desejo separar a UO Admin como uma UO raiz para minimizar os riscos de delegação incorreta.

Fonte


Recursos de apoio

Responder2

Acho que seu equívoco vem da suposição de que, como os administradores de domínio são um grupo protegido, todos os seus membros também estão protegidos. O que não é o caso. Portanto, AdminSDHolder não se aplica a essas contas.

A documentação nunca afirma isso explicitamente, mas também não afirma que os membros dos administradores de domínio sejam considerados protegidos. Nem afirma que os Operadores de Conta não podem excluir membros do grupo Administradores de Domínio

Referências:

informação relacionada