Acesso de leitura à propriedade do Active Directory (uSNChanged)

Question

Eu tenho um problema com o acesso de leitura à propriedade uSNChanged ao realizar pesquisas LDAP.

Se eu fizer uma pesquisa LDAP com um usuário que seja membro do grupo Admins. do domínio (UsuárioA), poderei ver a propriedade uSNChanged para cada usuário.

O problema é que, se eu fizer uma pesquisa LDAP com um usuário (UserB) que não seja membro do grupo Admins. do Domínio, posso ver a propriedade uSNChanged para alguns usuários (UserGroupA) e não para alguns usuários (UserGroupB) .

Quando olho para os usuários no UserGroupA e os comparo aos usuários no UserGroupB, vejo uma diferença crucial na guia "Segurança". Os usuários no UserGroupA têm a opção "Incluir permissões herdáveis do pai deste objeto" desmarcada. Os usuários no UserGroupB têm essa opção marcada.

Também percebi que os usuários no UserGroupA são usuários criados anteriormente. Os usuários no UserGroupB são usuários criados recentemente. É difícil quantificar, mas eu estimo que a fronteira entre o tempo de criação entre os usuários em UserGroupA e UserGroupB é de cerca de 6 meses atrás.

O que pode fazer com que a criação do usuário seja padronizada para ter essa propriedade de segurança marcada, em vez de desmarcada? Um tempo atrás (talvez cerca de 6 meses atrás?) Eu mudei o nível funcional do domínio do Windows Server 2003 para o Windows Server 2008 R2. Isso teria tido esse efeito? (Eu não posso exatamente rebaixar o nível funcional do domínio para testá-lo).

Esta propriedade de segurança é realmente a causa do problema com acesso de leitura à propriedade uSNChanged em pesquisas LDAP? Parece correlacionado, mas não tenho certeza sobre causa.

O que eu quero no final é que todos os usuários autenticados tenham acesso de leitura à propriedade uSNChanged para todos os usuários ao fazer uma pesquisa LDAP. Eu também estaria OK se eu pudesse conceder acesso de leitura para essa propriedade a um grupo do AD. Então, posso controlar o acesso adicionando membros ao grupo.

    

Answer 1

Eu não consigo descobrir como comentar a resposta de Craig620, mas ele ofereceu algumas boas informações. Algo que me parece estranho é que você não consegue ler o uSNChanged, que ainda deve ser legível por Usuários Autenticados e pelo grupo Acesso Compatível Anterior ao Windows 2000 (que, por padrão, contém Usuários Autenticados). Esses grupos, por padrão, são marcados por AdminSdHolder com "Read all properties" em objetos protegidos.

Embora pareça ser o oposto da sua situação, eu me deparei com o problema oposto em um ambiente que gerenciei, onde, sem que eu soubesse, os Usuários Autenticados haviam sido removidos do Acesso Compatível com Pré-Windows 2000. Isso teve o efeito de remover a maioria dos usuários da capacidade de ler a maioria das propriedades em contas não protegidas pelo AdminSdHolder, mas eles conseguiram ler essas propriedades em contas protegidas pelo AdminSdHolder. Apenas para estar seguro, você provavelmente deve verificar a associação do Acesso Compatível com Pré-Windows 2000.

Você também pode querer verificar a ACL padrão para usuários recém-criados na floresta. Em vez de reinventar a roda, dê uma olhada no link e verifique a ACL padrão da classe User. Isso é o que determina as permissões de um usuário recém-criado.

De qualquer forma, dê uma olhada e compare as ACLs em objetos "legíveis" e "não-legíveis" procurando por ACEs que a outra não possui.

    

Answer 2

Quando um usuário é adicionado a determinados grupos altamente privilegiados (administradores de domínio, administradores empresariais, administradores de esquema, possivelmente outros, como operadores de contas), o bit de herança para esses usuários é automaticamente desativado pelo sistema operacional. Quando esses usuários são removidos desses grupos, a herança NÃO é reativada pelo sistema operacional, você deve fazer isso manualmente. O UserB já foi membro de um grupo como esse?

P: Esta propriedade de segurança é realmente a causa?
Desconhecido ... quais permissões explícitas estavam em vigor com herança desativada?

Lembre-se de que o uSNChanged não é um atributo replicado. O uSNChanged para o mesmo objeto sempre será diferente em cada controlador de domínio. Consulte o "método 2" aqui link .

Eu não posso imaginar o nível funcional da floresta tendo algo a ver com isso. Suspeito que os perms explícitos não incluíram Usuários Autenticados com propriedades de Leitura permanentes no objeto onde a herança foi desabilitada.

    

Answer 3

Use a delegação do AD. Permite delegar acesso granular a qualquer uma das propriedades de qualquer objeto no AD.

No seu caso, você precisa delegar permissão de leitura ao grupo de segurança ou a usuários específicos que devem ter tais permissões.

Para delegar controle > clique com o botão direito do mouse no grupo de segurança desejado e execute o assistente de controle de delegação > selecione a permissão para delegar (ou escolha personalizado para configurar o seu), adicione usuários / grupos que terão essas permissões para objetos dentro do Grupo de Segurança.

Aqui está um exemplo

Implementação da delegação de administração do Active Directory