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

Question

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

Então o problema é que quando a máquina do usuário solicita a execução da página ASP ou mesmo a execução manual do arquivo WebService.asmx .NET, funciona porque as credenciais do usuário são repassadas, porém quando o arquivo ASP tenta invocar o webservice obtemos um 401.2 - Não autorizado: 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.
• "DIRETÓRIO\usuário1" de um navegador na máquina do usuário solicita o Arquivo1.asp, que funciona bem.
• _________ de dentro do Arquivo1.asp no servidor solicita Service.asmx que retorna 401.2

Então, presumi que precisava definir permissões NTFS em WebService.asmx para permitir permissões de leitura e execução da conta ASP, mas não sei em qual conta ela é executada e, pensando melhor depois de ler algumas das respostas, parece que nós não estiver chegando ao nível NTFS, o IIS rejeitará completamente a solicitação porque o acesso anônimo está desativado.

Isso indica que precisamos executar o processo ASP em uma conta de domínio?

Answer 1

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

Se você já tentou "Usuários autenticados" e não está funcionando, 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? Nesse caso, as credenciais do usuário não serão repassadas nessa solicitação porque a "autenticação integrada do Windows" não fornece ao servidor uma senha em texto simples para usar ao autenticar em outros servidores (ou em si mesmo).

Editar:

De acordo com o seu comentário, então, conforme declarado acima, o servidor não terá credenciais para autenticar o usuário porque a autenticação integrada do Windows não fornece ao servidor nenhuma senha de texto simples para transmitir a outros servidores (ou a si mesmo, que é outro servidor neste caso ).

Três coisas que você pode tentar:

• Se você conseguir que o WebService.asmx permita acesso anônimo, sua chamada HTTP do servidor para si mesmo deverá funcionar (você precisará permitir explicitamente o acesso anônimo, permitindo que IUSR_xxx leia o arquivoemodificando 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, uma vez que esse arquivo herdará as configurações "Autenticação integrada do Windows" habilitada e "Acesso anônimo" desabilitado do diretório em que está).

• Se o controle que você está usando para originar a solicitação HTTP suportar o fornecimento transparente das credenciais do usuário conectado ao servidor remoto, você poderá ativar a "Autenticação básica" no script ASP clássico (que fornece ao servidor uma senha de texto simples para passar para outros servidores) para que seu controle de solicitação HTTP possa transmitir essa senha de texto simples durante a solicitação de WebService.asmx. Você desejará exigir SSL no acesso ao script ASP clássico, nesse ponto, para manter as senhas de texto simples fora da rede.

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

Nenhuma dessas soluções é muito boa. Você está enfrentando um problema "clássico" que vimos com o "ASP clássico" ao tentar autenticar em uma camada de back-end (banco de dados, etc.) como o usuário que se 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á a autenticação integrada do Windowseo usuário está conectado como uma conta que se traduz em um servidor web (por exemplo, a máquina cliente está no mesmo domínio que o servidor web) e seu script será executado como a conta desse usuário.

Se alguma das opções acima for falsa (para que o servidor não possa concordar com uma conta de usuário com o navegador do cliente), então tudo o que você definiu como usuário para anônimo será usado, IUSR_<machine>por padrão, ou se a navegação anônima estiver desabilitada, o usuário irá receba um erro 401.*.

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

Você pode ver o usuário que o servidor web está usando atualmente para solicitações para uma área específica inserindo um script que consulta a coleção reqeust.servervariables e gera os valores relevantes - 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 se aplicar a um serviço separado em execução no mesmo servidor, eu acho (embora não tenha 100% de certeza). Pesquise no MSKB esse termo, "salto duplo" e você obterá alguns documentos que explicam como configurar a delegação para permitir que isso funcione. Aqui está um para começar,http://support.microsoft.com/kb/326985

O que você precisa é que o servidor IIS esteja configurado para “Delegação permitida”. Quando o usuário é autenticado por meio da Autenticação Integrada do Windows, ele deve obter um tíquete Kerberos (isso NÃO funcionará se você estiver obtendo autenticação NTLM).

Para fazer a delegação você precisará adicionar um SPN ao servidor. Certifique-se de que os usuários estejam acessando a página da Web com o FQDN real para o qual o servidor possui um SPN 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á ao servidor IIS personificar o usuário quando transferir a solicitação para o próximo serviço.

Answer 4

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