ASP MVC Preview 5 e 6 de autenticação do Windows IIS

Question

Eu apenas construiu um Web site básico ASP MVC para implantação em nossa intranet. Ele espera que os usuários para estar no mesmo domínio que a caixa IIS e se você não for um usuário autenticado do Windows, você não deve ter acesso.

Eu apenas implantado este para IIS6 em execução no Server 2003 R2 SP2. O aplicativo web está configurado com a sua própria piscina com a sua própria conta de usuário piscina. As opções IIS de segurança de diretório para o aplicativo web são definidas como "Segurança integrada do Windows" e só o arquivo web.config tem:

<authentication mode="Windows" />

A partir de uma sessão Remote Desktop no servidor IIS6 em si, uma janela do navegador IE7 com êxito pode autenticar e navegar na web app se acessado via http :. // localhost / myapp

No entanto, também a partir do servidor, se acessado via o nome do servidor (ou seja, http: // myserver / myapp ) em seguida, IE7 apresenta um diálogo credenciais que após três tentativas de entrar as credenciais corretas, eventualmente, retorna "Erro de HTTP 401.1 - não autorizado: acesso negado devido a credenciais inválidas".

O mesmo problema ocorre quando uma estação de trabalho navega para o URL do aplicativo web (naturalmente usando o nome do servidor e não "localhost").

O servidor IIS6 é membro do único domínio que temos e não tem firewall habilitado.

Existe algo que eu não conseguiram configurar corretamente para que este trabalho?

Obrigado,

---

Eu tentei as sugestões de Matt Ryan, Graphain, e Mike Dimmick até agora sem sucesso. Acabo construído um laboratório de teste de máquina virtual com um Server 2003 DC e um servidor separado 2003 IIS6 servidor e eu sou capaz de replicar o problema.

Eu estou vendo uma entrada no log de eventos do sistema do servidor IIS6 a primeira vez que eu tento acessar o site através do localhost não-url (ou seja, http: // IIS / myapp ). urls FQDN falhar também.

Fonte: Kerberos, ID de evento: 4
O cliente kerberos recebeu um erro de KRB_AP_ERR_MODIFIED do host do servidor / iis.test.local. O nome de destino usado era HTTP / iis.test.local. Isto indica que a senha usada para criptografar o tíquete de serviço kerberos é diferente do que no servidor de destino. Normalmente, isso é devido ao nome idêntico máquina de contas no domínio de destino (TEST.LOCAL), eo reino cliente.

Answer 1

Depois de uma extensa Googling eu consegui encontrar uma solução no artigo MSDN:
Como criar uma conta de serviço para um aplicativo ASP.NET 2.0

Especificamente a seção Considerações adicionais

que descreve "Criando nomes principais de serviço (SPN) para contas de domínio" usando a ferramenta setspn das ferramentas de suporte do Windows:

setspn -A HTTP / myserver MYDOMAIN \ MyPoolUser
setspn -A HTTP / myserver.fqdn.com MYDOMAIN \ MyPoolUser

Isso resolveu o meu problema em ambos meu laboratório de teste virtual e meu servidor problema original.

Há também uma nota importante no artigo que usando autenticação do Windows com piscina personalizada usuários constrange o nome DNS associado a ser utilizado por apenas que piscina. Ou seja, uma outra piscina com outra identidade teriam de ser associado a um nome DNS diferente.

Answer 2

Parece que o novo recurso de segurança de verificação de auto-retorno do Windows Server 2003 SP1. Pelo que entendi, é projetado para impedir que um tipo específico de ataque de interceptação.

A partir http://support.microsoft.com/kb/896861

Sintomas

Quando você usa o nome de domínio totalmente qualificado (FQDN) ou um cabeçalho de host personalizado para navegar em um site local que está hospedado em um computador que está executando o Microsoft Internet Information Services (IIS) 5.1 ou IIS 6, você pode receber uma mensagem de erro que se assemelha a seguinte: HTTP 401.1 - não autorizado: Falha de logon Este problema ocorre quando o site usa a autenticação integrada e tem um nome que é mapeado para o endereço de auto-retorno local.

Nota Você só receber essa mensagem de erro se você tentar navegar na Web site diretamente no servidor. Se você navega na Web site a partir de um computador cliente, as obras de site da Web como esperado.

Causa

Esse problema ocorre se você instalar o Microsoft Windows XP Service Pack 2 (SP2) ou Microsoft Windows Server 2003 Service Pack 1 (SP1). Windows XP SP2 e Windows Server 2003 SP1 inclui um recurso de segurança de verificação de loopback que é projetado para ajudar a prevenir ataques de reflexão em seu computador. Portanto, a autenticação falha se o FQDN ou o cabeçalho de anfitrião personalizado que você uso não coincidir com o nome do computador local.

Solução

• Método 1: Desactivar a verificação do loopback
• Método 2: Especificar nomes de host

Consulte http://support.microsoft.com/kb/896861 para mais detalhes.

---

Editar - só notei que você disse que estava vendo isso de PCs cliente, bem ... isso é mais incomum. Mas eu ainda ficaria com um teste dessas soluções alternativas, para ver se ele corrigido o problema (e em caso afirmativo, pode indicar um problema com a sua configuração DNS).

Answer 3

Parece-me como se você tiver feito tudo certo.

Eu tenho certeza que você é, mas você tem a certeza que você está usando 'domínio \ utilizador' como a conta de usuário e não apenas 'usuário'?

Answer 4

IE7 só envia as credenciais do Windows (NTLM, Kerberos) se identifica o servidor como estando na Intranet. IE7 também adicionou um recurso de bloqueio da zona Intranet - se você não estiver em um domínio, por padrão não servidores estão na zona da intranet. Isso foi feito para evitar ataques zona de migração.

Para mudar isso, vá em Ferramentas / Opções da Internet, guia Segurança, clique em Intranet local. Você pode então adicionar manualmente os servidores que devem ser tratados como Intranet, clicando no botão Sites, em seguida, Avançado, ou dizer-IE não detectar automaticamente a sua Intranet e selecionando as outras caixas de seleção conforme o caso.

Answer 5

Eu só encontrou o problema oposto - meus autentica local externamente, mas não localmente.

I comparado aos locais que temos de trabalho ea diferença foi que o site que falhou ao autenticar estava usando autenticação do Windows.

No entanto, outros sites que eu trabalho com (este é um servidor dev) tendem a ter autenticação básica.

Não sei por que exatamente, mas este fixa-lo.

No entanto, ao mesmo tempo, eu notei "Default Domain" e "reino" configurações.

Eu sei que é muito improvável, mas poderia estes talvez ajuda em tudo?