IIS 7 - erro 401.2 por nome de host, mas não por endereço IP

Question

Estou com um problema com um aplicativo do IIS 7 em nossa rede. O problema é o seguinte:

Se um usuário navegar até o site por endereço IP ( http://172.16.10.32/site ), o aplicativo é carregado corretamente, sem erros, e vale perfeitamente.

Se o mesmo usuário navegar até o site por nome de host ( http://dms-live/site ), uma mensagem "O Internet Explorer não pode exibir a página da Web" será exibida. Procurar resultados mais profundos no código de erro real 401.2 - Não autorizado.

Mais informações:

• Este é um site interno sem acesso externo

• O Internet Explorer é definido pela política de grupo para colocar o site no Zona da Intranet

• O aplicativo permite "Autenticação Anônima" (usando IUSR), "Representação do ASP.NET" (definida como Usuário Autenticado), "Autenticação Básica" (nenhum domínio ou domínio padrão especificado) e "Autenticação do Windows" (com a autenticação do modo do kernel ativada)

• O usuário pode executar o ping dms-live, que retorna o endereço IP correto 172.16.10.32

• O usuário pode navegar até http://172.16.10.32 e http://dms-live sem problemas e vê o padrão do IIS 7 tela

• O nome do host "dms-live" é um registro A adicional especificado no DNS apontando para 172.16.10.32

• O nome do host atual do servidor é "accserver16". Usando isso em lugar de "dms-live" dá exatamente o mesmo resultado (erro 401.2)

• Usar FQDNs em vez dos nomes de host curtos fornece o mesmo resultado bem (erro 401.2)

• O site tem ligações para dms-live, accserver16 e 172.16.10.32, mais os FQDNs associados

• Nossa rede tem dois domínios em duas florestas, domínio A na floresta A e domínio B na floresta B. Todos os usuários e estações de trabalho estão em domínio A, o servidor IIS está no domínio B. Há duas vias confiança configurada entre o domínio A e o domínio B.

• Ambos os domínios têm seus próprios servidores DNS

Esse problema surgiu apenas recentemente, depois que uma única alteração de DNS muito específica foi feita. Originalmente, a zona DNS do domínio B era hospedada pelo servidor DNS do domínio B e uma entrada de encaminhadores condicionais era configurada para encaminhar solicitações dos servidores DNS do domínio A. No interesse da resiliência, isso foi alterado para que os servidores DNS do domínio A tivessem as zonas de Avanço e Reversão secundárias configuradas para as zonas do domínio B.

A zona secundária está carregando bem, replica as alterações corretamente e retorna os registros DNS corretos para solicitações ping e nslookup.

Outra informação estranha - alguns PCs na rede conseguem carregar http://dms-live/site sem problemas. Não parece haver muito de um padrão para o qual os PCs funcionam e quais não funcionam.

Não cabe ao usuário (o mesmo usuário em dois PCs diferentes não necessariamente obterá o mesmo resultado), navegador (isso foi testado com IE8 e IE9 e os resultados não são consistentes) ou Sistema operacional (problema parece ser independente se o Windows XP ou Windows 7 está sendo usado).

Solução de problemas testada até agora:

• Ativando uma única forma de autenticação por vez
• Desativando a autenticação no modo kernel
• Configurando registros SPN para o DMS-LIVE e o FQDN associado
• Limpando o cache do IE entre as tentativas
• Reiniciando os PCs
• Descarregando o cache do DNS com ipconfig / flushdns
• Definir a chave de registro "DisableStrictNameChecking" como 1 e reinicializando o servidor
• Adicionando ACCSERVER16 $ e IIS_IUSRS às permissões NTFS do diretório de aplicativos

Em um PC que não carrega a página, o Fiddler mostra que é feito um único pedido que retorna um erro 401. Em um PC que carrega a página com sucesso, o Fiddler mostra o mesmo erro 401, seguido por um 302, seguido por um 200.

Se as zonas secundárias forem removidas e a entrada dos encaminhadores condicionais for devolvida, o problema desaparece.

Parece que, por algum motivo, ao usar uma Zona Secundária em vez de um Reencaminhador Condicional para resolver um nome de host em uma floresta diferente, a autenticação falha em alguns PCs, mas não em todos - mas por que esse seria o caso. . Alguém pode ajudar?

    

Answer 1

Depois de muita pesquisa, finalmente encontrei a causa do problema.

Nós rastreamos isso depois de notar alguns outros problemas relacionados. Ao tentar navegar para um compartilhamento no accserver16 um usuário seria apresentado com uma caixa de credenciais e a seguinte mensagem de erro:

The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.

O preenchimento das credenciais apropriadas funcionou, mas isso não deveria ter sido necessário.

Além disso, ao tentar validar a confiança no controlador de domínio da floresta B, a seguinte mensagem de erro foi exibida:

The secure channel (SC) reset on Active Directory Domain Controller \accserver04.domainb.local of domain domainb.local to domain domaina.local failed with error: There are currently no logon servers available to service the logon request.

Isso apontou para uma incapacidade de localizar os controladores de domínio na outra floresta como a causa do problema.

Dentro do DNS, na zona de pesquisa direta de cada domínio, existe uma zona de delegação denominada "_msdcs". Isso deve conter registros NS estáticos apontando para os servidores de nomes nesse domínio.

No domínio A e no domínio B, isso foi configurado incorretamente. No domínio A, o único servidor de nomes listado havia sido rebaixado e no domínio B apontava para um servidor que não existia mais na rede.

Aparentemente, isso não causou problemas para consultas DNS internas e não afetou as consultas entre florestas, desde que o encaminhamento condicional estivesse sendo usado. Assim que o encaminhamento condicional foi substituído por zonas secundárias, a confiança entre as florestas caiu em pedaços.

Corrigir os registros do servidor de nomes nas zonas de delegação _msdcs em cada domínio para apontar para os servidores de nomes corretos resolveu o problema.

    

Answer 2

Trabalhei com alguém sobre o mesmo problema aqui: link . Nós ainda não resolvemos completamente e estamos passivamente trabalhando nisso. No caso deles, usar um registro A em vez de um CNAME resolveu (correção temporária), mas como você já está usando um registro A, isso não funcionará para você.

Para você, e se você criar um registro de hosts para o nome de domínio? Isso tirará o AD principalmente da equação. Além disso, tente experimentar com a zona Intranet do IE e também tente visitar outro navegador.

O problema provavelmente está relacionado ao SPN, embora você tenha mencionado que você configurou registros.

E como você mencionou que funciona em alguns computadores, mas não em outros, também examine as configurações do SPN do computador e confie nas configurações.

Eu suponho que a página com falha é protegida por senha? Se não estiver, você poderá definir Autenticação / Anônimo para sempre executar como a identidade do pool de aplicativos. Em seguida, o usuário IIS_IUSRS não será usado e você só precisará testar com o que estiver usando para a identidade do pool de aplicativos.