O IIS autentica clientes do navegador

Artigo
03/22/2024

Este artigo apresenta como o IIS autentica clientes do navegador.

Versão original do produto: Internet Explorer
Número de KB original: 264921

Resumo

Este artigo descreve os diferentes métodos de autenticação que estão disponíveis no IIS para Windows NT 4.0, Windows 2000 e versões posteriores do Windows. Para obter uma descrição mais completa das informações discutidas neste artigo, consulte os guias de recursos do Windows NT 4.0 e windows 2000.

Métodos de autenticação disponíveis para Windows NT 4.0

Anônimo – Nenhum logon é necessário e qualquer pessoa tem permissão para obter acesso a dados protegidos com esse método. O servidor usa uma conta interna (IUSR_[nome do computador] por padrão) para controlar as permissões nos arquivos. O navegador não envia credenciais ou informações do usuário com esse tipo de solicitação.

Navegadores com suporte: Qualquer
Limitações: Nenhuma
Direitos do usuário Necessários: a conta de usuário anônima definida no servidor deve ter logon em Permissões locais .
Tipo de criptografia: nenhum

Básico (Limpar Texto) – O servidor solicita que o usuário faça logon e uma caixa de diálogo é exibida no navegador que permite que o usuário insira as credenciais necessárias. Essas credenciais devem corresponder às credenciais de usuário definidas nos arquivos que o usuário está tentando acessar.

Navegadores com suporte: Qualquer
Limitações: não seguro. As senhas são facilmente decifradas.
Direitos de Usuário Necessários: a conta de usuário deve ter logon em permissões localmente .
Tipo de criptografia: codificação base 64 (não criptografia verdadeira)

Windows NT Desafio/Resposta – O servidor solicita que o usuário faça logon. Se o navegador for compatível com Windows NT Desafio/Resposta, ele enviará automaticamente as credenciais do usuário se o usuário estiver conectado. Se o domínio em que o usuário está for diferente do domínio do servidor ou se o usuário não estiver conectado, uma caixa de diálogo aparecerá para solicitar as credenciais a serem enviadas. Windows NT Challenge/Response usa um algoritmo para gerar um hash com base nas credenciais do usuário e no computador que o usuário está usando. Em seguida, ele envia esse hash para o servidor. O navegador não envia a senha do usuário para o servidor.

Navegadores com suporte: Versões de Explorer da Internet 3.01 e posterior
Limitações: requer conexão ponto a ponto. Normalmente, um circuito é fechado após uma mensagem de erro "401 não autorizada"; no entanto, ao negociar uma sequência de autenticação desafio/resposta Windows NT (que requer várias viagens de ida e volta), o servidor mantém o circuito aberto durante a sequência após o cliente indicar que usará Windows NT Desafio/Resposta. Proxies CERN e determinados outros dispositivos de Internet impedem que isso funcione. Além disso, Windows NT Desafio/Resposta não dá suporte a representações de double-hop (em que uma vez passadas para o servidor IIS, as mesmas credenciais não podem ser passadas para um servidor de back-end para autenticação).
Direitos do usuário Necessários: a conta de usuário que está acessando o servidor deve ter permissões "Acessar este computador da rede".
Tipo de criptografia: algoritmo hash NTLM que também não é codificado.

Ordens de precedência: Quando o navegador faz uma solicitação, ele sempre considera a primeira solicitação anônima. Portanto, ele não envia credenciais. Se o servidor não aceitar Anônimo OU se a conta de usuário Anônima definida no servidor não tiver permissões para o arquivo que está sendo solicitado, o servidor IIS responderá com uma mensagem de erro do Access Negado e enviará uma lista dos tipos de autenticação com suporte usando um dos seguintes cenários:

Se Windows NT Desafio/Resposta for o único método com suporte (ou se o Anonymous falhar), o navegador deverá dar suporte a esse método para se comunicar com o servidor. Caso contrário, ele não pode negociar com o servidor e o usuário recebe uma mensagem de erro do Access Negado .
Se Basic for o único método com suporte (ou se o Anonymous falhar), uma caixa de diálogo será exibida no navegador para obter as credenciais e, em seguida, passará essas credenciais para o servidor. Ele tenta enviar essas credenciais até três vezes. Se tudo isso falhar, o navegador não estará conectado ao servidor.
Se houver suporte para Desafio/Resposta básico e Windows NT, o navegador determinará qual método é usado. Se o navegador for compatível com Windows NT Desafio/Resposta, ele usará esse método e não retornará ao Basic. Se Windows NT Desafio/Resposta não tiver suporte, o navegador usará o Basic.

Observação

Quando o navegador estabelece uma conexão com um site usando Basic ou NTLM autenticação, ele não volta para o Anonymous durante o restante da sessão com o servidor. Se você tentar se conectar a uma página da Web marcada apenas para Anônimo após a autenticação, será negado. (Isso pode ou não ser verdadeiro para o Netscape).
Quando a Internet Explorer estabeleceu uma conexão com o servidor usando Basic ou NTLM autenticando, ela passa as credenciais para cada nova solicitação durante a sessão.

Métodos de autenticação disponíveis para Windows 2000 e superior

Anônimo – nenhum logon é necessário e qualquer pessoa tem permissão para obter acesso aos dados protegidos com esse método. O servidor usa uma conta interna (IUSR_[nome do computador] por padrão) para controlar as permissões nos arquivos. O navegador não envia credenciais ou informações do usuário com esse tipo de solicitação.

Navegadores com suporte: Qualquer
Limitações: Nenhuma
Direitos de Usuário Necessários: a conta de usuário anônima definida no servidor deve ter permissões "logon Localmente".
Tipo de criptografia: nenhum

Navegadores com suporte: Qualquer
Limitações: não seguro. As senhas são facilmente decifradas.
Direitos do usuário Necessários: a conta de usuário deve ter logon nos direitos locais
Tipo de criptografia: codificação base 64 (não criptografia verdadeira)

Digest – O servidor solicita que o usuário faça logon e também envia um NONCE usado para criptografar a senha. O navegador usa o NONCE para criptografar a senha e envia isso para o servidor. O servidor então criptografa sua própria cópia da senha do usuário e compara os dois. Se eles corresponderem e o usuário tiver permissões, o acesso será concedido.

Navegadores com suporte: Versões Explorer 5 e posteriores da Internet
Limitações: não tão seguro quanto Integrado. Exige que o servidor tenha acesso a um Servidor do Active Directory configurado para Autenticação de Digestão.
Direitos do Usuário Necessários: exige que as senhas tenham "Salvar senha como texto limpo criptografado"
Tipo de criptografia: com base no NONCE enviado pelo servidor.

Windows Integrated (dividido em duas subcategorias)

Kerberos – O servidor solicita que um usuário faça logon. Se o navegador for compatível com Kerberos, o seguinte ocorrerá:

Autenticação de solicitações do IIS.
Se o cliente não tiver se conectado a um domínio, uma caixa de diálogo será exibida na Internet Explorer solicitando credenciais e, em seguida, entrará em contato com o KDC para solicitar e receber um tíquete de concessão de tíquete. Em seguida, ele envia o Tíquete de Concessão de Tíquete juntamente com informações sobre o servidor IIS para o KDC.
Se o Cliente IE já tiver feito logon com êxito no domínio e receber um tíquete de concessão de tíquete, ele enviará esse tíquete junto com informações sobre o servidor IIS para o KDC
O KDC emite um Tíquete de Recurso ao cliente.
O Cliente passa esse tíquete para o servidor IIS.

Kerberos usa tíquetes gerados em um KDC (Ticket Granting Server) para autenticar. Ele envia esse tíquete para o servidor IIS. O navegador NÃO envia a senha do usuário para o servidor.

Navegadores com suporte: Versões de Explorer da Internet 5.0 e superior
Limitações: o servidor deve ter acesso a um servidor do Active Directory. O servidor e o cliente devem ter uma conexão confiável com um KDC.
Direitos de Usuário Necessários: a conta de usuário anônima definida no servidor deve ter logon em permissões localmente .
Tipo de criptografia: tíquete criptografado.

Windows NT Desafio/Resposta – O servidor solicita que o usuário faça logon. Se o navegador for compatível com Windows NT Desafio/Resposta, ele enviará automaticamente as credenciais do usuário se o usuário estiver conectado. Se o domínio em que o usuário está for diferente do domínio do servidor ou se o usuário não estiver conectado, uma caixa de diálogo será exibida na Internet Explorer solicitando que as credenciais sejam enviadas. Windows NT Challenge/Response usa um algoritmo para gerar um hash com base nas credenciais do usuário e no computador que o usuário está usando. Em seguida, ele envia esse hash para o servidor. O navegador não envia a senha do usuário para o servidor.

Navegadores com suporte: versões 3.01 e posteriores do Explorer da Internet.
Limitações: requer conexão ponto a ponto. Normalmente, um circuito é fechado após uma mensagem de erro "401 não autorizada"; no entanto, ao negociar uma sequência de autenticação desafio/resposta Windows NT (que requer várias viagens de ida e volta), o servidor mantém o circuito aberto durante a sequência após o cliente indicar que usará Windows NT Desafio/Resposta. Proxies CERN e determinados outros dispositivos de Internet impedem que isso funcione. Além disso, Windows NT Desafio/Resposta não dá suporte a representações de double-hop (o que significa que, uma vez passadas para o servidor IIS, as mesmas credenciais não podem ser passadas para um servidor de back-end para autenticação, por exemplo, quando o IIS usa Windows NT Desafio/Resposta, ele não pode autenticar o usuário em um banco de dados SQL Server em outro computador usando a segurança integrada do SQL).
Direitos do usuário Necessários: a conta de usuário que acessa o servidor deve ter permissões "Acessar este computador da rede".
Tipo de criptografia: algoritmo hash NTLM que também não é codificado.

Ordens de precedência: Quando o navegador faz uma solicitação, ele sempre considera a primeira solicitação anônima. Portanto, ele não envia credenciais. Se o servidor não aceitar Anônimo ou se a conta de usuário Anônima definida no servidor não tiver permissões para o arquivo que está sendo solicitado, o servidor do IIS responderá com uma mensagem de erro do Access Negado e enviará uma lista dos tipos de autenticação com suporte usando um dos seguintes cenários:

Se o Windows Integrated for o único método com suporte (ou se o Anonymous falhar), o navegador deverá dar suporte a esse método para se comunicar com o servidor. Se isso falhar, o servidor não tentará nenhum dos outros métodos.
Se Basic for o único método com suporte (ou se o Anonymous falhar), uma caixa de diálogo será exibida no para obter as credenciais e, em seguida, as passará para o servidor. Ele tenta enviar as credenciais até três vezes. Se tudo isso falhar, o navegador não se conectará ao servidor.
Se houver suporte para o Basic e o Windows Integrated, o navegador determinará qual método é usado. Se o navegador for compatível com Kerberos ou Windows NT Desafio/Resposta, ele usará esse método. Ele não volta ao Basic. Se Windows NT Desafio/Resposta e Kerberos não tiverem suporte, o navegador usará Basic, Digest ou Fortezza se ele der suporte a eles. A ordem de precedência aqui é Basic, Digest e, em seguida, Fortezza.

Observação

Quando o navegador estabelece uma conexão com um site usando a autenticação Básica ou Integrada do Windows, ele não volta para o Anonymous durante o restante da sessão com o servidor. Se você tentar se conectar a uma página da Web marcada apenas para Anônimo após a autenticação, você será negado. (Isso pode ou não ser verdadeiro para o Netscape).
Quando a Internet Explorer estabeleceu uma conexão com o servidor usando um método de autenticação diferente do Anonymous, ele passa automaticamente as credenciais para cada nova solicitação durante a sessão.

Referências

Para obter mais informações sobre como configurar a autenticação do site do IIS no Windows Server 2003, confira Como configurar a autenticação do site do IIS no Windows Server 2003.