Como o IIS autentica clientes de navegador

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

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

Anônimo -Sem logon é necessária e qualquer pessoa tem permissão para acessar os dados protegidos com esse método. O servidor usa um interna na conta (IUSR _ [nome da máquina] por padrão) para controlar as permissões nos arquivos. O navegador não envia as credenciais ou informações do usuário com este tipo de solicitação.

• Navegadores compatíveis: qualquer
• Limitações: nenhum
• Direitos de usuário necessários: A conta de usuário anônimo definida no servidor deve ter permissões "Fazer logon local".
• Tipo de criptografia: nenhum

Básico (texto não criptografado) -O servidor solicita ao usuário para efetuar logon e uma caixa de diálogo é exibida no navegador que permite que o usuário insira as credenciais que são necessários. Essas credenciais devem coincidir com as credenciais de usuário definidas nos arquivos que o usuário está tentando acessar.

• Navegadores compatíveis: qualquer
• Limitações: Não é muito seguro. As senhas são facilmente deciphered.
• Direitos de usuário necessários: A conta de usuário deve ter permissões "Fazer logon local".
• Tipo de criptografia: Codificação de Base 64 (criptografia não é verdade)

Desafio/resposta do Windows NT -O servidor solicita ao usuário para efetuar logon. Se o navegador suporta Windows NT desafio/resposta, ele envia automaticamente as credenciais do usuário se o usuário fizer logon. Se o domínio que o usuário estiver no for diferente do domínio do servidor, ou se o usuário não estiver conectado, aparecerá uma caixa de diálogo solicitando as credenciais para enviar. Windows NT de desafio/resposta usa um algoritmo para gerar um hash com base nas credenciais do usuário e o computador que o usuário está usando. Ele então envia esse hash ao servidor. O navegador não envia a senha do usuário no servidor.

• Navegadores suportados: Internet Explorer versões 3.01 e posteriores
• Limitações: Requer uma conexão ponto a ponto. Normalmente, um circuito está fechado após um erro de "401 não autorizado" da mensagem; No entanto, ao negociar uma seqüência de autenticação de desafio/resposta de Windows NT (que requer várias viagens de ida), o servidor mantém o circuito aberto para a duração da seqüência depois que o cliente tenha indicado que ele usará o desafio/resposta do Windows NT. Alguns outros dispositivos de Internet e proxies CERN impedem isso funcione. Além disso, o desafio/resposta do Windows NT não oferece suporte impersonations de salto duplo (que passada para o servidor IIS, as mesmas credenciais não podem ser passadas para um servidor back-end para autenticação).
• Direitos de usuário necessários: A conta de usuário que está acessando o servidor deve ter permissões de "Acesso a este computador pela rede".
• Tipo de criptografia: O algoritmo de Hash NTLM que também é uuencoded.

Pedidos de precedência:Quando o navegador faz uma solicitação, ele considera sempre a primeira solicitação para ser anônimo. Portanto, ele não envia nenhuma credencial. Se o servidor não aceita anônimo ou se a conta de usuário anônimo definido no servidor não possui permissões para o arquivo solicitado, o servidor IIS responde com uma mensagem de erro "Acesso negado" e envia uma lista dos tipos de autenticação que são suportados por meio de uma das seguintes situações:

• Se Windows NT de desafio/resposta é o único suporte para o método (ou se anônimo falha), em seguida, o navegador deve oferecer 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 "Acesso negado".
• Se Basic é o único suporte para o método (ou se anônimo falha), em seguida, uma caixa de diálogo é exibida no navegador para obter as credenciais e, em seguida, passa essas credenciais para o servidor. Ele tenta enviar essas credenciais até três vezes. Se esses todos falharem, o navegador não está conectado ao servidor.
• Se houver suporte para Basic e o Windows NT de desafio/resposta, o navegador determina qual método é usado. Se o navegador suporta Windows NT desafio/resposta, ele usa esse método e não o retorno para básico. Se não há suporte para Windows NT de desafio/resposta, o navegador usa Basic.

Anotações:

• Quando seu navegador estabelece uma conexão com um site da Web usando a autenticação básica ou NTLM, ele não se voltará para anônimo durante o resto da sessão com o servidor. Se você tentar se conectar a uma página da Web que está marcada para ser anônimo somente depois de autenticar, você será negado. (Isso pode ou não pode permanecer true para o Netscape).
• Quando o Internet Explorer estabeleceu uma conexão com o servidor usando a autenticação básica ou NTLM, ele passa as credenciais para cada solicitação de nova para a duração da sessão.

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

Anônimo -Sem logon é necessária e qualquer pessoa tem permissão para acessar dados protegidos com este método. O servidor usa um interna na conta (IUSR _ [nome da máquina] por padrão) para controlar as permissões nos arquivos. O navegador não envia as credenciais ou informações do usuário com este tipo de solicitação.

• Navegadores compatíveis: qualquer
• Limitações: nenhum
• Direitos de usuário necessários: A conta de usuário anônimo definida no servidor deve ter permissões "Fazer logon local".
• Tipo de criptografia: nenhum

Básico (texto não criptografado) -O servidor solicita ao usuário para efetuar logon e uma caixa de diálogo é exibida no navegador que permite que o usuário insira as credenciais que são necessários. Essas credenciais devem coincidir com as credenciais de usuário definidas nos arquivos que o usuário está tentando acessar.

• Navegadores compatíveis: qualquer
• Limitações: Não é extremamente segura. As senhas são facilmente deciphered.
• Direitos de usuário necessários: Uma conta de usuário deve ter direitos de "Fazer logon local"
• Tipo de criptografia: Codificação de Base 64 (criptografia não é verdade)

Digest -O servidor solicita ao usuário para efetuar logon e também envia um NONCE usado para criptografar a senha. O navegador usa o NONCE para criptografar a senha e enviada para o servidor. Em seguida, o servidor criptografa a sua própria cópia da senha do usuário e compara os dois. Se elas corresponderem, e o usuário tem permissões, o acesso será concedido.

• Navegadores suportados: Internet Explorer 5 e versões posteriores
• Limitações: Não como proteger como integrados. Requer que o servidor para ter acesso a um servidor do Active Directory que esteja configurado para a autenticação Digest.
• Direitos de usuário necessários: Exige que as senhas têm "Salvar senha como texto criptografado"
• Tipo de criptografia: Dependendo NONCE enviada pelo servidor.

Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:FORTEZZA -Para usar a segurança de Fortezza com o IIS 5.0, você precisa ter um arquivo de provedor de serviços de API de criptografia (CSP) apropriado a partir de um provedor de Fortezza como, por exemplo, http://www.spyrus.com.

Integrada do Windows (divididos em duas categorias de sub)
Kerberos -O servidor solicita um usuário faça logon. Se o navegador dá suporte a Kerberos, ocorre o seguinte:

• Autenticação de solicitações do IIS.
• Se o cliente não tiver feito logon um domínio, uma caixa de diálogo é exibida no Internet Explorer solicitando credenciais e, em seguida, contata o KDC para solicitar e receber um tíquete de concessão de tíquete. Ele então envia o tíquete de concessão de tíquete junto com as informações sobre o servidor IIS para o KDC.
• Se o cliente IE já com sucesso logon no domínio e recebeu um tíquete de concessão de tíquete, ele envia esse tíquete junto com informações sobre o servidor IIS para o KDC
• O KDC emite um tíquete de recursos de cliente.
• O cliente passa esse bilhete para o servidor IIS.

Kerberos usa bilhetes gerados em um servidor de concessão de tíquete (KDC) para autenticar. Ele envia esse bilhete para o servidor IIS. O navegador não envia a senha do usuário no servidor.

• Navegadores suportados: Internet Explorer versões 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ônimo definida no servidor deve ter permissões "Fazer logon local".
• Tipo de criptografia: criptografados tíquete.

Desafio/resposta do Windows NT -O servidor solicita ao usuário para efetuar logon. Se o navegador suporta Windows NT desafio/resposta, ele envia automaticamente as credenciais do usuário se o usuário fizer logon. Se o domínio que o usuário estiver no for diferente do domínio do servidor, ou se o usuário não estiver conectado, uma caixa de diálogo é exibida no Internet Explorer solicitando as credenciais para enviar. Windows NT de desafio/resposta usa um algoritmo para gerar um hash com base nas credenciais do usuário e o computador que o usuário está usando. Ele então envia esse hash ao servidor. O navegador não envia a senha do usuário no servidor.

• Navegadores suportados: Internet Explorer versões 3.01 e posteriores.
• Limitações: Requer uma conexão ponto a ponto. Normalmente, um circuito está fechado após um erro de "401 não autorizado" da mensagem; No entanto, ao negociar uma seqüência de autenticação de desafio/resposta de Windows NT (que requer várias viagens de ida), o servidor mantém o circuito aberto para a duração da seqüência depois que o cliente tenha indicado que ele usará o desafio/resposta do Windows NT. Alguns outros dispositivos de Internet e proxies CERN impedem isso funcione. Além disso, Windows NT de desafio/resposta não oferece suporte a impersonations de salto duplo (que significa não que passada para o servidor IIS, as mesmas credenciais podem ser passadas para um servidor back-end para autenticação, por exemplo, quando o IIS usa Windows NT desafio/resposta, ele não pode, em seguida, autenticar o usuário contra um banco de dados de SQL Server em outro computador usando segurança integrada de SQL).
• Direitos de usuário necessários: A conta de usuário que acessa o servidor deve ter permissões de "Acesso a este computador pela rede".
• Tipo de criptografia: O algoritmo de Hash NTLM que também é uuencoded.

Pedidos de precedência:Quando o navegador faz uma solicitação, ele considera sempre a primeira solicitação para ser anônimo. Portanto, ele não envia nenhuma credencial. Se o servidor não aceita anônimo ou se a conta de usuário anônimo definido no servidor não tem permissões para o arquivo solicitado, o servidor IIS responde com uma mensagem de erro "Acesso negado" e envia uma lista dos tipos de autenticação que são suportados por meio de uma das seguintes situações:

• Se integrada do Windows é o único suporte para o método (ou se anônimo falha), em seguida, o navegador deve oferecer suporte a esse método para se comunicar com o servidor. Se isso falhar, o servidor não tente qualquer um dos outros métodos.
• Se Basic é a única suportada método (ou se anônimo falha), em seguida, uma caixa de diálogo aparecerá na obter as credenciais e os transmite para o servidor. Ele tenta enviar as credenciais de até três vezes. Se esses todos falharem, o navegador não se conectar ao servidor.
• Se houver suporte básica e integrada do Windows, o navegador determina qual método é usado. Se o navegador dá suporte a Kerberos ou Windows NT de desafio/resposta, ele usa esse método. Ele não se voltará para Basic. Se não há suporte para Windows NT de desafio/resposta e o Kerberos, o navegador usa básica, Digest ou Fortezza se ele dá suporte para esses. A ordem de precedência aqui é básica, Digest e Fortezza.

Anotações:

• Quando seu navegador estabelece uma conexão com um site da Web usando a autenticação básica ou integrada do Windows, ele não se voltará para anônimo durante o resto da sessão com o servidor. Se você tentar se conectar a uma página da Web que está marcada para ser anônimo somente depois de autenticar, são negadas. (Isso pode ou não pode permanecer true para o Netscape).
• Quando o Internet Explorer estabeleceu uma conexão com o servidor usando um método de autenticação diferente de anônimo, ele passa automaticamente as credenciais para cada nova solicitação durante a duração da sessão.

Para obter mais informações sobre como configurar a autenticação do site da Web do IIS no Windows Server 2003, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:Para obter mais informações sobre problemas que podem ocorrer se um pool de aplicativos do site da Web hospedado no IIS 6.0 recicla durante o processo de autenticação, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft: