Compartilhar via

Os aplicativos que usam NetUserGetInfo e APIs semelhantes dependem do acesso de leitura a determinados objetos do AD

  • Artigo

Este artigo discute um problema em que os aplicativos que usam APIs de nível inferior da classe NetUser ou NetGroup gostam NetUserGetInfo ou NetGroupGetInfo falham com o erro ACCESS DENIED.

Número original do KB: 2281774

Resumo

Você tem um aplicativo que usa as APIs de nível inferior da classe NetUser ou NetGroup, como NetUserGetInfo, NetUserSetInfo, NetUserEnum, NetGroupGetInfo, NetGroupSetInfo, , NetGroupEnum, , NetLocalGroupGetInfo, , NetLocalGroupSetInfoe NetLocalGroupEnum. Nesse esquema, as APIs da classe NetUser também são usadas para gerenciar a conta do computador.

As mesmas APIs são usadas quando você invoca o provedor ADSI WINNT.

Essas APIs podem falhar com ACCESS DENIED, embora a conta de chamada tenha permissões suficientes nas contas de destino. O motivo para isso é que a implementação da API do lado do cliente não tem uma relação 1:1 com as APIs RPC do SAM (Gerenciador de Contas de Segurança). O lado do cliente executa verificações e preparações adicionais para essas chamadas que exigem permissões adicionais no Active Directory.

Um aplicativo que usa essas APIs é o serviço de cluster e, no log do serviço de cluster, você verá:

00000a78.000021b8::2010/06/15-00:00:47.911 WARN [RES] Nome <da rede cluster-resource1>: Não foi possível determinar se a conta de computador cluster-resource1 já está desabilitada. Status 5

Outro sintoma desse efeito pode ser registros de auditoria excessivos no log de eventos de segurança de seus DCs para essas chamadas de API e os objetos citados abaixo, se a auditoria de acesso bem-sucedida ou com falha para a conta de chamada estiver habilitada.

Mais informações

A implementação das APIs usa várias chamadas RPC direcionadas ao Controlador de Domínio para configurar a sessão e verificar o domínio. Ele acessa os seguintes objetos com acesso de leitura:

  • Objeto Raiz de Domínio: ele pesquisa o domínio primário do Controlador de Domínio e abre o domínio para leitura, o que, por sua vez, abre o objeto AD para o domínio, como DC=contoso,dc=com.

  • Contêiner interno: esse é o objeto raiz do domínio interno. Ele é aberto quando o chamador deseja verificar sua existência. Portanto, o chamador precisa de acesso de leitura ao contêiner CN=Builtin,DC=contoso,dc=com.

  • Objeto de servidor SAM: esse objeto armazena permissões gerais sobre o acesso e a enumeração gerais da conta SAM. Ele será usado apenas em algumas chamadas. O nome do objeto é cn=server,cn=system,DC=contoso,dc=com.

Na maioria dos domínios do Active Directory, as permissões para esses objetos são concedidas com base na associação em grupos genéricos, como Usuários Autenticados, Todos ou o grupo Acesso Compatível com Pré-Windows 2000. A alteração para acionar o problema pode ter sido que o usuário foi removido do último grupo (talvez junto com Todos, e/ou as permissões nos objetos listados foram removidas em um movimento para proteger as permissões do Active Directory.

As abordagens para resolver o problema são conceder as permissões de leitura necessárias ou alterar o aplicativo para usar LDAP em vez das APIs mais antigas ou do provedor ADSI WINNT. O LDAP não tocará nos objetos acima e também oferecerá suporte às permissões granulares que você pode ter definido no objeto de destino.

Auditoria excessiva

Quando a auditoria estiver habilitada nesses objetos, você verá até três registros de auditoria para os objetos acima para abrir e fechar os objetos, além do acesso real ao objeto de destino. Se os eventos forem registrados excessivamente, faz sentido remover as entradas na ACL de auditoria para que esses tipos de acesso genéricos não sejam mais registrados. O problema é que o objeto Raiz do Domínio e o Contêiner Interno herdam muitos objetos subordinados.

Para resolver isso, você precisa interromper a herança no contêiner interno e redefinir as ACEs herdadas para se aplicarem apenas a esse objeto. Você também precisa tocar nas ACEs no objeto Raiz do Domínio para que as SACEs problemáticas não se apliquem mais ao objeto raiz do domínio. As etapas exatas dependem das configurações reais de SACL que estão em vigor em seu ambiente.