Que identidade o IIS usa para instanciar objetos COM de páginas ASP?

Question

Recebi a tarefa de portar e mover um aplicativo ASP antigo de um servidor Windows 2003 (x86) para um servidor Windows 2008R2 executando o IIS 7.5

Várias coisas precisaram ser alteradas (principalmente relacionadas ao acesso ao registro), mas me deparei com um problema que não consegui resolver de maneira satisfatória.

O aplicativo faz uso de um objeto COM externo (dll em processo). Ele criará uma instância desse objeto durante a fase de login e armazenará como uma variável de sessão.

Isso costumava funcionar bem e funcionava bem no meu teste, mas quando eu o implantei no primeiro servidor de produção, comecei a ter erros aleatórios "500" quando os usuários tentavam fazer o login. O erro não era consistente, então usei procmon para rastrear a origem do problema e entendi: quando um usuário tenta acessar o site , o processo de trabalho do IIS tenta abrir a DLL que hospeda o objeto COM, mas falha com um erro de acesso negado.

Agora, não entendo isto: o aplicativo da Web usa uma conta de serviço para acessar os recursos locais. Essa conta de serviço tem direitos explícitos no diretório onde essa biblioteca COM está localizada. No entanto, o acesso a esse arquivo ainda é negado.

Eu "consertei" o problema dando a "todos" acesso explícito de leitura e execução na dll e (parece que) resolveu o problema.

Mas eu não sei porque.

O mais estranho é que eu uso uma conta de administrador local para conectar-me à página da Web uma vez (e apenas uma vez) e, em seguida, o problema foi corrigido enquanto o aplicativo não foi reciclado.

Eu apreciaria se alguém pudesse lançar alguma luz sobre esse assunto. Eu posso viver com a correção, mas eu realmente gostaria de entender.

Editar Para esclarecer: o site não está definido para representar o usuário conectado. De fato, o único esquema de autenticação habilitado é "Autenticação Anônima". As configurações básicas, no entanto, estão definidas para usar a conta de serviço.

Editar A identidade relatada pelo procmon durante o acesso negado é "IIS APPPOOL \ (nome do aplicativo)"

    

Answer 1

Acho que você respondeu sua própria pergunta.

Seu aplicativo da Web está configurado para representar um usuário autenticado.

Quando uma solicitação é aceita, o encadeamento que manipula a solicitação recebe o token do usuário autenticado e, em seguida, essa identidade é usada para todas as operações desse encadeamento até que a solicitação seja encerrada.

O objeto COM precisa ser carregado apenas uma vez, e os administradores podem ler basicamente qualquer arquivo, de modo que o primeiro pedido como Admin é capaz de: a) ler o arquivo eb) carregá-lo no espaço de endereço do processo. Isso geralmente não precisa acontecer repetidamente: quando a DLL está na memória, ela está lá.

Se um usuário comum (ou usuário anônimo) autenticar e for representado, ele não teria permissão para abrir o arquivo, e o ProcMon deveria mostrar a você, junto com a identidade que estava sendo usada. (Por padrão: IUSR para solicitações anônimas).

O bit "conta de serviço" que você descreveu soa como uma identidade de processo de trabalho. Eles são usados apenas para iniciar o pool de aplicativos, ler a configuração e, em seguida, ficar por perto fazendo coisas que não estão diretamente relacionadas a uma solicitação *.

* a menos que você use a conta do Pool de aplicativos como a conta de usuário anônimo e a menos que o segmento representando o usuário não possa sair da caixa (ou seja, precisa delegar), caso em que a conta do Pool de aplicativos será ser usado.