Problemas de autenticação do usuário com o provedor WinNT das Interfaces de Serviço do Active Directory

Este artigo descreve problemas de autenticação do usuário com o provedor WinNT ADSI (Active Directory Service Interfaces).

Aplicável ao: Windows 10 - todas as edições
Número original do KB: 218497

Resumo

O método ADSI OpenDsObject ou a função auxiliar AD Há vários problemas que você deve estar ciente ao usar essa técnica com o provedor WinNT das Interfaces de Serviço do Active Directory.

Mais informações

O provedor WinNT das Interfaces de Serviço do Active Directory usa a função WNetAddConnection2 para fazer uma conexão com \\servername\IPC$ para estabelecer essas credenciais com o servidor remoto. Esse método é útil porque não requer privilégios especiais para clientes NT e funciona no Windows e dá suporte à autenticação em domínios não confiáveis.

Infelizmente, há várias desvantagens inerentes à função WNetAddConnection2 e são as seguintes:

• Se alguma conexão já tiver sido estabelecida com o servidor de destino por qualquer processo em execução no computador cliente, a função WNetAddConnection2 não poderá fazer uma nova conexão com credenciais diferentes daquelas usadas para a conexão existente.

  Se você tentar autenticar uma nova conta, receberá um erro de credenciais conflitantes. Se você tentar autenticar a conta existente, qualquer senha funcionará (válida ou não). Esse é um problema específico quando você está obtendo objetos de um controlador de domínio em que muitos processos do sistema estabelecem conexões com controladores de domínio.

• Se a conta Convidado estiver habilitada no computador de destino, é possível passar um nome de usuário e senha inválidos e criar uma conexão.

• O sistema não faz referência a conexões de contagem, portanto, se qualquer processo, incluindo o processo de cliente das Interfaces de Serviço do Active Directory, excluir a conexão, todos os processos que usam essa conexão deverão ser gravados para restabelecê-la quando descobrirem que ela foi excluída.

Quando você estiver usando o provedor WinNT, recomendamos que você se autentique com o servidor de destino fazendo logon em uma conta de domínio com credenciais apropriadas ou usando a função LogonUser (que requer privilégios elevados) antes de executar o código das Interfaces de Serviço do Active Directory. Também recomendamos que você não use o método OpenDsObject das Interfaces de Serviço do Active Directory para validar as credenciais de um usuário em qualquer domínio confiável para o computador cliente.

Se você estiver tentando validar contas de domínios não confiáveis, use o método OpenDsObject das Interfaces de Serviço do Active Directory, tendo em mente os problemas listados acima e entendendo que você enviará senhas não criptografadas pela rede. Você pode superar essas restrições executando o código de validação como um serviço em pelo menos um servidor em cada conjunto de domínios não confiáveis usando uma conexão SSL (ou HTTPS) para fornecer criptografia. Faça isso usando um arquivo de .asp de validação em um servidor IIS em cada conjunto de domínios não confiáveis e conecte-se a ele por HTTPS usando a autenticação básica.

O método OpenDsObject das Interfaces de Serviço do Active Directory usa as credenciais do usuário conectado para acessar o IIS. O nome de usuário e a senha fornecidos como parâmetros são ignorados. Você vê a seguinte mensagem de erro:

Acesso negado

No entanto, ele funciona depois que o usuário conectado do cliente é adicionado ao grupo Administradores do servidor.

Também funciona se você usar o código de script a seguir.

Set objLogon = CreateObject("LoginAdmin.ImpersonateUser")  
objLogon.Logon "Administrator", "AdminPassword", "Machinename"  
Set oNS = GetObject("IIS:")
Set oRoot = oNS.OpenDSObject("IIS://SERVER/SHARE", "Mordor\administrator", "Gollum", 1)'User credentials are ignored  
objLogon.Logoff
Set objLogon = Nothing