As aplicações que utilizam o NetUserGetInfo e APIs semelhantes dependem do acesso de leitura a determinados objetos do AD
Este artigo aborda um problema em que as aplicações que utilizam APIs de nível inferior da classe NetUser ou NetGroup gostam NetUserGetInfo
ou NetGroupGetInfo
falham com o erro ACESSO NEGADO.
Número original da BDC: 2281774
Resumo
Tem uma aplicação que utiliza as APIs de nível inferior da classe NetUser ou NetGroup, como NetUserGetInfo
, NetUserSetInfo
, , NetUserEnum
, NetGroupGetInfo
, NetGroupSetInfo
, NetGroupEnum
, NetLocalGroupGetInfo
, e NetLocalGroupEnum
NetLocalGroupSetInfo
. Neste esquema, as APIs de classe NetUser também são utilizadas para gerir a conta de computador.
As mesmas APIs são utilizadas quando invoca o fornecedor WINNT ADSI.
Estas APIs podem falhar com ACESSO NEGADO, embora a conta de chamada tenha permissões suficientes nas contas de destino. O motivo para tal é que a implementação da API do lado do cliente não tem uma relação 1:1 com as APIs RPC do Gestor de Conta de Segurança (SAM). O lado do cliente efetua verificações adicionais e preparação para estas chamadas que requerem permissões adicionais no Active Directory.
Uma aplicação que utiliza estas APIs é o serviço de cluster e, no registo do serviço de cluster, verá:
00000a78.000021b8::2010/06/15-00:00:47.911 WARN [RES] Network Name <cluster-resource1>: Não foi possível determinar se a conta de computador cluster-resource1 já está desativada. estado 5
Outro sintoma deste efeito pode ser registos de auditoria excessivos no Registo de Eventos de Segurança dos seus DCs para estas chamadas à API e os objetos indicados abaixo, se a auditoria de acesso bem-sucedida ou de falha da conta de chamada estiver ativada.
Mais informações
A implementação das APIs utiliza várias chamadas RPC direcionadas para o Controlador de Domínio, para configurar a sessão e verificar o domínio. Acede aos seguintes objetos com acesso de leitura:
Objeto raiz de domínio: procura o domínio primário do Controlador de Domínio e abre o domínio para leitura, que por sua vez abre o objeto do AD para o domínio, como DC=contoso,dc=com.
Contentor incorporado: este é o objeto raiz do domínio incorporado. É aberto quando o autor da chamada quer verificar a sua existência. Assim, o autor da chamada precisa de acesso de leitura ao contentor CN=Builtin,DC=contoso,dc=com.
Objeto de servidor SAM: este objeto armazena permissões gerais sobre o acesso e a enumeração gerais da conta SAM. Será utilizado apenas em determinadas 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 estes objetos são concedidas com base na associação em grupos genéricos, como Utilizadores Autenticados, Todos ou o grupo acesso compatível com o Pré-Windows 2000. A alteração para acionar o problema pode ter sido o facto de o utilizador ter sido removido do último grupo (talvez juntamente com Todos e/ou as permissões nos objetos listados terem sido removidas 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 a aplicação para utilizar LDAP em vez das APIs mais antigas ou do fornecedor WINNT ADSI. O LDAP não tocará nos objetos acima e também suportará as permissões granulares que pode ter definido no objeto de destino.
Auditoria excessiva
Quando tiver a auditoria ativada nestes objetos, verá até três registos de auditoria para os objetos acima para abrir e fechar os objetos, bem como o acesso real ao objeto de destino. Se os eventos forem registados excessivamente, faz sentido remover as entradas na ACL de Auditoria para que estes tipos de acesso genéricos já não sejam registados. O problema é que o objeto Raiz de Domínio e o Contentor Incorporado herdam muitos objetos subordinados.
Para resolver este problema, tem de interromper a herança no contentor incorporado e redefinir os ACEs que herdam para se aplicarem apenas a este objeto. Também tem de tocar nos ACEs no objeto Raiz do Domínio para que o problema SACEs já não se aplique ao objeto de raiz do domínio. Os passos exatos dependem das definições SACL reais que estão em vigor no seu ambiente.