Em que conta o ASP (classic) é executado quando a autenticação integrada do Windows está ativada?

Question

Eu tenho um arquivo ASP que está tentando fazer uma solicitação de serviço da Web para um serviço da Web ASP.NET em execução no mesmo servidor no mesmo diretório virtual. No IIS, o diretório virtual é configurado para desabilitar o acesso anônimo e a "autenticação integrada do Windows" é ativada.

Portanto, o problema é que, quando a máquina do usuário solicita a execução da página ASP ou até mesmo executa manualmente o arquivo .NET WebService.asmx, ela funciona porque as credenciais do usuário são repassadas, mas quando o arquivo ASP tenta invocar o serviço da web obtemos um 401.2 - Não autorizado: o acesso é negado devido à configuração do servidor.

Por exemplo:

• "DIRECTORY \ user1" de um navegador na máquina do usuário solicita Service.asmx, que funciona bem.
• "DIRECTORY \ user1" de um navegador na máquina do usuário solicita File1.asp, que funciona bem.

iis iis-6 asp-classic

por wweicker 08.07.2009 / 20:56

Answer 1

O ASP clássico é executado representando o usuário autenticado no servidor na sessão HTTP. Você precisa conceder aos usuários que estão se autenticando para executar a permissão clássica do aplicativo ASP ou permitir acesso anônimo.

Se você já tentou "Usuários autenticados" e não está funcionando, então eu diria que você não está tendo problemas de permissão de arquivo.

O que você quer dizer quando diz "... o arquivo ASP tenta invocar o webservice ..."? Você está dizendo que o script ASP está fazendo uma solicitação HTTP de volta ao servidor? Em caso afirmativo, as credenciais do usuário não serão transmitidas nessa solicitação porque "Autenticação integrada do Windows" não fornece ao servidor uma senha em texto sem formatação para usar ao autenticar em outros servidores (ou em si).

Editar:

Por seu comentário, como declarado acima, o servidor não terá credenciais para autenticar o usuário, pois a autenticação integrada do Windows não fornece ao servidor uma senha em texto sem formatação para passar a outros servidores (ou a ele próprio, que é outro servidor neste caso).

Três coisas que você pode tentar:

• Se você conseguir que o WebService.asmx permita o acesso anônimo, sua chamada HTTP servidor-para-si deverá funcionar (você precisará permitir explicitamente o acesso anônimo permitindo que o IUSR_xxx leia o arquivo e modificando a configuração "Acesso anônimo e controle de autenticação" para "Acesso anônimo" no próprio arquivo por meio do snap-in do console de gerenciamento do IIS, pois esse arquivo herdará as configurações "Autenticação integrada do Windows" ativadas e desativadas "Acesso anônimo" do diretório em que está).

• Se o controle que você está usando para fornecer a solicitação HTTP suportar de forma transparente as credenciais do usuário conectado ao servidor remoto, você poderá habilitar a "Autenticação básica" no script ASP clássico (que fornece a servidor uma senha de texto sem formatação para passar para outros servidores) para que o controle de solicitação HTTP possa passar essa senha de texto sem formatação durante a solicitação para WebService.asmx. Você vai querer exigir SSL no acesso ao script ASP clássico, nesse ponto, para manter as senhas de texto simples fora do fio.

• Por fim, você pode codificar apenas algumas credenciais de autenticação básica no script ASP clássico e habilitar a autenticação básica no arquivo WebService.asmx. Isso significa que o WebService.asmx sempre verá o acesso do mesmo usuário.

Nada disso é uma solução muito boa. Você está correndo para um problema "clássico" que vimos com "ASP clássico" ao tentar autenticar em uma camada de back-end (banco de dados, etc) como o usuário que autenticou para executar o script ASP clássico.

    

Answer 2

Se a autenticação integrada estiver ativada e o usuário estiver usando um navegador que fará autenticação integrada do Windows e , o usuário estará conectado como uma conta que se traduza em um servidor da web (por exemplo, o cliente a máquina está no mesmo domínio que o servidor da Web), o script será executado como a conta desse usuário.

Se qualquer uma das opções acima for falsa (para que o servidor não concorde com uma conta de usuário com o navegador do cliente), o que você definir como usuário anônimo será usado, IUSR_<machine> por padrão ou se anônimo navegação está desabilitada, o usuário receberá um erro 401. *.

Isso pressupõe que outras opiniões de autenticação estão desativadas. Não tenho certeza do que tem precedência se você tiver os esquemas de autenticação integrada e básica do Windows ativados ao mesmo tempo.

Você pode ver o usuário que o servidor da Web está usando no momento para solicitações em uma determinada área, soltando um script que consulta a coleção reqeust.servervariables e produz o (s) valor (es) relevante (s) - o nome de usuário está lá.

    

Answer 3

Parece que você está tentando fazer uma autenticação de "salto duplo". Normalmente, isso ocorre no contexto de um serviço SQL de back-end, mas pode ser aplicado a um serviço separado em execução no mesmo servidor que eu acho (não estou 100% seguro). Procure em MSKB por esse termo, "double hop" e você obterá alguns documentos que explicam como configurar a delegação para permitir que isso funcione. Aqui está uma para começar, link

O que você precisa é que o servidor IIS seja configurado para "Delegação permitida". Quando o usuário é autenticado via Autenticação Integrada do Windows, ele deve receber um tíquete Kerberos (isso NÃO funcionará se você estiver obtendo a autenticação NTLM).

Para fazer a delegação, você precisará adicionar um SPN ao servidor. Verifique se os usuários estão chegando à página da Web com o FQDN real em que o servidor tem um SPN para no AD. O Nome Principal do Serviço (SPN) é o que o agente Kerberos do usuário usará para criar o tíquete Kerberos correto, que permitirá que o servidor IIS represente o usuário quando passar a solicitação para o próximo serviço.

    

Answer 4

É importante que o serviço da Web use as credenciais do usuário conectado? Se você estiver usando algo como MSXML2.ServerXMLHTTPRequest para fazer a chamada para o serviço da Web, basta fornecer credenciais no método .Open para fornecer um conjunto fixo de credenciais ao serviço da Web?